Mitos e verdades sobre um QA
Por mais que eu esteja trabalhando com testes a apenas 8 anos (em comparação com muitos, falta bastante arroz com feijão pra mim ainda), já ouvi bastante coisa relacionada a como o QA (ou tester, analista de testes, tantos outros nomes) deve trabalhar. Muitas eu tomava como verdade absoluta e vi que estavam erradas, muitas eu nem sabia que existiam e que eu tinha que seguir. A intenção é compartilhar algumas dessas experiências e deixar alguns conselhos sobre como lidar com elas
“O QA é tipo o usuário do produto”
Mito. E esse ainda é um padrão que vejo em alguns profissionais. Eu tive esse mindset por bastante tempo, de que eu era como o usuário final, que eu usaria o produto como o fulano usaria. Mas como eu poderia sequer saber como esse produto é usado se eu nunca nem vi o usuário do meu produto?
Para saber quem é o usuário do produto, são necessárias pesquisas e dinâmicas com stakeholders para identificar o público alvo. Imagine um produto em que, após essas atividades, seja descoberto que o publico alvo sejam mulheres na faixa dos 40 anos, com filhos. Como eu, um homem na faixa dos 20 sem filhos vou pensar em utilizar um produto como o publico que ele quer atingir?
O QA não é o usuário do produto. Nosso papel no time é garantia de qualidade, de forma que o produto venha a ser construído com o mínimo de falhas, sejam elas de código ou de especificação, para que o usuário final utilize esse produto.
"QA não desenvolve"
MITO. Esse é mito em caps mesmo. Lembro que, em minha primeira oportunidade que tive de automatizar testes, um dev chegou pra mim e disse: "você escreve os casos de teste, pode deixar que eu codo. Testador não mete a mão em código". Dias depois eu tinha escrito os casos de teste e codado a maioria dos testes definidos para aquela "sprint".
O ponto é que não deve haver essa divisão em um time multidisciplinar. Claro, todos os papeis tem suas caraterísticas e pontos fortes, mas o QA faz parte do dev team. Seu teste é tão parte do produto sendo construído como qualquer outra classe de código. E sinto dizer, QAs que resistem a meter a mão no código estão perdendo grandes oportunidades de carreira mundo afora. Fica a dica !
"QA tem que participar de refinamento"
Verdade. Essa eu aprendi depois de alguns feedbacks que tomei. Mas primeiro, uma pausa para explicar o que são os refinamentos.
Refinamento são reuniões que, como o nome indica, servem para refinar itens do backlog e detalha-los melhor para que eles possam estar ready para serem puxados na próxima sprint. Eu trabalhei com refinamentos divididos em duas etapas: um de negócio, com participação dos usuários do produto; e um técnico, com a participação de uma figura técnica possa dar explicações para o dev team. Se quiser entender melhor, tem esse artigo bacana da K21 explicando.
A percepção que eu tinha de antes era que as definições sobre o produto já vinham prontas pra mim, e que era o papel do PO, quem sabe do UX e de um Dev mais sênior, de definirem elas para que o restante do time pudesse trabalhar. Mas é um engano pensar que nós não podemos participar dessas definições. Não só podemos como devemos estar para que possamos escrever cenários mais abrangentes e dar uma visão que talvez ainda não tenha sido observada nem pelo time e nem pelo cliente. O produto não apenas é desenvolvido a varias mãos, mas também definido com várias cabeças.
"O cliente não sabe o que QA faz/ não vê valor no QA"
Verdade. Porque falhamos em mostrar para eles o real valor do nosso trabalho.
O produto está em constante mudança. Antecipamos e prevemos essas mudanças, mas trabalhamos em cima de hipóteses. Tudo pode ser descartado e modificado. Novas coisas vão surgindo a medida em que o produto vai sendo discutido e feito. Mas o cliente muitas vezes não entende que mudanças não são falhas, não são bugs. E ai a situação se torna desfavorável porque o cliente não confia mais na qualidade do produto feito.
O que podemos fazer então? A sugestão que tenho é metrificar nosso trabalho e validar com o cliente.
Metrificar apresentando gráficos sobre as últimas rodadas de testes automatizados, testes incluídos na sprint, quantos falham, porquê e qual a ação tomada para correção, dentre outros que façam sentido para seu projeto. A Review é um bom momento para apresentar esses dados.
Validação com cliente seria checar se os cenários de teste que o time imaginou para uma determinada história atendem os critérios de aceite definidos. Em um refinamento, por exemplo, apresentar esses cenários pode gerar debates sobre a história onde novas coisas podem surgir, e traz o cliente junto da responsabilidade de criar os testes junto com o time. Afinal, o teste também é parte do produto.
"O teste acontece quando o desenvolvimento termina"
Mito. De fato, algumas camadas de testes dependem que uma determinada feature esteja done para serem terminados. Mas isso não impede que seu trabalho seja adiantado.
Em projetos onde o QA faz majoritariamente testes de UI, ouço bastante dizerem que ficam ociosos por boa parte da sprint e tem que correr pois os devs liberam a feature bem no fim da sprint. Não duvido que isso aconteça, mas em muitos casos que eu vejo, o QA também não adiantou nada do que poderia ser feito antes, deixando tudo para fazer quando recebe a feature
O que você pode fazer? Uma história, mesmo sem nenhuma linha de código feita, deve ter insumos suficientes para que você possa pensar e escrever os cenários que ela irá conter. O ideal é que esses cenários venham já de refinamentos anteriores, se possível e não atrapalhar seu trabalho na sprint corrente.
Além dos cenários, você já pode adiantar os steps e métodos, mesmo que ainda não saiba os elementos que irá interagir no HTML. Tudo para que quando o código daquela história chegar em sua mão, você tenha o mínimo de trabalho para fazer em cima da hora.
E uma dica: Não é interessante incluir uma coluna de testes no board do projeto. Por 2 motivos simples:
- O teste vai sendo escrito a medida que a história vai sendo desenvolvida, logo qual o sentido de dizer incluir uma coluna para algo que já está sendo feito?
- Quando uma história finaliza desenvolvimento e vai para a coluna de testes, vem a famosa frase "só falta o QA testar". Isso acaba isentando o time de uma possível falha, sendo que a responsabilidade é de todo o time, em caso de sucesso ou falha.
Use subtasks dentro da história para sinalizar os seus testes sendo feitos, assim como os devs e outros papeis fazem com suas tarefas dentro de uma determinado PBI (item do backlog).
