Building a Reliable API Automation Suite for zedu.chat ( What I Learned Along the Way)

When I started Stage 3 of the QA Engineering task, I initially thought it would just be about writing automated tests. But very quickly, I realized this stage was testing something deeper. A very important one of them all is the ability to think like an API tester and build a reliable automation system from scratch.

Step 1: Understanding the System Before Writing Code

Before writing any test, I explored the Swagger documentation and focused on one key flow:

Authentication → Token → Protected endpoints

I identified that most endpoints required a Bearer token, so getting login right was critical. Without that, every other test would fail.

Step 2: Solving Authentication (The Turning Point)

At first, I kept getting errors like:

404 Not Found → wrong base URL
400 Invalid credentials → wrong test data
Token not found → wrong JSON path

This forced me to actually inspect the API response carefully. I discovered that:

{
  "data": {
    "access_token": "..."
  }
}

The token was nested, not at the top level.

That was when I understood an important QA lesson:

Never assume response structure — always verify it.

I then created a reusable authentication function (auth.py) to dynamically generate tokens and used a pytest fixture to share it across tests.

Step 3: Building Structured Test Coverage

Instead of writing random tests, I grouped them properly:

Positive Tests

Valid login
Accessing protected endpoints with a valid token
Verifying response structure and data types

Negative Tests

Login with invalid credentials
Missing required fields
Invalid email format
Accessing endpoints without a token
Using malformed tokens

These tests helped validate how the API handles failure scenarios.

Edge Case Tests

This was where I had to think more deeply.

I tested:

Empty and null inputs
Extremely long email values
Special characters
Case sensitivity
Multiple repeated login attempts

This helped ensure the system behaves correctly under unusual conditions.

Step 4: Fixing Real Failures (Important Learning)

One of my tests failed even after everything seemed correct.

I assumed:

"user_id" in data["data"]

But the actual response was:

data → user → id

That mistake taught me:

Different endpoints return different structures you must validate each independently.

Step 5: Ensuring Test Reliability

To meet the task requirements, I ensured:

No hardcoded tokens
Tests are independent
Tests can run multiple times without failure
Environment variables are used (.env)
Assertions check more than just status codes

Final Outcome

Total tests written: 26
Includes:
- Positive tests
- Negative tests (10+)
- Edge cases (5+)
All tests pass consistently

What I Learned

This task changed how I see QA.

It’s not just about writing tests, it’s about:

Understanding how systems behave
Thinking about failure before it happens
Validating real-world usage, not just happy paths

Final Thought

At the beginning, I was debugging errors. By the end, I was designing test coverage.

That shift from reacting to errors to anticipating them is what defines a QA Engineer.

#QA #APItesting #Pytest #SoftwareTesting #HNGInternship #QualityAssurance

Command Palette