abraços

Viu o kanban que pode pode ser trabalhado com Designers?

http://www.dubaralho.com.br/2009/10/28/kanban-para-design-grafico-e-user-experience-ux-usando-scrum/

Em qualquer projeto de médio porte se torna inviável manter funcionando 100% da interface sem que haja um mecanismo (automático ou não) para tanto.

Posso pelo menos garantir que seus desenvolvedores não usarão o tempo das novas features para testar manualmente as permutações de uso de sua interface antiga. A GUI VAI quebrar e você vai pagar o pato.

Espero que outros desenvolvedores ágeis percebam que os testes de aceitação automatizados são parte inseparável de suas suites de testes, ou teremos clientes muito insatisfeitos no mundo ágil… De que adianta estar tudo “perfeitamente testado” se o botão “Submit” não faz nada?? Ou talvez faça, mas a tela de confirmação não aparece? E ao clicar em voltar ele recebe um erro?

Nós desenvolvedores infelizmente temos a tendência de focar nas coisas mais complexas, e acabamos deixando de lado o trivial botão, caixa de texto, etc. Justo aquilo que o usuário mais precisa para usar seu software…

Para o cliente, fica a frustração por ver coisas que antes funcionavam não funcionando mais, e para o desenvolvedor, retrabalho e mais retrabalho para as próximas iterações…

Enfim, sobre o que postou, realmente não dá pra “aceitar” sem ir até o último ponto do sistema envolvido na operação. No entanto, reconheço que usando outros mecanismos pode-se obter o efeito desejado, afinal, não há apenas uma maneira de atingir um objetivo. Talvez no caso deles seja teste de aceitação manual, seguindo um roteiro. Talvez esta técnica funcione até melhor para eles, afinal um ser humano avalia uma interface muito melhor do que uma máquina.

Para nós que não temos dinheiro para sequer considerar a possibilidade de manter o tal roteiro de testes manuais atualizado, ou pagar os testadores, temos que implementar testes automatizados.

Eu estou exatamente tratando milhares de problemas que aconteceram comigo devido a este fato: falta de testes automatizados que realmente são de _aceitação_.

Minha equipe está criando um editor de jogos eletrônicos, e algumas das features deveriam funcionar com mouse. Estas features ficaram sem uso por alguns meses, pois estávamos focando em outras áreas do editor. Todos os testes da citada API passam, no entanto o mouse simplesmente não funciona no editor como esperado, exibindo comportamentos estranhos ao clicar, arrastar, etc. Ou seja: não consigo fazer quase nada nesta área específica do mesmo.

Investiguei um pouco e descobri que houve uma mudança na maneira como o editor implementa o input, mas só atualizaram os comandos que se lembravam. Isto tem acontecido por mais de um mês, chegando ao ponto de hoje eu preferir nem usar o editor para aquela tarefa específica. O time não fez por mal, ninguém se lembrava daquelas feature nem muito menos tinham tempo para voltar a ela (ou tantas outras passadas) durante o desenvolvimento das novas features. O que faremos agora é, aos poucos, re-adicionar as histórias antigas nas iterações atuais, implementando também desta vez os testes de aceitação automatizados.

Espero que outros evitem erros como este, deixando testes de aceitação automatizado de lado. Geralmente ninguém tem tempo para manter testada cada uma das features de GUI do seu projeto, que provalmente contém código de meses de trabalho. De que adianta para o usuário final estar tudo perfeitamente testado se o botão “Submit” não faz nada?? Ou talvez faça, mas a tela de confirmação não aparece? E ao clicar em voltar ele recebe um erro?

Para o cliente, fica a sensação de que esperou tanto pela release só para ganhar bugs novos, e para o desenvolvedor, retrabalho e mais retrabalho para as próximas iterações…

Sim, quanto mais automaticas as coisas forem mais Pro Evolution Soccer a gente joga!

Contem comigo.

Grande abraço.

Ô Emerson, desta vez vamos babar com as morenas tomar umas “louras” lá em Sampa.

Grande abraço.