QA Docs - The Hidden Backbone of QA

Lucy Kendi — Mon, 20 Oct 2025 23:22:42 +0000

When I first joined the QA track of HNG Internship, it was mostly because I have a knack for spotting faults. Some may call me “nitpicky” — I like to think of it as a superpower. Naturally, I thought my role would be simple: find bugs, report bugs, repeat. Easy, right?

Well, not exactly.

My first assignment was on a project called Gradific. The task? Using the system PRD (Product Requirements Document) and FRD (Functional Requirements Document) to create a Test Plan, Test Cases and Non-Functional Requirements document.

My initial reaction?
"I came to find bugs, not juggle paperwork!"

A quick Google search later revealed that there's even more paperwork: Test Scenarios, Traceability Matrix, Test Summary Reports...

I went for a snack break to reset, then decided it was time to understand why all this documentation exists.

Turns out, each document is like a piece of a puzzle, completing the bigger picture of software quality.

Here's a simple breakdown:

Document	Purpose
PRD (Product Requirements Document)	Explains the why behind the product
FRD (Functional Requirements Document)	Details what the product/system should do
NFR (Non-Functional Requirements)	Defines how the system should behave - in terms of speed, security, reliability, availability and so on
Test Plan	Provides a guide on what and how to perform testing
Test Cases	Step-by-step checks from the requirements to verify that the product/system works as expected
Traceability Matrix	Maps requirements to test cases to ensure nothing gets missed
Test Summary Report	Summarizes test results after the testing process

Suddenly, it all made sense. The PRD and FRD explain why we’re building the system and what to build. The Test Plan and Test Cases confirm that those requirements are met. The Non-Functional Requirements make sure the system runs smoothly, securely, and reliably. And with this in mind, it became very easy to create the required documents.

My takeaway?

I’m still in QA for the thrill of finding bugs—but now I have a newfound respect for QA documentation. It’s not just paperwork; it’s the foundation of quality software.

No App is an Island: How APIs Connect Our Digital World

Lucy Kendi — Thu, 16 Oct 2025 20:32:22 +0000

TL;DR

APIs are the digital waiters of the internet, seamlessly taking orders from your apps and delivering data from powerful servers all around the world. REST APIs are the most popular type, following a simple set of rules to make this communication fast, reliable, and scalable. They are the invisible glue connecting our digital world, making everything from weather updates to food delivery possible with just a few taps.

Ever wonder how your phone knows it's going to rain? Or how you can log into a new game using your Google account in one tap? Or how a food delivery rider is able to find your exact spot?

(If you've never wondered, that's okay—you were probably just happily enjoying your delivered food. No judgment here! 😉)

We often just tap and swipe, crossing our fingers for instant results and hoping that pesky loading icon doesn't show up.


The loading icon - a sight that fills us all with a tiny bit of anxiety and a whole lot of hope

But behind that loading screen, there are quiet conversations taking place. And this is enabled by APIs.

So, what is an API?

API stands for Application Programming Interface. Fancy name, simple idea.

Think of it like ordering a pizza. 🍕

You (the customer) tell the waiter what you want. The waiter carries your order to the kitchen, then brings the pizza back when it’s ready.

Your phone works the same way:

The app on your phone (for example, weather app) is the customer.
The server that has the data is the kitchen.
The API is the waiter — the messenger that takes requests from the app and returns the answers.

And that’s the whole idea behind the name: it's an Interface that lets different Applications (even if written in various Programming languages) talk to each other.

Types of APIs

There are several types of APIs. You might hear techy names like SOAP, gRPC or GraphQL.

But the most popular is called a REST API.

Getting to Know REST APIs

Now that we know what APIs are, REST stands for: Representational State Transfer. Long name, huh. Feel free to take a quick rest to let that sink in (see what I did there 😉)

Okay, back to REST! Remember our waiter? They're the API, ferrying requests and responses back and forth.

REST is just a specific set of rules for how that waiter should do their job. The name tells us everything we need to know: Representational State Transfer. Let's break it down.

State Transfer:
State: This is just "what's going on right now." Your order's state is "one large Hawaiian pizza, cooking in the oven, 5 minutes until done." Transfer means "to move." So, we are moving that information from the kitchen to you. In short, State Transfer = moving the latest info from one place to another.
Representational:
This just means that the info is sent and received in a standard, agreed-upon format that is easy to understand, like JSON.

Since we mentioned earlier that REST includes rules to guide the API (waiter) on how to do their job, there are simple commands that are typically used:

GET: "Can I GET the menu?" (Asks for info)
POST: "I'd like to POST a new order." (Creates something new)
PUT: "I need to PUT a change to my whole order." (Updates everything)
PATCH: "Just PATCH the drink on my order." (Updates one little thing)
DELETE: "Please DELETE my order." (Cancels it)

These commands are also commonly referred to as HTTP verbs/methods.

Statelessness in REST APIs

Another key rule of REST is statelessness. This is a fancy word for a simple idea: the waiter has no memory.

Each time your app makes a request, the API treats it as a brand-new conversation. The waiter doesn't remember your name, your last order, or that you asked for extra napkins five minutes ago. Every single time, you have to reintroduce yourself and state your full request.

Why is this a good thing?

Imagine if a waiter had to remember every single customer's entire history. They'd get overwhelmed and slow down! With statelessness, any waiter (or server) can handle any customer (or app) at any time because every request is self-contained. This makes the whole system incredibly reliable and easy to scale.

So with each order/request, you have to provide little notes with further context. These are called Request Headers.

Request headers are not the main data, but they help provide further information that may be necessary for the API to do its job.

Examples of Request Headers:

Authorization - Proving that you are who you claim to be and have the permission to make orders in the restaurant (login token)
Content-Type - Tells the server how to read and format the data.
User-Agent - Tells the server what kind of device is making the request.

By including these headers, your app gives the "stateless" waiter all the extra info it needs to successfully complete each individual request.

API Security and Performance

For APIs to be useful, they need to be both secure (so your data is safe) and fast (to avoid that endless loading icon!).

Keeping Things Secure

Authentication (prove who you are): Use tokens or keys so the API knows the requester is real.
Authorization (limit what you can do): Even if you’re authenticated, only let you access what you’re allowed to. - HTTPS (lock the conversation): Encrypt traffic so nobody can eavesdrop on your order.
Input validation (don’t accept nonsense): Check incoming data, so attackers can’t send harmful stuff.
Rate limiting & throttling: Prevent one user from flooding the kitchen with orders.
Logging & monitoring: Keep a record and watch for suspicious activity so problems are spotted early.

Keeping Things Fast

Caching: Reuse common answers so the waiter can hand them over immediately.
Pagination & filtering: Don’t bring the whole menu at once; give it in slices.
Compression: Send smaller packets so responses travel faster.
CDNs & edge caching: Put copies of static stuff closer to users.
Efficient endpoints & batching: Let clients ask for only what they need and combine requests when possible.
Monitoring & autoscaling: Watch performance and add more “waiters” automatically when traffic spikes.

Wrapping it Up

So next time you check the weather or order food online, remember the friendly Waiter—the API—working behind the screen.

Just like people, our apps need to talk to each other to make amazing things happen. And APIs are the reason they can.

Forem: Lucy Kendi