Practice interview answers, not question lists.
Choose a QA track, recall your answer, reveal the coaching notes, and score your confidence before moving on.
Bank size
2161
matching questions
Track
All categories
Any difficulty
Drill length
10
questions per session
Progress
Session only
Checking sign-in
Browse question bank
Showing 2161 questions
What is Quality Assurance, and how is it different from simply finding defects?
QA is the process of building quality into the way software is delivered. It includes prevention, standards, reviews, risk management, and continuous improvement, while defect finding is only one testing activity inside the wider quality effort.
Can you explain the difference between Quality Assurance, Quality Control, and Testing?
QA is process focused and preventive, QC is product focused and detects issues in the delivered product, and testing is a QC activity that executes checks to reveal defects and provide quality information.
You join a project where testing only happens at the end of development. What QA improvements would you suggest?
I would move QA earlier by reviewing requirements, defining acceptance criteria, preparing test scenarios during development, adding smoke and regression checks, and feeding risks into planning instead of waiting for a finished build.
How would you explain the value of QA to a developer who believes testing is only the tester's responsibility?
I would explain that QA is a shared responsibility because defects are cheaper to prevent than fix late. Testers provide risk analysis, user perspective, evidence, and feedback loops that help developers and product teams deliver better software.
Can you explain the main phases of the Software Development Life Cycle?
The SDLC usually includes planning, requirement analysis, design, development, testing, deployment, and maintenance, with feedback loops depending on the delivery model.
What are the main phases of the Software Testing Life Cycle?
The STLC usually includes requirement analysis, test planning, test design, test environment setup, test execution, defect reporting, retesting, regression testing, and test closure.
What is the difference between SDLC and STLC, and how do they depend on each other?
SDLC covers the whole software delivery lifecycle, while STLC covers testing activities within it. STLC depends on SDLC outputs such as requirements, designs, builds, environments, and release plans.
If requirements are still changing during the test execution phase, how would that affect the STLC?
Changing requirements during execution can invalidate test cases, create new risks, require impact analysis, change regression scope, and affect schedule, coverage, and exit criteria.
How would you improve the testing process in a team where STLC activities are not clearly followed?
I would map the current gaps, introduce lightweight STLC checkpoints, define ownership for requirements, planning, execution, defect triage, and closure, then measure improvements through leakage, blocked tests, and release readiness.
Can you explain the seven principles of software testing?
The seven principles are: testing shows defects, exhaustive testing is impossible, early testing saves cost, defects cluster, repeated tests lose effectiveness, testing is context dependent, and absence of defects does not prove product usefulness.
How would you apply the principle "exhaustive testing is impossible" when testing a large e-commerce checkout flow?
I would identify the highest-risk checkout paths, use equivalence classes, boundaries, payment methods, promotions, and customer types, then prioritise critical combinations instead of trying every possible permutation.
A manager asks you to test every possible combination before release. How would you respond?
I would explain the cost and time impact, propose a risk-based and combinatorial approach, identify the highest-value coverage, and make the residual risk visible to stakeholders.
How do you manage stakeholder expectations when testing cannot provide 100% defect-free assurance?
I set expectations by explaining what testing can and cannot prove, sharing coverage and known risks, using metrics with context, and helping stakeholders make informed decisions rather than promising zero defects.
What is the difference between verification and validation?
Verification checks whether work products meet specified requirements, while validation checks whether the delivered software solves the user's real need. Verification asks whether we built it right; validation asks whether we built the right thing.
Give an example of verification and validation activities in a real web application project.
Verification can include reviewing user stories, designs, and acceptance criteria. Validation can include executing system tests, UAT, exploratory testing, and checking real user workflows in the application.
How would you verify requirements before test case design starts?
I would review requirements for clarity, testability, completeness, conflicts, dependencies, acceptance criteria, data rules, edge cases, and non-functional expectations before designing test cases.
A feature matches the requirement document but does not solve the user's actual problem. Is this a verification issue or a validation issue?
It is mainly a validation issue because the product may match the document but fail the real user need. It may also reveal a requirement analysis gap that should be corrected.
What do testers check during requirement analysis?
Testers check whether requirements are clear, complete, consistent, testable, prioritised, traceable, and aligned with user workflows and business rules.
How do you identify missing, unclear, or conflicting requirements?
I compare requirements with user journeys, acceptance criteria, designs, APIs, data rules, and edge cases, then raise precise questions with examples of the ambiguity or conflict.
You receive a requirement that says "the system should be fast." How would you handle this as a tester?
I would ask for measurable performance criteria such as response time, load, device, browser, data volume, and percentile targets, then document assumptions until the requirement is clarified.
A business analyst refuses to clarify an ambiguous requirement before development starts. What would you do?
I would document the ambiguity, explain the delivery and defect risk, propose testable wording, escalate through the product owner or project lead if needed, and track the decision.
Tell me about a time when your requirement analysis prevented a major defect later in the project.
A strong example should describe the unclear requirement, the question or evidence raised, the clarification obtained, and the defect or rework avoided later.
What is a test plan, and what key information should it contain?
A test plan defines scope, objectives, approach, resources, environments, schedule, risks, entry and exit criteria, deliverables, responsibilities, and defect management process.
How would you prepare a test plan for a new login and registration module?
I would define scope for login, registration, validation, security, email flows, data, browsers, roles, negative cases, regression impact, environments, entry criteria, and exit criteria.
If the release timeline is reduced by 40%, how would you adjust your test plan?
I would revisit scope using risk, prioritise critical flows, reduce low-value tests, increase targeted regression, clarify what is not tested, and communicate residual risk before sign-off.
How would you create a test plan for a project with multiple teams, multiple environments, and frequent releases?
I would create a plan with shared scope, dependencies, environment calendar, release cadence, ownership, risk matrix, reporting rhythm, defect triage process, and clear entry and exit criteria.
What is a test strategy, and how is it different from a test plan?
A test strategy is the high-level testing approach across a product or organisation, while a test plan applies that approach to a specific release, project, or feature.
How would you define a test strategy for a product that includes web, mobile, API, and database layers?
I would define layered coverage across UI, API, mobile, database, integrations, non-functional risks, environments, automation candidates, manual exploration, and release gates.
What factors would you consider when deciding the overall testing approach for a high-risk financial application?
I would consider regulatory risk, payment and data integrity, security, auditability, test environments, traceability, automation depth, exploratory testing, defect triage, and sign-off evidence.
How do you convince leadership to invest in a better long-term test strategy instead of relying only on last-minute manual testing?
I would use defect leakage, release delays, rework cost, regression effort, and production impact to show why a sustainable strategy reduces risk and cost over time.