Na Invillia, toda quarta-feira, ao meio dia, paramos uma hora para nos nutrir com as dicas, how-tos, boas práticas e tendências selecionadas por nossos especialistas em Product, Agile, Back e Front, Mobile, Quality, Security e Data. Uma troca de experiência vital para quem adora o novo. E essencial para que a inovação nunca pare. Se tecnologia está no sangue. A gente faz questão de deixá-la circulando cada vez mais_
Na veia_ O QA como participante ativo ao longo de todo o ciclo de inovação_
5 minutos de leitura
No artigo de hoje, deixamos os principais aprendizados da excelente edição sobre QA Ágil, apresentada por Milo Scarano Oliveira, nosso especialista em Qualidade. Um tema bastante polémico e crítico. Não apenas o QA saber como atuar no contexto dele, mas também como se relacionar e qual o papel dos outros membros da equipe. Será que um QA Ágil é um QA que testa rápido? Como verá nas próximas linhas, nada disso 🙂
Missão do QA
Muitas vezes o QA é entendido como alguém que está somente a testar, a validar o output do que está sendo codificado. Na verdade, a sua responsabilidade vai bem além disso. O QA tem como missão ajudar a construir um produto melhor e agregar efetivo valor ao negócio. Funciona como o “advogado” do cliente e do usuário final. É a pessoa que vai defendê-los a todo o custo. Trazer a sua dor e as suas expectativas ao longo do processo de inovação e entrega. Em contexto ágil, faz parte integrante do time de desenvolvimento. Minimizando custos e tempo através de automações, definições claras das regras de negócio, entendimento e acompanhamento ponta a ponta do que está acontecendo, e encontrando erros o quanto antes. Como o próprio nome “Quality Assurance” indica, o QA é a garantia de qualidade end-to-end.
Contexto Tradicional
O contexto tradicional é caracterizado pelo modelo cascata, waterfall, um modelo de desenvolvimento de software sequencial. Aqui o QA espera a etapa dele após a codificação para testar, validar e depois seguir com a entrega. Ninguém do time testa porque se subentende que só o QA faz isso. A adoção de metodologias ágeis não deixa esse modelo prevalecer, mas muitas empresas continuam no tradicional.
The Testing Manifesto
O Manifesto dos Testes foi criado alguns anos depois do Manifesto Ágil. Afinal, como é possível uma equipe ser ágil se nada muda na forma como testa? Existem então 5 princípios fundamentais:
- Testar por todas as etapas MAIS QUE testar no final
- Prevenir bugs MAIS QUE encontrar bugs
- Testar o entendimento/comportamento do produto MAIS QUE checar funcionalidades
- Construir o melhor sistema MAIS QUE quebrar o sistema
- Time responsável pela qualidade MAIS QUE responsabilidade exclusiva de QAs
QA Tradicional vs QA Ágil
Qual a diferença entre um e outro? No contexto tradicional, testar é uma fase, uma etapa. Existe uma separação em que parece que o QA está no mundo dele e o desenvolvedor em outro. Nem o “to-do” acompanha.
No contexto ágil, testar é uma atividade ao longo de um ciclo. O QA Ágil faz parte do board inteiro, não apenas de uma única coluna. Ele acompanha desde o princípio da concepção da história do produto, como está sendo desenvolvido e testado, tudo o que está acontecendo em cada card, seja no Jira ou em qualquer outra ferramenta. E ensina também, faz mentoring junto com os membros da equipe. Propaga a cultura de qualidade do “to-do” ao “done”. Quanto antes se conseguir agir melhor vai ser a entrega.
No contexto tradicional, geralmente o QA fica procurando bugs. No ágil o objetivo é prevenir bugs. Testar e fazer as perguntas certas na hora certa.
Por exemplo, na concepção de uma história de usuário perguntar como vai ser a interação com o sistema, e não somente clicar em algo. E se ele clicar diferente o que acontece? Quais os comportamentos esperados? Isso está mapeado antes do desenvolvedor começar a codificar? Como? Onde? É preciso trazer insumos não só para o QA mas para o time entender o que está sendo entregue.
No contexto tradicional, o QA apenas verifica se está tudo funcionando. Mas ele não é um “checker” de funcionalidades, é muito mais do que isso.
No contexto ágil, ele entende as necessidades e expectativas e faz parte do time para se testar no momento mais adequado e entregar com qualidade de ponta a ponta.
No contexto tradicional, o QA tenta quebrar o sistema para encontrar bugs, problemas. No contexto ágil, ele traz ferramentas, automações, mecanismos, técnicas para ajudar a construir o melhor sistema. É o melhor amigo do desenvolvedor e não um “inimigo” que veio para “destruir”.
O QA Ágil ajuda a validar, a perceber o que está por trás do que é preciso codificar. Tem uma atitude positiva e proativa, traz novas visões. Faz acontecer, antecipa, age em conjunto. Permite que a resposta às mudanças seja muito mais rápida.
E agora entramos no que é mais polémico. O QA é o único responsável pela qualidade? Não, não é. Ele vai trazer insumos e uma visão de garantia de qualidade para isso acontecer como um time da melhor maneira possível. Não é o portão que bloqueia. Pelo contrário, seu objetivo é abrir portas e discutir ideias.
O QA Ágil vai ajudar a compreender de ponta a ponta o que está acontecendo e todo o time toma a responsabilidade pela qualidade. O desenvolvedor, o QA, o Product Owner, o Scrum Master, o Agilista trabalham em conjunto para construir o melhor produto. E só quando todos estão confiantes é que fica pronto para subir para produção. A decisão é e será sempre do time.
Resumo da obra
Aqui está o resumo do que distingue um QA Tradicional de um QA Ágil:
É esta perpectiva do QA Ágil que acreditamos e fomentamos na Invillia. Todos trabalhamos juntos para agregar mais valor. Desde o entendimento do propósito do produto até ao seu desenvolvimento, implementação e evolução. É a nossa Global Growth Framework em ação. Data, People e Action combinadas para incrementar e acelerar em qualidade, escala e performance as missões de inovação contínua dos game-changers.
