Análise e Modelagem de Teste

As técnicas de teste dão suporte ao Testador na análise do teste (o que testar) e no projeto do teste (como testar). As técnicas de teste ajudam a desenvolver um conjunto relativamente pequeno, mas suficiente, de casos de teste de forma sistemática. As técnicas de teste também ajudam o Testador a definir as condições de teste, identificar os itens de cobertura e identificar os dados de teste durante a análise e o projeto do teste. Mais informações sobre técnicas de teste e suas medidas correspondentes podem ser encontradas no padrão ISO/IEC/IEEE 29119-4 e em (Beizer 1990, Craig 2002, Copeland 2004, Koomen 2006, Jorgensen 2014, Ammann 2016, Forgács 2019). Neste syllabus, as técnicas de teste são classificadas como caixa-preta, caixa-branca e baseadas na experiência. As Técnicas de Teste Caixa-Preta (também conhecidas como técnicas baseadas em especificações) são baseadas em uma análise do comportamento específico do objeto de teste sem referência à sua estrutura interna. Portanto, os casos de teste são independentes de como o software é implementado. Consequentemente, se a implementação mudar, mas o comportamento exigido permanecer o mesmo, os casos de teste ainda serão úteis. As Técnicas de Teste Caixa-Branca (também conhecidas como técnicas baseadas na estrutura) baseiam-se em uma análise da estrutura interna e do processamento do objeto de teste. Como os casos de teste dependem de como o software é projetado, eles só podem ser criados após o projeto ou a implementação do objeto de teste. As Técnicas de Teste Baseadas na Experiência usam efetivamente o conhecimento e a experiência dos Testadores para o projeto e a implementação dos casos de teste. A eficácia dessas técnicas depende muito das habilidades do Testador. As técnicas de teste baseadas na experiência podem detectar defeitos que podem não ser detectados usando as técnicas de teste caixa-preta e caixa-branca. Portanto, as técnicas de teste baseadas na experiência são complementares às técnicas de teste caixa-preta e caixa-branca.

As técnicas de teste caixa-preta comumente usadas e discutidas nas seções a seguir são:

●Particionamento de equivalência;

●Análise de valor de limite;

●Teste de tabela de decisão;

●Teste de transição de estado;

4.2.1 Particionamento de Equivalência (EP)

O Particionamento de Equivalência (EP) divide os dados em partições (conhecidas como partições de equivalência) com base na expectativa de que todos os elementos de uma determinada partição sejam processados da mesma forma pelo objeto de teste. A teoria por trás dessa técnica é que, se um caso de teste, que testa um valor de uma partição de equivalência, detectar um defeito, esse defeito também deverá ser detectado por casos de teste que testem qualquer outro valor da mesma partição. Portanto, um teste para cada partição é suficiente. As partições de equivalência podem ser identificadas para qualquer elemento de dados relacionado ao objeto de teste, incluindo entradas, saídas, itens de configuração, valores internos, valores relacionados ao tempo e parâmetros de interface. As partições podem ser contínuas ou discretas, ordenadas ou não ordenadas, finitas ou infinitas. As partições não devem se sobrepor e devem ser conjuntos não vazios. No caso de objetos de teste simples, o EP pode ser fácil, mas, na prática, entender como o objeto de teste tratará valores diferentes costuma ser complicado. Portanto, o particionamento deve ser feito com cuidado. Uma partição que contém valores válidos é chamada de partição válida. Uma partição que contém valores inválidos é chamada de partição inválida. As definições de valores válidos e inválidos podem variar entre equipes e organizações. Por exemplo, os valores válidos podem ser interpretados como aqueles que devem ser processados pelo objeto de teste ou como aqueles para os quais a especificação define seu processamento. Os valores inválidos podem ser interpretados como aqueles que devem ser ignorados ou rejeitados pelo objeto de teste ou como aqueles para os quais nenhum processamento é definido na especificação do objeto de teste.

No EP, os itens de cobertura são as partições de equivalência. Para atingir 100% de cobertura com essa técnica, os casos de teste devem executar todas as partições identificadas (inclusive as inválidas), cobrindo cada partição pelo menos uma vez. A cobertura é medida como o número de partições executadas por pelo menos um caso de teste, dividido pelo número total de partições identificadas, e é expressa como uma porcentagem. Muitos objetos de teste incluem vários conjuntos de partições (p. ex., objetos de teste com mais de um parâmetro de entrada), o que significa que um caso de teste abrangerá partições de diferentes conjuntos de partições. O critério de cobertura mais simples no caso de vários conjuntos de partições é chamado de Each Choice Coverage (ECC) (Ammann 2016). A cobertura de cada escolha exige que os casos de teste executem cada partição de cada conjunto de partições pelo menos uma vez. A cobertura de cada escolha não leva em conta as combinações de partições.

4.2.2 Análise de Valor de Limite (BVA)

A BVA (Boundary Value Analysis) é uma técnica baseada na execução dos limites das partições de equivalência. Portanto, a BVA só pode ser usada para partições ordenadas. Os valores mínimo e máximo de uma partição são seus valores de limite. No caso da BVA, se dois elementos pertencem à mesma partição, todos os elementos entre eles também devem pertencer a essa partição. O BVA concentra-se nos valores de limite das partições porque os desenvolvedores têm maior probabilidade de cometer erros com esses valores de limite. Os defeitos típicos encontrados pelo BVA estão localizados onde os limites implementados estão mal posicionados em posições acima ou abaixo das posições pretendidas ou são totalmente omitidos. Este syllabus abrange duas versões do BVA: BVA de 2 valores e BVA de 3 valores. Elas diferem em termos de itens de cobertura por limite que precisam ser executados para atingir 100% de cobertura. No BVA de 2 valores (Craig 2002, Myers 2011), para cada valor de limite há dois itens de cobertura: esse valor de limite e seu vizinho mais próximo pertencente à partição adjacente. Para atingir 100% de cobertura com o BVA de 2 valores, os casos de teste devem executar todos os itens de cobertura, ou seja, todos os valores de limite identificados. A cobertura é medida como o número de valores de limite que foram executados, dividido pelo número total de valores de limite identificados, e é expressa como uma porcentagem. No BVA de 3 valores (Koomen 2006, O'Regan 2019), para cada valor de limite há três itens de cobertura: esse valor de limite e seus dois vizinhos. Portanto, no BVA de 3 valores, alguns dos itens de cobertura podem não ser valores de limite. Para atingir 100% de cobertura com o BVA de 3 valores, os casos de teste devem executar todos os itens de cobertura, ou seja, os valores de limite identificados e seus vizinhos. A cobertura é medida como o número de valores de limite e seus vizinhos executados, dividido pelo número total de valores de limite identificados e seus vizinhos, e é expressa como uma porcentagem. O BVA de 3 valores é mais rigoroso do que o BVA de 2 valores, pois pode detectar defeitos ignorados pelo BVA de 2 valores. Por exemplo, se a decisão "se (x ≤ 10) ..." for implementada incorretamente como "se (x = 10) ...", nenhum dado de teste derivado do BVA de 2 valores (x = 10, x = 11) poderá detectar o defeito. Entretanto, x = 9, derivado do BVA de 3 valores, provavelmente detectará o defeito.

4.2.3 Teste de Tabela de Decisão

As tabelas de decisão são usadas para testar a implementação dos requisitos do sistema que especificam como diferentes combinações de condições resultam em diferentes resultados. As tabelas de decisão são uma forma eficaz de registrar lógicas complexas, como regras de negócios. Ao criar tabelas de decisão, são definidas as condições e as ações resultantes do sistema. Elas formam as linhas da tabela. Cada coluna corresponde a uma regra de decisão que define uma combinação única de condições, juntamente com as ações associadas. Nas tabelas de decisão de entrada limitada, todos os valores das condições e ações (exceto os irrelevantes ou inviáveis; veja abaixo) são mostrados como valores booleanos (verdadeiro ou falso). Como alternativa, em tabelas de decisão de entrada estendida, algumas ou todas as condições e ações também podem assumir valores múltiplos (p. ex., intervalos de números, partições de equivalência, valores discretos). A notação para condições é a seguinte: "V" (verdadeiro) significa que a condição foi satisfeita. "F" (falso) significa que a condição não foi satisfeita. "-" significa que o valor da condição é irrelevante para o resultado da ação. "N/A"

significa que a condição é inviável para uma determinada regra. Para ações: "X" significa que a ação deve ocorrer. Em branco significa que a ação não deve ocorrer. Outras notações também podem ser usadas. Uma tabela de decisão completa tem colunas suficientes para cobrir todas as combinações de condições. A tabela pode ser simplificada com a exclusão de colunas que contenham combinações inviáveis de condições. A tabela também pode ser minimizada pela fusão de colunas, nas quais algumas condições não afetam o resultado, em uma única coluna. Os algoritmos de minimização da tabela de decisão estão fora do escopo deste programa. No teste de tabela de decisão, os itens de cobertura são as colunas que contêm combinações viáveis de condições. Para atingir 100% de cobertura com essa técnica, os casos de teste devem executar todas essas colunas. A cobertura é medida como o número de colunas executadas, dividido pelo número total de colunas viáveis, e é expressa como uma porcentagem. O ponto forte do teste de tabela de decisão é que ele oferece uma abordagem sistemática para identificar todas as combinações de condições, algumas das quais poderiam ser negligenciadas. Ele também ajuda a encontrar quaisquer lacunas ou contradições nos requisitos. Se houver muitas condições, a execução de todas as regras de decisão pode consumir muito tempo, pois o número de regras cresce exponencialmente com o número de condições. Nesse caso, para reduzir o número de regras que precisam ser executadas, pode ser usada uma tabela de decisão minimizada ou uma abordagem baseada em risco.

4.2.4 Teste de Transição de Estado

Um diagrama de transição de estado modela o comportamento de um sistema, mostrando seus possíveis estados e transições de estado válidas. Uma transição é iniciada por um evento, que pode ser qualificado adicionalmente por uma condição de proteção. Presume-se que as transições sejam instantâneas e, às vezes, podem resultar em ações do software. A sintaxe comum de rotulagem de transição é a seguinte: "evento [condição de proteção] / ação". As condições de proteção e as ações podem ser omitidas se não existirem ou se forem irrelevantes para o Testador. Uma tabela de estados é um modelo equivalente a um diagrama de transição de estados. Suas linhas representam estados e suas colunas representam eventos (juntamente com condições de proteção, se existirem). As entradas (células) da tabela representam transições e contêm o estado de destino, bem como as ações resultantes, se definidas. Ao contrário do diagrama de transição de estados, a tabela de estados mostra explicitamente as transições inválidas, que são representadas por células vazias. Um caso de teste baseado em um diagrama de transição de estado ou em uma tabela de estados geralmente é representado como uma sequência de eventos, que resulta em uma sequência de alterações de estado (e ações, se necessário). Um caso de teste pode abranger, e geralmente abrangerá, várias transições entre estados. Existem muitos critérios de cobertura para o teste de transição de estado. Este syllabus aborda três deles. Na cobertura de todos os estados, os itens de cobertura são os estados. Para atingir 100% de cobertura de todos os estados, os casos de teste devem garantir que todos os estados sejam visitados. A cobertura é medida como o número de estados visitados dividido pelo número total de estados e é expressa como uma porcentagem. Na cobertura de transições válidas (também chamada de cobertura de 0-switch), os itens de cobertura são transições válidas únicas. Para atingir 100% de cobertura de transições válidas, os casos de teste devem executar todas as transições válidas. A cobertura é medida como o número de transições válidas executadas dividido pelo número total de transições válidas e é expressa como uma porcentagem. Na cobertura de todas as transições, os itens de cobertura são todas as transições mostradas em uma tabela de estados. Para atingir 100% de cobertura, os casos de teste devem executar todas as transições válidas e tentar executar as transições inválidas. O teste de apenas uma transição inválida em um único caso de teste ajuda a evitar o mascaramento de falhas, ou seja, uma situação em que um defeito impede a detecção de outro. A cobertura é medida como o número de transições válidas e inválidas executadas ou que tentaram ser cobertas pelos casos de teste executados, dividido pelo número total de transições válidas e inválidas, e é expressa como uma porcentagem. A cobertura de todos os estados é mais fraca do que a cobertura de transições válidas, porque normalmente pode ser obtida sem a execução de todas as transições. A cobertura de transições válidas é o critério de cobertura mais amplamente utilizado. Alcançar a cobertura total de todas as transições garante tanto a cobertura total de todos os estados quanto a cobertura total de transições válidas e deve ser um requisito mínimo para softwares de missão e segurança crítica.

Devido à sua popularidade e simplicidade, esta seção se concentra em duas técnicas de teste caixa-branca relacionadas ao código:

●Teste de instruções

●Teste de ramificação

Há técnicas mais rigorosas que são usadas em alguns ambientes de segurança crítica, de missão crítica ou de alta integridade para obter uma cobertura de código mais completa. Há também técnicas de teste caixa-branca usadas em níveis de teste mais altos (p. ex., teste de API) ou usando cobertura não relacionada ao código (p. ex., cobertura de neurônios em testes de redes neurais). Essas técnicas não são discutidas neste syllabus.

4.3.1 Teste de Instrução e Cobertura de Instrução

No teste de instrução, os itens de cobertura são as instruções executáveis. O objetivo é projetar casos de teste que exercitem as instruções no código até que um nível aceitável de cobertura seja alcançado. A cobertura é medida como o número de instruções exercidas pelos casos de teste dividido pelo número total de instruções executáveis no código, e é expressa como uma porcentagem. Quando a cobertura de 100% das instruções é alcançada, está garantido que todas as instruções executáveis no código tenham sido executadas pelo menos uma vez. Em particular, isso significa que cada instrução com um defeito será executada, o que pode causar uma falha que demonstre a presença do defeito. No entanto, a execução de uma instrução com um caso de teste não detectará defeitos em todos os casos. Por exemplo, pode não detectar defeitos que dependem de dados (p. ex., uma divisão por zero que só falha quando um denominador é definido como zero). Além disso, a cobertura de 100% de instrução não garante que toda a lógica de decisão tenha sido testada, pois, por exemplo, ela pode não executar todas as decisões do código (ver capítulo 4.3.2).

4.3.2 Teste de Ramificação e Cobertura de Ramificação

Uma ramificação é uma transferência de controle entre dois nós no gráfico do fluxo de controle, que mostra as possíveis sequências nas quais as instruções do código-fonte são executadas no objeto de teste. Cada transferência de controle pode ser incondicional (ou seja, código em linha reta) ou condicional (ou seja, um resultado de decisão). No teste de ramificação, os itens de cobertura são ramificações e o objetivo é modelar casos de teste para executar ramificações no código até que um nível aceitável de cobertura seja alcançado. A cobertura é medida como o número de ramificações exercidas pelos casos de teste dividido pelo número total de ramificações, e é expressa como uma porcentagem. Quando se atinge 100% de cobertura de ramificação, todas as ramificações do código, incondicionais e condicionais, são exercidas por casos de teste. As ramificações condicionais normalmente correspondem a um resultado verdadeiro ou falso de uma decisão "if...then", um resultado de uma instrução “switch/case” ou uma decisão de sair ou continuar em um “loop”. No entanto, e execução de uma ramificação com um caso de teste não detectará defeitos em todos os casos. Por exemplo, ele pode não detectar defeitos que exijam a execução de um caminho específico em um código. A cobertura de ramificação substitui a cobertura de instrução. Isso significa que qualquer conjunto de casos de teste que atinja 100% de cobertura de ramificação também atinge 100% de cobertura de instrução (mas não viceversa).

4.3.3 O valor do Teste Caixa-Branca

Um ponto forte fundamental que todas as técnicas caixa-branca compartilham é que toda a implementação do software é levada em conta durante o teste, o que facilita a detecção de defeitos mesmo quando a especificação do software é vaga, desatualizada ou incompleta. Um ponto fraco correspondente é que, se o software não implementar um ou mais requisitos, o teste caixa-branca pode não detectar os defeitos resultantes ausentes (Watson 1996).

As técnicas caixa-branca podem ser usadas em testes estáticos (p. ex., durante execuções secas de código). Elas são adequadas para revisar códigos que ainda não estão prontos para execução (Hetzel 1988), bem como pseudocódigo e outras lógicas de alto nível ou top-down que podem ser modeladas com um gráfico de fluxo de controle. Realizar somente testes caixa-preta não fornece uma medida da cobertura real do código. As medidas de cobertura de testes caixa-branca fornecem uma medição objetiva da cobertura e fornecem as informações necessárias para permitir que testes adicionais sejam gerados para aumentar essa cobertura e, consequentemente, aumentar a confiança no código.

As técnicas de teste baseadas na experiência comumente usadas e discutidas nas seções a seguir são:

●Suposição de erro

●Teste exploratório

●Teste baseado em lista de verificação

4.4.1 Suposição de Erro

A suposição de erro é uma técnica usada para prever a ocorrência de erros, defeitos e falhas, com base no conhecimento do Testador, incluindo:

●Como o aplicativo funcionou no passado;

●Os tipos de erros que os desenvolvedores tendem a cometer e os tipos de defeitos que resultam desses erros;

●Os tipos de falhas que ocorreram em outros aplicativos semelhantes.

Em geral, os erros, defeitos e falhas podem estar relacionados a: entrada (p. ex., entrada correta não aceita, parâmetros errados ou ausentes), saída (p. ex., formato errado, resultado errado), lógica (p. ex., casos ausentes, operador errado), cálculo (p. ex., operando incorreto, cálculo errado), interfaces (p. ex., incompatibilidade de parâmetros, tipos incompatíveis) ou dados (p. ex., inicialização incorreta, tipo errado). Os ataques a falhas são uma abordagem metódica para a implementação da suposição de erro. Essa técnica exige que o Testador crie ou adquira uma lista de possíveis erros, defeitos e falhas e modele testes que identifiquem os defeitos associados aos erros, exponham os defeitos ou causem as falhas. Essas listas podem ser criadas com base na experiência, nos dados de defeitos e falhas ou no conhecimento comum sobre o motivo pelo qual o software falha. Consulte (Whittaker 2002, Whittaker 2003, Andrews 2006) para obter mais informações sobre suposição de erro e ataques de falhas.

4.4.2 Testes Exploratórios

No teste exploratório, os testes são modelados, executados e avaliados simultaneamente enquanto o Testador aprende sobre o objeto de teste. O teste é usado para aprender mais sobre o objeto de teste, para explorá-lo mais profundamente com testes focados e para criar testes para áreas não testadas. Às vezes, o teste exploratório é estruturado e realizado usando testes baseados em sessões. Em uma abordagem baseada em sessões, o teste exploratório é realizado dentro de um período definido. O Testador usa uma carta de teste contendo os objetivos do teste para orientar o teste. A sessão de teste geralmente é seguida de uma reunião de informação que envolve uma discussão entre o Testador e stakeholders interessados nos resultados da sessão de teste. Nessa abordagem, os objetivos do teste podem ser tratados como condições de teste de alto nível. Os itens de cobertura são identificados e executados durante a sessão de teste. O Testador pode usar fichas de sessão de teste para documentar as etapas seguidas e as descobertas feitas. Os testes exploratórios são úteis quando há poucas especificações ou especificações inadequadas, ou quando há uma pressão significativa de tempo sobre os testes. O teste exploratório também é útil para complementar outras

técnicas de teste mais formais. O teste exploratório será mais eficaz se o Testador for experiente, tiver conhecimento do domínio e possuir um nível elevado de habilidades essenciais, como habilidades analíticas, curiosidade e criatividade (ver seção 1.5.1). O teste exploratório pode incorporar o uso de outras técnicas de teste (p. ex., particionamento de equivalência). Mais informações sobre testes exploratórios podem ser encontradas em (Kaner 1999, Whittaker 2009, Hendrickson 2013).

4.4.3 Testes baseados em Lista de Verificação

Nos testes baseados em lista de verificação (checklist), um Testador modela, implementa e executa testes para cobrir as condições de teste de uma lista de verificação. As listas de verificação podem ser criadas com base na experiência, no conhecimento sobre o que é importante para o usuário ou na compreensão de por que e como o software falha. As listas de verificação não devem conter itens que possam ser verificados automaticamente, itens mais adequados como critérios de entrada/saída ou itens muito gerais (Brykczynski 1999). Os itens da lista de verificação geralmente são formulados na forma de uma pergunta. Deve ser possível verificar cada item separadamente e diretamente. Esses itens podem se referir a requisitos, propriedades da interface gráfica, características de qualidade ou outras formas de condições de teste. As listas de verificação podem ser criadas para dar suporte a vários tipos de teste, incluindo testes funcionais e não funcionais (p. ex., 10 heurísticas para testes de usabilidade (Nielsen 1994)). Algumas entradas da lista de verificação podem se tornar gradualmente menos eficazes com o tempo, pois os desenvolvedores aprenderão a evitar os mesmos erros. Também pode ser necessário adicionar novas entradas para refletir defeitos de alta gravidade encontrados recentemente. Portanto, as listas de verificação devem ser atualizadas regularmente com base na análise de defeitos. Entretanto, deve-se tomar cuidado para evitar que a lista de verificação fique muito longa (Gawande 2009). Na ausência de casos de teste detalhados, os testes baseados em listas de verificação podem fornecer diretrizes e algum grau de consistência para os testes. Se as listas de verificação forem de alto nível, é provável que ocorra alguma variabilidade no teste real, resultando em uma cobertura potencialmente maior, mas com menos repetibilidade.

Cada uma das técnicas mencionadas acima (ver seções 4.2, 4.3, 4.4) tem um objetivo específico com relação à detecção de defeitos. As abordagens baseadas na colaboração, por outro lado, também se concentram em evitar defeitos por meio de colaboração e comunicação.

4.5.1 Escrita colaborativa de histórias de usuários

Uma história de usuário representa um recurso que será valioso para um usuário ou comprador de um sistema ou software. As histórias de usuários têm três aspectos críticos (Jeffries 2000), chamados em conjunto de "3C":

●Cartão: o meio onde se descreve uma história de usuário (p. ex., um cartão de registro, uma entrada em um quadro eletrônico);

●Conversação: a explicação de como o software será usado (pode ser documentado ou verbal)

●Confirmação: os critérios de aceite (ver seção 4.5.2)

O formato mais comum de uma história de usuário é "Como [ator ou persona], quero [meta a ser cumprida], para que eu possa [valor de negócio resultante para a função]”, seguido dos critérios de aceite. A autoria colaborativa da história do usuário pode usar técnicas como brainstorming e mapeamento mental. A colaboração permite que a equipe obtenha uma visão compartilhada do que deve ser entregue, levando em conta três perspectivas: negócios, desenvolvimento e testes. Boas histórias de usuários devem ser: Independentes, Negociáveis, Valiosas, Estimáveis, pequenas (Small) e Testáveis (INVEST). Se um stakeholder não souber como testar uma história de usuário, isso pode indicar que a história de usuário não está suficientemente clara, ou que não reflete algo valioso para ele, ou que o stakeholder precisa apenas de ajuda para testar (Wake 2003).

4.5.2 Critérios de Aceite

Os critérios de aceite de uma história de usuário são as condições que a implementação dela deve atender para ser aceita pelos stakeholders. Sob essa perspectiva, os critérios de aceite podem ser vistos como as condições de teste que devem ser executadas pelos testes. Os critérios de aceite geralmente são resultado da Conversação (ver seção 4.5.1). Os critérios de aceite são usados para:

●Definir o escopo da história do usuário;

●Chegar a um consenso entre os stakeholders;

●Descrever os cenários positivos e negativos;

●Servir como base para o teste de aceite da história do usuário (ver seção 4.5.3);

●Permitir planejamento e estimativa precisos.

Há várias maneiras de escrever critérios de aceite para uma história de usuário. Os dois formatos mais comuns são:

●Orientado a cenários (p. ex., formato Given/When/Then usado no BDD, ver seção 2.1.3);

●Orientado por regras (p. ex., lista de pontos de verificação ou forma tabulada de mapeamento de entrada e saída);

A maioria dos critérios de aceite podem ser documentadas em um desses dois formatos. No entanto, a equipe pode usar outro formato personalizado, desde que os critérios de aceite sejam bem definidos e não ambíguos.

4.5.3 Desenvolvimento Orientado por Teste de Aceite (ATDD)

O ATDD é uma abordagem que prioriza o teste (ver seção 2.1.3). Os casos de teste são criados antes da implementação da história do usuário. Eles são criados por membros da equipe com diferentes perspectivas, por exemplo, clientes, desenvolvedores e Testadores (Adzic 2009), podendo ser executados de forma manual ou automatizada. A primeira etapa é um workshop de especificação em que a história do usuário e, se ainda não estiver definida, seus critérios de aceite são analisados, discutidos e escritos pelos membros da equipe. Lacunas, ambiguidades ou defeitos na história do usuário são resolvidos durante esse processo. A próxima etapa é a criação dos casos de teste. Isso pode ser feito pela equipe como um todo ou individualmente pelo Testador. Os casos de teste são baseados nos critérios de aceite e podem ser vistos como exemplos de como o software funciona. Isso ajudará a equipe a implementar corretamente a história do usuário. Como exemplos e testes são a mesma coisa, esses termos são frequentemente usados de forma intercambiável. Durante o projeto do teste, as técnicas de teste descritas nas seções 4.2, 4.3 e 4.4 podem ser aplicadas. Normalmente, os primeiros casos de teste são positivos, confirmando o comportamento correto, sem exceções ou condições de erro, e compreendendo a sequência de atividades executadas se tudo ocorrer conforme o esperado. Depois que os casos de teste positivos forem concluídos, a equipe deverá realizar testes negativos. Por fim, a equipe deve cobrir também as características de qualidade não funcionais (p. ex., eficiência de performance, usabilidade). Os casos de teste devem ser expressos de forma que sejam compreensíveis para os stakeholders. Normalmente, os casos de teste contêm frases em linguagem natural que envolvem as pré-condições necessárias (se houver), as entradas e as pós-condições. Os casos de teste devem abranger todas as características da história do usuário e não devem ir além dela. Entretanto, os critérios de aceite podem detalhar alguns dos problemas descritos na história do usuário. Além disso, dois casos de teste não devem descrever as mesmas características da história do usuário. Quando capturados em um formato compatível com uma estrutura de automação de testes, os desenvolvedores podem automatizar os casos de teste escrevendo o código de suporte à medida que implementam o recurso descrito por uma história de usuário. Os testes de aceite tornam-se, então, requisitos executáveis.