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.
Top comments (0)