Por Everton Brandão
Trabalhar com agilidade requer mudança de mentalidade, atitude e postura. Para um Engenheiro de Qualidade, mais conhecido como QA (quality analyst), não poderia ser diferente. Esse perfil de profissional evoluiu com o tempo e deixou de ser um caçador de bugs para se tornar elemento fundamental no processo de construção do projeto, do início ao fim.
O QA tradicional você já deve ter bem claro na sua mente. Ele fica o tempo todo na aplicação, garante que os requisitos sejam atendidos, raramente foge daquele escopo e é resistente a mudanças. As verificações são manuais e os testes feitos na interface, sem dar atenção ao processo todo. Tem até alguns que tentam simular erros, o que chamamos de “quebrar o software”.
Em muitas empresas, os profissionais de teste ficam isolados da equipe, inclusive em um espaço físico diferente. Isso colabora para uma visão distorcida do desenvolvedor de que aquele profissional não deve ser bem-visto, não faz parte do time.
Nessa forma de trabalhar, toda a responsabilidade da qualidade da entrega recai sobre o testador. Se por acaso uma funcionalidade é entregue com alguma deficiência, a culpa é do QA, não do conjunto. O teste é uma fase da entrega do produto: depois que ele estiver desenvolvido, só falta testar. Ou seja, só final do desenvolvimento. Se der tempo.
QA ágil: qual o perfil ideal?
Um Engenheiro de Qualidade inserido em um time que já atua com agile faz basicamente o contrário de tudo o que eu falei até agora. Ele está junto do desenvolvedor desde a concepção do produto e das funcionalidades, com o objetivo de evitar bugs. O efeito disso é chegar ao final do ciclo do desenvolvimento sem erros, porque quanto mais cedo eles são detectados, mais barato fica para o projeto.
O QA ágil garante que as expectativas sejam claras, porque está próximo à equipe e ajuda a validar os critérios de aceite, auxilia o PO (Product Owner) a ver se o que está sendo desenvolvido está de acordo com o que o cliente espera. Ele aceita novas ideias, tanto na parte de automação, quanto na parte de teste.
A qualidade passa a ser uma responsabilidade da equipe e não do testador. O teste faz parte do ciclo de desenvolvimento, porque é superimportante levantar cenários que precisam ser testados. As verificações são manuais e automatizadas, e em diferentes níveis, dependendo das necessidades.
Esse profissional deve ser uma pessoa participativa dentro da equipe, estar junto, ter uma comunicação fluida. Deve contribuir, de fato, com a construção de um software melhor.
Um QA Ágil deve mostrar a importância de fazer testes e, principalmente, mostrar o que está testando. Não pode ser cabeça de bacalhau, que todo mundo sabe que existe, mas nunca vê. Deve ser parceiro, flexível e entender do negócio.
Comemorar bugs encontrados: é de bom tom? Não é.
Não apontar o dedo ao desenvolvedor e não comemorar bugs encontrados deve ser um mantra para um QA. Essa atitude, que infelizmente é comum, pode gerar rixas desnecessárias, pois todos estamos no mesmo barco. O desenvolvedor não é um rival, é um parceiro.
Na minha experiência de QA desde 2011, e hoje como agile master, me fez perceber que as entregas ágeis são muito mais robustas que as entregas de cascata, pois fazemos micro-entregas. Além de mudar essa postura “nós x eles”, aprendi que a organização é a palavra de ordem para não se perder. E também outras pequenas coisas que, somadas, são grandes impulsionadoras para o sucesso:
Documentar os casos de testes para ter um norte na hora de executar testes manuais ou para servir de consulta para outras pessoas.
Coletar evidências: essa eu aprendi apanhando. No passado, a gente testava, mas não evidenciada. Por mais que haja confiança da equipe, pode acontecer de algum erro ir para a produção e alguém questionar se não foi testado.
Compartilhar os testes com a equipe e estimá-los. É essencial mostrar qual o nível de esforço será necessário e o tempo que aqueles testes vão demandar.
Planejar cenários para automação: ao desenvolver uma nova feature, já precisamos pensar e mapear o que pode ser automatizado. Automatize o que vai agregar e o que vai ajudar na função, os principais fluxos, em especial aqueles com mais repetição, porque viciam os testes. Não tem que automatizar só para falar que automatizou. Isso é perda de tempo. E procure sempre atualizar e evoluir sua automação para ela não ficar inútil.
Lembre-se: o QA não é só um testador de telas e nem somente um automatizador.
Por fim, é regra de ouro detalhar as funcionalidades e garantir que aquilo que está sendo entregue vai atingir o objetivo final. Na mesma linha de raciocínio, é preciso aprender sobre o negócio, entender o produto, participar das cerimônias e apoiar na documentação. E questione. Seja curioso ou curiosa. É assim que a gente aprende.
Everton Brandão – Agile Master na TQI
