Test Plan and Non-Functional Requirements (NFR) Document

🧠 MyJourney as a QA Engineer at HNG: From Requirements to Quality Strategy

During my #HNGi13 experience at @HNGInternship, I had the opportunity to take on a real-world QA task: building a Test Plan and Non-Functional Requirements (NFR) document for a Language Learning AI Game (Delve).

At first glance, it seemed simple, read a document and write a plan.
But true QA work starts with understanding the product, not just testing it.

🧩 Step 1: Understanding the Requirements

I began by reviewing the Functional Requirements Document (FRD), breaking it down into user goals, workflows, and acceptance criteria.
It covered everything from signup/login to AI speech recognition, gamification, subscription management, and progress tracking.

I learned that good testing starts with clarity, every unclear requirement becomes a potential defect in disguise.

🧪 Step 2: Building the Test Plan

Next, I created a comprehensive Test Plan outlining how quality would be achieved, not just tested.
My plan included:

• Scope & Objectives: Define what’s in and out of testing.
• ⁠Approach: Manual + Automated testing using tools like Selenium, Postman, and JMeter.
• ⁠Risk & Mitigation: Predict what could go wrong and plan recovery.
• ⁠Deliverables: Reports, defect logs, test cases, and summaries.

⚙️ Step 3: Defining Non-Functional Requirements

Beyond functional checks, I focused on how well the system performs.
My NFRs covered:

• Performance: 500ms API response time target.
• ⁠Security: Encryption, secure sessions, and rate-limiting.
• ⁠Usability: Mobile responsiveness and accessibility (WCAG 2.1).
• ⁠Reliability: 99.9% uptime with automated backups.

This part deepened my appreciation for the invisible side of QA, quality you can’t see, but always feel.

💡 Key Takeaways

• QA is proactive, not reactive. It starts before a single test is run.
• ⁠Clarity + Collaboration = Quality. A well-documented plan saves time and prevents chaos.
• ⁠Metrics matter. Non-functional requirements define user satisfaction in numbers.

Click here to see my Test Plan and Non-Functional Requirements (NFR) Document