Como organizo meus testes no Azure DevOps no dia a dia como QA

Quando comecei a trabalhar com testes de software, uma coisa ficou clara rapidamente para mim.

Testar não é só executar cenários.

Grande parte do trabalho também envolve organizar os testes, manter rastreabilidade com o desenvolvimento e documentar o que foi validado ao longo do processo.

Hoje grande parte desse fluxo acontece dentro do Azure DevOps no time em que trabalho. Com o tempo fui entendendo melhor como usar as ferramentas da plataforma para estruturar meus testes de forma mais clara e organizada.

Esse é o fluxo que utilizo atualmente.

Como as demandas chegam para QA

No nosso processo de desenvolvimento, as funcionalidades são organizadas em alguns níveis dentro do Azure DevOps.

Primeiro temos os Epics, que representam iniciativas maiores do produto.

Dentro deles ficam as Features, que agrupam funcionalidades relacionadas.

E dentro das features estão as User Stories, que representam as entregas menores que o time desenvolve.

Para QA, normalmente é a partir da User Story que começamos a planejar os testes. Nesse momento procuro entender as regras de negócio e os critérios de aceite da funcionalidade, levantando possíveis cenários de validação e pontos que podem gerar dúvidas ou comportamentos inesperados.

Também procuro avaliar quais partes da funcionalidade parecem mais críticas ou têm maior risco de impacto no sistema. Isso ajuda a priorizar melhor os testes e garantir que os fluxos mais importantes sejam validados primeiro.

Onde entra o Test Plan

Para organizar os testes utilizamos o Test Plan do Azure DevOps, que é uma funcionalidade da plataforma voltada especificamente para gestão de testes.

Dentro dele criamos planos de teste e organizamos as suítes onde os casos de teste ficam estruturados.

Isso ajuda bastante a manter tudo centralizado. Os cenários planejados, as execuções realizadas e os resultados ficam registrados no mesmo lugar.

Essa organização também facilita quando precisamos revisitar algum comportamento no futuro ou entender rapidamente o que já foi validado em determinada funcionalidade.

Organização das suítes de teste

Dentro do Test Plan costumo utilizar Requirement-based suites.

Esse tipo de suíte permite associar diretamente uma User Story aos casos de teste.

Na prática isso cria uma conexão clara entre três coisas importantes:

• a história que está sendo desenvolvida
• os cenários de teste criados para validá-la
• a execução desses testes

Essa relação facilita muito a rastreabilidade, porque qualquer pessoa do time consegue entender rapidamente quais testes foram planejados para aquela funcionalidade.

Criação dos casos de teste

Depois de criar a suíte vinculada à User Story, começo a montar os test cases.

Mas antes de criar os casos de teste, procuro entender quais fluxos da funcionalidade são mais críticos para o usuário ou para o negócio. Esses cenários costumam ser priorizados na validação inicial.

Normalmente organizo cada caso com:

• descrição do cenário a ser validado
• passo a passo de execução
• expect result para cada passo

Durante essa etapa também procuro pensar em diferentes variações de uso da funcionalidade, incluindo cenários alternativos e possíveis comportamentos inesperados.

Sempre que surge alguma dúvida sobre regras de negócio ou comportamento esperado, costumo alinhar com o time de desenvolvimento ou produto antes da execução dos testes. Esse alinhamento evita interpretações diferentes sobre o funcionamento da funcionalidade.

Execução dos testes

Quando a User Story entra no status que no fluxo do time indica que está pronta para validação de QA, executo os testes diretamente pelo Test Plan.

A execução acontece dentro da suíte associada àquela User Story.

Durante o teste registro evidências como capturas de tela e ou vídeos quando necessário. Essas evidências ficam vinculadas à execução do teste.

Isso ajuda bastante quando precisamos revisitar algum comportamento ou explicar um problema encontrado durante a validação.

Registro de bugs durante o teste

Se algum comportamento inesperado aparece durante a execução, também é possível abrir um bug diretamente pelo Test Plan.

Isso mantém o bug automaticamente relacionado ao teste que estava sendo executado e à User Story correspondente.

Na descrição normalmente incluo:

• resultado encontrado
• resultado esperado
• passos para reprodução
• evidências visuais (print ou vídeo)

Esse padrão facilita bastante para o time de desenvolvimento entender rapidamente o problema.

Retestes e validação final

Quando um bug é corrigido, consigo executar novamente apenas o caso de teste específico que falhou, sem precisar rodar toda a suíte novamente.

Esse reteste também fica registrado no histórico de execução do Test Plan e podem depois serem vistos nas métricas que são configuradas daquela suíte.

Quando todos os cenários estão validados e não existem mais falhas abertas, a história segue no fluxo do time para as próximas etapas do processo, geralmente sendo o deploy.

Reutilização de cenários de teste

Em algumas situações também reutilizo cenários de teste quando funcionalidades existentes são estendidas.

Por exemplo, quando uma tela já possui determinados comportamentos e novas variações são adicionadas, adapto os casos existentes em vez de recriar todo o cenário do zero.

Isso ajuda a manter consistência nos testes e evita duplicidade de cenários.

Também é comum revisitar cenários que já quebraram em versões anteriores do sistema, garantindo que essas situações continuem sendo validadas em novas entregas.

Outro ponto importante nesse processo é revisar os próprios casos de teste ao longo do tempo. Conforme funcionalidades evoluem ou novos comportamentos são identificados durante testes e correções de bugs, alguns cenários precisam ser ajustados ou ampliados. Manter os test cases atualizados ajuda a garantir que a suíte de testes continue refletindo o comportamento real do sistema.

Por que esse fluxo ajuda no dia a dia

Uma das coisas que mais gosto nesse processo é a rastreabilidade.

Os cenários de teste ficam conectados às User Stories. As execuções ficam registradas. Os bugs ficam vinculados aos testes que os identificaram.

Isso cria um histórico claro do que foi testado, como foi testado e quais problemas foram encontrados durante o desenvolvimento.

No dia a dia de QA isso faz bastante diferença, principalmente quando precisamos revisitar funcionalidades, entender o impacto de mudanças no sistema ou validar correções de bugs.

Um ponto que ainda estou explorando…

Outro uso interessante do Test Plan é a organização de suítes de regressão para fluxos críticos do sistema.

Além dos cenários planejados, ao final da execução da suíte costumo revisitar alguns fluxos importantes da funcionalidade para garantir que nada passou despercebido. Muitas vezes esse momento acaba funcionando quase como um pequeno teste exploratório, onde tento navegar pela funcionalidade de forma mais livre para identificar comportamentos inesperados que não estavam previstos inicialmente.

Essa é uma prática que venho estudando para evoluir melhor dentro da estrutura de testes, principalmente pensando em regressão para partes críticas do sistema.

Com o tempo também fui identificando funcionalidades que costumam sofrer mais impacto quando novas entregas são feitas. Isso ajuda a manter alguns cenários sempre presentes na regressão, garantindo que comportamentos importantes continuem funcionando mesmo com mudanças no sistema.