Erros mais comuns entre QAs
A profissão de QA é desafiadora. Todos os dias estamos buscando o melhor para nossos processos e produtos. Além disso, buscamos melhorar nossas competências técnicas e soft skills. Nesta caminhada, é importante ter certo senso crítico sobre como desempenhamos nossas atividades, para identificar erros que podemos transformar em novas qualidades.
Te convido a conhecer os erros mais comuns entre QAs e o que podemos aprender com eles.
Não estudar
Estudar depois de um dia cansativo de trabalho é uma tarefa árdua. Para o universo da TI, renunciar os estudos é quase um crime! Minha dica é: escolha algo que te gere curiosidade, ou que você possa aplicar logo no dia seguinte no seu trabalho. Encontre o seu ritmo de estudos sem se comparar com os outros, o importante é ir no seu tempo, devagar e sempre ;)
Sofrer (mais que o necessário) quando um bug passa
Vai acontecer! Geralmente em algum cenário que você não pensou em testar; ou PIOR: publicaram em produção sem aguardar os testes. É terrível, eu sei.
É frustrante quando isso acontece. Sofrer por alguns minutos é compreensível. Mas o que você faz em seguida é o que importa. Tente analisar em qual etapa do processo houve falha e o que pode ser melhorado na estratégia de testes para evitar que isso se repita.
Confusão na definição de responsabilidades
A responsabilidade de realizar testes é de todo o time. Entretanto, podemos cometer o equívoco de não alinhar exatamente quem desempenhará cada tipo de teste.
Em leituras que fiz, na literatura acadêmica, e em textos de empresas que considero relevantes, não encontrei um consenso a respeito. Contudo, encontrei três formatações mais comuns:
1. QAs são responsáveis por testes funcionais, e separados em testadores manuais, automatizadores mobile e automatizadores web. Demais testes ficam sob responsabilidade dos desenvolvedores;
2. QAs atuando em todas as camadas da pirâmide de teste, e trabalhando próximos aos desenvolvedores. Ficam responsáveis também pela revisão de código, integração e deploy contínuos, utilizam BDD, TDD;
3. QAs são responsáveis pelos testes nas camadas de serviço e UI. Desenvolvedores são responsáveis pelos testes na camada de unidade e serviço.
O mais importante é entender qual formatação se adequa melhor ao seu time, ao perfil dos indivíduos e ao contexto do projeto.
Gerar relatórios em vão
Adotar indicadores de qualidade é uma das boas práticas de times de alta performance. A frase “aquilo que não se pode medir, não se pode melhorar” é uma grande verdade. O problema está em dedicar seu tempo de QA no processo de medição e geração de indiciadores, sem seguir para a análise/interpretação dos indicadores, e execução do plano de ação.
Suponha que um indicador seja o total de defeitos detectados (TDD), e que na sprint atual houve um aumento de 30% em relação à sprint anterior. O QA deve refletir sobre o que pode ter causado esse aumento, e propor ações para mitigá-lo. Ou seja, após gerar um indicador deve-se tomar medidas para (i) manter estáveis indicadores satisfatórios, e (ii) melhorar indicadores insatisfatórios.
E só será possível executar tais ações se o time estiver disposto. E não apenas QAs e desenvolvedores, mas todos os stakeholders precisam concordar que seja dedicado tempo para a melhoria da qualidade. Todos precisam se comprometer. Senão, em toda sprint o QA estará gerando relatórios em vão!
Focar somente em testes funcionais manuais
Inúmeras razões podem existir para o QA se limitar aos testes funcionais manuais. Um exemplo seria a falta de conhecimento a cerca de outras técnicas de teste, como, automação de testes.
Algo que atrapalha muito o desenvolvimento de testes automatizados são features que mudam constantemente. O QA precisa ter tempo hábil para refatorar os testes que acabam quebrando com tais mudanças, além de tempo para criar novos testes que cubram tais features.
Quando o QA está sobrecarregado, pode acabar priorizando os testes manuais, e invertendo a pirâmide de testes (o famoso sorvete). Nesse caso, o apoio do time se faz necessário, pois automação não é responsabilidade apenas do QA. Pode-se considerar também contratar mais um QA para fortalecer a equipe.
E quanto a processos?
Quanto a processos, alguns erros comuns são:
- Impor um processo de desenvolvimento sem considerar se o time possui condições e disposição de colocá-lo em prática;
- Burocratizar os processos, invés de construir uma cultura de qualidade;
- Não ir evoluindo/melhorando o processo com o passar do tempo;
- Não colher feedbacks a respeito.
E quanto a planejamento?
Quanto ao planejamento, alguns erros comuns são:
- Por adotar metodologias ágeis, achar que não precisa planejar os testes;
- Esquecer que testes também precisam ser priorizados. Deve-se considerar os riscos nesta etapa;
- Por falta de planejamento, ou falha no planejamento, acabar testando às pressas. Além de ser estressante, pode levar à não detecção de bugs importantes;
- Escrever casos de teste extensos e detalhados. Quanto mais tempo planejando testes, menos tempo é dedicado executando-os. É preciso equilibrar tais necessidades.
Considerações finais
Por fim, gostaria de ressaltar a importância de pedir ajuda e trabalhar colaborativamente. O QA está o tempo todo próximo do time, seja recebendo suporte de alguém, seja dando suporte a alguém. Ninguém sabe de tudo! E todos temos algo para ensinar.
Se identificou com algum dos “erros de QA” expostos neste post? Me conte aí. ;)
