De Oppenheimer a Barbie: saia do caos para o mundo perfeito priorizando o escopo de testes com RBT

Uma das principais portas de entrada para a área técnica de QA é o teste exploratório. Nesse procedimento, um profissional de QA é apresentado a um produto ou projeto com o qual nunca interagiu e recebe a tarefa de explorá-lo para identificar defeitos e reportá-los aos desenvolvedores.

Esse método dá ao QA a liberdade de explorar o sistema sem seguir rigidamente um conjunto predefinido de casos de teste. Ele utiliza sua experiência, intuição e conhecimento para interagir com o produto ou projeto, com o objetivo de descobrir possíveis defeitos, comportamentos inesperados e pontos de melhoria.

Na prática, costuma haver confusão nessa etapa em relação à terminologia. O que descrevi acima não é, na verdade, teste exploratório, e sim teste ad-hoc. A principal diferença é que o teste ad-hoc não exige experiência prévia nem planejamento estratégico. Já o teste exploratório exige experiência prévia e conhecimento de estratégias de teste, como heurísticas, mapas mentais, checklists e técnicas semelhantes, para explorar o produto de forma eficaz.

Segundo James Bach:

“O teste exploratório de software é uma abordagem poderosa, mas amplamente mal compreendida. Em determinadas situações, ele pode ser muito mais produtivo do que o teste roteirizado. Todos os testadores praticam alguma forma de teste exploratório, a menos que simplesmente não criem testes. Ainda assim, poucos de nós estudaram essa abordagem a fundo, e ela não é muito respeitada em nossa área. Essa atitude está começando a mudar à medida que as empresas buscam métodos de desenvolvimento de software cada vez mais ágeis e econômicos.”

Não vou me aprofundar no teste exploratório neste artigo (talvez em um próximo), mas, se você quiser uma compreensão completa, recomendo duas referências importantes:

• O artigo "Exploratory Testing Explained", de James Bach (citado acima);
• O livro "Explore it! Reduce Risk and Increase Confidence with Exploratory Testing", de Elisabeth Hendrickson.

O livro, em especial, traz explicações detalhadas sobre como explorar de forma eficaz, sessões práticas, fatores de qualidade, elementos essenciais e quando parar de testar.

Priorização de escopo

Embora essas leituras abordem o teste exploratório em profundidade, ainda resta um tema que não é mencionado explicitamente: a priorização de escopo.

Depois dessas leituras, talvez você já entenda como conduzir testes exploratórios de forma mais eficiente. Mas como priorizar o escopo identificado durante o teste exploratório? Sem essa priorização, todas as informações coletadas podem facilmente virar um caos.

Com esse caos em mente, lembrei de outro recurso que conheci no início da minha carreira, conhecido como Testes Baseados em Risco (RBT).

Os Testes Baseados em Risco (RBT) são uma abordagem de teste de software focada em alocar os recursos de teste nas áreas do sistema que apresentam maior risco. Seu objetivo principal é identificar, priorizar e tratar os riscos do software, garantindo que os testes se concentrem nos componentes críticos e mais propensos a erros.

Em vez de aplicar os testes de maneira uniforme em todo o sistema, o RBT otimiza o processo de teste para maximizar a descoberta de defeitos relevantes e, ao mesmo tempo, minimizar os riscos associados ao uso do software. Isso se torna especialmente crítico quando recursos de teste como tempo e orçamento são limitados.

Você pode criar seus casos de teste com base nesses esforços, estruturados da seguinte forma:

Os esforços de teste identificados por meio do teste exploratório são priorizados de acordo com o seu impacto multiplicado pela frequência de ocorrência (representados visualmente do vermelho ao verde, do maior número ao menor).

Depois que todos os esforços de teste estiverem mapeados nessa matriz de rastreabilidade, seu papel como QA é garantir que a cobertura comece pelos comportamentos com a maior relação entre impacto e ocorrência, avançando até os riscos menores e menos frequentes.

Portanto, o foco dos seus testes deve seguir sempre esta ordem de prioridade: 25, 20, 20, 16, 15, 15, 12, 12, 10, 10, 9, 8, 8, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 2, 1.

Mas como identificar qual parte do sistema corresponde a 25, 20, 16, 15 e assim por diante? É aí que entra a sua experiência de campo. Se você estiver em dúvida ou não tiver experiência, pode se apoiar em benchmarks de mercado, em critérios de criticidade definidos pelo cliente ou validar essas prioridades com o seu time.

Em outras palavras, o vasto fluxo do projeto observado durante o teste exploratório, que inicialmente parece caótico e sem priorização de escopo, começa a se transformar em um processo organizado e estruturado.

Melhor ainda: você não está limitado a usar o RBT apenas na execução de testes. O RBT também pode ser aplicado com eficácia na priorização de regras de negócio, critérios de aceitação, protótipos, documentação de requisitos e muito mais.

Curiosamente, à medida que você pratica o teste exploratório com mais frequência, priorizar o escopo se torna algo natural, formando um framework eficaz de teste exploratório baseado em experiência combinada com priorização de escopo.

Juntos, o teste exploratório e os testes baseados em risco fortalecem a qualidade do software, otimizam o processo de teste e aumentam significativamente a probabilidade de descobrir e corrigir defeitos críticos antes que cheguem aos usuários finais. Essas abordagens não apenas aprimoram a detecção de defeitos, mas também promovem uma mentalidade proativa de qualidade, permitindo uma colaboração mais próxima entre os times de desenvolvimento e de testes para mitigar riscos desde as fases iniciais do ciclo de vida do software.

A combinação de teste exploratório e testes baseados em risco desempenha um papel crucial para garantir a qualidade de produtos e projetos. O teste exploratório permite que os testadores interajam com o software de forma mais intuitiva e flexível, com base em técnicas de teste. Já os testes baseados em risco direcionam os esforços de teste para as áreas de maior impacto e risco.

No fim das contas, essa combinação estratégica contribui para a entrega de um produto ou projeto mais confiável, funcional e seguro.