“Ninguém testa a profundidade de um rio com os dois pés”
~ Provério africano
Teste automatizado é melhor do que teste manual
Testes automatizados são muito explícitos (preto no branco) então você tem uma chance maior de reproduzir um bug se achado por um teste automatizado ao saber o que o teste automatizado executou para atingir o resultado. Devido aos testes automatizados serem explícitos, eles também executam consistentemente, e não ficam cansados ou com preguiça como os humanos, os quais são mais propensos ao erro.
Os testes automatizados são mais rápidos de serem executados do que testes manuais, já que não há atraso entre o tempo de entrada e a verificação, e isso significa que você pode executar mais testes em mais navegadores mais rapidamente. Testar manualmente a mesma funcionalidade, por exemplo, em 8 navegadores e 4 dispositivos é cansativo, mas pode ser facilmente atingido com testes automatizados.
Testes automatizados também o capacitam a testar coisas que são manualmente impossíveis. Por exemplo, responder uma pergunta como ‘e se eu tiver 200 contas’, ou ‘e se seu processasse 10 transações simultaneamente’ pode somente ser respondida eficientemente ao usar testes automatizados.
Teste manual é melhor do que teste automatizado
Mesmo ao automatizar um cenário de teste, você tem que testá-lo manualmente ao menos uma vez de alguma forma para automatizá-lo. (Há controvérsias – ver TDD). E você tem que manualmente verificar o resultado do teste.
Testes automatizados podem parar de funcionar por algo como um pop-up inesperado, o qual pode ser rapidamente analisado e rejeitado quando testando manualmente.
O teste manual é uma atividade da ciência da sabedoria: uma atividade que requer julgamento humano. Quando você está testando você está usando conhecimento implícito para julgar se algo está ou não funcionando como esperado. Isso o dá a chance de encontrar bugs extras, os quais testes automatizados nunca iriam encontrar. Ele também o permite que você siga os cheiros que você encontra, para explorar áreas que podem não ter sido testadas ou exigidas.
Teste manual também é útil para encontrar problemas de layout e bugs triviais, os quais não seriam encontrados por testes automatizados, já que você está observando a aplicação totalmente enquanto a utiliza. Problemas de usabilidade também são identificáveis por testes manuais, mas não podem ser descobertos através da escrita e execução de scripts automatizados de teste.
TRADUÇÃO/ADAPTAÇÃO DE PRIDE AND PARADE, DE ALISTER SCOTT
My 50 cents:
Testes automatizados bem feitos não são facilmente enganados por um mero pop-up inesperado. Testes bem arquitetados evitam esse tipo de situação e trabalham em ambiente controlado.
Hoje em dia é possível fazer muito mais do que se pensa com testes automatizados, tais como testes de comparações de screenshots, os quais reduzem bastante o tempo de testes manuais para verificar simples bugs de estilo e layouts quebrados.
Testes automatizados podem (e se possível devem) ser escritos antes do código da funcionalidade em si. Estes guiam o desenvolvimento da funcionalidade em busca da simplicidade e arquitetura evolutiva.
Obviamente algumas coisas ainda assim serão somente encontradas com testes manuais, mas profissionais que fazem só isso cada vez mais deixam de ser procurados, e cada vez mais busca-se não só pessoal qualificado para trabalhar com automação de testes, mas profissionais completos, os quais são desenvolvedores que criam testes, arquitetam uma solução que agrega valor, desenvolvem e colocam software funcionando em produção continuamente.
E você, o que acha?
Logo falaremos sobre: Existem coisas que só podem ser testadas em produção?
TALKING ABOUT TESTING 
IMHO, testes (tanto automatizados quanto manuais) podem guiar o desenvolvimento da funcionalidade em busca da simplicidade e uma arquitetura mais testável. Eu sempre prefiro fazer uma exploração manual que me valide se a funcionalidade está pronta para meus cenários automatizados rodarem ou não. Ou seja, preciso, diariamente, usar os dois tipos de teste e portanto concordo que o tipo de profissional que “só teste manual” está em extinção – tanto quanto aquele que “só automatiza” 🙂
um pop-up inesperado? se ele apereceu quando não deveria é um bug.
Fausto, depende, como diria o Diego Blond =p. Pode ser que o pop-up não seja tão inesperado assim, caso o testes não esteja prevendo alguma situação como essa. Já passei por casos em que pop-ups apareciam e não era bug, e sim meu teste que estava frágil e necessitava ser refatorado. Em outros casos será um bug, como por exemplo, um alert que o desenvolvedor utilizou para debug e ficou esquecido. Por falar nisso, sempre vale ter atenção também a comandos javascript utilizados para debug, tais como console.log, que não devem ser esquecidos no código também, como nenhum outro tipo de código de debug.
Acho que um complementa o outro. Você pode ter um suíte top de testes automatizados mas mesmo assim terá que separar um tempo para realizar uma seção de testes exploratórios, e como eu gosto de falar, “pirar” no sistema em que está testando, USAR a imaginação, e criatividade, descobrindo novos cenários e possíveis bugs. Não existe melhor ou pior, cada um realiza uma função especifica.
Essa com certeza é uma excelente abordagem Allan. A existência de testes automatizados libera os profissionais para trabalhos mais criativos, tais como testes exploratórios.
Acho que cada um tem um propósito diferente, automatizar tem muito haver com TIME TO MARKET, ficar fazendo testes de regressão diversas vezes é cansativo pra qualquer testador, e o tempo de entrega é cada vez mais curto, temos que automatizar aquilo que é repetitivo. Já os testes exploratórios com foco no ambiente do cliente e testes inusitados pra encontrar bugs, cada ciclo de testes com automatizados, os testes manuais são feitos com mais qualidade porque aquilo que é repetitivo foi automatizado, tenho tempo pra pensa com mais qualidade nos testes.
Na minha opinião existe um paradigma nos testes automatizados porque eles passam a ter grandes lógicas para preverem varias situações e passam a depender de que alguém os testes manualmente para saber se esse código é válido . Se apareceu um pop-up que na funcionalidade não estava prevista inicialmente é um bug que deve ser tratado na origem e não como uma situação normal
Olá Rogério, obrigado pela contribuição. Você poderia elaborar um pouco mais, por favor? O que você quer dizer com existe um paradigma nos testes automatizados?
Sobre a questão do pop-up, este foi só um exemplo, e existem casos em que pode realmente ser um bug, mas outros em que é uma situação normal, algo que aplicação não controla, mas sim o navegador. As vezes, um refresh em uma página enquanto um formulário está sendo preenchido, pode gerar um pop-up para confirmar se você estar certo de que quer destarcar as mudanças. Tal pop-up, quando visto em um teste manual, seria simplestemente aceito, porém, no mesmo caso em um teste automatizado, tal teste deve estar preparado para tal situação, para que não falhe desnecessariamente, causando um resultado falsp positivo. Faz sentido?