Artefatos em Agile Testing – Caso de Teste

Seguindo a ideia do post anterior Artefatos em Agile Testing – Plano de Teste, vamos falar um pouquinho sobre caso de teste. De um modo geral, podemos dizer que caso de teste seria um conjunto de condições (passos) utilizado na execução de teste de software. Tais condições não mais são mais do que a definição dos dados de entrada e os seus resultados esperados. Os casos de teste são extraídos a partir da especificação de requisitos.

No contexto tradicional, para identificarmos os requisitos de teste, utilizamos os casos de uso (especificação de requisitos). Podemos dizer que um requisito de teste poderá ter “N” cenários de teste, onde cada cenário de teste poderá ter “N” casos de teste.
Este artefato deve ter, no mínimo, os seguintes dados na sua estrutura:
– Resumo
– Pré-Condições
– Entradas
– Ação
– Resultados Esperados
– Pós-Condições
O nível de detalhamento dependerá das premissas do time ou até mesmo do processo de desenvolvimento definido.

Já no contexto ágil, os cenários de teste são identificados a partir dos critérios de aceitação das histórias de usuário (especificação de requisitos), onde um critério de aceitação poderá ter “N” cenários de teste, que poderão ter “N” casos de teste (passos/condições). O foco é justamente validar o comportamento do requisito. Para isso, podemos utilizar o BDD (Behavior Driven Development) como design dos cenários de teste. Nesta estrutura temos:
– Título do cenário
– Dado que… (cenário atual)
– Quando… (ação do usuário)
– Então… (comportamento do software)
Ainda podemos criar cenários de teste mais ricos e para isso podemos utilizar o “E” e o “Ou” a cada ação do usuário e/ou comportamento do software. Para facilitar o entendimento, elaborei um modelo de cenários de teste na estrutura do BDD.

Independente do contexto do seu projeto, é importante termos em mente que…

* a partir de uma especificação de requisito, podemos identificar os requisitos de teste.
* um requisito de teste poderá ter “N” cenários de teste.
* um cenário de teste poderá originar “N” casos de teste.

Espero que tenha ajudado mais uma vez! 😉

Clique aqui para fazer o download:  Modelo Cenários de Teste – Formato BDD – Agile Testing

Anúncios

Artefatos em Agile Testing – Plano de Teste

Para quem trabalha na área de Teste de Software, principalmente no modelo Tradicional, elaborar artefatos de teste faz parte da rotina de trabalho. Os artefatos mais comuns são: planos de teste, casos de teste e relatórios de defeitos. Obviamente exitem outros artefatos e com outras nomenclaturas. 😉

Para quem está trabalhando em uma equipe que está começando a utilizar algumas boas práticas de Agile Testing, logo surgem dúvidas quanto à elaboração de artefatos. Não é que não existam artefatos em Agile Testing, mas busca-se documentar o que de fato trará valor ao projeto. É importante ter em mente que haverá a necessidade de dar manutenção nesta documentação e que o tempo é reduzido nos sprints!

Uma leitura torna-se obrigatória neste contexto, o livro Agile Testing, a pratical guide for Testers and Agile Teams da Lisa Crispin e da Janete Gregory. Além do famoso quadrante do teste ágil, o livro traz um modelo de Plano de Teste, onde busca-se identificar possíveis problemas e dependências, mostrar os riscos que poderão impactar no projeto, para que o time possa discutir a respeito da visão do todo.

Diante nisso, elaborei um modelo de Plano de Teste para facilitar essa fase de transição para o contexto ágil. É importante destacar que cada projeto é diferente. Então, não espere que uma solução sirva para todos.

Um ponto que deve ficar claro é que este artefato deverá conter a estratégia dos testes, que serão realizados no sprint. Ele poderá ser elaborado a partir da definição do objetivo do sprint, bem como definição da capacidade do time em atendê-lo dentro do prazo. O QA/Tester terá a visão do todo do escopo e assim estabelecer como deverão ser os testes. Neste caso, este artefato não seria “executável”. Quanto à utilização de ferramentas para a sua elaboração, fica a critério do que cada empresa utiliza para armazenar a documentação dos projetos.

Com o tempo, o amadurecimento do time e os desafios que surgirão a cada sprint, o QA/Tester encontrará a melhor forma de fazer o seu trabalho para agregar valor ao projeto. Espero que tenha ajudado!

Clique aqui para fazer o download: Modelo Plano de Teste by Lisa Crispin and Janet Gregory

Utilizando a Adaptação da Ferramenta 5W2H para Análise de Teste no Contexto Ágil

Uma das coisas que me deparei quando comecei a trabalhar no contexto ágil foi como extrair os requisitos de uma user story e elaborar a minha análise de teste. Bem… para quem já está adaptado a este contexto, isso pode parecer trivial, ou seja,  no a partir dos critérios de aceitação. Entretanto, se coloquem no lugar de quem está iniciando no agile testing… 😉

Depois de participar de treinamentos voltados aos Métodos Ágeis, tive alguns insights para melhorar a qualidade do meu trabalho. Um desses insights foi justamente a ferramenta 5W2H. Eu buscava motivações para evoluir como profissional e agregar qualidade no trabalho do time, tais como:

  • —Auxiliar na identificação dos critérios de aceitação dos requisitos;
  • —Minimizar possíveis lacunas na análise de requisitos;
  • —Melhorar a comunicação;
  • —Incentivar a pró-atividade;
  • —Melhoria contínua.

O que é a Ferramenta 5W2H?

—É uma ferramenta de planejamento muito utilizada na área de Administração, que consiste em um checklist contendo determinadas atividades nas quais os colaboradores da organização precisam desenvolver com o máximo de clareza. —Auxilia na eliminação por completo qualquer dúvida que possa surgir sobre um processo ou atividade.

5W2H

A ferramenta compreende as seguintes atividades:

  • What – O que será feito (etapas)?
  • Why – Por que será feito (justificativa)?
  • Where – Onde será feito (local)?
  • When – Quando será feito (tempo)?
  • Who – Por quem será feito (responsabilidade)?
  • How – Como será feito (método)?
  • How much – Quanto custará fazer (custo)?

Adaptando a Ferramenta…

Após analisar a ferramenta vi que precisava fazer algumas adaptações para atender às necessidades do projeto. Claro que não só para a análise de teste, mas também auxiliar no entendimento dos requisitos para o desenvolvimento.

Formato adaptado:

  1. Qual é o objetivo do requisito?
  2. Por que o requisito deve ser implementado?
  3. Onde poderá ser visualizado o requisito?
  4. Quais são os pré-requisitos para este requisito?
  5. Qual é o perfil de acesso para este requisito?
  6. Quais são os critérios de aceitação para este requisito?
  7. Quais serão as mensagens de validação para este requisito?

Para facilitar o entendimento, vou dar um exemplo de user story para utilizarmos esta adaptação.

** User Story **

Módulo Compras

Como operador de compras, necessito que seja implementado um ambiente de compra de matéria-prima para a fabricação de medicamentos manipulados, pois assim poderei receber as ofertas dos fornecedores e obter o melhor preço.

Para aceitar:

  1. Só poderão participar do processo de compra os fornecedores previamente cadastrados e com acesso ao Módulo Fornecedor liberado.
  2. Cada fornecedor deverá apresentar apenas uma cotação por produto.
  3. Toda cotação deverá possuir prazo de validade de 72 horas.
  4. Cada fornecedor irá receber uma nova solicitação de compra através do Módulo Fornecedor.
  5. Um fornecedor será considerado escolhido quando na sua cotação atingir 75% dos itens da solicitação de compra e ter oferecido o menor valor para cada item.

Para considerar:

  • O processo de compra deverá ter, no mínimo, 3 fornecedores participantes.
  • Para participar do processo, o fornecedor não deverá apresentar no seu histórico atraso na entrega dos produtos superior a 24 horas da data prevista.
  • O Módulo compras deverá ser integrado aos demais sistemas da rede.

** Utilizando a Ferramenta 5W2H Adaptada no Entendimento dos Requisitos **

1. Qual é o objetivo do requisito?

Seja implementado um ambiente de compra de matéria-prima para a fabricação de medicamentos manipulados.

2. Por que deve ser implementado?

Para receber as ofertas dos fornecedores e obter o melhor preço.

3. Onde poderá ser visualizado o requisito?

Não está claro na user story.

4. Quais são os pré-requisitos para este requisito?

  • O processo de compra deverá ter, no mínimo, 3 fornecedores participantes.
  • Para participar do processo, o fornecedor não deverá apresentar no seu histórico atraso na entrega dos produtos superior a 24 horas da data prevista.

5. Qual é o perfil de acesso para este requisito?

Perfil/papel Operador de Compras

6. Quais são os critérios de aceitação para este requisito?

  • Só poderão participar do processo de compra os fornecedores previamente cadastrados e com acesso ao Módulo Fornecedor liberado.
  • Cada fornecedor deverá apresentar apenas uma cotação por produto.
  • Toda cotação deverá possuir prazo de validade de 72 horas.
  • Cada fornecedor irá receber uma nova solicitação de compra através do Módulo Fornecedor.
  • Um fornecedor será considerado escolhido quando na sua cotação atingir 75% dos itens da solicitação de compra e ter oferecido o menor valor para cada item.

7. Quais serão as mensagens de validação para este requisito?

Não foi descrito na user story.

A partir das informações coletadas, já é possível identificar os cenários de teste. Caso as informações ainda estejam incompletas, é necessário contatar o Product Owner para maiores esclarecimentos. O importante é que antes de identificar os cenários de teste, as dúvidas sejam sanadas e, consequentemente, as perguntas respondidas. Novos dados poderão ser informados e assim ampliar o escopo dos testes.

** Cenários de Teste Identificados **

Em uma visão macro, temos os seguintes cenários de teste para o requisito:

  1. Validar a permissão de acesso ao Módulo Compras.
  2. Validar o fluxo do processo de compra.

a) perfil dos participantes
b) quantidade de participantes
c) quantidade de cotações por produto dos fornecedores.
d) prazo de validade das cotações.

3.  Validar a integração do Módulo Compras com os demais sistemas da rede.

De posse dos cenários de teste identificados, é hora de elaborar o artefato de teste adequado ao processo de desenvolvimento da sua empresa! 😉