From COREPHP
Os objetivos do teste
1 – Avaliar a capacidade de absorção e compreensão de informação do entrevistado em conversas com solicitantes.
2 – Conhecimentos técnicos básicos sobre modelagem de sistemas.
3 – Conhecimentos técnicos básicos sobre a linguagem de programação e implementação de segurança em sistemas.
Instruções para aplicação
O TESTE DEVE SER PASSADO VERBALMENTE!
Isso ajuda a ver a capacidade de captura e compreensão da pessoa.
PASSAR O TESTE IMPRESSO NÃO AJUDA A AVALIAR O CANDIDATO!
A idéia é deixar a pessoa o mais próximo de uma situação real o possível. Muitas vezes o cliente vai apenas falar o que quer, e você deve elaborar algo a partir de conversas (na vida real, registrará tudo em Atas que devem ser interpretadas posteriormente). Porém, do mesmo jeito que numa situação real, em casos de dúvida ele deve consultar o aplicador do teste de novo. Porém, não fale isso para o candidato, deixe-o que perguntar, tomar a iniciativa para isto, porque se a pessoa não entendeu e sai codificando e modelando, e sequer vai perguntar de novo, então já não é uma pessoa pró-ativa, o que já ajuda a descartar uma pessoa que vai acabar fazendo as coisas de qualquer jeito.
O teste será constituído de 3 partes, todas elas práticas. Se possível, o entrevistador deve se atrasar entre 20 a 30 minutos. Isso também ajuda a verificar o caráter do entrevistado (impaciente? paciente? "estrelinha"?).
Problema a ser passado VERBALMENTE
A empresa XPta Corporation S/A precisa de um sistema para gerenciar suas lojas. Nestas lojas há 3 tipos de profissionais: Administrador do Sistema, Gerente e Vendedor. sendo o nível de acesso inversamente proporcional à lista dada. O Vendedor é o mais básico de todos e a única coisa que ele pode fazer é consultar preços e registrar as vendas, que podem ter mais de um produto. Após uma venda registrada, apenas o Gerente pode alterá-la. O preço de um produto pode variar de venda para venda de acordo com o desconto dado pelo vendedor. Ele pode ainda dar um desconto sobre o valor total da venda. Já o Gerente pode fazer tudo que o Vendedor faz, e é responsável ainda pela manutenção da tabela de produtos. O Administrador acumula as atividades de todos os outros empregados, e é responsável ainda pelo cadastro do acesso dos funcionários do sistema, e auditoria do log das atividades realizadas. O acesso ao sistema é feito através de usuário e senha.
Exposto o problema acima, elaborar:
1 - Diagrama de caso de uso para cada ator identificado
2 - Modelagem de Classes com implementação no Banco de Dados
3 - Implemente o sistema de login e logout em PHP identificando o nível do usuário que se logou no sistema utilizando o banco de dados criado e sessões do PHP.
Resultados esperados
O que esperar do entrevistado:
1 - Pelo menos os diagramas de UC corretamente implementados, ou seja, todos os atores, e seus respectivos casos. Se a pessoa não conseguir fazer o diagrama, já perderá provavelmente 50% do teste, pois o restante depende disso.
2 - Como os papéis são cumulativos, se o entrevistado fizer especialização entre os atores, é um adicional muito bom, pois mostra capacidade de reaproveitamento real de código e conceitos.
3 - Modelagem com pelo menos as classes Usuário, Venda, Produto, com atributo tipo no Usuário, associação 0...* para Venda e 1 para Usuário, e associação 1 para Venda e 1...* para Produto. Se modelar coisas como preço do item na venda, desconto, quantidade de produto, ou seja, criar uma classe associativa entre Venda e Produto também é um adicional muito bom, pois mostra reflexão sobre a questão de temporalidade do registro, além de apego ao que foi solicitado. Porém, é normal a pessoa não perceber isso e deixar passar batido, pois é o tipo de reflexão que vem com a experiência.
4 - Quando clicar em logout, deve realmente fazer logout, ou seja, clicar em "voltar" no navegador deve dar erro ou aviso de que o usuário não está mais logado. Se clicar em voltar e entrar como o usuário que acaba de fazer logout, o entrevistado deve ser advertido para corrigir isso.
Se falhar completamente em qualquer um desses itens, já pode ser descartado. Há muitas pessoas que acreditam que um programador não deve saber análise, ou não é importante a parte documental de um sistema. Essas pessoas são filtradas por este teste.
Há também os casos das pessoas quem passam muito além do que foi solicitado. Não é o perfil ideal, porque a pessoa tem que fazer o que foi pedido, e não começar a expandir demais. Se é contratado um funcionário que se desprende demais da solicitação original, vai se ter um analista/programador que ao invés de gastar o tempo fazendo o que se pede, ficará inventando funcionalidade que não precisa (ou que não atende o que foi pedido, mas a outra coisa qualquer), fazendo com que nunca nada seja entregue dentro do prazo.
Pró-atividade é uma coisa desejada, mas ela deve respeitar hierarquia e solicitações. Pró-atividade não é tomar independência para decisões, mas tomar a iniciativa de realizar uma ação de acordo com o que a gerência especifica ou espera da pessoa. Ou seja, a pró-atividade desejada aqui é a da pessoa que percebe um possível problema ou oportunidade, e consulta as pessoas sobre se deve ou não tomar alguma ação sobre o assunto.
Diagramas "Ideais"
Casos de Uso
Imagem:Casos teste.png
Classes
Imagem:Classes teste.png
