QA: quando um incidente transforma estudo em experiência - Ciclo de Sanidade: carga/concorrência.

Recentemente vivi uma experiência que mudou minha percepção sobre evolução profissional em QA.

Objetivo do ciclo: sanidade pós-correção de incidente.
Atributo principal: confiabilidade — verificar perdas, duplicidades e pedidos presos.
Condição aplicada: carga/concorrência controlada.
Camada: integração/E2E — API, fila, estoque e banco.

Eu já havia estudado alguns conceitos relacionados a testes de confiabilidade, concorrência e desempenho. Ainda assim, esse tipo de trabalho parecia distante da minha realidade cotidiana. Até um incidente que gerou a necessidade de uma correção no menor tempo possível e consequetemente a validação da mesma. É muito diferente conhecer um assunto em um curso e precisar aplicá-lo durante a validação de uma correção originada por um incidente real.

Quando a demanda chegou, senti uma certa insegurança em saber como inciar a demanda. Reunião com a liderança do squad de Q.AS, reunião com o techlead do produto e a partir disso uma estratégia para seguir. Havia uma correção importante aguardando validação e o resultado dos testes ajudaria a equipe a decidir se ela estava segura para seguir para produção.

O desafio

O incidente envolvia um fluxo de pedidos processados de forma assíncrona. A API aceitava a solicitação, mas a conclusão dependia de outras etapas, como fila, processamento e disponibilidade de estoque.

Por isso, uma resposta de sucesso da API não era evidência suficiente. Um pedido poderia ser aceito e, ainda assim, permanecer em um estado intermediário ou não chegar ao resultado esperado pelo negócio.

A pergunta principal deixou de ser apenas “a API respondeu?” e passou a ser:

Todos os pedidos aceitos foram realmente processados até o estado final esperado, sem perdas, duplicidades ou pedidos indevidamente parados na fila?

Essa mudança de pergunta direcionou toda a validação.

Começando pelo que eu já conhecia

Iniciei os testes pelo Insomnia, ferramenta que já faz parte da minha rotina. Com ele, repeti o fluxo de criação de pedidos e observei o comportamento da fila.

Essa primeira etapa foi importante para validar o funcionamento básico da correção. Também me ajudou a perceber que repetir requisições em sequência não representava completamente o cenário do incidente, que havia ocorrido durante um volume concentrado de solicitações.

Eu precisava validar duas situações diferentes: o comportamento da fila ao processar vários pedidos e o comportamento do sistema quando pedidos chegavam concorrentemente.

Foi nesse momento que o k6 entrou na validação. Até então, eu o conhecia mais pelos estudos do que pela aplicação em uma demanda real. Utilizá-lo não foi somente escolher outra ferramenta, mas compreender qual risco ainda não estava coberto pelos testes que eu já havia executado.

Um passo de cada vez

Durante a preparação, nem tudo funcionou na primeira tentativa. Encontrei erro de rota, falha de autenticação e uma massa de teste que não representava corretamente o fluxo real.

Em vez de tratar isso como fracasso, passei a analisar um problema de cada vez. Primeiro confirmei a rota, depois a autenticação, o formato do pedido, a quantidade adequada e, somente então, aumentei o volume.

Essa forma de avançar foi essencial. Antes de executar centenas de pedidos, validei apenas um. Quando tive segurança de que a requisição estava correta, aumentei gradualmente a carga, sempre observando os resultados.

Também precisei respeitar as limitações do ambiente de homologação. O objetivo não era descobrir o limite máximo da plataforma, mas verificar com segurança se a correção se mantinha confiável diante do cenário que havia provocado o incidente.

A importância das evidências

Uma das partes mais marcantes dessa experiência foi entender que o teste não terminava na ferramenta que enviava as requisições.

Além de observar as respostas da API, registrei os horários, os tempos de resposta e os resultados de cada execução. Depois, cruzei essas informações com os registros do banco de dados para confirmar o estado final dos pedidos.

Esse cruzamento permitiu verificar se tudo o que havia sido aceito pela API realmente existia no banco, possuía o item esperado, recebeu estoque e chegou ao estado final correto.

Ao final do principal ciclo, foram criados 500 pedidos independentes. Todos foram aceitos pela API, encontrados no banco de dados e concluídos no estado esperado. Não houve falhas HTTP, perda de requisições nem pedidos indevidamente parados em estado intermediário.

Também foram realizados cenários regressivos com pedidos de estruturas diferentes, como combo e múltiplas variações, para verificar se a correção não havia afetado comportamentos relacionados.

Mais importante do que dizer “o teste passou” foi conseguir demonstrar por que ele passou.

O que essa experiência me ensinou

O primeiro aprendizado foi que uma resposta de sucesso técnico nem sempre representa o sucesso do negócio. Em fluxos assíncronos, é necessário acompanhar o processamento até a sua conclusão.

Também aprendi que repetição e concorrência cobrem riscos diferentes. Uma ferramenta conhecida pode ser suficiente para uma parte da validação, mas o contexto deve orientar quando é necessário ampliar a estratégia.

Outro ponto importante foi perceber que as próprias evidências precisam ser conferidas. Durante os testes, identifiquei uma contagem que poderia transmitir uma conclusão incorreta. Isso reforçou que não basta automatizar: é preciso questionar se o resultado apresentado realmente corresponde ao que foi executado.

Por fim, entendi que testes de confiabilidade e desempenho não se resumem a gerar grandes volumes. Eles exigem uma hipótese clara, um ambiente conhecido, limites responsáveis e critérios que conectem o resultado técnico ao comportamento esperado pelo negócio.

Evoluir como QA

Para mim, evoluir como QA não significa necessariamente seguir um único caminho ou buscar obrigatoriamente um cargo específico. Significa ampliar a capacidade de investigar riscos, compreender o sistema e oferecer informações confiáveis para que a equipe tome decisões melhores.

Mesmo com os estudos prévios, eu não comecei essa atividade me sentindo completamente preparado. A segurança foi sendo construída durante o processo: perguntando, pesquisando, testando em pequena escala, analisando os erros e compreendendo cada etapa antes de avançar.

Depois de concluir a validação, foi muito satisfatório apresentar as evidências dos testes executados e perceber que o trabalho ajudou a sustentar uma decisão mais segura. Não foi somente uma tarefa técnica concluída. Foi a sensação de ter apoiado um desenvolvimento mais íntegro e confiável.

O desafio que inicialmente parecia distante passou a fazer parte da minha experiência profissional. E talvez uma parte importante da evolução seja justamente essa: não esperar que o frio na barriga desapareça, mas aprender a transformá-lo em investigação, método e evidência. Saber pedir direcionamento para os colegas e agir na estratégia mas sem receio de sugerir teses.