domingo, 26 de outubro de 2008

Como pensa: Desenvolvedores e Testadores de Software

Oi pessoal, segue o primeiro post sobre teste de software. Neste primeiro post eu e a Neilza buscamos mostrar a diferença que existe na forma de pensar do desenvolvedor de software e o analista de teste de software.

Para mostrar esta diferença foi pego um requisito e apresentado aos dois profissionais, analista de teste de software e desenvolvedor de software.

Requisito (em forma de cartão de historia)

Como um aluno desejo calcular a media final da disciplina cursada, de modo que eu possa saber se estou aprovado ou de exame.


Conversas com o Product Owner

2 notas, PR1 e PR2
Media: 7,0
Mínimo: 4,0 para poder fazer exame
Calculo: (PR1 + PR2) / 7,0


Como o desenvolvedor (EU) pensou nas funcionalidades


1) Verificar se PR1 esta com valor null
2) Verificar se PR2 esta com valor null
3) Verificar se PR1 tem valor maior que 10
4) Verificar se PR2 tem valor maior que 10
5) Calcular a media
6) Mostrar mensagem de aprovado, reprovado ou exame


Confesso que após estes itens eu achei que estava podendo hahahahaha

Como o analista de testes pensou nas funcionalidades

1) Primeiro ele montou casos de testes com ênfase em o aluno estar logado
2) Depois o caso de teste já se preocupou em como a funcionalidade vai estar disponível no sistema, com por exemplo um item de menu
3) Fez casos de teste pensando na UI (interface), se preocupando com os campos de apresentação da informação (tamanho, habilitado/desabilitado, ordem de preenchimento, etc)
4) Fez casos de testes pensando nas probabilidades de entrada de dados, PR1 igual a vazio, PR2 igual a vazio, notas maiores que 10, etc. Para cada combinação existiu a preocupação com a apresentação das mensagens ao usuário
5) Fez casos de testes com dados cadastrados no banco de dados, para que o processamento das medias e apresentação das mensagens correspondentes fossem passiveis de ser testadas


O item deste exercício que mais me chamou a atenção foi a quantidade de casos de testes criados para um problema tão simples, como um calculo de media de uma disciplina cursada por um aluno. Eu não coloquei os casos de teste e sim fiz um resumo dos itens que ele tratava.

A lição aprendida que tirei deste exercício é que o desenvolvimento orientado ao comportamento, isto é, o teste idealizado pelo analista de teste faz com que após o termino do desenvolvimento a minha funcionalidade implementada esteja em conformidade com as expectativas criadas pelo analista de testes. Desta forma a minha funcionalidade implementada não terá apontamentos de erros ou itens abertos por falta de analise de sistemas.

Eu já participei de projetos que a quantidade de apontamentos de erros ou falta de comportamento para uma Use Case era muito maior que a quantidade de funcionalidade que o Use Case tinha.

Outra lição aprendida é que a analise de sistemas realizada pelo analista de teste e o desenvolvedor de software faz com que os erros de falta de especificação seja diminuída, pois cada um dos “Papeis” ataca a sua responsabilidade no sistema. Isso fica claro na questão do usuário estar logado e as necessidades de como executar a funcionalidade, por exemplo, um item de menu.

Este item mostra claramente a vantagem das equipes multidisciplinares e ainda a vantagem de toda a equipe estar junta no processo de analise de sistemas.

Um abraço a todos,

Abu e Neilza

Nenhum comentário: