QA > Teste – Parte 2

Na Parte 1 do texto QA > Testes nós entendemos um pouco de como as coisas funcionavam no processo de desenvolvimento de um sistema usando o modelo Waterfall e que, nesse modelo, existia uma etapa antes da entrega que era a etapa de Testes, e era nesse momento que o Quality Assurance atuava validando se o que havia sido desenvolvido era o que havia sido solicitado realmente. Também vimos um pouco de como esse mesmo processo de desenvolvimento acontece quando usamos modelos ágeis, que foi quando Quality Assurance passou a ser Quality Analyst e deixou de atuar em uma etapa exclusiva testes e passou a analisar a qualidade como um todo e apontando melhorias em todos os processos. Mas já que no modelo ágil não existe uma única etapa de testes, como fica o papel do QA? 

Nesse momento a gente traz o conceito de Testing Manifesto. Um conceito criado pela Karen Greaves e Samantha Laing e que é parecido com o Manifesto Ágil, mas é um manifesto voltado para a parte de testes.

Vamos explicar cada um dos itens: 

Testing throughout OVER Testing at the end

• Segundo as autoras do manifesto, o teste não deve ser uma etapa do seu fluxo, mas sim uma atividade como outra qualquer de dev. O teste deve ser uma atividade dentro desse fluxo
• Também é sobre implementar testes automatizados na pipeline e ter a pessoa de QA ajudando a analisar os testes desenvolvidos, é de fato estar dentro do processo de desenvolvimento e não atuar apenas quando já está desenvolvido

Como isso pode ser feito?

• O QA pode participar dos Code Reviews 
• QA pode ajudar a escrever teste, seja num pair programming, ou em uma área do sistema que não está coberta ainda 
• Fazer o Deskcheck, que é uma reunião rápida para garantir que o que foi desenvolvido realmente era o que estava sendo esperado antes de mandar isso para o cliente testar

Preventing bugs OVER Finding bugs

“The greatest victory is that which requires no battle” – Sun Tzu

• A ideia principal é prevenir e evitar bugs durante o processo de desenvolvimento antes que eles cheguem ao usuário final
• Os QAs podem até achar bugs, mas é importante tentar preveni-los 

Como isso pode ser feito?

• Ter o QA ajudando o PO na escrita e entendimento da história. Isso ajuda o QA a tirar dúvidas, pensar no que precisa ser verificado depois, além de ser um outro olhar em cima do que vai ser entregue, um olhar além do negócio, mas que vai pensar na qualidade do que vai ser entregue também. Isso pode até ajudar a definir critérios de aceite mais claros 
• Pair programming com o desenvolvedor, o que ajuda a entender e também dar sugestões no que está sendo desenvolvido 

Testing understanding OVER Checking functionality

• Não é sobre validar se o que foi feito está de acordo com o que foi escrito, é ser o advogado do usuário. É entender o que precisa ser testado, entender o negócio e verificar se aquilo realmente resolve o problema do usuário

Como isso pode ser feito?   

• Ter a pessoa de QA na parte da escrita das histórias ajuda nesse ponto também
• Ter um Kickoff antes do começo de cada uma das histórias. Uma conversa rápida com todo mundo que vai trabalhar nessa história para ver se todos entenderam o que deve ser feito. Nesse conversa, a pessoa de QA pode encontrar outros cenários de testes que podem ser feitos e pode ajudar o desenvolvedor a pensar nos testes automatizados que ele precisa fazer  

Building the best system OVER Breaking the system

• Priorizar os testes que realmente precisam ser feitos e testar cenários reais que podem acontecer 

Como isso pode ser feito? 

• Ajudando o PO na validação com o cliente 

Team responsibility for quality OVER Tester’s responsibility

• A qualidade do sistema é responsabilidade de todos 
• O papel do QA é garantir a qualidade e apontar onde ela pode ser melhorada 

Como isso pode ser feito? 

• Ter a pessoa de QA apontando melhorias no processo de todas as fases de desenvolvimento 

Com isso, podemos entender que o QA é diferente de Testes.

Quando olhamos para as responsabilidades de um QA, vemos que parte do trabalho dessa pessoa é realmente testar, mas ele também deve estar presente em todas as etapas do desenvolvimento, desde a escrita da história, até a entrega do produto apontando melhorias em todos os processos e ele tem um pouco das responsabilidades de cada um dos outros papéis do time. Por exemplo: sabemos que um dos papéis no time é o do PO, e o QA também faz um pouco disso quando ajuda a garantir a qualidade e ajuda também na escrita das histórias. Além disso, o QA também tem um papel conjunto com o Analista de Negócios que é o de ter entendimento real do negócio e auxiliar na melhoria dos processos do time. Na parte de UX não é diferente, o QA também ajuda no entendimento da necessidade do usuário e também  desafiando os requisitos, quando um requisito acaba sendo ruim para o próprio usuário. E por fim, o QA também pode colaborar com o DEV na escrita de testes e é por isso que o QA é muito maior que testes!