Junior QA / Software Tester

Sample Answer

Verification asks "are we building the product right?" It checks that the product conforms to its specified requirements at each stage of development — reviewing design documents, code reviews, walkthroughs, and inspections without running the software. Validation asks "are we building the right product?" It confirms that the final product meets the actual needs of the end user — typically through testing the working software against user requirements and acceptance criteria. In practice: verification catches specification and design errors early (cheaper to fix), while validation confirms the final product delivers business value. Both are part of a complete QA strategy.

Sample Answer

I would start by identifying the equivalence partitions: valid credentials, invalid username, invalid password, empty username, empty password, and both fields empty. For each I would write a test case with steps to reproduce, expected result, and actual result. Beyond functional cases, I would consider boundary conditions — what happens if the username is 1 character, exactly the maximum length, or one over the maximum? I would also test non-functional behaviour: does the password field mask input? Is there a lockout after multiple failed attempts? Is there an accessible error message that does not reveal whether the username or password was incorrect (a security consideration)? Finally I would test the "remember me" checkbox if present. A complete test suite for a login form could easily be 20 to 30 cases covering positive, negative, boundary, and security scenarios.

Sample Answer

Severity describes the impact of a defect on the system's functionality — how badly it breaks the software. A high-severity defect crashes the application or causes data loss. A low-severity defect might be a minor cosmetic issue like a misaligned button. Priority describes how urgently the defect needs to be fixed, based on business needs. These two dimensions are independent. A typo on the homepage of a major SA bank may be low severity (the app still works) but high priority (it is publicly visible and affects brand reputation and legal standing). Conversely, a critical crash in a rarely-used admin feature may be high severity but lower priority than a checkout bug affecting every user. QA analysts must assign both fields independently in a bug report.

Sample Answer

Black-box testing treats the system under test as an opaque box — the tester has no knowledge of the internal code or architecture. Tests are designed based on the requirements and expected behaviour only. This is the type of testing that most manual QA testers perform and most closely mirrors how an end user interacts with the product. White-box testing (also called glass-box or structural testing) requires knowledge of the internal code structure. Tests are designed to achieve code coverage — testing specific code paths, conditions, and branches. This is typically performed by developers or by QA engineers with programming skills. Most SA QA teams use a combination: manual QA testers perform black-box functional testing, while automation engineers and developers write white-box unit and integration tests.

Sample Answer

In a Scrum team, QA is not a phase that happens at the end — it runs throughout the sprint. During sprint planning, the QA analyst reviews user stories with the team and contributes to acceptance criteria, making sure stories are testable before development starts. During the sprint, QA tests stories as soon as they are marked ready for testing — not waiting until the end. This prevents a backlog of defects accumulating in the last two days of the sprint. QA also attends daily standups to flag blockers, participates in sprint reviews to demonstrate tested functionality, and contributes to sprint retrospectives with quality insights. In modern Agile teams, QA also writes automated test scripts that run as part of the CI/CD pipeline to catch regressions on every build.

Sample Answer

During my final year project, I was testing a student portal application my group had built. During exploratory testing, I noticed that if I created a new account, navigated back using the browser's back button, and submitted the form again with slightly different data, the system would create a duplicate account with no error message. The registration page was not invalidating the session properly after a successful submission. I wrote a full bug report with steps to reproduce, identified the root cause in the session handling code, and we fixed it before submission. The reason I am proud of it is that it was not in my pre-written test cases — it came from treating the system the way a curious or confused user would, which is what good exploratory testing requires.