Valor relativo do teste manual versus automatizado

A organização em que trabalho recentemente contratou um oficial de testes para executar testes manuais, mas quando perguntei sobre como ter tempo para desenvolver testes de unidade, a resposta foi que o teste manual proporcionaria um retorno maior. Isso é algo que parece errado para mim e estou procurando um meio de classificar testes manuais e automatizados um contra o outro, mais científico do que um pressentimento. Não estou dizendo que não há lugar para testes manuais - mas os testes automatizados parecem, pelo menos para mim, remover algumas das tarefas mais repetitivas e chatas. Temos um servidor de compilação que executa alguns testes de unidade e alguns de selênio - portanto, não é como a idéia de testes automatizados é um impedimento, mas apenas vista como um menor retorno do investimento.

Eu posso entender que ter alguém executando um teste completo de ponta a ponta de um sistema testa o produto final e, finalmente, isso é tudo que o usuário se importa, mas é lento e muito repetitivo. O teste de regressão manual significa repetir todos os testes anteriores e confirmar que nada mudou. Se houver 4 caminhos no processo, são 4 testes manuais que podem levar 5 minutos cada.

Então, existem fatos e números verificáveis ​​que eu possa usar para defender o tempo do orçamento para testes automatizados? Nesse caso, quais são as desvantagens dos testes automatizados além daqueles no link?

Eu seria cuidadoso ao pensar em teste "manual" versus teste "automatizado" em um contexto de retorno do investimento (ROI). É uma forma de pensamento falacioso ao discutir o valor da automação (consulte a seção "Time Machine" desse link).

A falácia resumida da Time Machine é a seguinte: a única maneira de determinar verdadeiramente o ROI de uma abordagem de teste é ter uma máquina do tempo em que você possa visitar o futuro e ver o que aconteceu. Como você (provavelmente) não pode fazer isso, as estimativas de ROI devem ser vistas como uma heurística, na melhor das hipóteses, e não como uma regra rígida. Use as informações atuais para tomar uma decisão informada sobre um determinado esforço de teste que seja útil para sua equipe ou não.

Em vez disso, quando se trata de testar, pense em quais áreas do seu produto precisam de mais atenção e onde podem estar os maiores riscos. Talvez tenha sido identificado que o teste de integração de ponta a ponta pode encontrar mais problemas com seu aplicativo. Mesmo que o teste de unidade traga benefícios, esses benefícios podem não valer os custos associados (obtenção do desenvolvedor, gravação e execução de testes etc.). Da mesma forma, tente pensar em benefícios / custos em vez de vantagens / desvantagens nos testes.

Primeiro, você deve diferenciar claramente os testes de unidade e outros testes automatizados . Essas são duas coisas diferentes, com objetivos diferentes.

Testes de unidade são testes para validar partes muito pequenas do seu código. Eles geralmente são testes de caixa branca, escritos por um desenvolvedor que conhece o código fonte "em teste". No TDD, eles são escritos da maneira do primeiro teste, por um desenvolvedor que escreverá o código-fonte depois que ele escreveu o teste. Esse tipo de teste não pode ser transferido para um "oficial de teste" por natureza e, se sua organização não estiver completamente desorientada, você não deverá perguntar ao seu chefe se e quando poderá escrevê-los - da mesma forma que você não deveria. pergunte ao seu chefe se e quando você pode escrever comentários no seu código-fonte.

Testes de integração, testes de aceitação e outros testes de caixa preta são uma coisa diferente. Se você tem um oficial de testes que os aplicará manualmente, e ele precisa repetir o mesmo tipo de testes repetidamente, a necessidade de automação deve ser solicitada por ele, não por você (é claro, você deve torne transparente para ele que tipo de testes você pode automatizar e quais não). Ele deve dizer para que tipo de teste ele acha que a automação fará sentido e para qual não. Talvez ele próprio faça a automação usando alguma ferramenta de teste de regressão ou peça sua ajuda para criar algumas ferramentas para ele.

Obviamente, quando você pensa que se ele não é experiente ou inteligente o suficiente para chegar a essa conclusão sozinho, deve conversar com ele (e se isso não ajudar, talvez com seu chefe). No entanto, IMHO, você deve fazer isso apenas quando tiver a impressão de que seu oficial de teste é um gargalo na sua produção devido a falta de automação de teste.

Todo mundo sempre quer exemplos e estudos externos, mas estes não são muito eficazes para convencer o gerenciamento. Se o teste manual for realmente um gargalo na sua empresa, você terá todos os exemplos internos necessários:

Um bug acidentalmente sai pela porta. Você afirma que ele costumava funcionar e solicita que seja adicionado aos testes de regressão. O testador manual afirma que o teste de regressão levará muito tempo. Você se oferece para fazer um teste automatizado para isso. O testador manual dá boas-vindas à idéia porque ele se sente sobrecarregado e gostaria de mais tempo para se concentrar nos casos de teste mais "interessantes". Com as vozes de clientes irritados ainda ecoando, o gerenciamento começa a entender sua opinião sobre a automação de testes.

Se reuniões como essa não estiverem acontecendo na sua empresa, nenhum estudo externo será suficiente.