Testes ao longo do Ciclo de Vida de Desenvolvimento de Software

A escolha do SDLC (Ciclo de Vida de Desenvolvimento do Software) tem impacto sobre como, quais e quando as atividades de teste serão implementadas e como o fluxo do processo de teste ocorre. Tendo impacto sobre:

• O escopo e cronograma das atividades.
• O nível de detalhamento da documentação.
• A escolha das técnicas e das abordagens.
• A extensão da automação.
• O papel e responsabilidade de um testador.

Nos modelos sequenciais, testes estáticos são implementados antes do código, então após o código os testes dinâmicos são implementados.

Nos modelos iterativos e incrementais, testes dinâmicos e estáticos podem ser realizados a cada iteração.

No desenvolvimento Ágil, a documentação leve e ampla automação de testes são favorecidas.

Boas práticas utilizadas em testes em qualquer SDLC são:

• Sujeitar todas as atividades de desenvolvimento ao Contole de Qualidade.
• Utilizar difentes níveis de teste.
• Aderir ao princípio do teste antecipado, ou seja, a análise e modelagem do teste deve começar o quanto antes no SDLC.
• Apoiar a estratégia Shift-left com a revisão dos produtos de trabalho logo em seus rascunhos.

Os testes podem ser um motivador e direcionador do desenvolvimento. Seguindo o princípio do teste antecipado e a abordagem Shift-left, os testes são escritos antes do código, dão suporte a um modelo de desenvolvimento iterativo e podem persistir com testes automatizados, para isso são utilizadas as seguintes abordagens:

• TDD (Test Driven Development) - Desenvolvimento Orientado por Testes: direciona a codificação por meio de casos de teste, onde os testes são escritos primeiro (e falham), depois o código (e passam), depois o código e o teste são refatorados (eliminam codsmell).
• ATDD (Acceptance Test Driven Development) - Desenvolvimento Orientado por Teste de Aceite: Teste de critérios de aceite são parte do desenho do sistema, onde os testes são escritos antes que a parte do software relacionada seja desenvolvida, e ao ser desenvolvida tem que atender aos testes de aceite.
• BDD (Behaviour Driven Development) - Desenvolvimento Orientado por Comportamento: Os casos de teste são escritos em um formato fácil de entender pelos stakeholders, normalmente Gherkin (Given, When, Then), e expressam o comportamento desejado do software. Os casos de teste são então traduzidos em testes executáveis (manuais e automatizados).

DevOps é uma abordagem que visa preencher as lacunas entre o desenvolvimento (inclui testes) e as operações, tratando suas funções com o mesmo valor. Promove autonomia da equipe, feedback rápido, Integração Contínua (CI) e Entrega Contínua (CD).

Benefícios:

• Feedback rápido
• Abordagem shift-left com CI, onde códigos são acompanhados de testes de componentes e análise estática.
• Ambientes de teste estáveis com CI/CD.
• Visão da qualidade não funcional.
• Reduz testes manuais repetitivos pela automação por meio da pipeline de entrega.
• Reduz riscos na regressão com testes automatizados.

Desafios:

• Definir a pipeline de entrega.
• Introduzir e manter ferramentas de CI/CD.
• Manter a automação de testes.

A abordagem Shift-left indica que os testes devem ser feitos o mais cedo possível, seguindo o princípio do teste antecipado, mas seguir boas práticas é o que definirá seguir a abordagem Shift-left, são elas:

• Revisão da especificação sob a perspectiva dos testes.
• Escrever casos de teste antes do código ser escrito e executar eles durante a implementação do código.
• Usar CI e CD para feedback rápido e teste de componentes automatizados.
• Realizar análise estática do código fonte antes do teste dinâmico.
• Realizar testes não funcionais desde o nível de teste de componente.

Seguir essa abordagem pode significar um custo mais elevado de treinamento, esforço e outros no inicio do processo, entretanto economizam ainda mais no fim do processo, pois seguem o princípio de que os testes antecipados economizam tempo e dinheiro.

Também conhecidas como "reuniões pós-projeto", normalmente acontecem nos marcos de um projeto, como final de iteração ou do projeto. Os resultados dessas reuniões fazem parte do relatório de Conclusão do teste, nelas os envolvidos (Testadores, desenvolvedores, arquitetos, product owner, analistas de negócios) discutem os seguintes tópicos:

• O que foi bem sucedido e deve ser mantido ?
• O que foi bem sucedido e deve ser melhorado ?
• Como incorporar as melhorias e manter os sucessos no futuro ?

Benefícios:

• Aumenta a eficácia dos testes.
• Aumenta a qualidade do material de teste.
• Melhora o vínculo e aprendizado da equipe.
• Melhora a qualidade da base de teste.
• Melhora a cooperação entre os membros das equipes.

Os tipos de teste podem ser diferenciados pelo: Objeto de teste, objetivo do teste, base de teste, defeitos e falhas, abordagem e responsabilidade. Os principais são:

• Teste de Componente: Testa componentes isoladamente, normalmente feita pelos desenvolvedores.
• Teste de Integração de Componentes: Testa a interface e integração entre os componentes.
• Teste de Sistema: Testa o comportamento geral do sistema e seus recursos, com tarefas de ponta a ponta.
• Teste de Integração de Sistema: Testa a interface do sistema e de outros sistemas e serviços externos relacionados. O ambiente de teste é semelhante ao operacional.
• Teste de Aceite: Se concentra na validação. De preferência deve ser feito pelos usuários previstos.

Os principais Tipos de Testes descritos a seguir, podem ser realizados em qualquer Nível de Teste, com foco diferente em cada nível. São eles:

• Teste funcional: responde a pergunta "O que deve fazer ?" . Avalia as funções que um componente ou sistema deve executar.
• Teste não funcional: responde a pergunta "O quão bom está ?". Avalia as características que não são funções em um sistema, como eficiência de performance, compatibilidade, usabilidade, confiança, segurança, capacidade de manutenção e portabilidade.
• Teste de Caixa-preta: é baseado na especificação, o principal é verificar o comportamento do sistema em relação às suas especificações.
• Teste de Caixa-branca: é baseada na estrutura,o principal é cobrir a estrutura pelos testes até o nível aceitável.

O Teste de Confirmação é realizado após a correção de um defeito e verifica se ele foi corrigido com sucesso. Pode-se adicionar novos casos de teste ou executar os casos de teste que falharam para verificar a correção.

O Teste de Regressão é realizado após uma alteração no sistema (inclui correções) e verifica se há consequências adversas em outras partes do software, nas quais podem ser afetadas com a alteração. São fortes candidatos a automação.