Critérios de Aceite + Cenários de Teste + Teste Unitário

Gestão de projetos

Para ajudar no entendimento e definição de estimativa, podemos usar um princípio visto em Gestão de projetos chamado de Triângulo do Projeto, que requer que o gerente tente manter um equilíbrio entre três pontos fundamentais, Escopo, Tempo e Custo.

Segundo essa ideia em Gestão de projetos, não é possível Modificar nenhum desses pilares sem afetar ao menos um outro pilar.

Triângulo do Projeto de forma Ágil

Nossa ideia é explorar como podemos aplicar esse princípio, primeira coisa a entender que a responsabilidade de manter o equilíbrio entre os pontos é do time e não exclusivamente de uma pessoa.

Cada ponto pode ser explorado para ajudar na estimativa e refinamento das histórias, vamos ver como podemos explora-los.

• Escopo:
  O uso de critérios de aceite podem ajudar a deixar claro esses limites.

• Tempo:
  O uso de técnicas como t-shirt ou Planning Poker para definir o tempo que será necessário para atender os critérios de aceite.

• Custo:
  Nesse ponto podemos avaliar o custo em "R$", demonstrando a necessidade de usar um recurso da AWS ou a necessidade de levantar mais uma máquina em produção e entre outros.

Resumo sobre BDD

Daniel Terhorst apresentou uma técnica para juntamente com TDD busca melhorar a qualidade dos nossos produtos, priorizando o foco em comportamento e nunca em processos.

Essa técnica auxilia no compartilhamento de informações entre membros do time independentemente se for um membro de negócio ou um membro técnico.

Parte importante da técnica está na escrita nos Cenários de Teste, esses cenários usam a seguinte estrutura base:

Estrutura pode chegar a usar outras palavras chaves como:

Ideia central

A ideia central e relacionar os critérios de aceite, cenários de teste e testes unitários, dessa forma unindo e ajudando na padronização da comunicação entre os membros do time.

Exemplo

Vamos imaginar que nosso time é composto por um Product Owner (PO), um Analista de Qualidade (QA) e Desenvolvedores, nesse contexto a PO escreverá os critérios de aceite para que o time possa estimar, e o time, juntamente com o QA vão criar os cenários de teste, tentando montar os cenários em cima de cada critério de aceite descrito pela PO.

Quando time começa a pensar nos cenários de teste com um "escopo limitado" isso tende a facilitar no planejamento técnico e definição de esforço.

Em nosso exemplo vamos criar uma história e passaremos pelos seguintes pontos:

• Critérios de Aceite
• Cenários de Teste
• Teste Unitário

Criaremos uma história usando o seguinte modelo, QUEM, O QUE e POR QUÊ

Obs: Sempre criar história com base no PROBLEMA e não da Solução.

História de Usuário

Eu, enquanto Comprador quero utilizar meu cartão de crédito no pagamento dos livros escolhidos para ter praticidade e segurança no pagamento.

Critério de Aceite

1. Somente podemos aceitar cartões de crédito com bandeiras VISA e MASTERCARD
2. Somente podemos aceitar cartões de crédito com data de expiração no futuro

Cenários de Teste

A ideia aqui é relacionar os critérios de aceite com os cenários de teste, para deixar nossa entrega mais simples e focada no que realmente foi solicitado pelo negócio.

Vamos criar quantos cenários forem necessários para cada critério de aceite.

Critério de Aceite1

Somente podemos aceitar cartões de crédito com bandeiras VISA e MASTERCARD*

agora vamos montar os cenários de teste focado nesse critério de aceite.

Cenário 1:

Cenário 2:

Cenário 3:

obs:
No critério de aceite não referencia nada de saldo, então devemos nos preocupar apenas com o que está no critério de aceite.

Critério de Aceite2

Somente podemos aceitar cartões de crédito com data de expiração no futuro

Cenário 1:

Cenário 2:

Teste Unitário

Aqui vamos fazer a última parte do nosso fluxo, escrever os teste unitários, a ideia aqui é escrever um teste unitário para cada cenário de teste definido anteriormente.

Critério de Aceite 1 | Cenário de Teste 1

@Test
public void mustAllowPaymentWithCreditCardVisa(){

    //create the saleMock
    ...

    CreditCard creditCardVisa = saleMock.getCreditCard();
    assertEqual("VISA", creditCardVisa.getFlag());

    Boolean success = saleService.finlizeSale(creditCardVisa);
    assertTrue(success);
}

Critério de Aceite 1 | Cenário de Teste 2

@Test
public void mustNotAllowPaymentWithCreditCardOtherCreditCard(){

    //create the saleMock
    ...

    CreditCard creditCardHiper = saleMock.getCreditCard();

    Boolean success = saleService.finlizeSale(creditCardHiper);
    assertFalse(success);
}

Critério de Aceite 1 | Cenário de Teste 3

@Test
public void mustAllowPaymentWithCreditCardMastercard(){

    //create the saleMock
    ...

    CreditCard creditCardMastercard = saleMock.getCreditCard();

    Boolean success = saleService.finlizeSale(creditCardMastercard);
    assertTrue(success);
}

Aqui vamos começar a fazer os testes para o Critério de aceite 2

Critério de Aceite 2 | Cenário de Teste 1

@Test
public void mustAllowPaymentWithCreditCardValidDate(){

    //create the saleMock
    ...

    CreditCard creditCardMastercard = saleMock.getCreditCard();
    assertTrue(creditCardMastercard.getExpirationDate().isAfter(LocalDate.now()));

    Boolean success = saleService.finlizeSale(creditCardMastercard);
    assertTrue(success);
}

Critério de Aceite 2 | Cenário de Teste 1

@Test
public void mustNotAllowPaymentWithCreditCardInvalidDate(){

    //create the saleMock
    ...

    CreditCard creditCardMastercard = saleMock.getCreditCard();
    assertTrue(creditCardMastercard.getExpirationDate().isBefore(LocalDate.now()));

    Boolean success = saleService.finlizeSale(creditCardMastercard);
    assertFalse(success);
}

Conclusão

Finalizamos nosso fluxo entregando uma tarefa focada na necessidade de negócio, com qualidade pois os teste unitário estão cobrindo todos os cenários de teste e consequentemente cobrindo os Critérios de aceite definidos por negócio.

Reduzindo acoplamento no desenvolvimento de software

Mattheus Cassundé ・ Sep 17 '22

#java #architecture #braziliandevs