Os testadores devem automatizar seu trabalho?

Estamos tentando configurar nosso processo de teste. Perguntamos se nossos testadores devem desenvolver testes de regressão automatizados ou se os desenvolvedores devem fazer isso.

E quanto a outros tipos de testes automatizados? Os testadores devem desenvolvê-los?

Eu digo que os testadores devem desenvolver os testes automatizados - eles têm a abordagem do "par de olhos externos" do código e irão (ou deve ser apenas 'pode'?) Detectar bugs que você não pensou, muito menos lidar com .

Além disso, a compreensão dos requisitos funcionais pode ser de nível superior ao entendimento dos desenvolvedores - portanto, fica entre o conhecimento de baixo nível do programador, mas não tão alto quanto o do BA.

Se você pode automatizar, automatize-o.

Deixe os testadores livres para encontrar o que você não pode automatizar. E quando encontrarem um novo bug, se ele puder ser automatizado e adicionado aos testes automatizados, adicione-o.

Na minha opinião, desenvolvedores e testadores são responsáveis ​​por diferentes tipos de testes.

O desenvolvedor, ao escrever a lógica, também deve escrever testes de unidade e integração. Isso permitirá que o desenvolvedor verifique se o que ele escreveu até agora funciona como pretendido. Além disso, esses testes ainda estarão disponíveis para o desenvolvedor executar quando fizerem alterações futuras. Depois que a lógica é concluída, o desenvolvedor pode ter certeza de que o que está escrito funciona conforme eles entendem as especificações e pode passar para o testador.

O testador a partir deste ponto deve ser responsável por escrever testes em todo o sistema que garantam que a lógica de negócios funcione conforme o planejado.

Dado que os desenvolvedores geralmente são muito apegados ao código, os testadores devem poder ajudar a limpar os testes do desenvolvedor, mas não vice-versa.

Na minha experiência, a maneira como um testador configura e executa um caso de teste automaticamente difere da maneira como um desenvolvedor o faz. Os testadores estarão pensando mais em como obter o máximo de informações do caso de teste, como executar testes rapidamente, como manter os testes em manutenção e assim por diante. Mais importante, os testadores verão nuances da cobertura de teste que os desenvolvedores sentirão falta.

Se os recursos de desenvolvimento de teste forem baixos, os desenvolvedores podem ajudar - mas o testador deve revisar seu trabalho com cuidado. Os desenvolvedores devem trabalhar em equipamentos e ferramentas de teste antes de escrever casos de teste reais, e os desenvolvedores nunca devem escrever casos de teste para seu próprio código. O fato de os desenvolvedores ajudarem nos testes tem vantagens - ele expõe os desenvolvedores a outras partes do produto, e os testes podem ajudá-los a se tornarem melhores desenvolvedores. No entanto, assim como o trabalho de um desenvolvedor júnior nunca ficaria sem uma revisão de código, o trabalho de QA de um desenvolvedor deve receber uma revisão de QA de alguém com mais experiência em testes.

Editado para adicionar: Sou um SDET com 5 anos de experiência. Eu trabalho com grandes desenvolvedores com mais de 10 anos de experiência cada um e ultimamente tenho trabalhado com eles para superar um gargalo de teste.

Uma coisa que eu realmente gostaria de ver é ferramentas sólidas de automação para testadores, que lhes permitem registrar efetivamente seu progresso através de um script de teste e, em seguida, permitir que esse script seja executado automaticamente no futuro. Especialmente se isso também facilitar a execução do mesmo script em diferentes versões do sistema operacional, sem que o testador precise executar todos eles manualmente.

Infelizmente, certamente para o produto em que trabalho, nenhuma das ferramentas do mercado funciona bem. Mas vale a pena ter isso em mente e analisar o que está disponível no mercado, caso haja algo que funcione para o que você está fazendo.

Uma distinção crítica que é realmente importante aqui é a seguinte: seus testadores estão simplesmente verificando ou estão testando ?

Este post de Michael Bolton explica melhor, mas em essência: eles estão olhando apenas para confirmar o comportamento ou estão procurando problemas com o sistema?

Eu acho que também é útil considerar os Quadrantes do Agile Testing (Brian Marick os descreveu originalmente, mas os encontrei no livro "Agile Testing" de Lisa Crispin e Janet Gregory: mesmo que você não esteja seguindo uma metodologia de desenvolvimento Agile, acho que o a distinção entre testes que criticam o produto e testes que dão suporte à equipe é realmente útil quando se considera a automação e se tenta desenvolver um plano para quem faz o quê e por quê.

Por exemplo, as verificações de unidade escritas pelos desenvolvedores atuam como detectores de alterações, permitindo que você faça as regressões mais cedo quando elas são executadas regularmente - esses são testes que dão suporte à equipe. As verificações de regressão no nível do sistema, automatizadas para que possam ser executadas regularmente e rapidamente, também dão suporte à equipe, capturando as regressões mais cedo e complementam os testes de unidade realizados pelos desenvolvedores. Isso libera o tempo dos testadores para realizar testes que criticam o produto - testes exploratórios, por exemplo. Ou, possivelmente, aplicando algumas das verificações automatizadas para testar o produto com estresse.

A outra coisa de que realmente gosto na apresentação de Lisa Crispin que vinculei é que ela indica que a automação também pode ser usada para dar suporte ao teste manual - criando dados de teste, a automação usada para obter um cenário no ponto em que você deseja se concentrar hoje, por exemplo.

A consideração desses dois artigos ajudará você a analisar que tipo de teste você deseja fazer, facilitará a escolha do que pode ser adequado para automação e descobrirá quais bits de automação são mais adequados para serem testados e quais pelos desenvolvedores.