Ser um QA Ágil significa atender as inovações que o mercado necessita. Hoje cada segundo na entrega de um novo produto gera um diferencial considerável no valor agregado. 

É necessário otimizar cada ponto no processo de desenvolvimento, desde a ideação até o produto ser entregue. 

O QA Ágil consegue destravar estágios desse fluxo; sendo um profissional que transita entre as áreas de negócios, processos e áreas técnicas, trazendo um background mais robusto para a validação de qualidade. Não somente isso, mas também, para o fluxo de desenvolvimento como um todo, enfocando em entregas de valor, rompendo a visão tradicional de um Tester, que antes atuava somente quando as tarefas estavam desenvolvidas. 

Aqui na Builders, consideramos essas atividades como uma boa prática de mercado, onde o QA é pensado como uma cultura end-to-end na esteira de desenvolvimento.

Ainda assim, o QA participa da criação do product backlog, pensando em como atuar com as validações de cada PBI, levando em consideração os critérios de aceite e métricas do negócio. Desta forma, é possível disseminar essas informações pelo DevTeam, considerando o relacionamento que o QA deve ter com cada membro do time. 

Leia também: Como está a saúde do seu backlog?

A partir disso, começa a auxiliar no sentimento de “dono do produto” que cada integrante deve ter, respeitando a atuação do PO e criando uma perspectiva de qualidade mais homogênea entre a área de negócios e DevTeam.  

 

Vamos falar sobre QA e Scrum

Pensando nas cerimônias de um framework Ágil de desenvolvimento, encontramos no Scrum algumas boas práticas quanto ao posicionamento do QA, dando voz a qualidade e ao colaborativismo. Vejamos em detalhes:

 

1. Ideação

Entendimento do escopo funcional e detalhar percepções de risco, destacar esforço e valor de negócio;

2. Sprint Planning

Explorar casos de testes, opinar e estimar na atuação das tarefas quanto ao esforço com enfoque na entrega de qualidade, considerando ainda a automatização das validações;

3. Sprint

Automatizar fluxos de testes, visando o atendimento dos critérios de aceite da área de negócios e auxiliar o time a criar e executar testes unitários;

4. Daily

Discutir sobre os impedimentos com os desenvolvedores, compartilhar informações sobre a atuação nas validações e acompanhar o desenvolvimento das tarefas.

5. Review

Inspeção e adaptação do produto visando a qualidade da entrega e validar junto à área de negócios;

6. Refinamento

Auxiliar em decompor itens do backlog até se tornar itens preparados, com visão crítica em qualidade;

7. Retrospectiva

Colaborar com a inspeção e adaptação do processo.

Conectando Qualidade e Negócios no DevTeam

Pensando em desenvolvimento com base na comunicação entre a área de negócios, desenvolvedores, UX e QAs, considerando o ciclo tradicional e de testes ágeis, encontramos uma maneira de atuar sob um framework adaptado estrategicamente com base no ATDD (Desenvolvimento Orientado a Testes de Aceitação). 

Leia também: 4 Dicas para um UX intuitivo

No início vamos chamá-lo de “ATDD 2.0”, onde nele defendemos que a interação com a Qualidade quanto a cultura deve ser de todos, e damos atenção a um contexto mais abrangente de planejamento de testes, totalmente aproveitável em frameworks de desenvolvimento ágeis como o scrum por exemplo.

Debater

O QA e P.O muitas vezes contando com a presença do UX, debatem sobre a escrita dos PBI, assim podemos adiantar casos de testes, tanto funcionais quanto unitários, explorando mais critérios de aceitação e aumentando a maturidade do product backlog como um todo. 

Desta maneira, o QA estará próximo do P.O o suficiente para alinhar a expectativa do produto, pensar em métricas de negócio que auxiliaria o DevTeam, amadurecer a cobertura das features de casos de testes, e também ajudar a fluir a comunicação entre Negócios e DevTeam. 

Refinar

O QA vem trazendo de uma forma bem simplificada os cenários de testes que já foram pensados com base no debate realizado entre ele, UX e o P.O. Assim teremos uma apresentação da história do usuário pensando no âmbito de negócio pelo P.O, através dos cenários de testes poderemos enxergar pontos técnicos e validações não pensadas.

Planejar

Como será feita a cobertura dos testes, separamos o que será tratado como teste unitário, teste de serviço e teste de aceitação. Levamos  os cenários de testes para cada um dos 3 tipos de abordagem de testes, onde é apresentado para o DevTeam de uma forma macro e caso seja necessário alguma alteração ela é realizada.

Desenvolver

A intenção é que Desenvolvedor e QA sentem juntos para construírem os testes funcionais de serviço e unitários, trocando experiências e auxiliando um ao outro. No caso de um QA que não possui a skill de automação, ele poderá se desenvolver, já para o desenvolvedor será criado o senso crítico, visando a qualidade em primeiro lugar.

Revisar

Neste momento, demonstramos os casos de testes para todo o DevTeam e para os responsáveis pelo produto. A demonstração dos casos de testes pode ser feita a partir da execução em um ambiente de Integração Contínuo ou de maneira mais simples, com a execução por meio de um job em um ambiente de testes. É interessante disponibilizar o acesso a feature de testes para todos, DevTeam e P.O.

Quando obtemos uma visão realista do produto, podemos realizar análises que influenciam os casos de testes e assim aumentar a cobertura com mais qualidade. Como QA, podemos ainda utilizar essas informações para auxiliar o time no entendimento sobre o valor de negócio, estreitando assim o relacionamento entre a área de negócios e DevTeam, conquistando uma entrega de valor voltada exclusivamente ao usuário.

Rodrigo Vieira
Últimos posts por Rodrigo Vieira (exibir todos)