Concrete Logo
Hamburger button

QA além da automação

  • Blog
  • 27 de Outubro de 2017
Share

Você que trabalha com qualidade deve saber que em pouco tempo houve uma mudança drástica na forma como trabalhamos: de cansativos e gigantes testes manuais passamos para os dinâmicos e rápidos (bem, nem sempre) testes automatizados. Eu comecei minha história na tecnologia há 7 anos, como estagiário de testes, e minha percepção sobre o trabalho mudou muito neste tempo. Quando comecei a trabalhar em um time ágil, por exemplo, aprendi também que as tarefas de qualidade não são responsabilidade de apenas uma única pessoa, mas de todo o time.

Mas se em um time ágil a qualidade não é responsabilidade de uma só pessoa, qual é o verdadeiro papel do QA?

Acredito que o papel de QA funciona como uma interface entre o negócio e o desenvolvimento. É do conhecimento de todos que em um time ágil todos devem se comunicar com transparência para conhecer as necessidades do outro, sem a necessidade de um mensageiro para levar demandas.

Contudo, o papel de um facilitador entre o que é codificado e o que é escrito/ projetado cai bastante no colo do QA. É esperado que ele tenha um bom conhecimento técnico para saber o que está sendo codificado, mas também um bom senso crítico com conhecimento de produto para saber o que está sendo projetado.

Essa é a grande diferença entre modelos de cascata e agile. Tradicionalmente, testar é o último passo de um projeto, ao passo que em um processo ágil estamos presentes durante toda a composição do produto, conhecendo de ponta a ponta.

Então, quais são características legais para um QA?

Tenha senso crítico

Com a popularização dos testes automatizados alguns deixaram de lado skills importantes para avaliar o produto, como o bom senso. Citando um texto sensacional sobre uma QA que se tornou PM:

Um bom QA encontra gaps na experiência do usuário que desafia até o propósito do produto. Às vezes isso pode ser um bug, mas geralmente é uma feature não prevista.

Críticas ao produto devem vir bem no início quando as histórias estão começando a ser escritas. É muito importante, por exemplo, que o QA esteja presente em ritos como o discovery e o refining, especialmente porque nosso papel, junto com POs e UXs, tem grande potencial para extrair o material bruto de comentários do cliente, fazendo isso se tornar algo útil para o projeto.

Ser crítico é também de grande valor na distribuição dos testes em diferentes camadas da pirâmide de testes. Saber onde e como cada cenário pode ser implementado te dá tempo para rodar os testes, especialmente, quando a comunicação com os devs está em sintonia, para juntos definirmos até mesmo o que pode ser feito com testes unitários.

Exercite a empatia

Outra qualidade importante que um QA deve ter é empatia, que de fato é essencial para todo mundo. Se você não tem a habilidade de se colocar no lugar do próximo, incluindo seu cliente/ usuário, é de extrema importância que você treine isso (sim, soft skills podem ser aprendidas!). Assumir diferentes personas é o que bons QAs fazem. Geralmente durante o design do produto, recebemos informações de como são os usuários do seu produto – então use isso a seu favor.

Quem são seus usuários? Um homem de meia idade usando Android ou uma adolescente com iPhone? Ou quem sabe até a mãe de duas crianças que usa Windows Phone (essas pessoas ainda existem, viu?)? Qual será o comportamento de cada uma dessas pessoas ao usar o meu produto? Aprenda a navegar e entender as diferentes necessidades dessas personas para encontrar gaps não apenas no código, mas também na experiência do usuário junto com os UXs.

Isso é essencial. Em conversas com UXs já conseguimos, muitas vezes, mapear comportamentos que não foram previstos e melhorar o produto para quem de fato vai usá-lo. Para isso é necessário também ter um feedback constante.

Mas vá além da empatia com o usuário. Comece com a empatia pelos seus colegas. Quando nos colocamos no lugar do outro, podemos ver caminhos que você não veria por si só e aí quanto mais cenários você conseguir visualizar, maior a qualidade que se está agregando ao produto.

Preveja o que pode acontecer

Não estou sugerindo que você seja tipo uma Mãe Dinah (RIP), mas sim que você use seu senso crítico e experiência para encontrar as especificações escondidas nos cantos mais remotos do produto.

Quando eu escrevo cenários, tenho que manter em mente que eles devem servir tanto como documentação viva para o negócio, quanto também como base para o que vai ser desenvolvido e automatizado. Prever e pensar nessas hipóteses gasta um bom tempo, mas o ganho em descobrir inúmeras possibilidades que o produto pode alcançar é enorme.

Saiba priorizar

Não vamos ganhar todas as batalhas. Já estive em uma situação em que eu era o único QA para oito devs em uma sprint. Eu sabia que eu não iria entregar os cenários escritos e a automação para tudo o que estava sendo desenvolvido. Sentei com o meu PO e definimos juntos o que naquele momento iria agregar mais valor para o produto.

Às vezes, naquela vontade enorme de entregar código, falhamos em especificar o suficiente. Precisamos ficar atentos e observar o que é mais importante em quais etapas do processo. Será que em estágios iniciais é mais importante eu ter cenários bem definidos ou suítes de testes de regressão completas?

Não estou dizendo que você não deva codificar, não me entenda errado! Mas é preciso ter essa percepção de como o projeto está andando e entender o momento certo para contribuir da melhor forma possível.

Compartilhe

Não faça tudo sozinho. Sabemos que a qualidade do produto não é responsabilidade apenas do QA, mas de todo o time. Dito isso, os cenários também não são sua propriedade e devem ser disponibilizados para todo o time assim que possível e, dada a necessidade, para os stakeholders também. Transparência.

Durante muito tempo fui ensinado que eu era o “guardião” da qualidade e eu trouxe essa mentalidade quando comecei em projetos ágeis. A mudança de mindset foi necessária, porque eu precisava, constantemente, checar o que estava especificando com POs e UXs para poder receber também ideias e compartilhar com eles coisas que não tinham sido previstas.

Compartilhar com o time de desenvolvimento é igualmente importante para que a documentação seja usada como referência para o que está sendo codificado, assim como receber feedback dos devs. O quanto antes os cenários são compartilhados com os devs, menor vai ser o retrabalho, já que menos bugs vão ser encontrados quando as histórias estiverem prontas.

Navegar é preciso

Aqui na Concrete tenho trabalhado muito próximo ao time de negócio. Tenho sentido uma melhora significativa no que vem sido escrito no backlog, como nas telas que são desenhadas e nos cenários que escrevo. Tento também me manter sempre ligado às diferentes branches que estão em desenvolvimento (comunicação com os devs para saber o que já está testável), para tentar encontrar bugs e gaps o mais rápido possível entre o que foi definido/ desenhado.

Mas não confunda essa “onipresença” com demandar algo. Não seja um chefe – esse não deve ser o papel de ninguém, aliás. Compartilhe suas ideias e opiniões, mas receba também as do outro. Lembre-se: faz parte da empatia ter uma troca natural, não apenas com o usuário, mas como o seu time e suas diferentes visões de acordo com suas diferentes experiências. Não existem chefes em agile (ou pelo menos não deveria).

Minha intenção aqui não é criticar o papel de QA que foca mais em seu lado técnico, aquele que é um dev sensacional e automatiza bastante. Acho automação extremamente importante e essencial e faço isso todos os dias para otimizar o máximo do meu tempo, mas o que quero pontuar é que nosso papel deve ir além de apenas automatizar e escrever cenários. Use seu tempo para priorizar melhor, considerar como melhorar sua cobertura de código, para ser criativo, comunicativo com seu time, ser empático e, assim de fato, ajudar a construir um produto melhor que faça a diferença para alguém.

Trabalha com QA e quer fazer parte do nosso time? Clique aqui.