Como acelerei a entrega de features do meu time usando Postman

Esse post é sobre uma daquelas situações em que o gargalo do time não estava no código, e sim no processo. E como uma ferramenta que todo mundo já usava todos os dias virou a chave pra resolver.

O cenário

O time era enxuto: PM, PO, TL, 4 devs e 2 QAs. A gente trabalhava com APIs e microsserviços, públicos e privados, backend de ponta a ponta.

Conforme as features iam saindo, o time de QA tinha que rodar testes regressivos pra garantir que o resto do sistema não tinha quebrado. Até aí, normal — todo time sério faz isso. O problema era como esses testes eram feitos.

Era literalmente abrir o Postman, mudar campo por campo, rodar request, conferir resposta no olho. As collections existiam, organizadas até, mas nada rodava de forma automática. Cada cenário pedia uma massa de dado específica: pra testar o cenário X, a coluna status precisava ser true; pro Y, false; pro Z, um CPF válido com BLOCKED no status. E como os QAs só tinham acesso de leitura no banco, quem precisava criar essas massas eram… os devs.

Resultado: tinha sprint em que a "atividade do dev" era literalmente ajudar QA a montar massa de teste. O regressivo demorava quase uma semana. Teve feature que levou duas semanas pra ir pra prod — e olha que o time e a direção foram bem compreensivos, todo mundo entendia que qualidade é inegociável. Mas dava pra ver o problema crescendo.

E o mais curioso: ninguém tinha pensado em mudar isso ainda. Tava todo mundo aceitando como o jeito que as coisas funcionavam.

A virada

Eu já sabia que dava pra usar variáveis de ambiente no Postman. O que eu não sabia é que existia uma seção de pre-request e post-request scripts — e foi aí que a ficha caiu.

A primeira coisa que resolvi foi a autenticação das requests privadas. No pre-request das chamadas privadas, eu salvava o token direto na collection variable. Pronto: nenhuma request privada precisava mais ser autenticada na mão.

Aba de pre-request no Postman com script de autenticação

Mas a parte da massa de dados era o ponto crítico. Aqui foi onde nasceu o "workaround feio que resolve problema real": criei uma variável de ambiente no projeto que, quando ativa, expunha um endpoint de criação de massa. O QA podia chamar essa API e moldar o dado como quisesse — CPF preenchido ou nulo, endereço opcional, status definido na hora. Era basicamente dar acesso ao banco via API, mas de forma controlada e só nos ambientes certos.

Com isso destravado, parti pros cenários. Pra um cenário que precisava de CPF válido, CEP e nome, escrevi uma função em JavaScript no pre-request que chamava a API do 4devs pra gerar dados dinâmicos, salvava na collection variable, e o request body só referenciava a variável.

// exemplo de pre-request para gerar dados dinamicos
pm.sendRequest({
    url: 'https://www.4devs.com.br/ferramentas_online.php',
    method: 'POST',
    header: {
        'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: {
        mode: 'urlencoded',
        urlencoded: [
            { key: 'acao', value: 'gerar_pessoa' },
            { key: 'sexo', value: 'H' },
            { key: 'pontuacao', value: 'S' },
            { key: 'idade', value: '18' },
            { key: 'cep_estado', value: 'MS' },
            { key: 'txt_qtde', value: '1' },
            { key: 'cep_cidade', value: '4152' }
        ]
    }
}, function (err, res) {
    if (err) {
        console.log('Error generating person:', err);
        return;
    }

    try {
        const data = res.json();
        // since it's an array, take the first item
        const pessoa = data[0];
        pm.collectionVariables.set('generatedName', pessoa.nome);
        pm.collectionVariables.set('generatedCPF', pessoa.cpf);
        pm.collectionVariables.set('generatedPhone', pessoa.celular);

    } catch (e) {
        console.log('Error parsing JSON:', e);
    }
});

Aba de request body no Postman com dados gerados pela pre-request

// exemplo de post-script para salvar a massa de teste que vai ser processada
const data = pm.response.json();

pm.collectionVariables.set('cpf', data.cpf);
pm.collectionVariables.set('accountType', data.accountType);
pm.collectionVariables.set('phone', data.phone);
pm.collectionVariables.set('accountStatus', data['account-status']);
pm.collectionVariables.set('createdDatetime', data['created-datetime']);
pm.collectionVariables.set('updatedDatetime', data['updated-datetime']);

Pra cenários que precisavam de um valor fixo (tipo status em BLOCKED), o body já vinha hard-coded mesmo. Simples.

Foi nesse momento que descobri uma outra coisa do Postman: dá pra rodar a collection inteira de uma vez, em sequência, e no final ele mostra exatamente quais requisições falharam.

Tela que faz a execucao de todas as requisicoes de uma collection

Daí pra frente, foi só multiplicar: cada cenário virou uma collection, nomeada de acordo com o caso de teste. A geração de massa se repetia em todas, e eu ia ajustando conforme o QA pedia.

Validando o resultado automaticamente

Tem mais uma peça importante que faltou contar: na aba post-request dá pra escrever asserts em JavaScript que rodam depois da resposta. É isso que faz o Collection Runner saber se a request "passou" ou "falhou" — não basta o status code estar OK, dá pra checar campo a campo do payload.

// exemplos de assertions na aba post-request
pm.test("status 200", () => pm.response.to.have.status(200));

pm.test("conta retornada está bloqueada", () => {
    const body = pm.response.json();
    pm.expect(body.status).to.eql("BLOCKED");
    pm.expect(body.cpf).to.eql(pm.collectionVariables.get("cpfGerado"));
});

Com isso, cada cenário deixou de depender de alguém olhar a resposta no olho. Se o comportamento esperado mudasse (regressão), o teste estourava sozinho — e o Collection Runner mostrava exatamente qual cenário quebrou.

A recepção

Eu montei essa primeira versão sozinho — confesso que parte da motivação foi egoísta: eu gosto quando o QA não acha bug no que eu fiz. Então primeiro fiz pra mim, pra testar minhas próprias implementações com mais profundidade. Depois pensei "espera, isso vai facilitar absurdamente a vida dos QAs também".

Fiz uma apresentação interna, mostrei como montar os cenários, como rodar a collection, e o pessoal abraçou na hora. Virei o "Dev Postman" na zoeira do time. 😂

Visao geral de como ficou a collection dos QAs apos apresentar a automacao

A primeira versão demorou pra mapear tudo, mas o resultado foi muito bom:

Regressivo passou de ~1 semana pra ~2 horas
Dezenas de collections, centenas de requisições mapeadas
A devolutiva do QA pro dev (encontrou bug → dev corrige) ficou drasticamente mais rápida
Acabaram as sprints de "dev ajudando QA". No máximo, um pedido pontual aqui ou ali
E o mais importante: as entregas voltaram a fluir

O que eu levei dessa

Esse projeto mudou como eu enxergo meu papel como dev.

Antes eu pensava que entregar feature era o trabalho. Hoje eu entendo que aliviar o peso do colega ao lado também é parte do trabalho — seja ele dev, QA, PO, quem for. Desde então, em toda empresa que entro, eu fico de olho: que atividade tá travando o time? Dá pra automatizar? Tem alguma coisa que todo mundo aceitou como "é assim mesmo" mas que com um pouco de curiosidade resolveria?

Algumas dessas automações que fiz, antigos colegas usam até hoje. Isso me dá uma satisfação que entregar feature nenhuma dá.

Recado final

Se tem alguma coisa te incomodando no dia a dia, e você é curioso o suficiente pra parar e pensar "será que dá pra resolver isso?" — provavelmente vai valer a pena.

A solução quase nunca tá numa ferramenta nova e brilhante. Tá na ferramenta que você já abre todo dia, e que você só não explorou ainda.