Aviso Legal: meu nome é Eric Burygin, trabalho como testador há muito tempo, dou aulas para alunos do curso "Engenheiro de Testes" , então pode parecer que o testador deseja apenas transferir um trabalho para os desenvolvedores. Na verdade, a abordagem descrita tem prós e contras, portanto, o artigo é, entre outras coisas, discutível. Eu ficaria feliz em ver as opiniões dos desenvolvedores e testadores nos comentários.
Se o desenvolvimento escreve testes, você pode resolver vários problemas de uma vez, por exemplo:
- Acelera perceptivelmente o ciclo de liberação.
- Teste de descarregamento.
Na maioria dos comandos, o processo se parece com isto:
- O desenvolvedor cria novos recursos e completa os existentes.
- O testador testa tudo isso e escreve vários casos de teste.
- O automatizador, justificando o título do cargo, automatiza tudo de acordo com os casos de teste escritos da cláusula 2.
Tudo parece simples.
Mas existem pontos fracos neste paradigma.
Digamos que um desenvolvedor tenha concluído seu recurso e aprovado com segurança para teste. Mas o recurso acabou não sendo raro, mas francamente cru. Isso levará a uma redescoberta do problema e correções adicionais, e pode haver de uma a N iterações, dependendo do tamanho deste recurso, sua complexidade, impacto nos processos relacionados e a consciência do próprio desenvolvedor. E também sobre como seus processos são, em princípio, organizados dentro do desenvolvimento, com que cuidado as solicitações pull parecem, se o aplicativo é iniciado antes de ser enviado para teste.
Em geral, existem variáveis suficientes.
Depois que a tarefa é testada e está pronta para lançamento, o teste precisa ser escrito para toda a funcionalidade dos casos de teste. Em seguida, regredir / fumar e finalmente soltar.
Depois de receber os casos de teste escritos, o automatizador cobre a funcionalidade com testes. Há uma probabilidade bastante alta de que a tarefa termine em uma fila existente, portanto, os testes serão escritos com um atraso.
- Só preciso de mais desenvolvedores
Infelizmente, não é uma panacéia. Muito pelo contrário. Quanto mais desenvolvedores você tiver neste esquema, mais forte será a carga de teste. Como resultado, o ciclo de lançamento ou a própria equipe de teste aumentará.
E isso, de acordo com o princípio do dominó, aumentará a carga sobre os automáticos, que terão que processar cada vez mais casos de teste que caem sobre eles. Haverá uma situação de espelho: ou o tempo de cobertura do teste aumentará ou a equipe de automação aumentará.
Normalmente, há dois testadores e um engenheiro de automação para cada oito desenvolvedores. Ao mesmo tempo, a automação não está diretamente envolvida no ciclo de lançamento - em vez disso, está próxima. E surge a pergunta: como tornar os processos descritos mais eficazes e até não perder em qualidade?
Vamos tentar mover o estágio de automação do terceiro lugar para o primeiro, para o estágio de desenvolvimento.
O que acontece
Você obterá imediatamente um bom conjunto de vantagens, veja:
- os desenvolvedores escrevem testes simultaneamente com a escrita do próprio recurso, o que melhora significativamente sua qualidade;
- a carga no teste diminui: os testadores agora precisam examinar os resultados do teste e avaliar se a tarefa foi suficientemente coberta pelos testes;
- a regressão manual no esquema não é mais necessária.
E quanto aos testadores?
O testador, mesmo no paradigma atualizado, continua sendo um especialista em teste - é ele quem revisa a qualidade e a integridade da cobertura do autoteste de um recurso específico, bem como analisa problemas complexos e incomuns. Mas agora, graças à carga reduzida, o testador libera parte do seu tempo, ele pode lidar com processos.
Ao mesmo tempo, você precisa entender que o teste manual ainda não levará a lugar nenhum - você sempre terá algo que, por algum motivo, é impossível de automatizar ou não faz sentido.
Então, para um novo paradigma. Legal? Sim, pelo menos implemente agora. Se você pode fazer duas coisas.
- Venda essa ideia para o desenvolvimento. Porque nem todo desenvolvedor vai querer escrever testes imediatamente, porque pode ser entediante, ou ele simplesmente não quer: você, de fato, tem testadores lá para quê?
- Venda essa ideia para gerentes. Porque, com outras vantagens, você aumenta o tempo de desenvolvimento de cada recurso.
Quais são as desvantagens aqui pode esperar por você.
- A maioria dos desenvolvedores simplesmente não sabe como testar, porque eles são desenvolvedores, não testadores. E tudo bem. Aqui você pode ensiná-los a testar, o que não será a tarefa mais trivial, ou apenas escrever casos de teste para eles. O que de fato quebra o próprio processo.
- No início, a automação levará mais tempo, pois não haverá base de código de teste, infraestrutura e abordagens usuais - a tarefa é nova.
- Relatórios claros serão necessários para o teste. Mas lembre-se: mesmo o relatório mais compreensível nem sempre pode ser lido corretamente de imediato.
- Você não pode cobrir fácil e rapidamente nem todos os problemas com testes. Em alguns casos, você terá que gastar mais tempo em testes do que na implementação real do recurso.
- Será difícil entregar tarefas em grande escala ao mesmo tempo que os testes, isso leva muito tempo.
- Para essas mesmas tarefas complexas e de grande escala, você ainda terá que reservar um tempo para simplesmente mergulhar nelas, porque não há outra maneira de verificar a exatidão dos testes que os desenvolvedores escreveram.
O que fazer?
Basicamente, cada problema tem uma solução.
- Os desenvolvedores não sabem como testar. →
Você pode consultá-los nos estágios iniciais para ajudar a entender. - , . →
. . - . →
, , . - . →
: . - , . →
, — . . - . →
. .
Uma abordagem com todos os seus prós e contras tem direito à vida. E se você também configurar os processos corretamente, isso irá ajudá-lo a acelerar o ciclo de liberação e não aumentar o estado (: