The Moment I Realised UI Testing Wasn't Enough

Three years into my QA career, I thought I was doing well.

I had a solid Selenium suite running. Regression coverage was green. Stakeholders were happy.

Then a production incident happened.

A payment API was returning incorrect amounts under a specific condition. The UI looked perfect — amounts displayed correctly after rounding. But the raw API response? Off by a significant margin.

My entire test suite missed it. Every single test.

Because I was only testing what users saw. Not what the system was actually doing.

That incident changed how I approached QA forever. 👇

Why API Testing Is the Most Underrated Skill in QA

Let me be direct about something.

Most QA engineers treat API testing as a secondary skill. Something you do with Postman when a developer asks you to verify an endpoint. A quick sanity check before moving on.

That's the wrong mental model entirely.

Here's the truth after 7.5 years:

The API layer is where your product actually lives.

The UI is a presentation layer. It shows users a version of the truth. But the API? That's the truth itself. Data contracts, business logic, validation rules, error handling — all of it lives at the API layer.

If you're only testing the UI, you're testing the packaging. Not the product.

My API Testing Journey — Tool by Tool

Let me walk you through exactly how my API testing practice evolved, and what each tool actually taught me.

Stage 1 — Postman: Learning to Think in Requests

Postman was my entry point. And it's still the tool I reach for first when exploring a new API.

But most people use Postman wrong.

They treat it like a manual testing tool — fire a request, check the response, move on. That's wasting 80% of what Postman can do.

Here's how I actually use it:

Collections + Environments = your real power combo

// Environment variables — not hardcoded values
{{base_url}}/api/v1/users/{{user_id}}

// Switch between dev/staging/prod by changing one environment
// Not by editing every single request

Pre-request scripts for dynamic data:

// Generate a unique email for every test run
const timestamp = Date.now();
pm.environment.set("test_email", `testuser_${timestamp}@example.com`);

Test scripts for automated assertions:

pm.test("Status code is 200", () => {
    pm.response.to.have.status(200);
});

pm.test("User ID matches", () => {
    const response = pm.response.json();
    pm.expect(response.data.id).to.eql(pm.environment.get("user_id"));
});

pm.test("Response time under 500ms", () => {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

What Postman taught me:
Thinking in terms of contracts. Every API has an implied contract — here's what you send, here's what you get back. My job as a tester is to verify that contract holds under every condition.

Stage 2 — Charles Proxy: Seeing What the System Hides

Postman is great when you know what API you're testing.

But what about the APIs you don't know about?

Charles Proxy changed my debugging game completely. I started opening it before I even wrote my first test on any new feature.

Here's my actual workflow:

1. Open Charles, start capturing
2. Perform the user action in the app (or mobile device via proxy)
3. See every network call — including the ones nobody told me about
4. Build my test suite from what I actually observe, not just what's in the Swagger docs

The Swagger docs lie. Or they're outdated. Or they're incomplete. Charles never lies.

Where Charles became indispensable:

Scenario: Mobile checkout flow
What Swagger documented: 3 API calls
What Charles actually showed: 7 API calls

The undocumented calls included:
- A fraud scoring API call
- An inventory reservation call  
- A session refresh call

All three were failure points nobody had tested.

Breakpoints for on-the-fly request modification:

Set a breakpoint on any request. Intercept it before it hits the server. Modify the payload. Fire it. See what happens.

This is how I test edge cases that would take hours to set up in a test environment — in minutes.

Stage 3 — Playwright for API Testing: Automation That Actually Scales

Manual Postman and Charles get you far. But they don't scale.

When I needed repeatable, CI-friendly API tests, I moved to Playwright's API testing capabilities. Most people don't know Playwright does this — they think of it as a browser tool only.

import { test, expect } from '@playwright/test';

test.describe('User API', () => {

    let authToken;

    test.beforeAll(async ({ request }) => {
        // Authenticate once, reuse token across all tests
        const response = await request.post('/api/auth/login', {
            data: {
                email: 'test@example.com',
                password: 'testpassword'
            }
        });
        const body = await response.json();
        authToken = body.token;
    });

    test('GET user profile returns correct schema', async ({ request }) => {
        const response = await request.get('/api/v1/users/profile', {
            headers: {
                'Authorization': `Bearer ${authToken}`
            }
        });

        expect(response.status()).toBe(200);

        const body = await response.json();

        // Schema validation
        expect(body).toHaveProperty('id');
        expect(body).toHaveProperty('email');
        expect(body).toHaveProperty('role');
        expect(typeof body.id).toBe('number');
        expect(typeof body.email).toBe('string');
    });

    test('POST create user — validates required fields', async ({ request }) => {
        const response = await request.post('/api/v1/users', {
            headers: { 'Authorization': `Bearer ${authToken}` },
            data: {
                // Missing required 'email' field intentionally
                name: 'Test User'
            }
        });

        expect(response.status()).toBe(400);

        const body = await response.json();
        expect(body.error).toContain('email');
    });

    test('Response time SLA — under 800ms', async ({ request }) => {
        const start = Date.now();

        await request.get('/api/v1/users/profile', {
            headers: { 'Authorization': `Bearer ${authToken}` }
        });

        const duration = Date.now() - start;
        expect(duration).toBeLessThan(800);
    });
});

What makes Playwright API testing powerful:

• Runs in the same framework as your UI tests — one suite, one report
• Built-in request context — no extra HTTP client libraries
• Parallel execution out of the box
• Integrates cleanly with CI/CD

Stage 4 — DB Validation: The Layer Nobody Tests

This is the one most automation engineers completely skip.

Here's the problem with testing only at the API layer:

POST /api/v1/orders
Response: { "status": "success", "order_id": "ORD-123" }
Test result: ✅ PASS

But did the order actually get written to the database correctly?
Did all the fields persist as expected?
Did the foreign key relationships hold?
Did any triggers fire that modified related records?

Your API test doesn't know. Your DB test does.

import { test, expect } from '@playwright/test';
import { Client } from 'pg'; // PostgreSQL client

test('Order creation — validates DB persistence', async ({ request }) => {

    // Step 1: Create order via API
    const response = await request.post('/api/v1/orders', {
        headers: { 'Authorization': `Bearer ${authToken}` },
        data: {
            product_id: 42,
            quantity: 2,
            user_id: 101
        }
    });

    expect(response.status()).toBe(201);
    const { order_id } = await response.json();

    // Step 2: Validate at DB layer
    const db = new Client({ connectionString: process.env.DB_URL });
    await db.connect();

    const result = await db.query(
        'SELECT * FROM orders WHERE order_id = $1',
        [order_id]
    );

    expect(result.rows.length).toBe(1);

    const order = result.rows[0];
    expect(order.product_id).toBe(42);
    expect(order.quantity).toBe(2);
    expect(order.user_id).toBe(101);
    expect(order.status).toBe('pending'); // Business logic check

    await db.end();
});

This two-layer approach has caught bugs that API testing alone never would:

• Records created with wrong foreign keys
• Decimal precision lost during persistence
• Audit log entries missing
• Cache not invalidated after write

Stage 5 — JMeter: When "Does It Work?" Isn't Enough

All the tests above answer one question: does it work?

JMeter answers a different question: does it work under load?

I've been using JMeter for performance testing for years. And the pattern I see constantly is this — APIs that pass every functional test absolutely fall apart at scale.

My standard performance test structure for any API:

Thread Group: 100 concurrent users
Ramp-up: 60 seconds
Duration: 5 minutes

HTTP Request: POST /api/v1/orders
  → CSV Data Set Config (unique test data per user)
  → HTTP Header Manager (auth tokens)

Listeners:
  → Summary Report (throughput, error rate)
  → Response Time Graph
  → View Results Tree (for debugging failures)

Assertions:
  → Response time < 1000ms (95th percentile)
  → Error rate < 1%

The bugs JMeter found that nothing else did:

• A search API that handled 10 concurrent users fine — degraded to 30-second responses at 50 users (missing database index)
• A session API with a race condition that only appeared when 20+ users hit it simultaneously
• A payment API that started returning 500s after sustained load for 10 minutes (connection pool exhaustion)

None of these would've been caught by functional tests alone.

The Career Impact — What API Testing Actually Changed

Here's what shifting my focus to API testing actually did for my career:

I became the person who caught things before production.

Not because I'm smarter than anyone else. Because I was looking at a layer most testers weren't looking at.

I got closer to developers.

API testing made me fluent in the language developers speak. Endpoints, payloads, status codes, contracts, performance SLAs. When you speak that language, developers start treating you as a peer — not a gatekeeper.

I became harder to replace.

A tester who only does UI automation is replaceable. A tester who understands the full stack — UI, API, performance, database — is a different kind of engineer entirely.

It prepared me for AI testing.

Everything I'm doing now with RAG-based testing and LLM validation is built on top of API testing fundamentals. AI systems are, at their core, APIs. The mental model transfers directly.

Where to Start If You're Behind on API Testing

If you're reading this and realising your API testing practice needs work — here's the honest starting point:

Week 1: Learn Postman properly. Collections, environments, test scripts. Newman for CLI runs.

Week 2: Set up Charles Proxy. Intercept a real app's traffic. Map every API call for one feature.

Week 3: Write your first Playwright API test suite for a real endpoint in your project.

Week 4: Add DB validation for your most critical write operations.

Month 2: Set up a JMeter test for your highest-traffic endpoint. Run it. See what breaks.

You don't need to do all of this overnight. But you need to start. Because the gap between teams that do this and teams that don't is enormous — and it shows up directly in production.

Final Thought

The best QA engineers I've ever worked with share one trait.

They're deeply curious about how things work — not just whether things work.

API testing is what happens when that curiosity meets a systematic approach.

It's not glamorous. There's no visual feedback, no screenshots, no UI to look at. Just raw data flowing between systems — and your job to make sure every byte of it is exactly right.

That's the work. And in my experience, it's the most valuable work in QA.

Faizal Shaikh | Senior Automation Engineer | AI & RAG-Based Testing
Connect with me on LinkedIn

Building a complete RAG Testing Series on Dev.to — follow along if you're curious about testing AI systems.