Preciso de teste automático? Quando é necessário? Que valor isso traz?
O artigo discute quando e por que o teste é necessário como tal e em que casos sua automação é necessária.
Durante a discussão sobre esse assunto realizada no clube para eles. Francis Bacon (“KifB Web-Meetings” em teleram), colegas trocaram experiências e anotaram seus pensamentos.
A automação de teste é necessária se agregar valor. Quando o próprio teste traz valor? Dois casos foram identificados.
Se o processo detectar erros no software antes de partir para a batalha
Se o teste da nova versão revelou erros que foram corrigidos posteriormente, esse teste não foi em vão.
Mas e se a situação for revertida? Se o teste não encontrou um erro, mas eles apareceram na batalha? Se erros foram detectados no banco de testes (incluindo o banco de testes configurado mais próximo da batalha).
Alega-se que, neste caso, o teste foi realizado mal.
Como medir a qualidade dos testes? Nesse caso, a métrica é adequada = o número de erros no ambiente de teste / (o número de erros no ambiente de teste + combate). Nesse caso, o número de erros é considerado ponderado pelo nível de criticidade.
Mas e se o teste não encontrou erros e não foi encontrado no servidor de batalha?
Alega-se que, nesse caso, o teste, como tal, não trouxe valor e esses trabalhos foram realizados em vão (com exceção do caso a seguir, que discutiremos mais adiante). Do ponto de vista de Lean, isso é uma perda.
Quando isso é possível? Quando o módulo em teste não mudou. O que pode mudar um módulo?
- Modificação do código do módulo.
- Alterando a versão das bibliotecas usadas (incluindo SO, banco de dados, etc.). A mudança pode ocorrer devido aos requisitos dos reguladores, e é por isso que a biblioteca precisa ser atualizada em um prazo fixo.
- A alteração de configurações ou dados que afetam seriamente o comportamento de uma funcionalidade universal, cujo teste abrangente é desnecessariamente difícil de conduzir e, como resultado, o teste foi abandonado. Exemplos:
- Definir promoções em soluções como Siebel CRM ou Oracle ATG pode levar à degradação do desempenho das funções de cálculo da promoção, e a possibilidade de verificação abrangente é impossível em um tempo razoável devido à flexibilidade e versatilidade excessivas dessas soluções.
- A descrição html do cartão do produto pode conter uma estrutura de documento quebrada ou erros na descrição do código js escritos dentro, o que quebra a página do cartão do produto
- O uso da funcionalidade não se destina a esse fim (pregos de martelo com um microscópio). Por exemplo, uma alteração no tipo de carga que não é inerente aos requisitos e, como resultado, não é levada em consideração durante o teste. Por exemplo, antes da Black Friday, vale a pena realizar um teste de carga separado para a página de destino, para onde o tráfego irá se não houver requisitos de carga para esse tipo de página.
- Alterando o comportamento da API de outros módulos que o módulo em desenvolvimento usa. Especialmente se a funcionalidade da API não for coberta pelo teste de regressão.
Como as opções para alterações podem ser diferentes, e a realização de um teste de regressão completo custa dinheiro, não vale a pena todos os testes. Uma opção de controle é marcar os testes com tags e antes do teste. O gerenciador de testes determina qual suíte de testes deve ser enviado para execução para uma determinada parte das alterações.
Quando preciso escrever autotestes neste caso?
Para começar, o teste automatizado não cancela os casos de teste de configuração, design de teste e gravação de configuração de teste! E não os substitui. Se não for esse o caso, a automação não deve ser tratada. Ao mesmo tempo, os autotestes devem ser entendidos não apenas como o próprio script, mas também como uma preparação para sua execução e uso dos resultados.
Se você escrever autotestes após criar o código, isso levará a um aumento no time2market (o que levará automaticamente a um aumento no capital conectado). Portanto, se for decidido cobrir o código com autotestes, você deve escrever esses autotestes paralelamente ao código principal, no paradigma de desenvolvimento de "TestFirst" ou "TDD".
O principal valor criado pela automação de testes é a redução do time2market devido ao upload mais rápido da nova versão.
Testes são necessários para garantir o desempenho de processos críticos.
Apesar do fato de o carro nunca ter pegado fogo, a presença de um extintor não é inútil.
Um erro em um site com alto tráfego que não permite adicionar um item à cesta pode levar a perdas mais significativas do que o custo de desenvolver e testar esse recurso ao longo do ano.
Portanto, é necessário destacar processos críticos que serão submetidos a verificações regulares (que valem a pena se ocorrer algum tipo de alteração). Compare:
- perda do tempo de inatividade de uma função durante o tempo desde a detecção até a correção,
- testes regulares manuais de despesas ou sua automação e sua subsequente implementação durante o período de recuperação.
Mas e se o teste regular não encontrar erros por um longo tempo e eles não ocorrerem na batalha? Então o teste não agrega valor e, portanto, não é necessário. Quando isso é possível?
- O módulo em desenvolvimento não é muito grande.
- Equipe estável e altamente competente.
- As integrações são fechadas por testes ou, por outro lado, não há alterações.
É possível não fazer nenhum teste?
Isso é possível através do lançamento de várias instalações da solução e do teste de novas versões beta em gatos, se isso for tecnicamente possível e se forem encontrados voluntários. Após o layout da nova versão, a telemetria é monitorada e uma reversão é realizada em caso de degradação dos indicadores. (Lembre-se de que a telemetria em batalha deve ser independente da disponibilidade dos testes).
Outro caso da utilidade do autoteste de regressão é o teste da API (teste de contrato da API), se essa API for necessária para suportar um processo crítico. Isso é especialmente importante se os desenvolvedores de outro módulo alterarem algo e não fizerem testes de qualidade das alterações por parte deles.
Quando a automação de teste não é necessária
Se você tiver uma grande quantidade de código herdado, não de alta qualidade. Cobrir autotestes com esse caos está aumentando o caos.
Nesse caso, vale destacar o módulo lógico dessa solução. Depois de selecionar a camada de interação deste módulo com o restante do código, você precisa cobrir a interação com os autotestes. Isso fornecerá garantias da integridade do comportamento e da integridade do módulo após sua recodificação.
Os autotestes não substituem o teste manual. O teste manual geralmente é realizado de forma mais rápida e barata que a gravação e os autotestes subsequentes. Em particular, se o teste for realizado após o desenvolvimento do código, a partir desse teste, somente a parte que fará o teste regular da funcionalidade crítica deverá ser automatizada.
E finalmente - uma lista de verificação da disponibilidade da empresa para autotestes
Vamos fazer uma reserva imediatamente, essa lista de verificação não é para todos, foi escrita para testadores de empresas para as quais o desenvolvimento de software é a principal fonte de receita.
Lista de verificação
- A empresa desenha o principal processo de entrega de negócios e tem um entendimento de onde você está localizado.
- A empresa elaborou o processo de entrega de valor aos clientes.
- O gerenciamento de tarefas foi configurado, o que significa que todos os envolvidos levam as tarefas ao status desejado. E as tarefas são tipificadas.
- A empresa formulou objetivos de teste.
- Os títulos das tarefas no rastreador são "penteados", em outras palavras, pelo título, você pode entender que tipo de tarefa é.
- O registro de tarefas é gerenciável, a qualquer momento, reflete o status e a política atuais do projeto / produto.
- Há um registro de requisitos e é gerenciável.
- Há rastreabilidade de requisitos de tarefas.
- Há rastreabilidade dos requisitos de teste. Sabe-se quais requisitos são cobertos por quais testes.
- Há rastreabilidade de testes de tarefas. Sabe-se que já foi testado onde e como.
- Existe uma matriz da influência dos componentes um sobre o outro.
- As tarefas são rastreadas para componentes.
- Tudo está no controle de versão.
- Existe uma política versionada de quem, como e por quê. Há um entendimento de por que o fluxo git é um modelo ruim.
- Normas existentes: codificação e outras
- Existe um ci
- Existe uma política de liberação, na qual métodos específicos de controle de versão são prescritos, tudo o que é necessário.
- Existe um repositório para artefatos de onde você pode retirar exclusivamente um produto pronto para instalação.
- Existe uma política para marcar artefatos de acordo com diferentes critérios. A análise de código estático não é esquecida.
- A varredura média do produto aumenta com o clique de um dedo. O ambiente também está no controle de versão.
- O ambiente é totalmente automatizado, verificado quanto à correção. Portas, versão Java, ...
- O produto se desdobra ao clicar com cheque
- O produto é configurado automaticamente para a tarefa necessária. A propósito, isso também se aplica às configurações de negócios. E isso também é verificado automaticamente.
- Você pode gerar repetidamente e automaticamente todos os dados de teste necessários. Os scripts de geração também estão no controle de versão e estão associados aos artefatos do produto.
- Todas as opções acima funcionam para qualquer versão do produto.
- Você tem um pipeline de entrega registrado dentro da política de liberação.
Por fim, obrigado aos membros do grupo pela discussão e ajuda na preparação do artigo.