Entenda como o papel do Analista de Testes ou QA é determinante para a qualidade de produtos digitais
Por Rodrigo Matola
A maneira como desenvolvemos produtos está mudando constantemente. Atualmente empresas em todo mundo estão adotando o desenvolvimento ágil de produtos, utilizando alguns de seus frameworks (Scrum, Kanban, Lean…).
Essa nova maneira de trabalho afeta todos os cargos tradicionais, incluindo Analistas de Testes, ou QA (Quality Assurance).
Neste artigo, vamos falar de uma maneira básica sobre as diferenças entre QAs tradicionais e QAs Ágeis, além de um breve conceito sobre agilidade e o framework Scrum.
Contexto tradicional x Contexto ágil
Em um contexto tradicional, os passos do projeto são planejados com antecedência, antes do seu início. O escopo é definido e não pode ser alterado após iniciado o desenvolvimento. Qualquer mudança requer uma aprovação e um novo contrato entre as partes. A data de entrega também é definida.
Para passar de um estágio para o próximo, é necessário inspeção e aprovação. Esse contexto também é chamado de cascata (waterfall), e geralmente segue o modelo da figura abaixo:
No modelo ágil, o software é entregue em pequenos pedaços, geralmente já funcionais, em um prazo que varia de uma semana a um mês, no caso do framework Scrum. Com estes pequenos incrementos funcionais, é possível se adaptar rapidamente a mudanças. Ser ágil não é ser rápido, mas ser adaptativo!
QA tradicional
Com base a figura acima, vemos que os testes só acontecem no quarto estágio do projeto. Nesta etapa, o software está praticamente pronto.
Geralmente, no contexto tradicional, QAs não têm contato direto com os desenvolvedores. Nesta situação, QAs praticamente caçam bugs, às vezes sendo a quantidade de bugs encontrados, uma medida de desempenho.
Nestas circunstâncias, somente QAs são responsáveis pela qualidade do produto. São eles que garantem que os requisitos foram atendidos corretamente. Qualquer erro no software, ou não conformidade com os requisitos, a responsabilidade é exclusiva da pessoa QA.
O Manifesto dos Testes
O Manifesto Ágil foi criado por um grupo de pessoas que queriam mudar a maneira de como softwares eram desenvolvidos. Alguns anos depois, seguindo os passos do Manifesto Ágil, foi criado o Manifesto dos Testes:
- Testar por todas as etapas MAIS QUE testar no final;
- Prevenir bugs MAIS QUE encontrar bugs;
- Testar o entendimento 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 Ágil
Pegando como referência o Manifestos dos Testes, vamos aqui descrever um pouco de como deve ser o comportamento de QAs Ágeis. Assim como no Manifesto Ágil, valoriza-se mais o item à esquerda que o item à direita – não é uma substituição, você vai continuar fazendo o que está à direita, entretanto, vai priorizar a esquerda (não confundir com política ok!?). Sendo assim, o QA Ágil deve:
Testar por todas as etapas [mais que] testar no final
Os testes devem começar já na reunião de planejamento. A partir dos critérios de aceite definidos, já é possível pensar nos casos/cenários de testes que serão feitos.
Se o time já tem mentalidade voltada a testes e realizam TDD, BDD ou outra técnica, é hora de combinar a divisão dos testes (aplicação da pirâmide ou outra estratégia); definir o que vale a pena ser automatizado; como será a integração contínua, etc.
Também é recomendado que QAs façam code review e pair programming. Muitos bugs e inconsistências podem ser pegos durante o desenvolvimento somente observando o código, o que leva ao próximo tópico…
Prevenir bugs [mais que] encontrar bugs
Com os testes sendo feitos durante o desenvolvimento, a chance de um bug ir para produção é muito menor. Nessa fase a correção do bug pode ser imediata, pois o time de desenvolvimento está trabalhando na funcionalidade.
Dependendo do conhecimento, no momento que o bug é descoberto, a própria pessoa QA pode corrigi-lo.
Testar o entendimento [mais que] checar funcionalidades
A qualidade vai além de verificar se o software funciona como foi descrito. Isso pode ser feito por um robô.
Qualidade também engloba o entendimento da necessidade do usuário e garantir que essa necessidade é realmente o que o usuário precisa. Para isso o usuário também deve participar junto com o time no desenvolvimento, dentro do possível.
Construir o melhor sistema [mais que] quebrar o sistema
Como parte de um time, apontar defeitos e encontrar meios de quebrar o sistema vai contra o objetivo de entregar o melhor software possível. Temos que ter em mente que um software sem defeitos, nem sempre significa um software de qualidade.
O melhor sistema é aquele que resolve as dores de seus usuários. Trabalhe para isso.
Leia também: O que é de fato a Transformação Digital?
Time responsável pela qualidade [mais que] responsabilidade exclusiva de QAs
Colocar a responsabilidade da qualidade em apenas uma pessoa ou área é isentar outras pessoas envolvidas no processo de qualquer problema que será identificado.
Todos que fazem parte, direta ou indiretamente, do desenvolvimento de uma solução devem ser responsáveis por entregar o melhor possível dentro do seu papel.
QAs podem não ser desenvolvedores no sentido de serem a pessoa que codifica a aplicação, mas desenvolvem testes e fazem parte do time de desenvolvimento. Todos que contribuem com o desenvolvimento do produto, incluindo designers/UX, são desenvolvedores e devem se responsabilizar pela qualidade do que vai ser entregue.
Trabalho em conjunto
Como o time é responsável pela qualidade, QAs devem estar presentes em todas as etapas do desenvolvimento, ajudando o time a entregar o melhor produto. A figura abaixo mostra como, em cada etapa da Sprint, QAs podem contribuir com suas próprias responsabilidades e ajudando membros do time.
E também, como parte do time:
- ajudam a descobrir o produto certo;
- colaboram para especificar;
- pensam em exemplos;
- refinam as especificações criadas pelo time;
- automatizam as especificações;
- ajudam a manter a Integração Contínua;
- ajudam a manter a Documentação Viva atualizada e acessível.
QAs tradicionais x QAs Ágeis
Resumindo em tópicos as diferenças entre QAs tradicionais e QAs Ágeis são:
Além disso, QAs Ágeis:
- estão sempre aprendendo novas habilidades e tecnologias, se adaptando a mudanças;
- praticam comunicação clara e efetiva, colaborando com pessoas técnicas e não técnicas;
- entendem do negócio, defendem o produto e colaboram com o cliente;
- disseminam a cultura de qualidade e cuidam da saúde do time;
- promovem e obtém feedbacks, tendo coragem de expor o que errado e elogiando o que está certo;
- se mantém simples e auto-organizado, não dependendo de instruções para realizar suas atividades;
- gostam do que fazem 🙂
E você, está no contexto tradicional ou ágil? Se no tradicional, gostaria de ir para o ágil? Se no ágil, faz o foi descrito no texto ou já está além? Deixe um comentário aqui!
