Build a complete QA pack for a real or sample app
The capstone project for QA Testing & Software Testing — a free Data & Tech course. Pass it and you earn a certificate anyone can verify.
- Free
- 6 steps
- Pass mark 65%
- Graded within minutes
- Beginner-friendly
The project unlocks once you complete the lessons. The workbook is free to download now so you can see exactly what is expected.
What you will submit
A single public link (Google Doc, GitHub repo, or Notion page) containing your full QA pack: (1) a short test plan with scope, testing types and environment; (2) at least 10 structured test cases in a table with IDs, preconditions, steps, data, specific expected results and Pass/Fail status, covering positive, negative and boundary cases; (3) at least 3 well-written bug reports with title, reproduction steps, expected vs actual, severity with justification, priority, environment and evidence; and (4) a one-paragraph intro plus a short earning note. Tool screenshots (Jira/TestRail) are a welcome bonus but not required.
What to do, step by step
- Choose one real, well-known app or website you can access — ideally a Nigerian one everyone recognises (a bank/fintech app, a food-delivery service, an e-commerce store, or a government/utility portal) — and pick ONE clear feature to focus on (e.g. login, sign-up, money transfer, add-to-cart and checkout, or search). Name the app and the feature in one or two sentences.
- Write a short TEST PLAN (about half a page) covering: what you are testing and why, what is IN scope and OUT of scope, which testing types you will use (e.g. functional, smoke, regression, plus negative/boundary), and the test environment (device, OS, app version or browser, and network).
- Write at least TEN well-structured TEST CASES for your chosen feature in a clean table, each with a Test Case ID, Title, Preconditions, numbered Steps, Test Data, and a specific, observable Expected Result. Cover positive cases, negative cases, and at least two boundary/edge cases (use equivalence partitioning and boundary value analysis from Lesson 3). Execute them and record Actual Result and Status (Pass/Fail) for each.
- Find and write at least THREE strong BUG REPORTS (real bugs you find, or realistic ones if the app is genuinely flawless — but try hard to find real ones). Each report must include: a clear Title using the [what + where + condition] formula, numbered Steps to Reproduce from a known starting point, Expected Result, Actual Result, a Severity rating (Critical/High/Medium/Low) with a one-line justification, a suggested Priority, the Environment, and Evidence (a screenshot or screen-recording link, or pasted exact error text).
- Show the bug lifecycle awareness from Lesson 5: for each bug, state what its status would be (e.g. New) and what would have to happen for you to move it to Closed. Optionally, log at least one of your bugs in a free Jira practice project and one test case in TestRail (or a Google Sheet mimicking it) and include a screenshot to prove tool familiarity.
- Assemble everything into ONE clean, shareable document or repo (Google Doc, public GitHub repo, or Notion page) with a one-paragraph intro naming the app, the feature, and a short note on how you would use this pack to apply for QA roles (where you would apply and rough pay in ₦ and/or $). Make sure the link is publicly viewable, then submit it.
Files to work with
Project workbook (fill in, then submit)The whole brief, an evidence checklist, the grading rubric as a self-check and the link-sharing steps in one file. Opens in Word, Google Docs or WPS.Word · 7 KBHow it is graded
| Criterion | Weight |
|---|---|
| Test plan — clearly names the app and feature, states in/out scope, the testing types used, and a realistic environment (device/OS/version/network) | 15% |
| Test cases — at least 10 well-structured cases with IDs, preconditions, numbered steps, test data and specific, observable expected results; meaningfully covers positive, negative AND boundary/edge cases | 30% |
| Bug reports — at least 3 reproducible reports with strong titles, numbered steps from a known start, expected vs actual, evidence and correct environment | 30% |
| Severity, priority & lifecycle — bugs carry sensible severity (with justification) and suggested priority, and show awareness of the bug lifecycle / status | 15% |
| Clarity, presentation & earning note — one clean shareable document, well organised and easy to follow, with an intro and a realistic note on how to earn from the skill | 10% |
You need 65% overall to pass. A failed submission comes back with feedback and can be revised and resubmitted.
Before you submit: make your link public
If your work lives in Google Drive or Google Docs, open Share → General access and change “Restricted” to “Anyone with the link” (Viewer). Then paste the link into a private browser window: if it opens without sign-in, you are ready. A private link cannot be graded — it is the single most common reason a good project fails.
Frequently asked questions
Do I have to finish QA Testing & Software Testing before submitting the project?
Yes. The submission screen opens once every lesson in QA Testing & Software Testing is marked complete. The lessons are where the methods, the Nigerian context and the worked examples the project depends on are taught.
How is the project graded?
An examiner scores each rubric criterion from 0 to 100 and weights them as shown on this page; you need 65% overall to pass. Most submissions are graded within minutes and you get written feedback on what was strong and what to improve.
Can I resubmit if I fail?
Yes. A failed project comes back with feedback; revise the weak parts and resubmit. A passed project is final — the certificate is issued and cannot be re-rolled.
What do I actually submit?
A write-up of what you did (under 5,000 characters) plus a public link to your work — a Google Drive folder, Google Doc, spreadsheet, GitHub repository or video. The link must open without sign-in; a private link cannot be graded. The free project workbook on this page walks you through all 6 steps.
Is the certificate real?
Yes. Passing this project issues a certificate with a unique verification code. Anyone — an employer, a client, a school — can open the verification page and see that the certificate is genuine and which project earned it.
More Data & Tech projects
- Sales Dashboard for a Local Business
Data Analysis Foundations
- My Skillnaija Frontend Portfolio
Frontend Web Development
- My First Python Program: 'Kudi Tracker'
Coding Foundations
- Your Junior Technician Field Pack
Data Centre Technician: Racks, Power, Cooling, Cabling and Remote Hands
Ready to earn this certificate?
QA Testing & Software Testing is free and self-paced. Finish the lessons, complete this project, and the certificate is yours to share.
Start learning free