Teste ao longo do Ciclo de Vida

Um modelo de ciclo de vida de desenvolvimento de software (SDLC) é uma representação abstrata e de alto nível do processo de desenvolvimento de software. Um modelo SDLC define como as diferentes fases de desenvolvimento e os tipos de atividades realizadas nesse processo se relacionam entre si, tanto lógica quanto cronologicamente. Exemplos de modelos de SDLC incluem: modelos de desenvolvimento sequencial (p. ex., modelo em cascata, modelo em V), modelos de desenvolvimento iterativo (p. ex., modelo em espiral, prototipagem) e modelos de desenvolvimento incremental (p. ex., Processo Unificado). Algumas atividades nos processos de desenvolvimento de software também podem ser descritas por métodos de desenvolvimento de software mais detalhados e práticas ágeis. Os exemplos incluem: desenvolvimento orientado por testes de aceite (ATDD), desenvolvimento orientado pelo comportamento (BDD), domain-driven design (DDD), extreme programming (XP), feature-driven development (FDD), Kanban, Lean IT, Scrum e desenvolvimento orientado por teste (TDD).

2.1.1 Impacto do Ciclo de Vida de Desenvolvimento de Software nos Testes

Para ser bem-sucedido, o teste deve ser adaptado ao SDLC. A escolha do SDLC tem impacto sobre:

●O escopo e cronograma das atividades de teste (p. ex., níveis de teste e tipos de teste);

●O nível de detalhamento da documentação de teste;

●A escolha das técnicas de teste e da abordagem de teste;

●A extensão da automação de testes;

●O papel e responsabilidades de um Testador;

Nos modelos de desenvolvimento sequencial, nas fases iniciais, os Testadores normalmente participam das revisões de requisitos, da análise de testes e da modelagem de testes. O código executável geralmente é criado nas fases posteriores, portanto, os testes dinâmicos não podem ser realizados no início do SDLC. Em alguns modelos de desenvolvimento iterativos e incrementais, supõe-se que cada iteração entregue um protótipo funcional ou um incremento de produto. Isso implica que, em cada iteração, os testes estáticos e dinâmicos podem ser realizados em todos os níveis de teste. A entrega frequente de incrementos exige feedback rápido e testes de regressão extensivos. O Desenvolvimento Ágil de Software pressupõe que podem ocorrer mudanças ao longo do projeto. Portanto, a documentação leve do produto de trabalho e a ampla automação de testes para facilitar os testes de regressão são favorecidas em projetos Ágeis. Além disso, a maior parte dos testes manuais tende a ser feita usando técnicas de teste baseadas na experiência (ver seção 4.4) que não exigem análise e modelagem de teste prévio extensivo.

2.1.2 Ciclo de Vida de Desenvolvimento de Software e boas práticas de Teste

As boas práticas de teste, independentemente do modelo de SDLC escolhido, incluem:

●Para cada atividade de desenvolvimento de software, há uma atividade de teste correspondente, de modo que todas as atividades de desenvolvimento estejam sujeitas ao controle de qualidade;

●Diferentes níveis de teste (ver seção 2.2.1) têm objetivos de teste específicos e diferentes, o que permite que os testes sejam adequadamente abrangentes, evitando redundância;

●A análise e a modelagem do teste para um determinado nível de teste começam durante a fase de desenvolvimento correspondente do SDLC, para que o teste possa aderir ao princípio do teste antecipado (ver seção 1.3);

●Os Testadores estão envolvidos na revisão dos produtos de trabalho assim que os rascunhos dessa documentação estiverem disponíveis, de modo que esse teste antecipado e a detecção de defeitos possam apoiar a estratégia shift-left (ver seção 2.1.5).

2.1.3 Teste como um motivador para o desenvolvimento de software

O TDD, ATDD e BDD são abordagens de desenvolvimento semelhantes, em que os testes são definidos como um meio de direcionar o desenvolvimento. Cada uma dessas abordagens implementa o princípio do teste antecipado (ver seção 1.3) e segue uma abordagem shift-left (ver seção 2.1.5), pois os testes são definidos antes de o código ser escrito. Elas dão suporte a um modelo de desenvolvimento iterativo. Essas abordagens são caracterizadas da seguinte forma: Desenvolvimento Orientado por Testes (TDD):

●Direciona a codificação por meio de casos de teste (em vez de um projeto de software extenso) (Beck 2003);

●Os testes são escritos primeiro, depois o código é escrito para satisfazer os testes e, em seguida, os testes e o código são refatorados;

Desenvolvimento Orientado por Teste de Aceite (ATDD) (ver seção 4.5.3):

●Deriva testes de critérios de aceite como parte do processo de desenho do sistema (Gärtner 2011);

●Os testes são escritos antes que a parte do aplicativo relacionada seja desenvolvida para atender aos testes.

Desenvolvimento Orientado pelo Comportamento (BDD):

●Expressa o comportamento desejado de um aplicativo com casos de teste escritos em uma forma simples de linguagem natural, que é fácil de entender pelos stakeholders - geralmente usando o formato Dado/Quando/Então. (Chelimsky 2010);

●Os casos de teste são então traduzidos automaticamente em testes executáveis.

Para todas as abordagens acima, os testes podem persistir como testes automatizados para garantir a qualidade do código em futuras adaptações/refatoração.

2.1.4 DevOps e Testes

DevOps é uma abordagem organizacional que visa a criar sinergia, fazendo com que o desenvolvimento (incluindo os testes) e as operações trabalhem juntos para atingir um conjunto de objetivos comuns. O DevOps exige uma mudança cultural em uma organização para preencher as lacunas entre o desenvolvimento (incluindo testes) e as operações, tratando suas funções com o mesmo valor. O DevOps promove a autonomia da equipe, feedback rápido, cadeias de ferramentas integradas e práticas técnicas como Integração Contínua (CI Continuous Integration) e Entrega Contínua (CD Continuous Delivery). Isso permite que as equipes criem, testem e liberem códigos de alta qualidade mais rapidamente por meio de um pipeline de entrega de DevOps (Kim 2016). Do ponto de vista dos testes, alguns dos benefícios do DevOps são:

●Feedback rápido sobre a qualidade do código e se as alterações afetam negativamente o código existente;

●O CI promove uma abordagem shift-left nos testes (ver seção 2.1.5), incentivando os desenvolvedores a enviar códigos de alta qualidade acompanhados de testes de componentes e análise estática;

●Promove processos automatizados, como CI/CD, que facilitam o estabelecimento de ambientes de teste estáveis;

●Aumenta a visão das características de qualidade não funcionais (p. ex., performance, confiabilidade);

●A automação por meio de um pipeline de entrega reduz a necessidade de testes manuais repetitivos;

●O risco na regressão é minimizado devido à escala e ao alcance dos testes de regressão automatizados;

O DevOps tem seus riscos e desafios, que incluem:

●O pipeline de entrega de DevOps deve ser definido e estabelecido;

●As ferramentas de CI/CD devem ser introduzidas e mantidas;

●A automação de testes requer recursos adicionais e pode ser difícil de estabelecer e manter.

Embora o DevOps venha com um alto nível de testes automatizados, os testes manuais - especialmente da perspectiva do usuário - ainda serão necessários.

2.1.5 Abordagem Shift-Left

O princípio do teste antecipado (ver seção 1.3) às vezes é chamado de shift-left porque é uma abordagem em que o teste é realizado mais cedo no SDLC. Normalmente, o shift-left sugere que os testes devem ser feitos mais cedo (p. ex., não esperar que o código seja implementado ou que os componentes sejam integrados), mas isso não significa que os testes posteriores no SDLC devam ser negligenciados. Existem algumas boas práticas que ilustram como obter um "shift-left" nos testes, que incluem:

●Revisão da especificação sob a perspectiva de testes. Essas atividades de revisão das especificações geralmente encontram possíveis defeitos, como ambiguidades, incompletude e inconsistências;

●Escrever casos de teste antes de o código ser escrito e fazer com que o código seja executado em um conjunto de testes durante a sua implementação;

●Usar a CI e, melhor ainda, a CD, pois ela vem com feedback rápido e testes de componentes automatizados para acompanhar o código-fonte quando ele é enviado ao repositório de código;

●Concluir a análise estática do código-fonte antes do teste dinâmico ou como parte de um processo automatizado;

●Realizar testes não funcionais começando no nível de teste do componente, sempre que possível. Essa é uma forma de shift-left, pois esses tipos de testes não funcionais tendem a ser realizados mais tarde no SDLC, quando um sistema completo e um ambiente de teste representativo estão disponíveis.

Uma abordagem shift-left pode resultar em treinamento, esforço e/ou custos adicionais no início do processo, mas espera-se que economize esforços e/ou custos no final do processo. Para a abordagem shift-left, é importante que os stakeholders sejam convencidos a aceitarem esse conceito.

2.1.6 Retrospectivas e melhoria de processos

As retrospectivas (também conhecidas como "reuniões pós-projeto" e retrospectivas de projeto) geralmente são realizadas no final de um projeto ou de uma iteração, em um marco de lançamento, ou podem ser realizadas quando necessário. O momento e a organização das retrospectivas dependem do modelo específico de SDLC que está sendo seguido. Nessas reuniões, os participantes (não apenas os Testadores, mas também, por exemplo, Desenvolvedores, Arquitetos, Product Owner, Analistas de Negócios) discutem:

●O que foi bem-sucedido e deve ser mantido?

●O que não foi bem-sucedido e poderia ser melhorado?

●Como incorporar as melhorias e manter os sucessos no futuro?

Os resultados devem ser registrados e normalmente fazem parte do relatório de conclusão do teste (ver seção 5.3.2). As retrospectivas são essenciais para a implementações bem-sucedidas da melhoria contínua e é importante que todas as melhorias recomendadas sejam acompanhadas. Os típicos benefícios dos testes incluem:

●Aumento da eficácia/eficiência do teste (p. ex., implementando sugestões de aprimoramento do processo);

●Aumento da qualidade do material de teste (p. ex., por meio da revisão conjunta dos processos de teste);

●Vínculo e aprendizado da equipe (p. ex., como resultado da oportunidade de levantar questões e propor pontos de melhoria);

●Melhoria da qualidade da base de teste (p. ex., como as deficiências na extensão e na qualidade dos requisitos podem ser abordadas e resolvidas);

regularmente);

Níveis de Teste e Tipos de Teste

Os níveis de teste são grupos de atividades de teste que são organizadas e gerenciadas em conjunto. Cada nível de teste é uma instância do processo de teste, realizado em relação ao software em um determinado estágio de desenvolvimento, desde componentes individuais até sistemas completos ou, quando aplicável, sistemas de sistemas. Os níveis de teste estão relacionados a outras atividades dentro do SDLC. Nos modelos sequenciais do SDLC, os níveis de teste são geralmente definidos de forma que os critérios de saída de um nível façam parte dos critérios de entrada do próximo nível. Em alguns modelos iterativos, isso pode não se aplicar. As atividades de desenvolvimento podem se estender por vários níveis de teste. Os níveis de teste podem se sobrepor no tempo. Os tipos de teste são grupos de atividades de teste relacionadas a características de qualidade específicas e a maioria dessas atividades de teste pode ser realizada em todos os níveis de teste.

2.2.1 Níveis de Teste

Neste syllabus, são descritos os cinco níveis de teste a seguir:

●O Teste de Componente (também conhecido como Teste de Unidade) concentra-se em testar componentes isoladamente. Geralmente, requer suporte específico, como estruturas de teste ou frameworks de teste de unidade. Normalmente, os testes de componentes são realizados por desenvolvedores em seus ambientes de desenvolvimento.

●O Teste de Integração de Componentes (também conhecido como Teste de Integração de Unidades) concentra-se no teste das interfaces e interações entre os componentes. O teste de integração de componentes depende muito das abordagens da estratégia de integração, como bottom-up, top-down ou big-bang.

●O Teste de Sistema concentra-se no comportamento geral e nos recursos de todo um sistema ou produto, geralmente incluindo o teste funcional de tarefas de ponta a ponta e o teste não funcional de características de qualidade. Para algumas características de qualidade não funcionais, é preferível testálas em um sistema completo em um ambiente de teste representativo (p. ex., usabilidade). Também é possível usar simulações de subsistemas. O teste do sistema pode ser realizado por uma equipe de teste independente e está relacionado às especificações do sistema.

●O Teste de Integração de Sistema concentra-se no teste das interfaces do sistema e de outros sistemas e serviços externos. O teste de integração do sistema requer ambientes de teste adequados, de preferência semelhantes ao ambiente operacional.

●O Teste de Aceite concentra-se na validação e na demonstração da disposição para a implantação, o que significa que o sistema atende às necessidades (requisitos) de negócio do usuário. Preferencialmente, o teste de aceite deve ser realizado pelos usuários previstos. As principais formas de teste de aceite são: Teste de Aceite do Usuário (UAT), Teste de Aceite Operacional, Teste de Aceite Contratual e Normativo, Teste Alfa e Teste Beta.

Os níveis de teste são diferenciados pela seguinte lista incompleta de atributos, para evitar a sobreposição de atividades de teste:

●Objeto de teste;

●Objetivos do teste;

●Base de teste;

●Defeitos e falhas;

●Abordagem e responsabilidades.

2.2.2 Tipos de Teste

Existem muitos tipos de testes que podem ser aplicados em projetos. Neste programa, são abordados os quatro tipos de teste a seguir: O Teste Funcional avalia as funções que um componente ou sistema deve executar. As funções são "o que" o objeto de teste deve fazer. O principal objetivo do teste funcional é verificar a integridade funcional, a correção funcional e a adequação funcional. O Teste Não Funcional avalia atributos que não sejam características funcionais de um componente ou sistema. O teste não funcional é o teste de "quão bem o sistema se comporta". O principal objetivo do teste não funcional é verificar as características não funcionais da qualidade do software. A norma ISO/IEC 25010 fornece a seguinte classificação das características não funcionais de qualidade do software:

●Eficiência de Performance;

●Compatibilidade;

●Usabilidade;

●Confiabilidade;

●Segurança;

●Capacidade de manutenção;

●Portabilidade.

Às vezes, é apropriado que os testes não funcionais comecem no início do ciclo de vida (p. ex., como parte de revisões e testes de componentes ou testes de sistema). Muitos testes não funcionais são derivados de testes funcionais, pois usam os mesmos testes funcionais, mas verificam se, ao executar a função, uma restrição não funcional é atendida (p. ex., verificar se uma função é executada dentro de um tempo especificado ou se uma função pode ser portada para uma nova plataforma). A descoberta tardia de defeitos não funcionais pode representar uma séria ameaça ao sucesso de um projeto. Às vezes, os testes não funcionais precisam de um ambiente de teste muito específico, como um laboratório de usabilidade para testes de usabilidade. O Teste Caixa-Preta (ver seção 4.2) é baseado em especificações e deriva testes da documentação externa ao objeto de teste. O principal objetivo do teste caixa-preta é verificar o comportamento do sistema em relação às suas especificações. O Teste Caixa-Branca (ver seção 4.3) é baseado na estrutura e deriva testes da implementação ou da estrutura interna do sistema (p. ex., código, arquitetura, fluxos de trabalho e fluxos de dados). O principal objetivo do teste caixa-branca é cobrir a estrutura subjacente pelos testes até o nível aceitável. Todos os quatro tipos de teste mencionados acima podem ser aplicados a todos os níveis de teste, embora o foco seja diferente em cada nível. Diferentes técnicas de teste podem ser usadas para derivar condições de teste e casos de teste para todos os tipos de teste mencionados.

2.2.3 Testes de Confirmação e Teste de Regressão

Normalmente, as alterações são feitas em um componente ou sistema para aprimorá-lo, adicionando um novo recurso, ou para corrigi-lo, removendo um defeito. Os testes também devem incluir testes de confirmação e testes de regressão. O Teste de Confirmação confirma que um defeito original foi corrigido com sucesso. Dependendo do risco, é possível testar a versão corrigida do software de várias maneiras, inclusive:

●executando todos os casos de teste que falharam anteriormente devido ao defeito, ou, também,

●adicionar novos testes para cobrir quaisquer alterações necessárias para corrigir o defeito

No entanto, quando há pouco tempo ou dinheiro para corrigir defeitos, o teste de confirmação pode se restringir a simplesmente executar as etapas que devem reproduzir a falha causada pelo defeito e verificar se a falha não ocorre.

Os Teste de Regressão confirmam que nenhuma consequência adversa foi causada por uma alteração, inclusive uma correção que já tenha sido confirmada após o teste. Essas consequências adversas podem afetar o mesmo componente em que a alteração foi feita, outros componentes do mesmo sistema ou até mesmo outros sistemas conectados. O teste de regressão pode não se restringir ao objeto de teste em si, mas também pode estar relacionado ao ambiente. É aconselhável realizar primeiro uma análise de impacto para otimizar a extensão do teste de regressão. A análise de impacto mostra quais partes do software podem ser afetadas. Os conjuntos de testes de regressão são executados muitas vezes e, em geral, o número de casos de teste de regressão aumentará a cada iteração ou versão, portanto, os testes de regressão são fortes candidatos à automação. A automação desses testes deve começar no início do projeto. Quando a CI é usada, como no DevOps (ver seção 2.1.4), é uma boa prática incluir também testes de regressão automatizados. Dependendo da situação, isso pode incluir testes de regressão em diferentes níveis. Testes de confirmação e/ou testes de regressão para o objeto de teste são necessários em todos os níveis de teste se os defeitos forem corrigidos e/ou se forem feitas alterações nesses níveis de teste.

Há diferentes categorias de manutenção, que podem ser corretivas, adaptáveis a mudanças no ambiente ou melhorar a performance ou a capacidade de manutenção (ver ISO/IEC 14764 para mais detalhes), portanto, a manutenção pode envolver versões/implantações planejadas e versões/implantações não planejadas (hot fixes). A análise de impacto pode ser feita antes de uma alteração, para ajudar a decidir se a alteração deve ser feita, com base nas possíveis consequências em outras áreas do sistema. O teste das alterações em um sistema em produção inclui a avaliação do sucesso da implementação da alteração e a verificação de possíveis regressões em partes do sistema que permanecem inalteradas (que geralmente é a sua maior parte). O escopo dos testes de manutenção geralmente depende de:

●O grau de risco da mudança;

●O tamanho do sistema existente;

●O tamanho da mudança.

Os fatores para manutenção e teste de manutenção podem ser classificados:

●Modificações, como aprimoramentos planejados (ou seja, baseados em versões), alterações corretivas ou hot fixes;

●Atualizações ou migrações do ambiente operacional, como de uma plataforma para outra, o que pode exigir testes associados ao novo ambiente, bem como ao software alterado, ou testes de conversão de dados quando os dados de outro aplicativo são migrados para o sistema que está sendo mantido.

●Aposentadoria, por exemplo, quando um aplicativo chega ao fim de sua vida útil. Quando um sistema é desativado, isso pode exigir testes de arquivamento de dados se forem necessários longos períodos de retenção de dados. O teste dos procedimentos de restauração e recuperação após o arquivamento também pode ser necessário caso determinados dados sejam necessários durante o período de arquivamento.