Como evoluir a atuação de pessoas que testam aplicações em um time?
Durante uma sessão de feedback, Maria recebeu diversos elogios de seus colegas de trabalho por conseguir finalizar todos os testes da sprint em tempo record, sendo chamada de heroína da qualidade. No primeiro momento ela se sentiu muito feliz, mas voltando para casa ela sentiu que algo estava errado.
Mesmo estando em um time ágil, ela estava sempre produzindo diversos artefatos de teste, executando os testes somente no final da sprint e sem tempo para desenvolver scripts de automação. Maria então percebeu que ela precisava de uma evolução!
Imagino que você conheça alguém na mesma situação da Maria, ou até mesmo você esteja passando por isso em seu emprego atual. Muitas empresas que dizem praticar a metodologia Ágil em seus times de desenvolvimento ainda adotam diversas práticas do modelo Cascata, surgindo então o assustador "Cascágil".
No Cascágil, ainda temos QAs produzindo diversos artefatos como casos de teste, planos de teste, procedimentos de teste, etc. Esses artefatos consomem um tempo excessivo de produção, o que sobrecarrega o QA que precisa criar os artefatos, executar os testes, automatizar, tudo em uma sprint de 2 semanas.
Identificando onde estou
É muito importante entender como é o papel da pessoa responsável pela qualidade no time em que você atua para que você consiga sugerir melhorias no processo de desenvolvimento do seu time. Neste vídeo, meu mentor Julio de Lima explica que podemos entender a evolução da responsabilidade em testes em 4 níveis:
Modelo 1.0: Cascata
Neste modelo temos um time de teste composto por Analistas de teste, automatizadores e testadores. Essas pessoas são as responsáveis por produzir artefatos de teste, desenvolver scripts de automação, realizar testes de sistemas, dar suporte aos usuários em testes de aceitação, além de revisar artefatos como requisitos de sistema, desenhos de telas, etc. Perceba que são diversos papéis, então é possível dividir as responsabilidades, evitando a sobrecarga.
Modelo 1.5: Ágil imaturo
O time de desenvolvimento é composto pelos desenvolvedores e QA. O QA é responsável pelos testes manuais e automatizados de sistema, criar artefatos de teste, dar suporte aos desenvolvedores em testes de unidade e integração e aos usuários em testes de aceitação, além de revisar requisitos e artefatos de UX. Aqui já temos a situação da Maria, onde ela executa tantas tarefas que acaba desenvolvendo uma frustração.
Modelo 2.0: Ágil em maturação
O time de desenvolvimento é composto pelos desenvolvedores e QA. Aqui o time é responsável pelos testes de unidade, integração e sistema, dar suporte aos usuários em testes de aceitação e revisar artefatos. O QA atua como mentor da qualidade e práticas de teste para o time.
Modelo 3.0: Ágil
O time de desenvolvimento é composto apenas por engenheiros de software, sendo todos fluentes em técnicas de qualidade de software. O time é responsável pelos testes de unidade, integração e sistema, dar suporte aos usuários em testes de aceitação e revisar artefatos. Nesse modelo o QA se torna um engenheiro de software que conhece a fundo sobre qualidade.
Vale lembrar que atuar como um Analista de Testes não necessariamente é melhor ou pior do que atuar como um QA, por exemplo. Cada papel existe a fim de suprir uma necessidade do time. Podemos entender o papel de quem testa aplicações como a evolução do Eevee em Pokemón. O Eevee possui diversas evoluções no universo Pokémon, mas não necessariamente uma é melhor que a outra.
E aí se encontrou em algum dos modelos apresentados? Quer mudar seu papel no time? Então escolha sua evolução!
Evolução 1 — Analista de testes
Para se tornar um analista de testes é preciso ter uma visão crítica sobre a documentação produzida nas etapas de Análise de requisitos e especificação e Design. Dessa forma você conseguirá produzir os artefatos de teste necessários para que os testadores executem os testes e os automatizadores gerem os scripts de testes automatizados.
Tá bom, e quais são esses tais artefatos de teste?
Para produzir artefatos de teste no modelo cascata você pode utilizar a ISO/IEC/IEEE 29119–3 para a escrita de Plano de teste, Casos de teste e Procedimentos de teste, além do Relatório de status dos testes a ser criado após a execução dos testes.
Evolução 2 — Testador
Além de executar os casos de teste, o testador deve reportar de forma concisa os incidentes encontrados. Um bom detalhamento é fundamental para a correção do incidente, então capriche nas evidências de teste!
Aqui a ISO/IEC/IEEE 29119–3 também pode te auxiliar na criação de Log dos testes e Relatório de incidentes.
Evolução 3 — Automatizador
Ser um automatizador não diz respeito apenas a criar scripts de testes automatizados. O automatizador deve atuar ativamente na escolha da melhor ferramenta de automação a ser utilizada no projeto, além de sugerir melhorias nos casos de teste descritos.
Evolução 4— QA ágil
Um QA ágil é aquele capaz de ser um mentor da qualidade no time em que atua, fazendo com que todo o time seja responsável pela qualidade. Com a mentoria do QA, todos os desenvolvedores passam a desenvolver e validar seu desenvolvimento, atuando em testes manuais e automatizados. Você deve estar pensando que isso é uma utopia, impossível de alcançar, mas eu te digo: estamos longe desse modelo, mas podemos chegar lá!
Em um contexto ágil é importante começar a pensar em qualidade o quanto antes. Com o auxílio de mapas mentais você pode estruturar melhor as informações sobre as estórias, riscos e ferramentas a serem utilizadas. No artigo Organizando informações com mapas mentais do João Vitor dos Santos (Goku) temos informações sobre o que é e como começar a utilizar mapas mentais no dia a dia, vale a pena conferir!
Participe ativamente das cerimônias de refinamento e planejamento com o time, assim você poderá clarificar as ideias do que será desenvolvido.
Apoie os desenvolvedores que não possuem afinidade com conceitos de teste, ensine sobre técnicas de teste, ferramentas de teste, ensine-o a testar! Assim todos podem dividir a responsabilidade sobre a qualidade do software.
Pelo pouco que conhecemos sobre a história da Maria lá do começo do artigo, podemos dizer que ela está no Modelo 1.5 — Ágil imaturo. Nesse modelo o QA pode, aos poucos, envolver mais os desenvolvedores nas atividades voltadas para qualidade de software e se envolver em atividades voltadas ao desenvolvimento.
Nos artigos Como estreitar os laços com desenvolvedores, escrito por Rafael Bandeira e O papel do QA no Time Ágil, escrito por Fernanda Franklin, a Maria encontraria valiosas dicas de como evoluir seu papel dentro do time para um QA Ágil.
Pessoas que testam aplicações possuem um papel fundamental na interação do time. Antes de pensar na melhor ferramenta, pense na melhor forma de estabelecer um diálogo, somente assim você conseguirá evoluir a mentalidade do seu time em relação a qualidade.
Independente da evolução que você escolher, no dia a dia você pode atuar em discussões sobre viabilidade, levantar riscos, tudo isso antes de começar o desenvolvimento!
Pergunte, sugira, critique, be brave!
