Testadores ágeis são muitas vezes conhecidos como analistas de qualidade (QAs), engenheiros de software em testes, engenheiros de testes, lideres de qualidade, entre outras varianças. Eu tenho trabalhado como um Agile QA por um tempo, em portugues podemos traduzir como analista de qualidade ágil. Eu gostaria de compartilhar meu ponto de vista sobre como um QA trabalha em um time ágil. Nesse artigo eu vou usar a terminologia QA para representar o testardor ágil.
A maioria das pessoas, mesmo em times ágeis, tratam QAs como sub-papéis ou um papel separado do time. Eu acredito que isso está totalmente fora de moda. A diferença entre um QA e um desenvolvedor (também chamado como Dev) é apenas o jeito de pensar (ou mindset para os que estão acostumados com o termo).
Mas o que distingue QAs entre eles mesmos? Perfis de QA podem ser classificados em 3 categorias: Negócio, Técnico e DevOps. Eu chamo esses 3 de "3 dimensões de perfis de QA". QAs podem ter tanto um desses perfis como também pode combinar os 3 perfis de acordo com o seu level de conhecimento em cada uma das dimensões.
Vamos mergulhar mais a fundo nessas dimensões e entender melhor cada uma delas:
Dimensão de negócio
Os QAs nessa dimensão são realmente dirigidos à negócio. Eles tem habilidades que ajudam o time deles a entender o contexto de negócio dado pelo cliente. Eles tem boas habilidades de comunicação que facilitam o time a focar no problema de negócio durante o projeto todo.
Extraindo testes de aceitação do cliente é uma das especialidades e BDD é uma das técnicas que eles usam para quebrar a barreira entre contexto de negócio vindo do cliente e o contexto técnico vindo dos engenheiros do time.
Eles trabalham em par com os desenvolvedores para alinhar o que precisa ser feito com o cliente antes de começar a jogar as estórias. Durante esse período eles guiam o par para escrever testes de aceitação para ter certeza que a estória está testada antes deles moverem isso a diante.
Esses QAs geralmente leem livros como:
Specification by Example: How Successful Teams Deliver the Right Software
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
The Cucumber Book: Behaviour Driven-Development for Testers and Developers
Dimensão técnica
Eu me identifico com essa dimensão porque os QAs aqui são muito técnicos e tem boas habilidades de programação. No mundo ideal, não deveria exisitir nenhuma diferença entre um QA e um desenvolvedor. Em um time ágil, todo mundo é um engenheiro e deveria ser tratado como tal.
Os QAs técnicos trabalham em par com desenvolvedores para construir a aplicação sem gap técnico. Eles codam juntos. Eles também ajudam os desenvolvedores a desenvolver usando TDD, promovendo boas práticas como código limpo e padrões de desenvolvimento, garantindo um código de alta qualidade.
Eles tem muito conhecimento em automação de testes e ajudam o time a escolher o melhor framework de testes para o projeto. Eles também são responsáveis por garantir que o time tenha uma boa estrategia de testes em mãos.
Os QAs na dimensão técnica podem também trabalhar com testes de performance e segurança, dependendo quão avançado é o conhecimento deles em testes não funcionais.
Para testes de performance, eles trabalham com o cliente para descobrir os SLAs (Service Level Agreement). Dado essas informações eles criam os testes de performance para mensurar e rastrear as melhorias feitas na aplicação relacionadas aos SLAs.
Esses QAs também são envolvidos em segurança. Eles entendem o contexto de negócio com o cliente e analisam possíveis vulnerabilidades. Com isso eles criam testes de segurança para garantir que essas possíveis vulnerabilidades estão sendo cobertar por algum mencanismo de segurança.
QAs nesta dimensão geralmente leem livros como:
Test Driven Development: By Example
Clean Code: A Handbook of Agile Software Craftsmanship
Selenium Testing Tools Cookbook
The Art of Application Performance Testing: Help For Programmers and Quality Assurance
Dimensão de DevOps
Como DevOps está relacionado a testes? Existem várias coisas que QAs podem fazer para ajudar o time deles através do conhecimento deles em DevOps.
Eles introduzem a prática de entrega contínua e ajudam o time a criar um pipeline de integração contínua para receber um feedback mais rápido após cada commit. Isso ajuda o time a fazer deploy de novas funcionalidades para produção mais vezes. Em alguns casos, cada commit vai diretamente para produção após executar todo o pipeline com sucesso. Esse pipeline irá também executar o build e empacotar a aplicação, ferramentas de qualidade de código, testes unitários, testes de componente e testes funcionais.
Os QAs DevOps configuram scripts para o time rodar mais facilmente os testes em suas máquinas locais. Em alguns casos, máquinas virtuais são necessárias e nelas os testes são configurados para executar em paralelo.
Eles usam task runners para que o time execute tarefas repetitivas sem muito esforço, tais como auto watches para executar testes automatizados depois de cada vez que a pessoa salva o código fonte. Isso diminui o tempo de feedback durante o desenvolvimento de novas funcionalidades.
Esse QA geralmente lê livros como:
Continuous Integration: Improving Software Quality and Reducing Risk
Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation
As melhores referências em português são:
DevOps na prática: entrega de software confiável e automatizada
Entrega Contínua: Como Entregar Software de Forma Rápida e Confiável
O que é comum para todos os QAs?
QAs em todas essas 3 dimensões mantêm o time focado em entregar o valor certo para o cliente durante cada ciclo de desenvolvimento. Ao mesmo tempo, eles devem estar preocupados sobre a qualidade do produto que está sendo entregue.
Além deles compartilharem a responsabilidade dos testes com o time, também transmitem para o time todo o conhecimento que eles tem sobre testes. Através dessa abordagem, cada membro do time pensará sobre testes independente do papel dele. QAs vestem muitos chapéus, mas o foco principal deles deveria ser em ajudar o time a entregar valor de negócio frequentemente e com qualidade.
Livro que todos os QAs agéis deveria ler (que é a atual bíblia do Agile Testing)
Agile Testing: A Practical guide for Testers and Agile Teams
E você? Onde você está nessas dimensões? Qual delas você tem interesse em melhorar?
...e vamos começar!
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.