Olá QAs, tudo massa? Daremos continuidade ao tema, abordando um case.

1. CENÁRIO ATUAL

Versões geradas durante a sprint e disponibilizadas para teste não estão alcançando êxito e funcionamento pleno conforme o planejado.

2. PROBLEMAS

• Não alcançar o êxito e funcionamento pleno da versão disponibilizada para teste, parte do tempo da próxima sprint do projeto, em alguns casos 50% do prazo, é utilizado para corrigir as issues recorrentes encontradas ou pendentes da sprint anterior.

• História de Usuário no Jira não seguem um padrão de informação ou requisitos essenciais para designer, desenvolvimento e teste.

• Definição de pronto: requisitos + desenvolvimento + teste = funcionando.

3. SOLUÇÃO PROPOSTA

Utilizar o Manifesto Ágil, que são 4 pilares da metodologia Ágil:

• Indivíduos e interações mais que processos e ferramentas. ​

• Software em funcionamento mais que documentação abrangente. ​

• Colaboração com o cliente mais que negociação de contratos. ​

• Responder a mudanças mais que seguir um plano. ​

Quadrantes do Teste Ágil

Fonte: https://blog.adaptworks.com.br/2013/11/introducao-do-quadrante-de-teste-agil/

4. COMO?

A proposta inicial será divida em algumas fases do Ciclo de Desenvolvimento de Projeto, conforme listadas abaixo:

• Definição de Escopo: fase inicial do projeto que definirá todo o seu escopo e aplicabilidade conforme requisitos do cliente.

Atores principais: Gerente do Projeto, Stakeholders, Diretoria de Desenvolvimento, PO e os Tech Lead.

• Prazos do Projeto: fase de definição dos prazos que o projeto terá para desenvolvimento e entrega do produto funcionando.

Atores principais envolvidos: Gerente do Projeto, Stakeholders, Diretoria de Desenvolvimento e PO.

• Planning Geral: fase que antecederá todas as sprints ou início de sprint, será definido o escopo de trabalho, conforme o prazo total do projeto.

Atores principais envolvidos: Product Owner, Scrum Master, Desenvolvedores, Analistas de Teste, Infraestrutura e Designer.

• Planning de Desenvolvimento: próxima fase, após a planning geral, que definirá a prioridade e criticidade de cada item que será desenvolvido, conforme escopo, planejamento e prazos de cada sprint e entregas planejadas.

Atores principais: Tech Lead, PO e Desenvolvedores.

• Planning de Teste: próxima fase, após a planning geral, que definirá a prioridade e criticidade de cada item que será testado, conforme escopo, planejamento e prazos de cada sprint e entregas planejadas.

Atores principais: Tech Lead, PO e Analista de Teste

• Demais Times Envolvidos: próxima fase, após a planning geral, que definirá a prioridade e criticidade de cada item que será trabalhado, conforme escopo, planejamento e prazos de cada sprint e entregas planejadas.

Atores principais: Tech Lead, PO e time do projeto.

5. FASE DE TESTES

• Teste de Desenvolvedor: atividade na qual o desenvolvedor irá garantir que a feature permaneça sendo bem executada, mesmo que haja a necessidade de alteração em sua base de código, através de testes unitários garantindo uma boa cobertura de testes.

• Teste de QA: atividade de Analista de Teste que verificará e validará o item conforme requisitos do cliente. Além de testes não funcionais como carga, estresse e performance garantindo dados para as melhores decisões relacionados a infraestrutura do projeto.

• Teste Homologação: atividade que contará com a participação de todo o time do projeto para validação e verificação do correto funcionamento do sistema em ambiente do cliente (antes da entrega para produção).

• Teste Produção: testes pontuais e acompanhamento do sistema entregue.

6. REGISTRO E ACOMPANHAMENTO

• Documentação: cada Time envolvido em sua respectiva atividade ou integração elaborará os documentos conforme procedimentos estabelecidos pela organização.

• Jira: ferramenta oficial da organização ara registro de atividades, esforço de trabalho, escopo do projeto, entregas realizadas e demais itens relacionados ao projeto.

• Testes de contrato: ferramenta para garantir a qualidade do código fonte em desenvolvimento (SonarQube, Postman, etc.), realizando diversas análises automatizadas durante o processo de compilação. Buscando trechos de códigos que possam gerar bugs na aplicação, falhas de segurança, cobertura de testes unitários, além de validar boas práticas de programação.

7. TIMES ENVOLVIDOS

1. Stakeholder

2. Gerenciamento: Gerente

3. Planejamento: Product Owner

4. Acompanhamento: Scrum Master

5. Infraestrutura: Banco de Dados e Serviços

6. Designer

7. Desenvolvimento

8. Teste

8. INTEGRAÇÃO ENTRE OS TIMES ENVOLVIDOS:

• Feedbacks mais rápidos: cada Time envolvido em sua respectiva atividade ou integração, deverá manter um constante contato e canal aberto de comunicação, que deverá garantir que o que está sendo trabalhado e desenvolvido, além de entregas de artefatos para outros times, está de acordo com o escopo e prazos do projeto estabelecidos.

• Desenvolvedores e Testadores: Testadores irão replicar o ambiente de desenvolvimento para que seja possível realizar testes funcionais logo após o término do desenvolvimento da feature pelo desenvolvedor, garantindo um feedback mais rápido para o desenvolvedor.

9. PROPOSTA DE HISTÓRIA DE USUÁRIO

Será apresentado a seguir, um modelo de User Story que deverá existir estes campos como padrão:

Não escreva histórias épicas, pois elas serão extensas demais para finalizar. Se for extensa, então será um épico que resultará em um conjunto de histórias menores.

 Eu como <ATOR/QUEM>,
 Quero <O QUÊ>,
 Para que <POR QUE>.
 Onde:

a) ATOR/QUEM: define quem é o usuário que tem a necessidade. Pode ser representado por um usuário do produto, por uma persona ou até mesmo por um usuário específico.

b) O QUÊ: define qual é a necessidade do usuário. Tradicionalmente, os requisitos do produto são representados apenas por essa parte.

c) POR QUE: define qual o benefício do usuário ao ter a funcionalidade desenvolvida para atender a essa necessidade. Em outras palavras, qual o valor direto obtido pelo usuário.

• Nome da História: Nome deve ser objetivo, que descreverá a finalidade.
• Descrição: Irá descrever de forma resumida a objetividade da história como: finalidade, funcionalidade ou utilização.
• Telas Necessárias: Mostrará as telas que são necessárias e fazem parte da história, assim como também telas dependentes ou que fazem comunicação com a mesma, direta ou indiretamente.
• Fluxo: Mostrará integração (tela) anterior e a próxima. Pode ser uma sequência também.
• Critérios de Aceitação: Descrerá por uma lista de itens de negócio (funcionalidades) que expressam na prática, as funcionalidades implementadas na história. O objetivo dessa lista é validar se a História foi implementada de acordo com o que o PO solicitou, através dos requisitos do cliente.
• Definition Of Ready: História pronta para ser adicionada no sprint.
• Definition Of Done: Pronto é PO + Dev + Teste = Aprovado

10. NA PRÁTICA COMO FUNCIONARÁ?

Seguindo todo o processo atual que já existe e é conhecido pelos times, a mudança ocorrerá estrategicamente em um ponto (conforme figura acima destacado em vermelho) para que o tempo de resposta e entrega final seja mais rápido.

Elaborado pelo autor: Proposta do fluxo.

a) Método corrente (usado hoje): após a conclusão de desenvolvimento é gerado uma build para o time de teste e daí em diante segue o ciclo de teste.

b) Método proposto: ao invés de entregar para o time de teste, próximo do final da sprint, o pacote fechado com a build para teste, é disponibilizado logo após o desenvolvimento parte ou a feature (funcionalidade) para teste, para que seja verificado e validado o item previamente (sem aplicar o processo completo de teste), dessa forma antecedendo resultado e o funcionado.
Após as correções realizadas, se houverem, o processo de entrega (build pacote fechado) para o time de teste, seguirá normalmente para teste e aplicando o processo de teste, para os testes de integração e sistema.

Okay, mas o que o time ganha se nada mudará na prática? Muito pelo contrário, essa pequena mudança estratégica neste ponto, a tendência de ocorrer erros ou issues durante os testes de integração e sistema é menor, pois o item já foi verificado e validado previamente.

Este post é apenas um pedacinho da Área de Qualidade de Software e Desenvolvimento de Software, busque e qualifique-se.