Updated: 13 October 2026. A testing interview often includes questions such as “What would you test on a login page?” or “How do you report a bug?” A strong fresher can do better than memorising definitions: build a small, ethical manual software-testing portfolio project using a fictional job-application website. This guide provides requirements, positive and negative test cases, a bug-report example, a test summary and a two-week learning plan.
What you will create
Imagine an entirely fictional site called DemoApply. It has a sign-in form and an application form. There is no real employer, no real applicant data and no actual hiring. You can implement a simple local mock website or test against your own offline prototype. Never run intrusive security tests against a real recruitment portal without permission.
| Feature | Expected behaviour |
|---|---|
| Login | Valid demo credentials open the applicant dashboard; invalid entries show a safe error |
| Required fields | Name, email, job role and consent are required to submit an application |
| Email format | Malformed email addresses must trigger validation |
| Duplicate submissions | Accidental repeated clicks should not create unexpected duplicate records |
| Application status | A submitted demo record receives a unique reference and confirmation |
| Mobile experience | Forms remain usable on narrow screens and with keyboard navigation |
This document is a starting requirements specification. Real testers clarify ambiguous acceptance criteria with a product owner; they do not silently assume behaviour just because they have seen a similar website.
SDLC, STLC and a beginner testing workflow
The software development lifecycle (SDLC) covers the overall product path—from requirements and design through coding, testing, release and maintenance. The software testing lifecycle (STLC) focuses on analysing requirements, planning tests, designing test cases, setting up a test environment, executing tests, reporting defects and closing the testing work.
In an interview, explain what you personally tested and which risk the test was meant to uncover. Manual testing is not random clicking. Good testing involves hypotheses, evidence and reproducible results.
Build a test-case sheet with meaningful columns
Create a spreadsheet with Test ID, Requirement, Preconditions, Steps, Input, Expected result, Actual result, Status, Evidence, Defect ID. Record the software version and browser used, because an issue seen in one version may not reproduce in another.
| Case | Test input / action | Expected result |
|---|---|---|
| TC-01 | Log in with valid demo credentials | Dashboard appears and session is established |
| TC-02 | Submit invalid password | Safe rejection without revealing whether an account exists |
| TC-03 | Leave email field empty | Required-field message; no application created |
| TC-04 | Enter name-at-example as email | Format validation message |
| TC-05 | Enter leading/trailing spaces in a name | Documented normalization or validation applied consistently |
| TC-06 | Fill every required field with valid fictional values | One application is created and confirmation shown |
| TC-07 | Double-click Submit quickly | No unintended duplicate application |
| TC-08 | Refresh confirmation page | No additional application is created by refresh |
| TC-09 | Use the form on a small mobile viewport | Labels, fields and error messages remain visible and usable |
| TC-10 | Navigate using only keyboard | Logical focus order and usable controls |
| TC-11 | Upload a disallowed file type in mock form | File rejected with understandable message |
| TC-12 | End session and revisit private dashboard | Reauthentication is required where the spec calls for it |
Do not declare a test “Pass” without comparing the observed result to the expected one. If requirements are ambiguous, mark the test for clarification and document the question.
Positive, negative and boundary testing
Positive tests verify a valid expected workflow, such as successfully submitting the demo form. Negative tests check invalid input or forbidden conditions, such as a malformed email or missing mandatory consent. Boundary tests focus on edges: if a name can contain 2–80 characters, try lengths 1, 2, 80 and 81. First make sure the 2–80 rule actually exists in the documented requirement; do not invent production policies.
Equivalence partitioning helps reduce redundant input combinations. For example, you might group emails into syntactically valid and invalid classes, then choose representative examples. It does not prove that every valid-looking address belongs to a real person.
Example of a useful bug report
Imagine the local prototype saves two records when the user double-clicks the submit button. A clear report could look like this:
| Bug ID | BUG-007 |
|---|---|
| Title | Double-clicking Submit creates two demo applications |
| Environment | DemoApply v0.2, local Chrome test environment |
| Precondition | Signed-in fictional applicant; valid form completed |
| Steps | Open form → enter valid details → double-click Submit quickly → check dashboard |
| Expected | Exactly one record and one confirmation reference |
| Actual | Two records with different references |
| Evidence | Mock screenshot, local console log, timestamps and relevant record IDs |
| Suggested severity | Major (illustrative classification; align with team policy) |
| Suggested priority | High if duplicate submissions are frequent or costly |
The “Actual” observation and screenshots in this sample are fictional. Do not claim you discovered this defect in a real employer’s website. When you do test your own prototype, attach genuine evidence and confirm that the steps reproduce.
Severity versus priority: a simple distinction
Severity describes impact on the system or user. Priority describes how urgently a team should fix the defect in its current business context. A cosmetic typo might be low severity but high priority just before an important launch. A severe issue in an inaccessible experimental feature might be assigned a different release priority. Teams use their own classification scales, so explain your reasoning instead of claiming a universal rating.
Smoke testing, regression testing and retesting
Smoke testing asks whether a build’s most important flows work well enough for further testing. Retesting checks whether a reported defect is fixed in a new version. Regression testing checks whether new changes have broken previously working behaviour. For DemoApply, a fix to double-click handling may require retesting that case and regression testing ordinary single-click submission, refreshing the page and confirmation handling.
What belongs in a test summary report?
Suppose your fictional project defines 12 test cases. In a sample report you could write: 12 planned; 10 executed; 7 passed; 2 failed; 1 blocked; 2 not yet run. The numbers should add up and the blocked case should explain its dependency. List known unresolved defects and the remaining risks. A “ready for release” statement requires stakeholder criteria; a beginner should not claim readiness solely because most tests pass.
Build a mini QA portfolio repository
Use a public repository with invented data and a simple structure:
demoapply-qa/
README.md
requirements/
acceptance-criteria.md
test-cases/
manual-cases.csv
defects/
BUG-007.md
reports/
test-summary.md
evidence/
demo-screenshots/Write the README to explain the fictional product, scope, environment, assumptions, how another person can run your tests and what is out of scope. Avoid copying real candidate documents, recruiter email addresses, authentication cookies or screenshots that expose personal information.
A realistic 14-day manual testing roadmap
| Days | Work to complete |
|---|---|
| 1–2 | Read requirements and write acceptance questions |
| 3–4 | Identify positive, negative and boundary scenarios |
| 5–6 | Create 12–20 clear test cases in a spreadsheet |
| 7–8 | Run tests on your own mock prototype and capture results |
| 9–10 | File actual reproducible defects, fix or retest as appropriate |
| 11 | Run a small smoke and regression checklist |
| 12 | Prepare a factual test summary report |
| 13 | Organise evidence and remove sensitive information |
| 14 | Publish README and practise explaining your test decisions |
The plan is a suggestion, not a recruitment syllabus. Completing the first basic test design correctly is more important than rushing to claim expertise in automation tools.
Manual testing interview questions with answer guidance
- What is a test case? Explain input, preconditions, steps and expected result with your login-page example.
- What is the difference between smoke and regression tests? Use a small release change to illustrate.
- What would you do with an unclear requirement? Ask the product owner, record assumptions and avoid inventing expected outcomes.
- How would you test a login form? Cover valid, invalid, empty, expired-session, keyboard and usability paths within authorised scope.
- Why is a bug report useful? Reproducible steps help developers find and fix the issue efficiently.
- Does manual testing require coding? Not always; SQL and scripting can improve your versatility, while test design and communication remain important.
How to show your testing project on a fresher resume
A truthful example bullet, only if you did this work: “Designed and executed 18 manual test cases for a fictional job-application prototype; documented reproducible defects, regression checks and a test summary report in GitHub.” Never invent a defect count or claim to have tested an employer’s production website without permission.
Useful next steps and references
Practise data checks using our SQL interview workbook and review GitHub portfolio presentation. For accessibility checks, the W3C WAI forms tutorial gives useful guidance on form labels and instructions. For software testing terminology, consult the ISTQB glossary.
Frequently asked questions
Can I present a personal QA portfolio without an internship?
Yes, if you make clear that it is an independent learning project and the results are genuine. Do not represent the project as paid industry work.
Should I learn Selenium immediately?
First practise test design, defect reporting and application behaviour. Add automation after you can write clear, repeatable cases worth automating.
Can I test any live job application form for my portfolio?
No. Use a local prototype, an authorised test environment or a site expressly intended for practice. Avoid creating fake applications on real employers’ systems.
Editorial disclosure: DemoApply, all test inputs and BUG-007 are original fictional examples developed for Hiring365, not employer interview materials. Featured illustrative photograph: Zan Lazarevic / Unsplash.
