Frequently asked Testing Interview Questions

What is software testing, and why is it performed?

Software testing is the process of evaluating a software product to find defects and determine whether it satisfies specified requirements and user needs. Testing provides information about product quality and release risk. It can reveal failures, incorrect behavior, security weaknesses, performance problems, and gaps between the implemented product and its requirements. Testing reduces risk, but it cannot prove that a non-trivial application contains no defects.

What is the difference between quality assurance and quality control?

Quality assurance (QA) is process-oriented. It aims to prevent defects by improving development and testing practices, standards, reviews, and workflows. Quality control (QC) is product-oriented. It evaluates the developed product through activities such as inspection and testing to identify defects. Testing is generally treated as one part of quality control, while QA covers the wider process used to build quality into the product.

What is the difference between verification and validation?

Verification evaluates work products such as requirements, designs, and code to determine whether they meet specified conditions. It is often summarized as, “Are we building the product right?” Reviews and static analysis are verification activities. Validation evaluates the working product to determine whether it meets its intended use and stakeholder needs. It asks, “Are we building the right product?” Executing tests against a deployed build is a validation activity.

What are the main levels of software testing?

• Unit or component testing: Checks individual functions, classes, or components in isolation.
• Integration testing: Checks interfaces and interactions between components, services, databases, or external systems.
• System testing: Evaluates the complete integrated system against functional and non-functional requirements.
• Acceptance testing: Determines whether the product satisfies agreed acceptance criteria and business needs. User acceptance testing is one form of acceptance testing.

What are functional and non-functional testing?

Functional testing checks what the system does, such as authentication, calculations, search, order placement, and data validation. Non-functional testing checks how well the system operates. It includes performance, usability, accessibility, reliability, compatibility, recoverability, and security testing. A feature can be functionally correct but still fail a non-functional requirement, such as an acceptable response-time target.

What is the difference between black-box, white-box, and grey-box testing?

• Black-box testing: Designs tests from requirements and externally visible behavior without relying on knowledge of the internal implementation.
• White-box testing: Designs tests using knowledge of internal code, logic, branches, conditions, or data flow.
• Grey-box testing: Uses partial implementation knowledge, such as database structure or API design, while testing through externally visible interfaces.

What is a test case, and what fields should it contain?

A test case defines the conditions and actions used to verify a specific behavior. Its fields commonly include a test case ID, objective, related requirement, preconditions, test data, execution steps, expected result, actual result, environment, status, and evidence. A useful test case is clear enough for another tester to execute and trace back to a requirement or risk.

What is the difference between a test scenario and a test case?

A test scenario is a high-level statement describing what needs to be tested, such as “Verify that a registered customer can complete checkout.” A test case provides the detailed preconditions, data, steps, and expected results for one path through that scenario. One scenario can therefore lead to several test cases covering successful, alternative, boundary, and error paths.

What does a software test plan include?

A test plan describes how testing will be managed for a project or release. It normally identifies:

• Testing objectives and scope
• Features included and excluded
• Test levels, test types, and techniques
• Roles, responsibilities, environments, data, and tools
• Schedule, estimates, dependencies, and deliverables
• Entry criteria, exit criteria, suspension criteria, and resumption criteria
• Product risks, project risks, assumptions, and mitigation actions
• Reporting, defect management, and approval process

How is a test strategy different from a test plan?

A test strategy defines the broad testing principles and approach, such as risk-based testing, supported test levels, automation goals, environments, and reporting standards. A test plan applies that approach to a particular project or release by defining its scope, people, schedule, risks, and deliverables. Terminology varies among organizations, so an interview answer should explain how the documents are used in the candidate’s workplace rather than rely only on document names.

What is requirements traceability in software testing?

Requirements traceability links requirements to related test conditions, test cases, and defects. A requirements traceability matrix can show whether every in-scope requirement has tests and whether each test has a valid reason to exist. Traceability helps identify missing coverage and assess the effect of a requirement change. It does not, by itself, prove that the tests are effective.

What is test coverage, and how should it be measured?

Test coverage measures how much of a defined test basis has been exercised. Depending on the objective, teams may measure requirement coverage, risk coverage, feature coverage, configuration coverage, or structural code coverage such as statement and branch coverage. The calculation is generally the number of covered items divided by the total number of applicable items, multiplied by 100. A high percentage is useful only when the selected coverage model and the tests themselves are meaningful.

What is equivalence partitioning?

Equivalence partitioning divides input or output values into groups that are expected to be processed in the same way. A tester selects representative values from each valid and invalid partition instead of checking every possible value. For an age field accepting values from 18 through 60, the partitions could be values below 18, values from 18 to 60, and values above 60.

What is boundary value analysis?

Boundary value analysis tests values at and around the edges of ordered partitions because boundary errors are common. If a field accepts values from 18 through 60, useful values for basic two-value boundary analysis include 17, 18, 60, and 61. A team may also test additional nearby values, such as 19 and 59, depending on its chosen coverage approach and risk.

When should a tester use a decision table?

A decision table is useful when an outcome depends on combinations of conditions or business rules. The table lists conditions, possible values, and the actions expected for each relevant rule. For example, an insurance premium may depend on customer type, age group, and claim history. Decision tables make missing or contradictory combinations easier to see.

What is state transition testing?

State transition testing verifies how a system changes from one state to another after an event. It is suitable when behavior depends on the current state or event history. An account that becomes locked after a defined number of failed login attempts is a common example. Tests should cover valid transitions, invalid transitions, significant event sequences, and state-dependent outputs.

What is the difference between retesting and regression testing?

Retesting executes tests that previously failed to confirm that a specific defect has been fixed. Regression testing checks whether a change has unintentionally affected previously working behavior. After a defect fix, a tester may first retest the original failure and then run a risk-based regression suite around the changed and dependent areas.

What is the difference between smoke testing and sanity testing?

Smoke testing is a broad, shallow check of critical functions used to decide whether a build is stable enough for more detailed testing. Sanity testing is commonly used for a focused check of a changed feature or related area after a small update. These terms are used differently by different teams, so candidates should state their team’s definition and give an example.

What is exploratory testing?

Exploratory testing combines learning, test design, and execution. The tester investigates the product using a goal or charter, observes its behavior, and adapts the next test based on what is learned. It is not necessarily undocumented or random. Testers can record charters, coverage notes, data, defects, questions, and session results so that the work can be reviewed.

How does exploratory testing differ from ad-hoc testing?

Exploratory testing is a deliberate approach guided by a mission, risks, observations, and continuous test design. It may use time-boxed sessions and documented findings. Ad-hoc testing is generally less structured and may be performed without a defined objective or record. Both can find unexpected defects, but structured exploratory testing is easier to explain, review, and repeat.

What should a useful defect report contain?

A useful defect report contains a concise title, environment and build details, preconditions, reproducible steps, test data, expected result, actual result, frequency, severity, and supporting evidence such as screenshots, logs, videos, or request and response details. It should contain enough information to reproduce and investigate the problem without adding assumptions about the cause.

What is the difference between defect severity and priority?

Severity describes the impact of a defect on the system or user. Priority describes how urgently the defect should be addressed from a delivery or business perspective. Data corruption may be both severe and urgent. A spelling error on a heavily visited launch page may have low functional severity but high priority. The exact classifications and decision owners depend on the organization.

What stages are included in a defect life cycle?

A typical defect may move through New, Triaged, Assigned, In Progress, Fixed, Ready for Retest, Closed, and Reopened states. Other possible resolutions include Duplicate, Deferred, Rejected, Cannot Reproduce, and Works as Designed. The workflow is not universal; the important point is that every state has a clear meaning, owner, and transition rule.

How do you perform root cause analysis for a recurring defect?

First, collect evidence and reproduce the failure consistently where possible. Identify when the defect was introduced, which components and conditions are involved, and why existing controls did not detect it earlier. Techniques such as the Five Whys, cause-and-effect diagrams, log analysis, and change-history review can help. Corrective actions should address the underlying technical or process cause and include a way to verify that the problem does not recur.

What is the tester’s role in an Agile team?

An Agile tester contributes throughout product development rather than waiting for a completed build. Typical work includes refining acceptance criteria, identifying risks, reviewing stories, preparing test data, testing during the iteration, supporting automation, investigating defects, and communicating quality information. Quality remains a shared team responsibility even when one team member specializes in testing.

What is shift-left testing?

Shift-left testing means performing suitable quality activities earlier in development. Examples include reviewing requirements before coding, defining examples with business representatives, running static analysis, adding unit and API tests, and testing small changes continuously. Its purpose is to provide earlier feedback. It does not remove the need for system, acceptance, exploratory, performance, or production-focused testing.

Which test cases should be automated?

Good automation candidates include repeatable regression tests, checks run across many data sets or configurations, stable critical paths, API tests, and tests required in continuous integration. Poor candidates can include rapidly changing features, one-time checks, subjective usability assessments, and investigations that require human observation. The decision should consider risk, execution frequency, maintenance cost, reliability, and the value of faster feedback.

Can automated testing replace manual testing?

No. Automation is effective for repeatable checks and rapid feedback, but it does not replace human investigation, product learning, usability evaluation, or judgment about unexpected behavior. A practical test approach combines automated checks at appropriate layers with targeted manual and exploratory testing.

What is the difference between load, stress, and spike testing?

• Load testing: Evaluates behavior under expected or specified workload levels.
• Stress testing: Pushes the system beyond expected limits to observe its breaking point, error handling, and recovery.
• Spike testing: Evaluates behavior when workload rises or falls sharply over a short period.

Useful performance results include response times, throughput, error rates, resource utilization, and recovery behavior measured against stated objectives.

What does software security testing examine?

Security testing examines whether the system protects data and functions against relevant threats. Depending on scope and authorization, it may include authentication and authorization checks, session management, input handling, encryption configuration, dependency scanning, vulnerability assessment, and penetration testing. Security testing should be based on identified risks and must be conducted only with appropriate permission.

How would you test a login page?

Begin by clarifying the supported login methods, password rules, lockout policy, session behavior, and recovery requirements. Then cover:

• Valid and invalid username-password combinations
• Empty, malformed, boundary-length, and whitespace inputs
• Password masking, show-password behavior, and keyboard navigation
• Lockout, throttling, password recovery, and generic error messages
• Remember-me behavior, logout, session expiry, and back-button behavior
• Supported browsers, devices, accessibility, performance, and authorized security checks

A strong interview response explains the risks and expected behavior instead of presenting an unprioritized list of inputs.

How would you test an e-commerce checkout flow?

Trace the complete journey from the cart through order confirmation. Test item quantities, stock changes, pricing, taxes, discounts, shipping methods, addresses, payment outcomes, order creation, notifications, and inventory updates. Include duplicate submission, browser refresh, network interruption, payment timeout, declined payment, callback retry, and concurrent stock changes. Confirm that the customer is not charged twice and that order, payment, and inventory states remain consistent.

What would you do if requirements were incomplete or ambiguous?

Identify the unclear points and discuss them with the product owner, analyst, developer, or relevant stakeholder. Use examples, decision tables, prototypes, or acceptance criteria to make expected behavior concrete. Record assumptions and unresolved risks rather than silently inventing behavior. Testing can begin on understood areas while questions that affect correctness or release decisions remain visible.

How would you test when there is not enough time to run every test?

Use a risk-based approach. Prioritize critical user journeys, recently changed code, integrations, security-sensitive functions, historically defect-prone areas, high-usage features, and tests related to severe business consequences. Run a smoke check first, then targeted regression and exploratory testing. Communicate what was tested, what was not tested, known failures, residual risks, and the basis for the prioritization.

What would you do if a developer said that a reported defect could not be reproduced?

Recheck the steps and compare the build, environment, configuration, account permissions, test data, browser or device, timing, and feature flags. Add logs, screenshots, video, timestamps, request details, or database evidence where appropriate. Try to reduce the failure to the smallest reproducible sequence and reproduce it together with the developer. If it remains intermittent, document the observed frequency and conditions instead of closing it without evidence.

How do you prioritize test cases for a release?

Prioritize tests using product risk, business impact, change scope, usage frequency, technical complexity, dependencies, regulatory obligations, and defect history. Start with build acceptance and critical end-to-end flows, then cover changed components and their integrations. The prioritization should be revisited as new information appears, such as failed tests, late code changes, or unstable environments.

How do you decide whether testing is complete?

Testing is assessed against agreed exit criteria rather than an assumption that every possible test has been executed. Relevant evidence can include coverage of critical requirements and risks, execution results, unresolved defect severity, regression status, performance results, and accepted residual risks. The tester supplies quality and risk information, while the authorized stakeholders make the release decision.

Which software testing metrics are useful?

Useful metrics depend on the decision being made. Examples include risk or requirement coverage, pass and fail trends, defect discovery and resolution trends, escaped defects, automation stability, execution duration, environment availability, and time from defect discovery to resolution. Metrics need context; raw test-case counts or defect counts can be misleading and should not be used to rank individual testers.

How should an experienced tester describe a challenging project?

Use a specific example and explain the situation, assigned responsibility, actions, evidence, and outcome. Describe the product risk, constraints, stakeholders, testing choices, and trade-offs. State personal contributions accurately and explain what changed as a result, such as earlier defect detection, clearer acceptance criteria, shorter feedback time, or a better-informed release decision. Avoid claiming sole credit for team outcomes.

Which testing interview questions should freshers prepare first?

Freshers should first understand testing levels, testing types, verification and validation, test cases, defect reporting, severity and priority, regression testing, equivalence partitioning, boundary value analysis, and the software testing life cycle. They should also practise designing tests for familiar features such as login, search, registration, and checkout.

How should I answer scenario-based software testing questions?

Start by asking about requirements, users, platforms, integrations, and risks. Divide the problem into functional paths, negative cases, boundaries, data, interfaces, and relevant non-functional concerns. Prioritize the most serious risks and explain the expected result and evidence. Interviewers are usually evaluating the reasoning process as well as the final list of tests.

Do manual testing interviews include automation questions?

They can. A manual testing role may still require knowledge of API testing, databases, continuous integration, test automation concepts, and selecting suitable automation candidates. Candidates should distinguish between understanding automation strategy and claiming hands-on experience with a particular tool or language.

What should an experienced QA candidate prepare before an interview?

Prepare concise examples involving risk assessment, test planning, difficult defects, production incidents, incomplete requirements, release decisions, automation trade-offs, and collaboration with developers and product stakeholders. Be ready to explain the context, personal contribution, evidence used, result, and lesson learned for each example.