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…

Tirando a piadinha, já trabalhei bastante com software para médicos e de fato a usabilidade é o maior risco. Médico é um usuário muito ruim. Se a usabilidade não ajudar o sistema será um fracasso. É lícito afastar este risco no início. Até porque é natural em processos ágeis focar em valor, mesmo que isso não se traduza em software que vai diretamente para produção.

Vou encerrar essa discussão por aqui porque já virou teimosia e saiu do tópico do post há muito tempo. Se vc quer discutir sobre testes, sugiro que vc leia mais sobre o assunto para podermos discutir melhor.

Testes unitários até podem ser testes de caixa preta, mas normalmente o que se faz não é isso. Principalmente quando você usa TDD, que usam-se mocks e testa-se intencionalmente se o caminho que vc quer dentro de um método ou parte do sistema é percorrido, o teste é de caixa branca porque você está conhecendo e exercitando intencionalmente várias partes do código interno. Até porque a intenção maior é o melhor design, alta coesão e baixo acoplamento.

E sobre testes de aceitação, quando você desenvolve uma história você está entregando para o cliente alguma coisa que foi feita do início ao fim, ou seja, algo completamente “usável” por ele. Um exemplo de história seria “Para poder transferir dinheiro para outras pessoas, eu como usuário quero poder dizer um número de conta, uma quantia X e clicar num botão para que a transferência seja feita”. Se o seu teste de aceitação testa a API que faz estas operações de transferência mas NÃO inclui a interface, o teste não pode ser considerado de aceitação. A API pode funcionar perfeitamente mas a interface não, e a funcionalidade não está entregue para o usuário. Neste caso, o teste de aceitação deveria ser um teste de caixa preta que, usando a interface, faz as tais operações no sistema. O teste da API não dá cobertura suficiente para garantir que os critérios de aceitação da história foram atendidos.

[ ]s, gc

“Se nao testa a UI ou API nao pode ser de aceitacao”

Se vc aplicar abstracao black-box no teste de uma API nao tem porque falar em termos de web services, facades ou bibliotecas de classe. Pro XP e pro agile em geral a palavra aceitacao em “teste de aceitacao” é mais importante que a palavra teste.

Se você não está incluindo a interface no teste de aceitação, ele não pode ser considerado um teste de aceitação (a não ser que seu sistema seja uma API, que não é o caso).

A definição de teste de aceitação (http://en.wikipedia.org/wiki/Acceptance_testing) não deixa dúvidas:

“[...] acceptance testing is black-box testing performed on a system [...]”

Por ser um teste de caixa preta (http://en.wikipedia.org/wiki/Black-box_testing), o teste envolve avaliar se dada uma determinada entrada no sistema ele terá uma determinada saída, sem haver nenhum conhecimento sobre o que há internamente no sistema em termos de infraestrutura, código, métodos ou qualquer coisa de programação.

Se você precisa conhecer, digamos, um Façade para testar uma regra de negócio, como é o que você parece estar propondo, você não está mais fazendo um teste de caixa preta no sistema, você está testando direto a infra do sistema – um teste de caixa branca (http://en.wikipedia.org/wiki/White_box_testing):

“White box testing uses an internal perspective of the system to design test cases based on internal structure. [...]”

Neste caso que você citou, o que você está propondo poderia ser considerado um teste de integração (http://en.wikipedia.org/wiki/Integration_testing).

Eu não falei em momento algum que eles não fazem esse tipo de teste, aliás, nem o Jeff falou isso. Porém, é muito provável que façam, já que é um tipo de teste relativamente fácil e, como não testam todas as interfaces, pode ser bem útil.

[ ]s, gc

Sim isso ficou claro, alias esse é justamente o meu ponto de discordancia.

“Os testes de aceitação são diferentes dos testes de interface, porém os testes de aceitação muitas vezes USAM a interface. Se vc não tem como criar algo automatico que usa a interface pode ficar complicado fazer um teste de aceitação automatizado também, e esse é exatamente o ponto em que eles estão.”

Muitas vezes usam mas nao é recomendado que assim seja neste caso por exemplo. O que significa que testes de aceitacao nao podem ser automatizados ou que devemos procurar outras ferramentas para o trabalho?

Se partimos de um ponto onde concordamos que os dois testes tem naturezas distintas entao nao é dificil compreender o meu ponto de vista; funcionalidades que sao objeto dos testes de aceitacao podem ser testadas em um nivel abaixo da UI. Isso é particularmente importante quando se tem mais de uma maneira de se chegar ate essa funcionalidade.

[]s

Os testes de aceitação são diferentes dos testes de interface, porém os testes de aceitação muitas vezes USAM a interface. Se vc não tem como criar algo automatico que usa a interface pode ficar complicado fazer um teste de aceitação automatizado também, e esse é exatamente o ponto em que eles estão.

Por isso que eles têm esse percentual alto de testes manuais – que aliás é exatamente o que o Jeff relata e ele qe dá essa ênfase, não eu

A justificativa apresentada por eles e que vc expos no texto é legitima para nao haver testes de interface automatizados, mas qual seria o oimpedimento em relacao a automatizar os testes de aceitacao?

Quaqluer sistema de software minimamente funcional pode se beneficiar de testes de aceitacao automatizados. E mais complexidade se traduz em maior necessidade de que tais testes existam e sejam automatizados, nao menor como deu a entender no seu post.

Talvez hajam outras razoes que justifiquem o “80% dos testes desses sistemas não são automatizados”, nao estou duvidando dos numeros apresentados (apesar de achar que vc os super-enfatizou). O meu ponto é que testes de interface sao diferente de testes de aceitacao. Por mais que o cliente seja incapaz de dizer qual a diferenca, pra uma estrategia de desenvolvimento agil isso importa.

Por essas que vejo selenium com restricoes…

Considerando que a validacao de fato de UIs se da pela interacao homem-maquina o mais sensato mesmo nao seria eliminar o usuario do processo.