Gerenciamento das Atividades de Teste

5.1.1 Objetivo e conteúdo de um Plano de Teste

Um plano de teste descreve os objetivos, os recursos e os processos de um projeto de teste. Um plano de teste:

●Documenta os meios e o cronograma para atingir os objetivos do teste;

●Ajuda a garantir que as atividades de teste realizadas atenderão aos critérios estabelecidos;

●Serve como um meio de comunicação com os membros da equipe e outros stakeholders;

●Demonstra que os testes seguirão a política e a estratégia de testes existentes (ou explica por que os testes se desviarão delas);

O planejamento de testes orienta o pensamento dos Testadores e os força a enfrentar os desafios futuros relacionados a riscos, cronogramas, pessoas, ferramentas, custos, esforços etc. O processo de preparação de um plano de teste é uma maneira útil de pensar nos esforços necessários para atingir os objetivos do projeto de teste. O conteúdo típico de um plano de teste inclui:

●Contexto do teste (p. ex., escopo, objetivos do teste, restrições, base do teste);

●Premissas e restrições do projeto de teste;

●Stakeholders (p. ex., funções, responsabilidades, relevância para os testes, necessidades de contratação e treinamento);

●Comunicação (p. ex., formas e frequência de comunicação, modelos de documentação);

●Registro de riscos (p. ex., riscos do produto, riscos do projeto);

●Abordagem de teste (p. ex., níveis de teste, tipos de teste, técnicas de teste, produtos de teste, critérios de entrada e de saída, independência do teste, métricas a serem coletadas, requisitos de dados de teste, requisitos de ambiente de teste, desvios da política de teste organizacional e da estratégia de teste);

●Orçamento e cronograma.

Mais detalhes sobre o plano de teste e seu conteúdo podem ser encontrados na norma Isso/IEC/IEEE 29119-3.

5.1.2 Contribuição do Testador para o planejamento de iteração e liberação

Nos SDLCs iterativos, normalmente ocorrem dois tipos de planejamento: planejamento de liberação e planejamento de iteração. O planejamento da liberação prevê o lançamento de um produto, define e redefine o backlog do produto e pode envolver o refinamento de histórias de usuários maiores em um conjunto de histórias de usuários menores. Ele também serve como base para a abordagem e o plano de teste em todas as iterações. Os Testadores envolvidos no planejamento da liberação participam da escrita das histórias de usuário e critérios de aceite testáveis (ver seção 4.5), participam das análises de risco do projeto e da qualidade (ver seção 5.2), estimam o esforço de teste associado às histórias de usuário (ver seção 5.1.4), determinam a abordagem de teste e planejam o teste para a versão. O planejamento da iteração prevê o fim de uma única iteração e se preocupa com o backlog da iteração. Os Testadores envolvidos participam da análise de risco detalhada das histórias de usuários, determinam a testabilidade das histórias, dividem-nas em tarefas (especialmente tarefas de teste), estimam o esforço de teste para todas as tarefas de teste e identificam e refinam os aspectos funcionais e não funcionais do objeto de teste.

5.1.3 Critérios de Entrada e Critérios de Saída

Os critérios de entrada definem as condições prévias para a realização de uma determinada atividade. Se os critérios de entrada não forem atendidos, é provável que a atividade seja mais difícil, demorada, cara e arriscada. Os critérios de saída definem o que deve ser alcançado para que uma atividade seja declarada concluída. Os critérios de entrada e os critérios de saída devem ser definidos para cada nível de teste e serão diferentes com base nos objetivos do teste. Os critérios de entrada típicos incluem: disponibilidade de recursos (p. ex., pessoas, ferramentas, ambientes, dados de teste, orçamento, tempo), disponibilidade de material de teste (p. ex., base de teste, requisitos testáveis, histórias de usuários, casos de teste) e nível de qualidade inicial de um objeto de teste (p. ex., todos os testes de fumaça foram aprovados). Os critérios de saída típicos incluem: medidas de precisão (p. ex., nível de cobertura alcançado, número de defeitos não resolvidos, densidade de defeitos, número de casos de teste com falha) e critérios de conclusão (p. ex., testes planejados foram executados, testes estáticos foram realizados, todos os defeitos encontrados foram relatados, todos os testes de regressão foram automatizados). O esgotamento do tempo ou do orçamento também pode ser visto como um critério de saída válido. Mesmo sem que outros critérios de saída sejam atendidos, pode ser aceitável encerrar os testes nessas circunstâncias, se os stakeholders tiverem analisado e aceitado o risco de entrar em operação sem mais testes.

No desenvolvimento ágil de software, os critérios de saída são geralmente chamados de Definição de Feito (DoD Definition of Done), definindo as métricas objetivas da equipe para um item liberável. Os critérios de entrada que uma história de usuário deve cumprir para iniciar as atividades de desenvolvimento e/ou teste são chamados de Definição de Pronto (DoR - Definition of Ready).

5.1.4 Técnicas de estimativa

A estimativa do esforço de teste envolve a previsão da quantidade de trabalho relacionado ao teste necessária para atender aos objetivos de um projeto de teste. É importante deixar claro para os stakeholders que a estimativa é baseada em várias suposições e está sempre sujeita a erros. A estimativa para tarefas pequenas geralmente é mais precisa do que para as grandes. Portanto, ao estimar uma tarefa grande, ela pode ser decomposta em um conjunto de tarefas menores que, por sua vez, podem ser estimadas. Neste syllabus, são descritas as quatro técnicas de estimativa a seguir. Estimativa baseada em índices. Nessa técnica baseada em métricas, os números são coletados de projetos anteriores dentro da organização, o que torna possível derivar “indicadores padrão" para projetos semelhantes. As proporções dos próprios projetos de uma organização (p. ex., extraídas de dados históricos) geralmente são a melhor fonte a ser usada no processo de estimativa. Esses indicadores padrão podem então ser usados para estimar o esforço de teste para o novo projeto. Por exemplo, se no projeto anterior a proporção de esforço de desenvolvimento para teste foi de 3:2 e no projeto atual espera-se que o esforço de desenvolvimento seja de 600 homens/hora, o esforço de teste pode ser estimado em 400 homens/hora. Extrapolação. Nessa técnica baseada em métricas, as medições são feitas o mais cedo possível no projeto atual para coletar os dados. Com observações suficientes, o esforço necessário para o trabalho restante pode ser aproximado por meio da extrapolação desses dados (geralmente aplicando um modelo matemático). Esse método é muito adequado em SDLCs iterativos. Por exemplo, a equipe pode extrapolar o esforço de teste na próxima iteração como o esforço médio das três últimas iterações. Wideband Delphi. Essa técnica iterativa é baseada em especialistas que fazem estimativas baseadas na experiência. Cada especialista, isoladamente, estima o esforço. Os resultados são coletados e, se houver desvios que estejam fora da faixa dos limites acordados, os especialistas discutem suas estimativas atuais. Em seguida, pede-se a cada especialista que faça uma nova estimativa com base nesse feedback, novamente de forma isolada. Esse processo é repetido até que se chegue a um consenso. O Planning Poker é uma variante do Wideband Delphi, comumente utilizado no desenvolvimento ágil de software. No Planning Poker, as estimativas geralmente são feitas usando cartões com números que representam o tamanho do esforço. Estimativa de três pontos. Nessa técnica baseada em especialistas, três estimativas são feitas pelos especialistas: a estimativa mais otimista (o), a estimativa mais provável (m) e a estimativa mais pessimista (p). A estimativa final (E) é a média aritmética ponderada dessas estimativas. Na versão mais popular dessa técnica, a estimativa é calculada como:

𝐸=

𝑜 + 4𝑚 + 𝑝 6

A vantagem dessa técnica é que ela permite que os especialistas calculem o erro de medição:

𝑆𝐷 =

(𝑝 − 𝑜) 6

Por exemplo, se as estimativas (em homens/hora) forem: o=6, m=9 e p=18, então a estimativa final é de 10±2 homens/hora (ou seja, entre 8 e 12 homens/hora), porque:

𝐸=

6+36+18 6

= 10 e 𝑆𝐷 =

(18−6) 6

=2

Consulte (Kan 2003, Koomen 2006, Westfall 2009) para conhecer essas e muitas outras técnicas de estimativa de teste.

5.1.5 Priorização de casos de teste

Depois que os casos de teste e os procedimentos de teste são especificados e reunidos em conjuntos de testes, esses conjuntos de testes podem ser organizados em um cronograma de execução de testes que define a ordem em que devem ser executados. Ao priorizar os casos de teste, diferentes fatores podem ser levados em conta. As estratégias de priorização de casos de teste mais comumente usadas são as seguintes:

●Priorização baseada em risco, em que a ordem de execução do teste é baseada nos resultados da análise de risco (ver seção 5.2.3). Os casos de teste que abrangem os riscos mais importantes são executados primeiro.

●Priorização baseada em cobertura, em que a ordem de execução do teste é baseada na cobertura (p. ex., cobertura de instrução). Os casos de teste que atingem a maior cobertura são executados primeiro. Em outra variante, chamada de priorização de cobertura adicional, o caso de teste que atinge a maior cobertura é executado primeiro; cada caso de teste subsequente é aquele que atinge a maior cobertura adicional.

●Priorização baseada em requisitos, em que a ordem de execução do teste é baseada nas prioridades dos requisitos rastreados até os casos de teste correspondentes. As prioridades dos requisitos são definidas pelos stakeholders. Os casos de teste relacionados aos requisitos mais importantes são executados primeiro.

Preferencialmente, os casos de teste seriam ordenados para execução com base em seus níveis de prioridade, usando, por exemplo, uma das estratégias de priorização mencionadas anteriormente. Entretanto, essa prática pode não funcionar se os casos de teste ou os recursos que estão sendo testados tiverem dependências. Se um caso de teste com prioridade mais alta for dependente de um caso de teste com prioridade mais baixa, o caso de teste de prioridade mais baixa deverá ser executado primeiro. A ordem de execução do teste também deve levar em conta a disponibilidade de recursos. Por exemplo, as ferramentas de teste necessárias, os ambientes de teste ou as pessoas que podem estar disponíveis apenas em um período específico.

5.1.6 Pirâmide de Teste

A pirâmide de teste é um modelo que mostra que diferentes testes podem ter diferentes granularidades. O modelo da pirâmide de testes apoia a equipe na automação de testes e na alocação de esforço de teste, mostrando que diferentes objetivos são apoiados por diferentes níveis de automação de testes. As camadas da pirâmide representam grupos de testes. Quanto mais alta a camada, menor a granularidade do teste, o isolamento do teste e o tempo de execução do teste. Os testes na camada inferior são pequenos, isolados, rápidos e verificam uma pequena parte da funcionalidade, portanto, geralmente são necessários muitos deles para obter uma cobertura razoável. A camada superior representa testes complexos, de alto nível e de ponta a ponta. Esses testes de alto nível geralmente são mais lentos do que os testes das camadas inferiores e, normalmente, verificam uma grande parte da funcionalidade, de modo que, em geral, são necessários apenas alguns deles para obter uma cobertura razoável. O número e a nomenclatura das camadas podem ser diferentes. Por exemplo, o modelo original da pirâmide de testes (Cohn 2009) define três camadas: "testes de unidade“, "testes de serviço" e "testes de interface do usuário". Outro modelo popular define testes de unidade (componente), testes de integração (integração de componente) e testes de ponta a ponta. Outros níveis de teste (ver seção 2.2.1) também podem ser usados.

5.1.7 Quadrantes de Teste

Os quadrantes de teste, definidos por Brian Marick (Marick 2003, Crispin 2008), agrupam os níveis de teste com os tipos de teste, as atividades, as técnicas de teste e os produtos de trabalho apropriados no desenvolvimento ágil de software. O modelo ajuda o gerenciamento de testes a visualizá-los para garantir que todos os tipos e níveis de teste apropriados sejam incluídos no SDLC e a entender que alguns tipos de teste são mais relevantes para determinados níveis de teste do que outros. Esse modelo também fornece uma maneira de diferenciar e descrever os tipos de testes para todos os stakeholders, incluindo desenvolvedores, Testadores e representantes do negócio.

Nesse modelo, os testes podem ser voltados para os negócios ou para a tecnologia. Os testes também podem apoiar a equipe (ou seja, orientar o desenvolvimento) ou criticar o produto (ou seja, medir seu comportamento em relação às expectativas). A combinação desses dois pontos de vista determina os quatro quadrantes:

●Quadrante Q1 (voltado para a tecnologia, apoia a equipe). Esse quadrante contém testes de componentes e de integração de componentes. Esses testes devem ser automatizados e incluídos no processo de CI.

●Quadrante Q2 (voltado para os negócios, apoia a equipe). Esse quadrante contém testes funcionais, exemplos, testes de histórias de usuários, protótipos de experiência do usuário, testes de API e simulações. Esses testes verificam os critérios de aceite e podem ser manuais ou automatizados.

●Quadrante Q3 (voltado para os negócios, avalia o produto). Esse quadrante contém testes exploratórios, testes de usabilidade e testes de aceite do usuário. Esses testes são orientados para o usuário e geralmente manuais.

●Quadrante Q4 (voltado para a tecnologia, avalia o produto). Esse quadrante contém smoke tests e testes não funcionais (exceto testes de usabilidade). Esses testes geralmente são automatizados.

As organizações enfrentam muitos fatores internos e externos que tornam incerto se e quando elas atingirão seus objetivos (ISO31000). O gerenciamento de riscos permite que as organizações aumentem a probabilidade de atingir seus objetivos, melhorem a qualidade de seus produtos e aumentem a confiança dos stakeholders. As principais atividades de gerenciamento de riscos são:

●Análise de risco (que consiste na identificação e avaliação de risco. (ver seção 5.2.3)

●Controle de riscos (que consiste na mitigação e monitoramento de riscos. (ver seção 5.2.4)

A abordagem de teste, na qual as atividades de teste são selecionadas, priorizadas e gerenciadas com base na análise e no controle de riscos, é chamada de teste baseado em riscos.

5.2.1 Definição de Risco e Atributos do Risco

Risco é um possível evento, perigo, ameaça ou situação cuja ocorrência causa um efeito adverso. Um risco pode ser caracterizado por dois fatores:

●Probabilidade: a probabilidade de ocorrência do risco (maior que zero e menor que um)

●Impacto (dano): as consequências dessa ocorrência

Esses dois fatores expressam o nível de risco, que é uma medida do risco. Quanto maior o nível de risco, mais importante é o seu tratamento.

5.2.2 Riscos do projeto e riscos do produto

No teste de software, geralmente nos preocupamos com dois tipos de riscos: riscos de projeto e riscos de produto. Os Riscos do Projeto estão relacionados ao gerenciamento e ao controle do projeto. Os riscos do projeto incluem:

●Problemas organizacionais (p. ex., atrasos na entrega de produtos de trabalho, estimativas imprecisas, redução de custos)

●Problemas de pessoal (p. ex., habilidades insuficientes, conflitos, problemas de comunicação, falta de pessoal)

●Problemas técnicos (p. ex., desvios de escopo, suporte insuficiente a ferramentas)

●Problemas com fornecedores (p. ex., falha na entrega de terceiros, falência da empresa de apoio)

Os riscos do projeto, quando ocorrem, podem ter um impacto no cronograma, no orçamento ou no escopo do projeto, o que afeta a capacidade do projeto de atingir seus objetivos. Os Riscos do Produto estão relacionados às características de qualidade do produto (p. ex., descritas no modelo de qualidade ISO 25010). Exemplos de riscos do produto incluem: funcionalidade ausente ou errada, cálculos incorretos, erros de tempo de execução, arquitetura ruim, algoritmos ineficientes, tempo de resposta inadequado, experiência ruim do usuário, vulnerabilidades de segurança. Os riscos do produto, quando ocorrem, podem resultar em várias consequências negativas, incluindo:

●Insatisfação do usuário;

●Perda de receita, confiança e reputação;

●Danos a terceiros;

●Altos custos de manutenção, e sobrecarga do helpdesk;

●Penalidades criminais;

●Em casos extremos, danos físicos, lesões ou até mesmo a morte.

5.2.3 Análise de Risco do Produto

Do ponto de vista do teste, o objetivo da análise de risco do produto é proporcionar uma conscientização do risco do produto para concentrar o esforço de teste de forma a minimizar o nível residual de risco do produto. O ideal é que a análise comece no início do SDLC. A análise de risco do produto consiste na identificação e na avaliação de riscos. A identificação de riscos consiste em gerar uma lista abrangente de riscos. Os stakeholders podem identificá-los usando várias técnicas e ferramentas, como, por exemplo, brainstorming, workshops, entrevistas ou diagramas de causa e efeito. A avaliação de riscos envolve: a categorização dos riscos identificados, a determinação da probabilidade, do impacto e do nível dos riscos, a priorização e a proposta de maneiras de lidar com eles. A categorização ajuda a atribuir ações de mitigação, porque geralmente os riscos que se enquadram na mesma categoria podem ser mitigados usando uma abordagem semelhante. A avaliação de riscos pode usar uma abordagem quantitativa ou qualitativa, ou uma combinação delas. Na abordagem quantitativa, o nível de risco é calculado como a multiplicação da probabilidade de risco e do impacto do risco. Na abordagem qualitativa, o nível de risco pode ser determinado usando uma matriz de risco. A análise de risco do produto pode influenciar a minúcia e o escopo dos testes. Seus resultados são usados para:

●Determinar o escopo dos testes a serem realizados;

●Determinar os níveis de teste específicos e propor os tipos de teste a serem realizados;

●Determinar as técnicas de teste a serem empregadas e a cobertura a ser alcançada;

●Estimar o esforço de teste necessário para cada tarefa;

●Priorizar os testes em uma tentativa de encontrar os defeitos críticos o mais cedo possível;

●Determinar se outras atividades, além dos testes, podem ser empregadas para reduzir o risco.

5.2.4 Controle de Risco do Produto

O controle de riscos do produto compreende todas as medidas tomadas em resposta aos riscos identificados e avaliados do produto. O controle de riscos do produto consiste na mitigação e no monitoramento dos riscos. Esta mitigação envolve a implementação das ações propostas na avaliação de riscos para reduzir o nível de risco. O objetivo do monitoramento de riscos é garantir que as ações de mitigação sejam eficazes, obtenham mais informações para melhorar a avaliação de riscos e identificar riscos emergentes. Com relação ao controle de riscos do produto, uma vez que um risco tenha sido analisado, várias opções de resposta ao risco são possíveis, por exemplo, mitigação do risco por meio de testes, aceite do risco, transferência do risco ou plano de contingência (Veenendaal 2012). As ações que podem ser tomadas para mitigar os riscos do produto por meio de testes são as seguintes:

●Selecionar os Testadores com o nível de experiência e habilidade adequado para um determinado tipo de risco;

●Aplicar um nível adequado de independência de testes;

●Conduzir revisões e realizar análises estáticas;

●Aplicar as técnicas de teste e os níveis de cobertura adequados;

●Aplicar os tipos de teste apropriados que abordam as características de qualidade afetadas;

●Realizar testes dinâmicos, incluindo testes de regressão.

O monitoramento de testes está relacionado à coleta de informações sobre os testes. Essas informações são usadas para avaliar o progresso do teste e para medir se os critérios de saída do teste ou as tarefas de teste associadas aos critérios de saída foram atendidos, como o cumprimento das metas de cobertura dos riscos, requisitos ou critérios de aceite do produto. O controle de testes usa as informações do monitoramento de testes para fornecer, na forma de diretrizes de controle, orientação e as ações corretivas necessárias para obter testes mais eficazes e eficientes. Exemplos de diretrizes de controle incluem:

●Repriorizar os testes quando um risco identificado se torna um problema;

●Reavaliar se um item de teste atende aos critérios de entrada ou saída devido ao retrabalho;

●Ajustar o cronograma de testes para lidar com um atraso na entrega do ambiente de teste;

●Adicionar novos recursos quando e onde forem necessário.

A conclusão do teste coleta dados de atividades de teste concluídas para consolidar a experiência, o material de teste e qualquer outra informação relevante. As atividades de conclusão do teste ocorrem em marcos do projeto, como quando um nível de teste é concluído, uma iteração Ágil é finalizada, um projeto de teste é concluído (ou cancelado), um sistema de software é lançado ou uma versão de manutenção é concluída.

5.3.1 Métricas usadas em testes

As métricas de teste são reunidas para mostrar o progresso em relação ao cronograma e orçamento planejados, a qualidade atual do objeto de teste e a eficácia das atividades de teste em relação aos objetivos ou a uma meta de iteração. O monitoramento do teste reúne uma variedade de métricas para apoiar o controle e a conclusão do teste. As métricas de teste comuns incluem:

●Métricas de progresso do projeto (p. ex., conclusão de tarefas, uso de recursos, esforço de teste);

●Métricas de progresso do teste (p. ex., progresso da implementação do caso de teste, progresso da preparação do ambiente de teste, número de casos de teste executados/não executados, aprovados/fracassados, tempo de execução do teste);

●Métricas de qualidade do produto (p. ex., disponibilidade, tempo de resposta, tempo médio até a falha);

●Métricas de defeitos (p. ex., número e prioridades de defeitos encontrados/corrigidos, densidade de defeitos, porcentagem de detecção de defeitos);

●Métricas de risco (p. ex., nível de risco residual);

●Métricas de cobertura (p. ex., cobertura de requisitos, cobertura de código);

●Métricas de custo (p. ex., custo de teste, custo organizacional de qualidade).

5.3.2 Relatórios de Teste: objetivo, conteúdo e público-alvo

Os relatórios de teste resumem e comunicam as informações do teste durante e após o teste. Os relatórios de progresso do teste dão suporte ao controle contínuo do teste e devem fornecer informações suficientes para fazer modificações no cronograma, nos recursos ou no plano de teste, quando essas alterações forem necessárias devido a desvios do plano ou mudanças nas circunstâncias. Os relatórios de conclusão do teste resumem um estágio específico do teste (p. ex., nível de teste, ciclo de teste, iteração) e podem fornecer informações para testes subsequentes. Durante o monitoramento e o controle do teste, a equipe de teste gera relatórios de progresso do teste para os stakeholders, a fim de mantê-los informados. Os relatórios de progresso do teste geralmente são gerados regularmente (p. ex., diariamente, semanalmente etc.) e incluem:

●Período de teste;

●Progresso do teste (p. ex., adiantado ou atrasado), incluindo quaisquer desvios notáveis;

●Impedimentos para testes e suas soluções;

●Métricas de teste (ver seção 5.3.1 para obter exemplos);

●Riscos novos e alterados durante o período de teste;

●Testes planejados para o próximo período.

Um relatório de conclusão de teste é preparado durante a conclusão do teste, quando um projeto, nível de teste ou tipo de teste está concluído e quando, idealmente, seus critérios de saída foram atendidos. Esse relatório usa relatórios de progresso do teste e outros dados. Os relatórios típicos de conclusão de teste incluem:

●Resumo do teste;

●Testes e avaliação da qualidade do produto com base no plano de teste original (ou seja, objetivos de teste e critérios de saída);

●Desvios do plano de teste (p. ex., diferenças em relação ao cronograma, à duração e ao esforço planejados);

●Impedimentos e soluções alternativas para o teste;

●Métricas de teste baseadas em relatórios de progresso de teste;

●Riscos não mitigados, defeitos não corrigidos;

●Lições aprendidas que são relevantes para o teste;

Públicos diferentes exigem informações diferentes nos relatórios e influenciam o grau de formalidade e a frequência dos relatórios. Os relatórios sobre o progresso dos testes para outras pessoas da mesma equipe costumam ser frequentes e informais, enquanto os relatórios sobre os testes de um projeto concluído seguem um modelo definido e ocorrem apenas uma vez. A norma ISO/IEC/IEEE 29119-3 inclui modelos e exemplos de relatórios de progresso de teste (chamados de relatórios de status de teste) e relatórios de conclusão de teste.

5.3.3 Comunicação do status dos testes

O melhor meio de comunicar o status do teste varia, dependendo das preocupações com o gerenciamento de testes, das estratégias de teste da organização, dos padrões normativos ou, no caso de equipes auto-organizadas (ver seção 1.5.2), da própria equipe. As opções incluem:

●Comunicação verbal com membros da equipe e outros stakeholders;

●Painéis (p. ex., painéis de CI/CD, painéis de tarefas e gráficos de burn-down);

●Canais de comunicação eletrônica (p. ex., e-mail, bate-papo);

●Documentação on-line;

●Relatórios de testes formais (ver seção 5.3.2).

Uma ou mais dessas opções podem ser usadas. Uma comunicação mais formal pode ser mais apropriada para equipes distribuídas, em que a comunicação direta, face a face, nem sempre é possível devido à distância geográfica ou às diferenças de horário. Normalmente, diferentes stakeholders estão interessados em diferentes tipos de informações, portanto, a comunicação deve ser adaptada de acordo.

Nos testes, o gerenciamento de configuração (CM - Configuration Management) oferece uma disciplina para identificar, controlar e rastrear produtos de trabalho, como planos de teste, estratégias de teste, condições de teste, casos de teste, scripts de teste, resultados de teste, registros de teste e relatórios de teste como itens de configuração. Para um item de configuração complexo (p. ex., um ambiente de teste), o CM registra os itens que o compõem, seus relacionamentos e versões. Se o item de configuração for aprovado para teste, ele se tornará uma linha de base e só poderá ser alterado por meio de um processo formal de controle de alterações. O gerenciamento de configuração mantém um registro dos itens de configuração alterados quando uma nova baseline é criada. É possível reverter para uma baseline anterior para reproduzir resultados de testes anteriores. Para dar suporte adequado aos testes, o CM garante o seguinte:

●Todos os itens de configuração, incluindo itens de teste (partes individuais do objeto de teste), são identificados de forma exclusiva, controlados por versão, rastreados quanto a alterações e relacionados a outros itens de configuração para que a rastreabilidade possa ser mantida durante todo o processo de teste

●Todos os itens de documentação e software identificados são referenciados sem ambiguidade na documentação de teste

A integração contínua, a entrega contínua, a implantação contínua e os testes associados normalmente são implementados como parte de um pipeline de DevOps automatizado (ver seção 2.1.4), no qual a CM automatizada normalmente está incluída.

Como um dos principais objetivos do teste é encontrar defeitos, um processo de gerenciamento de defeitos estabelecido é essencial. Embora digamos "defeitos", aqui as anomalias relatadas podem se tornar defeitos reais ou outra coisa (p. ex., falso positivo, solicitação de–alteração) - isso é resolvido durante o processo de tratamento dos relatórios de defeitos. As anomalias podem ser relatadas durante qualquer fase do SDLC e a forma depende do SDLC. No mínimo, o processo de gerenciamento de defeitos inclui um fluxo de trabalho para lidar com anomalias individuais, desde sua descoberta até seu fechamento, e regras para sua classificação. O fluxo de trabalho normalmente inclui atividades para registrar as anomalias, analisá-las, classificá-las, decidir sobre uma resposta adequada, como consertar ou manter como está e, finalmente, fechar o relatório de defeitos. O processo deve ser seguido por todas os stakeholders envolvidos. É aconselhável lidar com os defeitos dos testes estáticos (especialmente a análise estática) de maneira semelhante. Os típicos relatórios de defeitos possuem os seguintes objetivos:

●Fornecer aos responsáveis pelo tratamento e solução dos defeitos relatados informações suficientes para resolver o problema;

●Fornecer os meios de rastrear a qualidade do produto do trabalho;

●Fornecer ideias para aprimoramento do processo de desenvolvimento e teste.

Um relatório de defeitos registrado durante um teste dinâmico normalmente possui:

●Um identificador exclusivo;

●Um título com um breve resumo da anomalia que está sendo relatada;

●A data em que a anomalia foi observada, a organização emissora e o autor, incluindo seu cargo;

●A identificação do objeto de teste e do ambiente de teste;

●O contexto do defeito (p. ex., caso de teste que está sendo executado, atividade de teste que está sendo realizada, fase do SDLC e outras informações relevantes, como a técnica de teste, a lista de verificação ou os dados de teste que estão sendo usados);

●A descrição da falha para permitir a reprodução e a resolução, incluindo as etapas que detectaram a anomalia e todos os registros de teste relevantes, despejos de banco de dados, capturas de tela ou gravações;

●Os resultados esperados e os resultados reais;

●A severidade do defeito (grau de impacto) nos interesses dos stakeholders ou nos requisitos;

●A prioridade de correção;

●O status do defeito (p. ex., aberto, adiado, duplicado, aguardando correção, aguardando teste de confirmação, reaberto, fechado, rejeitado);

●As referências (p. ex., ao caso de teste).

Alguns desses dados podem ser incluídos automaticamente ao usar ferramentas de gerenciamento de defeitos (p. ex., identificador, data, autor e status inicial). Modelos de documentos para um relatório de defeitos e exemplos de relatórios de defeitos podem ser encontrados na norma ISO/IEC/IEEE 29119-3, que se refere a relatórios de defeitos como relatórios de incidentes.