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:
| Item | Descrição |
|---|---|
| Dado | Descreve o Contexto em que nosso usuário está |
| Quando | Descreve o comportamento que nosso usuário irá realizar |
| Então | Descreve o resultado gerado pelo comportamento do nosso usuário |
Estrutura pode chegar a usar outras palavras chaves como:
| Step | Descrição | Obrigatório |
|---|---|---|
| Feature | Descreve a HST em uma linha | Não |
| Cenário | Descreve cenário em uma linha | Não |
| Dado | Descreve o contexto | Sim |
| E | Detalha o contexto | Não |
| Quando | Descreva o Comportamento | Sim |
| Entao | Descreva o resultado | Sim |
| E | Detalha o resultado | Não |
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
- Somente podemos aceitar cartões de crédito com bandeiras VISA e MASTERCARD
- 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:
| Step | Descrição |
|---|---|
| Dado | Comprador de Livro utilizando cartão de crédito Visa |
| Quando | Tenta finalizar compra |
| Então | Recebe mensagem de sucesso |
Cenário 2:
| Step | Descrição |
|---|---|
| Dado | Comprador de Livro utilizando cartão de crédito diferente de Visa ou Mastercard |
| Quando | Tenta finalizar compra |
| Então | Recebe mensagem de Falha |
Cenário 3:
| Step | Descrição |
|---|---|
| Dado | Comprador de Livro utilizando cartão de crédito Mastercard |
| Quando | Tenta finalizar compra |
| Então | Recebe mensagem de sucesso |
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:
| Step | Descrição |
|---|---|
| Dado | Comprador de Livro utilizando cartão de crédito com expiração 01/01/2020 |
| Quando | Tenta finalizar compra |
| Então | Recebe mensagem de falha |
Cenário 2:
| Step | Descrição |
|---|---|
| Dado | Comprador de Livro utilizando cartão de crédito com expiração 01/01/2025 |
| Quando | Tenta finalizar compra |
| Então | Recebe mensagem de sucesso |
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.
Top comments (2)
Muito massa o texto Mattheus. Obrigado por compartilhar :)
Opa @vctrsmelo fico feliz que tenha gostado.