How I sped up my team's feature delivery using Postman

This post is about one of those situations where the bottleneck wasn't in the code — it was in the process. And how a tool everyone on the team already used every day turned out to be the key to fixing it.

The setup

The team was lean: PM, PO, TL, 4 devs and 2 QAs. We worked with APIs and microservices, public and private — backend through and through.

As features kept rolling out, the QA team had to run regression tests to make sure nothing else in the system had broken. Fair enough — every serious team does this. The problem was how those tests were being done.

It was literally opening Postman, changing fields one by one, firing the request, eyeballing the response. The collections were there, even organized, but nothing ran automatically. Every scenario needed a specific test data setup: to test scenario X, the status column had to be true; for Y, false; for Z, a valid CPF with BLOCKED status. And since QAs only had read access on the database, the people who had to create that test data were… the devs.

The result: there were sprints where the "dev's task" was literally helping QA build test data. Regression took almost a full week. There was even one feature that took two weeks to ship — and yes, leadership and the team were understanding, everyone got that quality is non-negotiable. But you could see the problem growing.

And the most curious part: nobody had thought about changing this yet. Everyone just accepted it as the way things worked.

The turning point

I already knew you could use environment variables in Postman. What I didn't know was that there was a pre-request and post-request scripts section — and that's when it clicked.

The first thing I solved was authentication for private requests. In the pre-request of those private calls, I'd save the token straight into a collection variable. Done: no more authenticating each private request by hand.

But the test data piece was the critical one. This is where the "ugly workaround that solves a real problem" was born: I created an environment variable in the project that, when active, exposed a test data generator endpoint. QA could call this API and shape the data however they wanted — CPF filled or null, address optional, status defined on the spot. It was basically giving access to the database via API, but in a controlled way and only in the right environments.

With that out of the way, I went after the scenarios. For a scenario that needed a valid CPF, ZIP code and name, I wrote a JavaScript function in the pre-request that called the 4devs API to generate dynamic data, saved it into collection variables, and the request body just referenced those variables.

// pre-request example: generate dynamic test data
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);
    }
});

// post-script example: persist the generated test data for later steps
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']);

For scenarios that needed a fixed value (like status set to BLOCKED), the body was just hard-coded. Simple.

That was the moment I discovered another Postman feature: you can run an entire collection at once, sequentially, and at the end it shows exactly which requests failed.

From there, it was just a matter of multiplying: each scenario became a collection, named after its test case. The data generation repeated across all of them, and I kept tweaking based on what QA needed.

Validating the result automatically

There's one more important piece I left out: in the post-request tab you can write JavaScript assertions that run after the response. That's what lets the Collection Runner know whether a request "passed" or "failed" — it's not enough for the status code to be OK, you can check field by field of the payload.

// assertion examples in the post-request tab
pm.test("status 200", () => pm.response.to.have.status(200));

pm.test("returned account is blocked", () => {
    const body = pm.response.json();
    pm.expect(body.status).to.eql("BLOCKED");
    pm.expect(body.cpf).to.eql(pm.collectionVariables.get("generatedCPF"));
});

With this, every scenario stopped depending on someone reading the response by eye. If the expected behavior changed (a regression), the test would blow up on its own — and the Collection Runner would show exactly which scenario broke.

How the team took it

I built this first version on my own — honestly, part of the motivation was selfish: I like it when QA can't find bugs in what I shipped. So I built it for me first, to test my own implementations more thoroughly. Then I thought "wait, this is going to make the QAs' lives way easier too."

I gave an internal presentation, showed how to build scenarios, how to run the collection, and the team picked it up immediately. They started calling me "Dev Postman" as a running joke. 😂

The first version took a while to map everything, but the result was great:

• Regression went from ~1 week to ~2 hours
• Dozens of collections, hundreds of mapped requests
• The QA → dev feedback loop (bug found → dev fixes it) got drastically faster
• No more "dev helping QA" sprints. At most, the occasional one-off ask
• And most importantly: feature delivery was flowing again

What I took away from it

This project changed how I see my role as a dev.

I used to think shipping features was the job. Today I understand that lightening the load of the person next to you is also part of the job — whether they're dev, QA, PO, whoever. Ever since, at every company I join, I keep an eye out: what activity is jamming up the team? Can it be automated? Is there something everyone has accepted as "just the way it is" that a bit of curiosity would actually solve?

Some of these automations I built, old coworkers still use today. That gives me a kind of satisfaction no shipped feature ever has.

Final note

If something is bugging you in your day-to-day, and you're curious enough to stop and think "wait, can I solve this?" — it's almost certainly going to be worth it.

The solution is rarely in some shiny new tool. It's in the tool you already open every day, that you just haven't fully explored yet.