Explorar o teste shift-left
O teste no gerenciamento do ciclo de vida do aplicativo é essencial para maximizar a qualidade do código e minimizar o risco operacional associado à implantação e atualização de software. O termo shift-left, neste contexto transmite a ideia de mover atividades de teste o mais cedo possível na fase de desenvolvimento. A organização em nosso cenário de exemplo deve considerar incorporar essa abordagem em sua estratégia de DevOps para minimizar os problemas atuais de segurança e estabilidade. Nesta unidade, examine diferentes tipos de testes que podem ser implementados dessa maneira e examine seus métodos de implementação.
Quais testes devem fazer parte do teste shift-left?
O desenvolvimento de software incorpora uma ampla gama de tipos de teste, mas aqueles de um interesse específico para nós incluem:
testes de unidade: esses testes se concentram nas menores partes testáveis de um código de aplicativo, como funções ou métodos individuais. O objetivo é estabelecer se cada unidade de código pode executar com êxito sua operação pretendida isoladamente do restante da base de código e das dependências externas. Esses testes devem ser totalmente automatizados, rápidos (concluídos dentro de 30 segundos) e fornecer cobertura completa de código (o que basicamente significa que todos os testes de unidade devem testar coletivamente toda a base de código). O teste de unidade é adequado para a abordagem shift-left. É recomendável aplicá-lo a todo o código o mais cedo possível no ciclo de desenvolvimento, preferencialmente no início da fase de programação.
Smoke tests: Estes testes têm como objetivo avaliar as funcionalidades principais de um aplicativo em um ambiente de teste. Embora testem o aplicativo real (em vez de seus componentes individuais e isolados, como fazem os testes de unidade), sua finalidade é determinar se a compilação ou implantação do aplicativo é suficientemente estável para garantir um teste mais aprofundado. No entanto, eles não verificam a interoperabilidade entre aplicativos. Assim como acontece com os testes de unidade, eles devem ser totalmente automatizados e relativamente rápidos (a interação do usuário pode ser simulada usando ferramentas de automação do navegador e estruturas de automação de interface do usuário). O termo smoke test, destina-se a transmitir a ideia de fumaça indicando um grande problema (incêndio) que deve ser resolvido o mais rápido possível. O teste de fumaça também deve ser implementado no início do ciclo de desenvolvimento, preferencialmente, assim que uma versão do software que ofereça sua funcionalidade principal estiver disponível. Isso se aplica às fases de build e implantação do aplicativo.
testes de integração: esses testes validam a interação entre diferentes componentes do aplicativo. Ao contrário dos testes de unidade, eles podem levar um tempo considerável para serem concluídos. A duração estendida desses testes é comumente usada como um argumento para executá-los no início do ciclo de vida de desenvolvimento de software. Em geral, você deve considerar testes de integração em cenários para os quais os testes de unidade ou de fumaça não são adequados. No entanto, a recomendação é agendá-los para serem executados em intervalos regulares. Essa abordagem oferece um comprometimento razoável entre um possível atraso na detecção de problemas de integração e um tempo de espera extra necessário para concluí-los.
testes de aceitação: esses testes determinam se um produto de software atende aos requisitos de negócios e está pronto para uma entrega para seus consumidores. O teste de aceitação não é adequado para a estratégia shift-left, mas pode ser possível incorporar alguns de seus elementos no início do ciclo de vida de desenvolvimento de software. Por exemplo, critérios de aceitação e histórias de usuário, que são componentes essenciais do teste de aceitação, devem ser introduzidos no início do processo de desenvolvimento. Isso facilita a colaboração entre equipes de desenvolvimento, proprietários de produtos e stakeholders do projeto. Além disso, os consumidores de software e os stakeholders do projeto devem estar envolvidos nas fases de teste anteriores para compartilhar seus comentários. Isso pode envolver o uso de métodos como teste alfa ou beta, teste de usabilidade ou versões iniciais antes do teste formal de aceitação.