Guia de sobrevivência do QA no mundo ágil

Publicado por Bruno Tanoue no dia agile, qa

Cowboy Frog

Com a introdução da metodologia ágil, a produção de software sofreu mudanças em relação ao seu processo. O planejamento e o ciclo de desenvolvimento se tornaram mais dinâmicos, ao ponto de estar em constante adaptação até os dias atuais. Em meio a essas mudanças, o profissional de QA (Quality Assurance) encontra-se muitas vezes em dificuldade para se inserir no mundo ágil, se sentindo excluído do processo e não conseguindo realizar totalmente seu trabalho. Ele pode até ser talentoso tecnicamente (bons Hard Skills), mas se não tiver habilidades humanas (Soft Skills) bem apuradas, dificilmente sobreviverá nesse tipo de metodologia.

Aqui na Resultados Digitais trabalhamos com times especializados em determinadas features do sistema, estruturados em um modelo bem parecido com o que a Spotify utiliza. Na imagem seguinte, o retângulo vertical cinza ilustra a estrutura de um time (Squad). As estruturas horizontais simbolizam um conjunto de pessoas que desempenham o mesmo papel (Chapters).

RD Teams Modelo de Chapters e Squads

Com o QA introduzido dentro de times heterogênios, a interação deste profissional com todos os outros é extremamente importante. A seguir serão listadas algumas dicas rápidas para que os profissionais de QA consigam se adaptar mais rapidamente a este processo.

Solução/UX

O ciclo da metodologia ágil começa com o planejamento e a criação de uma solução para resolver problemas do usuário, ou melhorar a sua experiência. O envolvimento do profissional de qualidade nesta fase é importante pela questão de entender o problema como um todo em uma fase que o custo de prevenção (ou correção) de erros é o mais baixo possível.

Cost of Change

Vale lembrar que é importante separar as coisas, respeitar o projeto de planejamento e solução e focar todos os esforços em entender as possíveis falhas de desenvolvimento. Se for realmente necessário, deve-se provar que as falhas ou defeitos da solução do sistema vão muito mais prejudicar do que ajudar no negócio. Dar ideias também é um diferencial, mas é importante não invadir o espaço de solução (design/UX) e deixar a resolução do problema a cargo deles.

Com a solução proposta, é chegada a hora de planejar os casos de teste. A documentação deve ser feita em uma linguagem não tão codificada (ruim para o entendimento dos PO’s) mas também não tão detalhada (para uma posterior automação). De maneira geral, recomenda-se o uso de Gherkin, que faz a descrição em uma linguagem ideal para todas as partes. A partir de um documento de fácil entendimento é possível corrigir problemas com um custo mínimo.

Desenvolvimento

Durante o ciclo de desenvolvimento, a comunicação com o desenvolvedor deve fluir naturalmente. Normalmente ele entende a necessidade do QA, mesmo que ocorram atrasos na entrega do seu trabalho. Uma visão mais “fora da caixa” traz a garantia de processo bem executado e segurança maior no lançamento das features. Em raras exceções, pode acontecer do desenvolvedor ver a garantia de qualidade como um processo que vai postergar a entrega do seu trabalho ao máximo, para que nenhum erro chegue ao ambiente de produção . Esta visão deve ser mudada, através da uma relação de confiança entre ambas as partes.

Ao encontrar algum bug na revisão de uma tarefa, por exemplo, é importante descrever detalhadamente os passos para reproduzir o problema, o resultado esperado e o resultado obtido, para que seja de fácil entendimento inicial.

Good Bug Description

Uma descrição ruim, ou em um tom errado, pode iniciar um ruído na comunicação entre ambas as partes. Ao se deparar com uma descrição mal escrita, o desenvolvedor pode não conseguir reproduzir o problema, deduzindo que coisas estão sendo vistas onde não existem, ou estão pegando no seu pé. Isso pode causar quebra de confiança ou uma discussão pela falta de entendimento do problema. Depois, a tendência é que a comunicação se torne desgastante e improdutiva. O pior cenário desse fato pode ser um incidente em produção, por um report de bug que foi ignorado, uma falha grave no processo que poderia ter sido facilmente evitada. O que impede o desenvolvedor de desenvolver uma feature e tentar realizar a entrega em produção sem envolver o QA se ele não se sentir mais confortável?

Bad Description

Também é necessário um tom sempre pacífico, porque pode ser que o problema visto seja apenas uma regra de negócio que não foi lembrada. Uma pergunta sobre o problema pode ser uma boa solução quando se está em dúvida, para evitar uma afirmação errada e um início de discussão.

Asking About Bug

É relevante que toda essa comunicação seja arquivada em algum lugar. Aqui utilizamos o Github para fazer todas as revisões. Se existir um problema futuro, podemos verificar todos os comentários de um PR (Pull Request) para entender o porquê deste problema ter ocorrido. Isso evita muito do “disse me disse” e mantém a relação QA/Dev sólida.

PR Discussion

Melhor do que isso, um pair review pode terminar a revisão de forma muito mais rápida e clara, gerando uma troca de conhecimento mútua, entre “o que revisar” e “como foi implementado”. Isso pode aumentar consideravelmente a afinidade entre ambas as partes, fazendo o processo fluir naturalmente. Por que não se arriscar em um pair programming também?

Pair Programming

Um outro ponto importante sobre a revisão de funcionalidade é tentar entender e testar a feature como um todo e não apenas em partes isoladas. Erros relacionados a usabilidade do usuário (um texto que aparece de maneira errada, um botão com uma cor diferente, a falta de um feedback melhor, etc.) são importantes, mas prioritariamente o QA deve garantir que não hajam erros que impeçam o fluxo do usuário como um todo. Se o usuário não conseguir realizar o que o sistema se propõe a fazer, com certeza desistirá de utilizá-lo.

Testes de Aceitação

Testes manuais e revisões de tarefas com o decorrer do tempo se tornam repetitivos e cansativos (além de tomar muito tempo para execução). Quando isto acontece, os olhos do testador ficam viciados e erros grosseiros passam despercebidos. Testes automatizados de aceitação ajudam muito nesse quesito e devem ser desenvolvidos em acordo (ou juntamente) com a equipe. Eles funcionam como critérios de aceite para que o PO considere a feature entregue, ou seja, testam a funcionalidade de maneira geral, com ênfase nos fluxos importantes para o sucesso do usuário. Se esses fluxos forem automatizados desde o início, o QA pode focar em cenários menos usuais, aumentando consideravelmente a qualidade do produto. Vale ressaltar que este tipo de teste deve complementar os testes de mais baixo nível, como os unitários e os de integração (não fazendo as mesmas coisas).

Priorização de Bugs

Não existem sistemas complexos sem bugs. Se eles não existem, apenas não foram descobertos ainda. Estão lá, escondidinhos, esperando para aparecer e brilhar quando você menos esperar em produção.

Oh Hi Bug

Em um cenário real, devem ser cadastrados e priorizados juntamente com o dono do produto (PO). É claro que desenvolver novas funcionalidades para atender os usuários sempre vai ser mais prioritário para o PO, mas é importante mostrar que se as funcionalidades existentes deixarem os usuários descontentes, pode ser um problema ainda maior e o usuário vai desanimar no uso dessas novas features. Tudo isso deve ser negociado e agradar ambas as partes. Bugs críticos devem ser corrigidos e alocados dentro dos ciclos de desenvolvimento o mais rápido possível para evitar decepções por parte do usuário. Se você tem curiosidade sobre como fazemos isso na Resultados Digitais, recomendo ler o post Como fazemos gestão de defeitos com GitHub.

Conclusão

No mundo ágil é importante mesclar uma ampla gama de conhecimentos na área de TI, mas também são exigidas habilidades sociais como: bom relacionamento, comunicação e trabalho em equipe. Estes elementos são essenciais e formam a base de trabalho para qualquer cargo dentro do Agile.

É importante ressaltar também que se a qualidade de modo geral está ruim, a responsabilidade não deve cair somente nas costas do QA. Em contrapartida, se o produto está com a qualidade exemplar, o time todo também deve ser parabenizado. Todos tem que se responsabilizar pelo produto, tanto para ouvir críticas positivas quanto críticas negativas. Isto é trabalhar em equipe!

Além de discutir coisas sobre o trabalho, procure também conversar com seu time sobre coisas que tenham afinidade (saia para almoçar!), não ficando apenas no ciclo de pessoas que fazem a mesma coisa que você. O profissional por mais brilhante que seja, se não souber interagir com seu time e ser parte da equipe dificilmente conseguirá trabalhar em um ambiente ágil.

E você? O que você acha deste assunto? Os soft skills tem grande importância no seu trabalho?

Leia mais sobre:

Bruno Tanoue

Bruno Tanoue

Quality Assurance Engineer

Comentários