Manual Testing Interview Questions for Freshers (36 Questions with Answers)

These manual testing interview questions for freshers cover what interviewers ask candidates with 0–6 months of experience: testing fundamentals, SDLC and STLC, testing types, test design techniques, test cases and the defect life cycle. The first answers in each section are detailed, with examples you can adapt; the shorter ones are quick answers to revise the night before. Every answer ends with what the interviewer is really listening for.

Software Testing Fundamentals

1. What is software testing and why is it important?

Software testing is the process of evaluating and verifying that a software application or system works as expected. It involves executing the software with specific inputs, observing its behavior, and comparing the actual results against expected results to identify defects.

Why testing is important

• Quality Assurance: Testing ensures the product meets specified requirements and works correctly in all expected scenarios.
• Cost Reduction: Defects found early (during development or testing) cost far less to fix than defects found in production. A widely quoted rule of thumb is that a bug found in production can cost up to 100 times more to fix than one found during coding.
• Security: Testing helps uncover security vulnerabilities before malicious users can exploit them.
• User Satisfaction: A well-tested product improves user experience, reduces complaints, and builds trust.
• Regulatory Compliance: Industries like banking, healthcare, and aviation require testing to comply with regulations.
• Business Reputation: A product failure in production can cause financial loss, legal issues, and brand damage.
• Risk Mitigation: Testing identifies risks before they become failures that impact real users.

Real-world example: In 2012, Knight Capital Group lost $440 million in 45 minutes due to a software bug that wasn't properly tested during deployment. This is a classic case showing why testing is critical.

2. What is the difference between Error, Defect, Bug, and Failure?

These terms are often used interchangeably but have precise technical meanings in software testing:

Error (Mistake)

• Definition: A human mistake made by a developer, analyst, or any team member.
• Cause: Misunderstanding of requirements, logic mistake, typo in code, incorrect assumption.
• Example: A developer misunderstands that age validation should be 18–60 and writes code for 18–65.
• Also called: Human error, mistake.

Defect (Bug/Fault)

• Definition: The result of the error — a flaw in the code, design, or document that causes incorrect behavior.
• It exists in the software even before execution.
• Example: The code says "if age <= 65" instead of "if age <= 60" — this is the defect in the code.
• Also called: Bug, fault.

Failure

• Definition: When the defect is executed and the software behaves unexpectedly or produces wrong output.
• It is observable by users or testers during execution.
• Example: A user aged 63 successfully registers when they should be rejected — this is the failure.

Chain of events

Developer misunderstands requirement (ERROR) → Wrong code is written (DEFECT) → System allows user aged 63 to register (FAILURE)

Important note: Not every defect causes a failure. A defect in a code path that is never executed will remain dormant and may never cause a failure during testing. This is why code coverage matters.

3. What is the difference between Verification and Validation?

Verification and Validation are two fundamental concepts in software quality assurance that are often confused. Barry Boehm summarized them perfectly:

• Verification: "Are we building the product RIGHT?"
• Validation: "Are we building the RIGHT product?"

Verification

• Checks whether the software conforms to its specifications and requirements.
• Performed WITHOUT executing the software (static testing).
• Activities: Reviews, walkthroughs, inspections, desk checking.
• Focus: Process-oriented — does the product match what was designed/documented?
• Performed by: QA team, internal reviewers.
• Example: Reviewing a test plan to ensure it covers all requirements. Reviewing code against design documents.

Validation

• Checks whether the software meets the actual needs and expectations of the end user.
• Performed BY executing the software (dynamic testing).
• Activities: Unit testing, integration testing, system testing, UAT.
• Focus: Product-oriented — does the product do what the user actually needs?
• Performed by: QA team, and ultimately end users (UAT).
• Example: Running the application and testing that users can complete a purchase successfully.

Practical example

• Scenario: A banking app requirement says "transfer limit is $10,000/day."
• Verification: Reviewing the code and checking it has the $10,000 limit programmed correctly.
• Validation: Actually executing a $10,001 transfer and confirming it gets blocked.

Why both matter: You can verify a product (it matches specs) but still fail validation (the specs were wrong to begin with). Both are needed for a quality product.

4. Explain the difference between QA, QC, and Testing.

QA, QC, and Testing are distinct but related concepts in software quality management. Understanding the differences is fundamental for any testing professional.

Quality assurance (QA)

• Definition: A proactive, process-oriented approach focused on PREVENTING defects by improving and defining the development and testing processes.
• Goal: Ensure that the right processes are followed, which will lead to high-quality products.
• Activities: Process definition, process audits, creating standards and guidelines, training, process improvements, introducing best practices.
• Focus: People and processes — how work is done.
• Example: Creating a standardized code review process that prevents common bugs from being introduced. Implementing a test case review step before execution.
• Responsibility: Entire development team (not just testers).

Quality control (QC)

• Definition: A reactive, product-oriented approach focused on IDENTIFYING defects in the finished product.
• Goal: Verify that the product meets quality standards before release.
• Activities: Testing, inspections, product reviews, code reviews.
• Focus: The product itself — is it correct?
• Example: Running a full regression test suite and comparing outputs against expected results.
• Responsibility: Primarily the QA/testing team.

Testing

• Definition: A subset of QC — the execution of software to find defects.
• It is a specific technique within QC.
• Testing involves: writing test cases, executing them, reporting results, and logging defects.
• Not all QC involves testing (e.g., design inspections are QC but not testing).

Relationship: Testing ⊂ QC ⊂ QA

• QA is the umbrella — it encompasses all quality activities.
• QC is within QA — focuses on product quality.
• Testing is within QC — the hands-on activity of executing software.

Analogy: Think of baking a cake.

• QA = Creating the recipe and baking process standards.
• QC = Inspecting the finished cake for taste, appearance, and texture.
• Testing = Actually tasting a slice to find any issues.

5. What are the 7 principles of software testing?

The 7 principles of software testing (from ISTQB) are fundamental guidelines that every tester should understand and apply:

Principle 1: Testing shows presence of defects, not their absence.

• Testing can prove a system has bugs; it cannot prove it has NO bugs.
• Even after extensive testing, there may be undiscovered defects.
• Implication: Never claim a system is "bug-free" — say "no defects were found in the tested scenarios."

Principle 2: Exhaustive testing is impossible.

• Testing all possible input combinations, scenarios, and preconditions is not feasible for any real system.
• A simple login form with a 10-character password field has trillions of possible inputs.
• Solution: Use risk-based testing, equivalence partitioning, and BVA to test smartly and prioritize.

Principle 3: Early testing saves time and money.

• Defects found in requirements phase cost ~10x less to fix than those found in production.
• Testing activities should start as early as possible — review requirements, participate in design discussions.
• This is the basis of Shift-Left Testing.

Principle 4: Defect clustering.

• A small number of modules (typically 20%) contain the majority (80%) of defects. (Pareto Principle / 80-20 rule)
• Modules that are complex, recently changed, or have had previous bugs are likely to have more bugs.
• Implication: Prioritize testing effort on high-risk modules.

Principle 5: Pesticide paradox.

• If you keep running the same tests repeatedly, they stop finding new bugs — just like pesticides become ineffective on insects over time.
• Solution: Regularly review and update test cases, add new tests, use exploratory testing to uncover new areas.

Principle 6: Testing is context-dependent.

• There is no one-size-fits-all testing approach. Testing an e-commerce site is very different from testing a medical device.
• A safety-critical system (aircraft navigation) requires much more rigorous testing than a blog website.
• Always tailor your testing approach to the project context, risk, and domain.

Principle 7: Absence-of-errors fallacy.

• Finding and fixing bugs does not guarantee the system is good or useful.
• If the system is built based on wrong requirements, it can be defect-free yet completely useless.
• Example: A perfectly coded app that solves the wrong problem is still a failure.
• Validation (user acceptance) must confirm the system meets real user needs.

6. What is Black Box, White Box, and Grey Box testing?

These are the three fundamental testing approaches based on the tester's knowledge of the system's internals:

Black box testing

• Definition: The tester has NO knowledge of the internal code, architecture, or implementation. Testing is purely based on inputs and expected outputs.
• Also called: Behavioral testing, functional testing, specification-based testing.
• Focus: What the system does, not how it does it.
• Tester's perspective: End-user perspective.
• Techniques used: Equivalence Partitioning, BVA, Decision Tables, Use Case Testing, State Transition.
• Who performs it: QA testers, business analysts, end-users (UAT).
• Advantages: Unbiased (tester not influenced by implementation), reflects real user perspective, no programming knowledge required.
• Disadvantages: Cannot test all code paths, may miss logic-level bugs.
• Example: Testing a login form by entering valid/invalid credentials and verifying behavior — without looking at the authentication code.

White box testing

• Definition: The tester has FULL knowledge of the internal code, architecture, logic, and implementation.
• Also called: Clear box, glass box, structural testing, code-based testing.
• Focus: How the system works internally — code coverage, paths, branches, loops.
• Tester's perspective: Developer/technical perspective.
• Techniques used: Statement coverage, Branch coverage, Path coverage, Condition coverage.
• Who performs it: Developers (unit testing), technical QA engineers.
• Advantages: Thorough code coverage, can find hidden code paths, detects security vulnerabilities in code.
• Disadvantages: Requires programming knowledge, very time-consuming, may miss requirements-level bugs.
• Example: A developer writes unit tests ensuring every if-else branch in the authentication function is executed.

Grey box testing

• Definition: The tester has PARTIAL knowledge — knows some internals (database structure, APIs, architecture) but not all code details.
• Combines elements of both black box and white box.
• Focus: Integration between components, end-to-end flows with some technical insight.
• Who performs it: Experienced QA testers with technical skills.
• Advantages: More targeted than pure black box, less effort than full white box.
• Example: An API tester who knows the database schema validates both the API response AND the database state after a call, without knowing the exact code implementation.

Comparison table

• Knowledge of internals: Black Box = None, Grey Box = Partial, White Box = Full
• Primary focus: Black Box = Functionality, Grey Box = Integration, White Box = Code coverage
• Skill required: Black Box = Domain, Grey Box = Domain + Technical, White Box = Programming
• Test design basis: Black Box = Requirements, Grey Box = Requirements + Architecture, White Box = Source code

7. Can testing guarantee that software has zero bugs?

No. Testing can only prove the presence of defects, never their absence. This is Principle 1 of software testing. Passing every test case only proves those specific scenarios work — there will always be untested combinations, edge cases, or environments that were never covered. Testing reduces risk, it does not eliminate it.

8. What is the Pesticide Paradox? How do you overcome it?

The Pesticide Paradox (Principle 5) states that if the same set of test cases is run repeatedly, they eventually stop finding new bugs — just like a pesticide that stops killing insects that build immunity to it.

To overcome it: regularly review and update existing test cases, add new test cases to cover untested areas, and use exploratory testing to go beyond scripted scenarios.

9. Explain defect clustering with a real example.

Defect Clustering (Principle 4) states that 80% of bugs tend to be found in 20% of the modules. This is based on the Pareto principle.

Example: On a sales-management project, the complex data processing module may have 70% of all bugs while the simple read-only report screens have almost none. A good tester identifies high-risk modules early and focuses effort there.

10. What is the difference between Manual Testing and Automation Testing?

Manual Testing is done by a human tester without tools. It is best for exploratory testing, UI/UX validation, and ad-hoc testing. No coding required. Cost-effective for small or short-term projects.

Automation Testing uses scripts and tools. Best for repetitive, regression, and performance testing. Requires coding. Cost-effective for large, long-term projects.

Key point: Automation does not replace manual testing. Both are needed. Manual testing catches what automation misses — usability, look-and-feel, and unexpected behaviour.

Testing Types

11. What is the difference between Smoke Testing and Sanity Testing?

Smoke Testing and Sanity Testing are both types of lightweight testing done to quickly assess a build or fix — but they serve different purposes and are performed at different times.

Smoke testing

• Definition: A quick, broad set of tests to verify that the most critical functionalities of a new build work enough to proceed with further testing.
• Purpose: Determines if the build is STABLE enough for testing. If critical features are broken, there's no point in full testing — the build is rejected.
• When performed: After receiving a NEW BUILD from development, before the full test cycle begins.
• Scope: Broad but SHALLOW — covers critical features at a high level, not deep testing.
• Also called: Build Verification Test (BVT), Confidence Test.
• Who performs it: QA team.
• Duration: Short — usually 30 minutes to 2 hours.
• Example: New build received. Smoke tests check: Can the application launch? Can a user log in? Can basic navigation happen? If any of these fail, the build is returned to development.
• Origin: "Turn on the hardware — if smoke comes out, something is wrong." Applied metaphorically to software.

Sanity testing

• Definition: A focused, narrow test to verify that a specific bug fix or change is working correctly, without running the full test suite.
• Purpose: Confirms that a SPECIFIC FIX or change works as expected before proceeding to regression testing.
• When performed: After receiving a build with a SPECIFIC BUG FIX or minor change.
• Scope: Narrow but DEEP — focuses only on the fixed area and directly related functionality.
• Also called: Narrow regression test.
• Who performs it: QA team.
• Duration: Short — typically 1–4 hours depending on complexity.
• Example: Developer fixes a bug where the "Forgot Password" email wasn't being sent. Sanity test: Verify password reset email is now sent correctly, verify the link in the email works, verify invalid email shows proper error.

Key differences at a glance

• Trigger: Smoke = new build received; Sanity = specific fix received.
• Scope: Smoke = broad, all critical features; Sanity = narrow, specific feature.
• Depth: Smoke = shallow; Sanity = deep in the fixed area.
• Documentation: Smoke = usually scripted; Sanity = may be unscripted/exploratory.
• Failure outcome: Smoke = entire build rejected; Sanity = specific fix rejected.

Analogy

• Smoke test = Pre-flight check (does everything basic work before takeoff?).
• Sanity test = Post-repair check (is this specific thing that was fixed actually working now?).

12. What is the difference between Retesting and Regression Testing?

Retesting and Regression Testing are both performed after bug fixes, but they serve very different purposes and are often confused by beginners.

Retesting

• Definition: Re-executing the same test cases that previously FAILED after a defect has been fixed, to confirm the fix is working correctly.
• Purpose: Confirms that a SPECIFIC defect has been resolved.
• Scope: Very narrow — only the failed test cases are re-executed.
• Based on: Defect reports — the exact steps that exposed the bug.
• Type: Always planned (you know exactly what to retest — the failed test case).
• Timing: Performed first after a fix — before regression testing.
• Example: Bug #456: "Login with valid credentials redirects to error page." Developer fixes it. Retesting: Run that exact login test case with valid credentials and confirm it now redirects to the dashboard.

Regression testing

• Definition: Executing a broader set of tests to ensure that recent code changes (fixes, new features, enhancements) have NOT broken any previously working functionality.
• Purpose: Prevents unintentional side effects from code changes.
• Scope: Broad — covers the impacted areas AND all other features that could be affected.
• Based on: A maintained regression test suite (collection of important test cases).
• Type: Both planned and partially exploratory.
• Timing: Performed after retesting confirms the fix works.
• Example: Same bug #456 fix. Regression testing: Run all authentication-related tests (login, logout, registration, forgot password), plus any features that use authentication (shopping cart, profile page, checkout) to confirm nothing else broke.

Why both are needed

• A developer fixing bug #456 might change the authentication module.
• Retesting confirms: Login works now. ✓
• Regression testing discovers: The logout button is now broken because of the same code change. ✗

Relationship

Defect Fixed → RETEST (confirm fix) → REGRESSION TEST (confirm nothing else broke)

Types of regression testing

• Full Regression: Run the entire test suite (time-consuming but thorough).
• Partial/Selective Regression: Run only tests related to impacted areas (faster, risk-based).
• Progressive Regression: Run tests for new features + impacted areas.
• Re-test All: Run all test cases (used for major releases).

13. What is Exploratory Testing?

Exploratory Testing is a sophisticated testing approach where the tester simultaneously learns about the system, designs tests, and executes them — all at the same time. It was defined and popularized by Cem Kaner.

Formal definition (Cem Kaner): "A style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of their work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project."

Key characteristics

• Simultaneous learning, design, and execution — no pre-scripted test cases required.
• Tester uses their knowledge, creativity, and intuition to guide testing.
• Time-boxed sessions with a specific charter/mission.
• Results are documented during and after the session.
• Very effective at finding unexpected defects that scripted tests miss.

WHEN IS EXPLORATORY TESTING MOST VALUABLE?

• When requirements are unclear or incomplete.
• When testing time is short and flexibility is needed.
• When a new product/feature needs quick initial exploration.
• When scripted tests have been exhausted and you need to find new bugs.
• For usability issues and workflow gaps.
• When you want to understand the application better.

Exploratory testing process

1. Define a charter (mission): "Explore the checkout flow to find issues with coupon application."

2. Set a time box: Usually 45–90 minutes.

3. Explore freely using the charter as a guide.

4. Take notes of what you tested, what you found.

5. Log defects as you find them.

6. Debrief after the session.

Techniques used within exploratory testing

• Boundary probing: Test extremes and boundaries.
• Error seeding: Try to cause errors deliberately.
• Domain expertise: Apply business knowledge to test realistic scenarios.
• History-based: Focus on areas with past defect history.
• Tour-based testing: Different "tours" — feature tour, complexity tour, risk tour, etc.

Exploratory vs scripted testing

• Scripted: Pre-defined test cases, predictable coverage, good for regression.
• Exploratory: Dynamic, unscripted, good for finding new bugs, understanding the app.
• Best practice: Use both — scripted for critical paths, exploratory for new areas and gaps.

Charter example

"Explore the user profile settings page with different account types (free, premium, admin) to discover any permission or data display issues."

14. Explain all major types of testing with examples.

Software testing is classified into many types based on purpose, knowledge, and approach. Here is a comprehensive breakdown:

Based on execution (static vs dynamic)

Static Testing (No execution)

• Reviews, walkthroughs, inspections, static analysis.
• Example: Reviewing a test plan document for completeness.

Dynamic Testing (With execution)

• All forms of testing where the software is actually run.
• Example: Executing login test cases.

Based on knowledge (black/white/grey box)

Already covered in detail in Topic 1.

Functional testing types

Unit Testing

• Tests individual components/functions in isolation.
• Performed by developers.
• Example: Testing the "calculateTax()" function alone.

Integration Testing

• Tests how multiple modules work together.
• Example: Testing that the payment module correctly communicates with the inventory module.

System Testing

• Tests the complete, integrated system against requirements.
• Example: Testing the entire e-commerce website end-to-end.

User Acceptance Testing (UAT)

• End-users validate the system meets business needs.
• Example: Business users testing a new HR system before go-live.

Regression Testing

• Re-testing to ensure new changes haven't broken existing features.
• Example: After adding a new payment method, re-run all checkout tests.

Smoke Testing

• Quick broad test of a new build's basic functionality.
• Example: Can the app start? Can users log in?

Sanity Testing

• Quick focused test after a specific fix.
• Example: Verify password reset email now works after the fix.

Exploratory Testing

• Unscripted investigation of the application.
• Example: Freely exploring a new checkout flow to find unexpected issues.

Non-functional testing types

Performance Testing

• Tests speed, responsiveness, stability under load.
• Sub-types: Load, Stress, Spike, Soak testing.
• Example: Verify the website handles 10,000 concurrent users.

Security Testing

• Tests for vulnerabilities and security weaknesses.
• Example: Testing for SQL injection, XSS, unauthorized access.

Usability Testing

• Tests ease of use from user's perspective.
• Example: Observing real users completing tasks to identify UX issues.

Compatibility Testing

• Tests across different browsers, OS, devices.
• Example: Verifying the app works on Chrome, Firefox, Safari, and Edge.

Accessibility Testing

• Tests for users with disabilities (screen readers, keyboard navigation).
• Example: Verifying all images have alt text for screen readers.

Localization/Internationalization Testing

• Tests for different languages, cultures, and regions.
• Example: Verifying date format changes to DD/MM/YYYY for UK users.

Other important types

Alpha Testing: Internal pre-release testing by employees.

Beta Testing: Real users test in their environment before release.

Ad-hoc Testing: Random, unplanned testing without documentation.

Monkey Testing: Completely random inputs to crash the system.

Mutation Testing: Intentionally introduce bugs to verify tests catch them.

A/B Testing: Compare two versions to see which performs better with users.

15. What is UAT (User Acceptance Testing) and what is your role as a QA tester?

User Acceptance Testing (UAT) is the final phase of the software testing process, where actual business users validate that the system meets their requirements and is fit for use in their work environment. It is the last checkpoint before production release.

Purpose of UAT

• Validate that the software meets business requirements, not just technical specifications.
• Ensure the system works correctly in a real-world business context.
• Give stakeholders confidence to sign off on the release.
• Identify any business-critical gaps before they impact real users.

Who performs UAT

• Primary: Actual end-users or business representatives (not QA).
• Also involved: Business Analysts, Product Owners, key stakeholders.
• QA role: Supporting role — not the primary tester but a facilitator.

Types of UAT

• Alpha Testing: UAT performed by internal employees (different team).
• Beta Testing: UAT performed by selected external/real users.
• Contract Acceptance Testing: Verifies the system meets contractually specified criteria.
• Regulation Acceptance Testing: Verifies compliance with government/regulatory standards.
• Operational Acceptance Testing: Verifies operational readiness (backup, recovery, maintenance procedures).

UAT process

1. UAT Planning: Define what business flows will be tested, select users, prepare environment and data.

2. UAT Test Cases: Written in business language (not technical) — often based on real business scenarios.

3. UAT Execution: Business users follow test scripts and record results.

4. Defect Reporting: Issues logged — some may be defects, some may be new requirements.

5. UAT Sign-off: Business stakeholders sign off, approving the release.

QA tester's role during UAT

• Prepare UAT environment and test data.
• Create UAT test cases/scripts in business language.
• Train business users on the UAT process.
• Provide support during execution (answer questions, resolve environment issues).
• Log and track defects raised during UAT.
• Communicate UAT progress and metrics.
• NOT: Execute the tests yourself (that defeats the purpose of UAT).

Common UAT issues

• Users raise issues that are "nice to have" changes, not actual defects — these need scope management.
• Environment issues preventing testing — require rapid resolution.
• Users don't have time — requires strong stakeholder management.
• Late discovery of major gaps — requires escalation and re-planning.

SDLC and STLC

16. What is SDLC and explain the different models?

SDLC (Software Development Life Cycle) is a structured process used by the software industry to plan, design, develop, test, and deliver software. It provides a systematic framework that ensures quality and correctness.

Phases of SDLC (General)

1. Requirement Gathering/Analysis: Understanding what needs to be built.

2. System Design: Defining architecture, database, interfaces.

3. Implementation/Coding: Actual development.

4. Testing: Verification and validation of the software.

5. Deployment: Releasing to production.

6. Maintenance: Bug fixes, enhancements post-release.

SDLC models

1. WATERFALL MODEL:

• Linear, sequential approach — each phase must complete before the next begins.
• Phases: Requirements → Design → Development → Testing → Deployment → Maintenance.
• Advantages: Simple, well-documented, easy to manage for small projects.
• Disadvantages: Very inflexible — changes are costly. Testing only at the end means late defect discovery.
• Best for: Small projects with well-defined, stable requirements.

2. V-MODEL (Verification and Validation Model):

• Each development phase has a corresponding testing phase.
• Left side (development): Requirements → System Design → Architecture → Module Design → Coding.
• Right side (testing): Acceptance Testing → System Testing → Integration Testing → Unit Testing.
• Testing activities start EARLY — test plans are created at each development phase.
• Advantages: Early test planning, clear mapping of test levels to development.
• Disadvantages: Still sequential, not flexible to changes.
• Best for: Safety-critical applications where early defect detection is critical.

3. AGILE MODEL:

• Iterative and incremental development in short cycles called Sprints (1–4 weeks).
• Requirements can evolve; collaboration over documentation.
• Testing happens continuously within each sprint.
• Frameworks: Scrum, Kanban, XP (Extreme Programming).
• Advantages: Highly flexible, fast delivery, continuous feedback, early value delivery.
• Disadvantages: Requires active stakeholder involvement, can be chaotic without discipline.
• Best for: Projects with frequently changing requirements, long-running products.

4. SPIRAL MODEL:

• Combines iterative development with systematic risk management.
• Each spiral has four phases: Planning, Risk Analysis, Development, Evaluation.
• Advantages: Excellent risk management, suitable for large complex systems.
• Disadvantages: Expensive, complex to manage.
• Best for: Large, high-risk projects (aerospace, defense).

5. RAD MODEL (Rapid Application Development):

• Focuses on rapid prototyping and quick feedback cycles.
• Uses components and reusable modules.
• Heavy user involvement throughout.
• Advantages: Fast delivery, user involvement reduces rework.
• Disadvantages: Requires skilled developers, not suitable for all projects.

17. What is STLC (Software Testing Life Cycle) and what are its phases?

STLC (Software Testing Life Cycle) defines the specific sequence of activities performed by the testing team during the software testing process. It is a subset of SDLC focused entirely on testing activities.

The 6 phases of STLC

Phase 1: REQUIREMENT ANALYSIS

• What happens: Testing team analyzes the requirements (BRS, FRS, User Stories) to understand what must be tested.
• Activities: Identify testable/non-testable requirements, understand business flows, identify test environment needs, identify automation feasibility, clarify ambiguities with stakeholders.
• Entry Criteria: Requirements documents available and baselined.
• Exit Criteria: RTM (Requirement Traceability Matrix) created, test environment needs identified.
• Deliverables: RTM, Automation feasibility report.

Phase 2: TEST PLANNING

• What happens: Create the overall testing strategy, plan resources, timeline, scope, and tools.
• Activities: Define scope (what to test/not test), select testing types, estimate effort, create schedule, allocate resources, identify risks, select tools and environments.
• Entry Criteria: Requirements analysis complete.
• Exit Criteria: Test Plan document signed off by stakeholders.
• Deliverables: Test Plan document.

Phase 3: TEST CASE DEVELOPMENT

• What happens: Create detailed test cases, test scripts, and test data.
• Activities: Write test cases for each requirement, create test data, review test cases with peers and stakeholders, update RTM with test case mappings.
• Entry Criteria: Test plan approved.
• Exit Criteria: Test cases reviewed and approved, test data ready.
• Deliverables: Test cases, test scripts, test data.

Phase 4: TEST ENVIRONMENT SETUP

• What happens: Prepare the hardware, software, and network configuration needed for testing.
• Activities: Install application, configure environment, set up databases, create test accounts, verify environment is working (smoke test the environment).
• Entry Criteria: Test plan ready, test cases ready.
• Exit Criteria: Environment ready, smoke test passed.
• Deliverables: Environment ready sign-off, smoke test results.

Phase 5: TEST EXECUTION

• What happens: Execute the test cases and log results. Report defects for failed tests.
• Activities: Execute test cases in test management tool, mark pass/fail, log defects in bug tracker for failures, retest fixed defects, perform regression testing.
• Entry Criteria: Test environment ready, test cases approved, build received.
• Exit Criteria: All test cases executed (or planned subset), defects logged and tracked to closure.
• Deliverables: Test execution report, defect report.

Phase 6: TEST CYCLE CLOSURE

• What happens: Evaluate completion criteria, prepare final reports, capture lessons learned.
• Activities: Check exit criteria, prepare test summary/closure report, calculate metrics (pass rate, defect density, DRE), document lessons learned, archive test artifacts.
• Entry Criteria: Testing is complete, exit criteria met or deviation approved.
• Exit Criteria: Test closure report signed off.
• Deliverables: Test closure/summary report, metrics report.

ENTRY AND EXIT CRITERIA — WHY THEY MATTER:

Entry criteria prevent teams from starting a phase before prerequisites are ready (e.g., testing without a stable build wastes time). Exit criteria ensure a phase is truly complete before moving forward (e.g., not releasing with open critical defects).

18. What is the difference between Waterfall and Agile testing?

Waterfall and Agile represent two fundamentally different philosophies for software development and testing. Understanding both is essential for modern testers.

Testing in waterfall

Characteristics

• Testing happens as a SEPARATE PHASE at the end of development.
• Requirements are completely finalized before development or testing begins.
• Testers receive requirements, write test cases, then wait for the complete build.
• Complete system is tested at once.
• Changes to requirements are very costly and discouraged.

Testing Process

• Test Plan created from finalized requirements.
• Test cases written, then executed on the complete build.
• Defects fixed, retested, then released.

Advantages for Testing

• Clear requirements = clear test cases.
• Sufficient time dedicated to testing (it's a defined phase).
• Easy to measure test completion.

Disadvantages for Testing

• Defects found late = expensive to fix.
• If requirements were wrong, extensive rework needed.
• Testers are idle during development, then overloaded at end.
• No feedback loop — users see product only at the end.

Testing in agile

Characteristics

• Testing is CONTINUOUS — happens within every sprint alongside development.
• Requirements evolve throughout the project.
• Testers collaborate closely with developers and business analysts daily.
• Small increments are tested and delivered every 1–4 weeks.
• Changes are welcomed, even late in development.

Testing Process

• Sprint Planning: Tester reviews user stories, defines acceptance criteria.
• During Sprint: Developer codes → Tester tests → Defects fixed → Retested (all in the same sprint).
• Sprint End: Working, tested software is delivered.
• Regression run regularly (often automated).

Advantages for Testing

• Defects found immediately — same sprint as development.
• Continuous feedback to developers.
• Early delivery of working software.
• Testers are never idle — always involved.

Disadvantages for Testing

• Short sprints = pressure to test quickly.
• Requirements may change mid-sprint.
• Regression testing becomes a significant challenge without automation.
• Documentation can be sparse.

Key differences summary

• When testing starts: Waterfall = after development; Agile = during development.
• Requirements: Waterfall = fixed; Agile = flexible.
• Feedback cycle: Waterfall = at end; Agile = every sprint.
• Defect discovery: Waterfall = late, expensive; Agile = early, cheap.
• Documentation: Waterfall = extensive; Agile = lightweight.
• Flexibility: Waterfall = rigid; Agile = highly adaptive.

19. What is the difference between SDLC and STLC?

SDLC covers the entire software development process — from requirement to deployment. It involves the whole team: business analysts, developers, testers, and project managers.

STLC is a subset of SDLC. It covers only the testing activities — from requirement analysis through test closure. It is owned by the QA team.

STLC runs within SDLC, not separately.

20. What is the V-Model? How is it different from Waterfall?

The V-Model is an extension of Waterfall where each development phase has a corresponding test planning phase. The left arm of the V is development, the right arm is testing.

Key difference: In Waterfall, testing is a separate phase that starts AFTER development ends. In V-Model, test planning starts in parallel with each development phase — so by the time coding is done, test cases are already ready.

21. What are Entry and Exit Criteria in testing?

Entry Criteria are the minimum conditions that must be met before the QA team begins testing. Examples: stable build deployed, test cases approved, test data ready, smoke test passed.

Exit Criteria are the conditions that must be met before testing is considered complete. Examples: all test cases executed, all critical defects closed, test coverage met, summary report approved.

Importance: Entry criteria prevent wasted effort on unstable builds. Exit criteria give a clear, objective definition of when testing is done.

Test Design Techniques

22. Explain Equivalence Partitioning and Boundary Value Analysis with detailed examples.

These two techniques are the most fundamental and frequently tested test design techniques. They work together to achieve maximum coverage with minimum test cases.

Equivalence partitioning (EP)

Concept: Divide the input domain into partitions (groups) where all values in a partition are expected to behave the same way. If one value from a partition causes a pass/fail, all values in that partition should do the same. Test only ONE representative value from each partition.

Why it's useful: Reduces the number of test cases dramatically while maintaining coverage. For an age field accepting 1–120, you don't need to test all 120 values — just one from each partition.

How to identify partitions

• Valid partition: Values the system should accept.
• Invalid partitions: Values the system should reject (can have multiple invalid partitions).
• For every boundary, there is at least one invalid partition on each side.

DETAILED EXAMPLE — Password Length (6–12 characters):

• Valid Partition: 6–12 characters. Test with: 9 characters (e.g., "myPass123").
• Invalid Partition 1: Less than 6 characters. Test with: 3 characters (e.g., "abc").
• Invalid Partition 2: More than 12 characters. Test with: 15 characters (e.g., "myLongPass12345").
• Result: Only 3 test cases needed instead of testing every possible length.

Equivalence partitioning for non-numeric fields

• Example: Country dropdown with "USA", "UK", "Canada" as valid options.
• Valid partition: Any of the listed countries.
• Invalid partition: A value not in the list (if the user can type — e.g., "France").

Boundary value analysis (BVA)

Concept: Extends EP by testing at and around the boundaries of each partition, because bugs most frequently occur at boundary values. For each boundary, test: just below the boundary, at the boundary, and just above the boundary.

Why at boundaries? Developers often make off-by-one errors (using < instead of <=, or + 1 where they meant to use the original value). These bugs are caught by BVA.

How to apply BVA

For a valid range [min, max]:

• Lower boundary: (min-1), min, (min+1)
• Upper boundary: (max-1), max, (max+1)

DETAILED EXAMPLE — Age Field (18–60 years):

Boundaries to test

• Lower boundary values: 17 (invalid — just below), 18 (valid — at boundary), 19 (valid — just above).
• Upper boundary values: 59 (valid — just below), 60 (valid — at boundary), 61 (invalid — just above).
• Total BVA test cases: 6 test cases that catch the most common boundary bugs.

Combining EP and BVA

These techniques complement each other

• EP identifies the partitions and one value from each.
• BVA then adds the boundary values for maximum coverage.
• Together: For age 18–60, you'd test: 17 (invalid EP+BVA), 18, 19 (BVA), one from middle e.g. 35 (EP), 59, 60 (BVA), 61 (invalid EP+BVA).

23. What is a Decision Table and when do you use it?

A Decision Table is a test design technique used when the system has multiple conditions that combine to produce different outcomes. It systematically captures all possible combinations of conditions and their corresponding actions.

When to use decision tables

• Complex business rules with multiple conditions.
• When multiple inputs interact to determine the output.
• When you want to ensure all combinations are tested.
• Example scenarios: Insurance premium calculation, loan approval rules, discount eligibility, tax calculation.

Structure of a decision table

The table has two parts

• Conditions (top section): The input variables that affect the output.
• Actions (bottom section): The results/outcomes based on the conditions.

Each column represents a RULE (a combination of conditions and corresponding action).

DETAILED EXAMPLE — Online Shopping Discount:

Business Rule: A discount applies if the customer is a Premium member AND the order total is over $100. Free shipping if order total > $50 OR customer is a Premium member.

Conditions

• C1: Is customer a Premium member? (Yes/No)
• C2: Is order total > $100? (Yes/No)
• C3: Is order total > $50? (Yes/No)

Actions

• A1: Apply 10% discount.
• A2: Apply free shipping.

Decision Table (4 columns = 4 rules for 2 binary conditions):

Test Cases Derived

• TC1: Premium member + $150 order → 10% discount + free shipping.
• TC2: Premium member + $75 order → No discount + free shipping (premium member gets free shipping).
• TC3: Non-premium + $120 order → No discount + free shipping (order > $50).
• TC4: Non-premium + $40 order → No discount + no free shipping.

Advantages

• Ensures all combinations are considered — no missing scenarios.
• Identifies impossible/redundant rules.
• Provides clear traceability from business rules to test cases.
• Makes complex rules visual and easy to communicate.

Limitations

• Number of rules grows exponentially with conditions: 2 conditions = 4 rules, 3 conditions = 8 rules, 4 conditions = 16 rules.
• For many conditions, can become unwieldy (use pairwise testing instead).

24. What is State Transition Testing?

State Transition Testing is used when the system behaves differently depending on its current state. You test valid transitions (allowed) and invalid transitions (should be rejected).

Example: An ATM has states — idle, card inserted, PIN entry, authenticated, card blocked. Test each valid path and also test what happens if you try to jump states illegally.

25. What are positive and negative test cases? Give an example.

Positive test case: Tests the system with valid, expected inputs to verify it works correctly. Example: Login with correct username and password — expects successful login.

Negative test case: Tests the system with invalid, unexpected, or out-of-range inputs to verify it handles errors gracefully. Example: Login with wrong password — expects an error message, NOT a crash.

Test Cases and Documentation

26. How do you write a high-quality Test Case? Walk through a complete example.

A well-written test case is clear, unambiguous, reproducible, and contains all the information needed for any tester to execute it without additional clarification. Poor test cases lead to inconsistent results and missed defects.

Components of a test case

1. TEST CASE ID: Unique identifier. Example: TC_LOGIN_001

2. TEST CASE TITLE: Concise, descriptive name. Example: "Verify successful login with valid email and password"

3. DESCRIPTION: Brief explanation of what is being tested.

4. MODULE/FEATURE: Which part of the application. Example: "Authentication / Login"

5. PRE-CONDITIONS: What must be true/set up before executing. Example: "User account exists with email test@email.com and password Test@123"

6. TEST DATA: Specific input values to use. Example: Email: test@email.com, Password: Test@123

7. TEST STEPS: Numbered, clear, action-oriented steps.

8. EXPECTED RESULT: What should happen if the system works correctly.

9. ACTUAL RESULT: What actually happened (filled during execution).

10. STATUS: Pass / Fail / Blocked / Not Executed.

11. PRIORITY: High / Medium / Low.

12. SEVERITY: Critical / Major / Minor.

13. CREATED BY / DATE / REVIEWED BY.

COMPLETE EXAMPLE — Login Functionality:

Test Case ID: TC_LOGIN_001

Title: Verify successful login with valid credentials

Module: Authentication - Login

Priority: High | Severity: Critical

Pre-conditions

• Application is accessible at https://app.example.com/login
• Test user account exists: email = testuser@example.com, password = ValidPass@123
• User is not currently logged in

Test Data

• Email: testuser@example.com
• Password: ValidPass@123

Test Steps

1. Open the application URL in a web browser.

2. Observe the login page is displayed with Email and Password fields.

3. Enter "testuser@example.com" in the Email field.

4. Enter "ValidPass@123" in the Password field.

5. Click the "Login" button.

6. Observe the page after login.

Expected Result

• User is redirected to the dashboard/home page.
• User's name "Test User" is displayed in the top-right corner.
• No error messages are displayed.
• URL changes to https://app.example.com/dashboard.

Actual Result: [Filled during execution]

Status: [Pass/Fail — filled during execution]

Qualities of a good test case

• Atomic: Tests one thing at a time.
• Clear Steps: Each step has a clear action AND observation.
• Specific Data: No vague "enter valid data" — specify exactly what data.
• Precise Expected Result: Not "page loads" — describe exactly what should be visible.
• Independent: Can be executed in any order without depending on other test cases.
• Maintainable: Easy to update when requirements change.

Common mistakes in test cases

• Vague expected results ("page should work correctly").
• Missing pre-conditions (leads to inconsistent execution).
• Steps that are too broad ("test login functionality").
• No test data specified.
• Steps that don't have corresponding observations.

27. What is RTM (Requirements Traceability Matrix) and how do you create one?

The Requirements Traceability Matrix (RTM) is a document that maps each requirement to its corresponding test cases, ensuring complete test coverage and providing impact analysis capability.

Purpose of RTM

• Ensures no requirement is left untested (forward traceability).
• Ensures every test case maps back to a requirement (backward traceability).
• Helps identify the impact of requirement changes on test cases.
• Used for coverage analysis — what percentage of requirements are tested.
• Provides audit trail for compliance and regulatory purposes.
• Helps in making a "Go/No-Go" decision — are all requirements verified?

Types of traceability

• Forward Traceability: Requirement → Test Case (ensures all requirements have test cases).
• Backward Traceability: Test Case → Requirement (ensures no test case is untraceable to a requirement — prevents "orphan" test cases).
• Bi-directional Traceability: Both directions — the most complete form.

Structure of an RTM

Column 1: Requirement ID (e.g., REQ_001)

Column 2: Requirement Description

Column 3: Test Case IDs (linked test cases, e.g., TC_001, TC_002, TC_003)

Column 4: Test Case Status (Pass/Fail/Blocked/Not Executed)

Column 5: Defect IDs (bugs related to this requirement)

Column 6: Requirement Status (Covered/Partially Covered/Not Covered)

Example RTM (Login Feature)

REQ_001 | System allows login with valid credentials | TC_001, TC_002 | Pass | - | Covered

REQ_002 | System rejects login with invalid password | TC_003, TC_004 | Pass | - | Covered

REQ_003 | Account locked after 5 failed attempts | TC_005, TC_006 | Fail | BUG_012 | Covered (Defective)

REQ_004 | Password reset email sent within 2 minutes | TC_007, TC_008 | Not Executed | - | Partially Covered

How to create an RTM (step by step)

1. List all requirements from BRS/FRS/User Stories with their IDs.

2. Review requirements and create test cases for each.

3. Map each test case to its requirement ID.

4. Verify every requirement has at least one test case.

5. Verify every test case maps to a requirement.

6. Update status columns as test execution progresses.

7. Add defect IDs when bugs are found.

Using RTM for impact analysis

When a requirement changes, the RTM immediately shows which test cases are affected. Example: REQ_003 changes from "lock after 5 attempts" to "lock after 3 attempts" — the RTM shows TC_005 and TC_006 need to be updated.

RTM metrics

• Requirements Coverage = (Requirements with test cases / Total requirements) × 100
• Test Execution Coverage = (Test cases executed / Total test cases) × 100

28. What is the difference between a Test Case and a Test Scenario?

Test Scenario: A high-level, one-line description of what needs to be tested. No steps. Example: Verify the login functionality.

Test Case: A detailed, step-by-step document with test data, preconditions, and expected results. Example: TC_001 — Verify that a registered user can login with valid credentials.

Relationship: One test scenario produces multiple test cases.

29. Write test cases for a Login page.

Positive cases: 1) Login with valid username and valid password — expect dashboard. 2) Login with email in uppercase — expect case-insensitive login to succeed.

Negative cases: 3) Login with valid username, wrong password — expect error message. 4) Login with empty username — expect validation error. 5) Login with empty password — expect validation error. 6) Login with both fields empty — expect validation error. 7) SQL injection in username field — expect no DB error.

Edge cases: 8) Login after 3 wrong attempts — expect account lockout. 9) Login with password containing special characters — expect success if valid. 10) Login with very long username string — expect graceful error.

Bugs and the Defect Life Cycle

30. How do you write a clear and effective defect/bug report?

A well-written defect report is crucial — it determines how quickly a developer can reproduce, understand, and fix the bug. A poor bug report wastes everyone's time and creates friction between QA and development teams.

Components of a high-quality bug report

1. BUG ID: Unique identifier (auto-generated by the tool). Example: BUG-2345.

2. BUG TITLE/SUMMARY:

• Should be: Specific, concise, action+result format.
• Bad: "Login not working."
• Better: "Login fails with valid credentials — user gets 'Invalid credentials' error on Chrome 120."
• Good titles help developers find duplicates and prioritize without opening every bug.

3. DESCRIPTION: More context if needed — what were you testing when you found this?

4. STEPS TO REPRODUCE:

• Numbered, clear, specific actions.
• Include exact data used.
• Should be reproducible by anyone following these steps.
• Example:

1. Navigate to https://app.example.com/login.

2. Enter email: testuser@example.com.

3. Enter password: ValidPass@123.

4. Click the "Login" button.

5. EXPECTED RESULT: What SHOULD happen based on requirements.

Example: User should be redirected to the dashboard.

6. ACTUAL RESULT: What ACTUALLY happened.

Example: Error message "Invalid credentials. Please try again." is displayed. User remains on login page.

7. SEVERITY (Technical impact):

• Critical/Blocker: System crash, data loss, security breach.
• High: Major feature broken, no workaround.
• Medium: Feature broken, workaround exists.
• Low: Minor UI issue, cosmetic defect.

8. PRIORITY (Business urgency):

• P1: Fix immediately, blocks business.
• P2: Fix in current sprint/release.
• P3: Fix in next release.
• P4: Nice to fix when time permits.

9. ENVIRONMENT:

• OS: Windows 11 / macOS 14.
• Browser: Chrome 120.0.6099.109 / Firefox 121.
• Application version/build: v2.3.1 Build #456.
• Test environment: QA / Staging / UAT.

10. TEST DATA: The exact data used that exposed the bug.

11. ATTACHMENTS:

• Screenshots showing the bug.
• Video recording of reproduction steps.
• Log files / console error output.
• Network request/response (from browser DevTools).

12. ADDITIONAL INFORMATION:

• Is it reproducible every time or intermittent?
• Which users/roles are affected?
• Does it happen on all browsers or specific ones?
• Workaround available? Yes/No.

Complete example bug report

Title: "Forgot Password" email not sent when email address contains uppercase letters

Steps to Reproduce

1. Navigate to the login page.

2. Click "Forgot Password."

3. Enter "TestUser@Example.COM" in the email field.

4. Click "Send Reset Link."

Expected Result: Password reset email sent to TestUser@Example.COM within 2 minutes.

Actual Result: No email received. Page shows "If this email exists, a reset link has been sent" but no email is delivered.

Severity: High | Priority: P2

Environment: Chrome 120, Windows 11, Build v2.3.1

Additional: Works correctly with all-lowercase email. Uppercase causes failure.

Attachments: Screenshot_001.png, console_log.txt

• One bug per report — don't combine multiple issues.
• Verify reproducibility before logging.
• Be objective — describe symptoms, not guesses about the cause.
• Include "Additional Info" — context helps developers prioritize.
• If you found a workaround, mention it — helps business decide priority.

31. Explain the complete Defect Life Cycle with all possible states.

The Defect Life Cycle (also called Bug Life Cycle) is the complete journey of a defect from the moment it is discovered to the moment it is closed. Understanding this cycle is fundamental for any tester.

Standard defect states and transitions

1. NEW:

• State when: Tester logs a new defect in the bug tracking tool.
• Who handles: QA tester creates the report.
• Transition: Goes to "Assigned" when a lead/manager reviews and assigns it.

2. ASSIGNED:

• State when: The bug has been reviewed, deemed valid, and assigned to a developer.
• Who handles: QA lead or project manager assigns.
• Transition: Developer opens it → status moves to "Open."

3. OPEN:

• State when: Developer acknowledges the bug and starts working on the fix.
• Who handles: Developer is actively investigating/fixing.
• Transition: Fix completed → "Fixed." Cannot reproduce → "Cannot Reproduce." Won't fix → "Deferred" or "Won't Fix."

4. FIXED:

• State when: Developer has made a code fix and believes the issue is resolved.
• Who handles: Developer changes status to Fixed.
• Transition: Goes back to QA for retesting → "Retest."

5. RETEST:

• State when: Bug is ready for QA to verify the fix.
• Who handles: QA tester re-executes the original failing test case.
• Transition: Fix works → "Closed." Fix doesn't work → "Reopened."

6. CLOSED:

• State when: QA confirms the fix works correctly. Defect is resolved.
• Final state for resolved defects.
• Who handles: QA tester closes after successful retest.

7. REOPENED:

• State when: Fix didn't resolve the issue OR the same bug recurred after a later code change.
• Who handles: QA tester reopens with updated comments.
• Transition: Goes back to "Assigned" → "Open" → developer fixes again.

Other important states

8. REJECTED:

• State when: Developer or lead determines it is NOT a real bug.
• Reasons: Working as designed, misunderstood requirement, test environment issue, invalid test data, duplicate.
• Who handles: Developer or lead rejects with reasoning.
• QA response: Review the rejection reason. If you disagree, escalate with requirement evidence.

9. DEFERRED:

• State when: Bug is valid but will NOT be fixed in the current release (intentionally postponed).
• Reasons: Low priority, timeline constraints, fix too risky near release date.
• Who decides: Project manager or product owner.
• Action: Document in release notes; retested in a future release.

10. DUPLICATE:

• State when: The same bug was already reported by another tester.
• Action: Original bug report is kept; duplicate is linked and closed.

11. CANNOT REPRODUCE:

• State when: Developer cannot reproduce the bug following the reported steps.
• Reasons: Environment-specific issue, missing steps in report, intermittent bug, test data issue.
• QA action: Provide more details, verify steps, check environment differences. If still not reproducible, may be closed or deferred.

12. WONT FIX:

• State when: Bug is valid but the team decides not to fix it.
• Reasons: Very low impact, fixing it is too risky, feature being deprecated.
• This is a business/prioritization decision, not a technical one.

The full lifecycle flow

New → Assigned → Open → Fixed → Retest → Closed (successful path)

Deviations: Open → Cannot Reproduce, Open → Deferred, Assigned → Rejected, Retest → Reopened → Assigned...

Severity vs priority deep dive

High Severity + High Priority: Login page crashes — fix immediately.

High Severity + Low Priority: Feature used by 0.1% of users crashes — valid but lower urgency.

Low Severity + High Priority: Company logo is misspelled on homepage — minor bug but embarrassing, fix fast.

Low Severity + Low Priority: Tooltip text slightly misaligned — fix eventually.

32. What is the difference between Severity and Priority?

Severity is the technical impact of the bug on the system — how badly it affects functionality. Set by the QA tester. Levels: Critical, High, Medium, Low.

Priority is the business urgency — how soon it must be fixed. Set by the Project Manager. Levels: High, Medium, Low.

Key example: A company logo is broken (Low severity — cosmetic) but must be fixed before tomorrow's board presentation (High priority). These two are independent of each other.

33. What is Bug Triage? Who is involved?

Bug triage is a structured meeting to review, prioritise, and assign open defects. The goal is to ensure the team is working on the most important bugs first.

Participants: QA Lead, Development Lead, Project Manager, and sometimes the Business Analyst.

Outcome of triage: each bug gets a priority decision — fix now, fix next sprint, defer to future release, or reject.

34. A developer marks your bug as 'Not a Bug'. What do you do?

First, I re-read the original requirement document to confirm whether the behaviour I reported was actually wrong or by design.

If the requirement supports my finding, I reopen the bug with a clear reference to the specific requirement section and explain why the current behaviour violates it.

If the requirement is unclear, I escalate to the Business Analyst or Product Owner for clarification before making a final call.

I never argue without evidence. The requirement document is the source of truth.

35. What is a Showstopper bug?

A Showstopper (also called a Blocker) is a critical severity bug that completely prevents testing from continuing. It blocks major functionality to the point where further test execution is not possible.

Example: The application fails to launch, or login is completely broken preventing access to all other features.

Action: Report immediately, escalate to QA Lead, and pause execution of dependent test cases until fixed. Document the blocked test cases in your daily status update.

Agile and Scrum Basics

36. What is Agile and what is the role of a QA tester in a Scrum team?

Agile is an iterative software development methodology that delivers working software incrementally, embraces change, and emphasizes collaboration between cross-functional teams and stakeholders.

THE AGILE MANIFESTO — 4 VALUES:

1. Individuals and interactions OVER processes and tools.

2. Working software OVER comprehensive documentation.

3. Customer collaboration OVER contract negotiation.

4. Responding to change OVER following a plan.

Note: The right-side items have value, but left-side items are valued MORE.

12 AGILE PRINCIPLES (Key ones for testers):

• Working software is the primary measure of progress.
• Welcome changing requirements, even late in development.
• Deliver working software frequently (weeks, not months).
• Business and developers must work together daily.
• Sustainable development pace.
• Continuous attention to technical excellence.
• Simplicity — maximize work NOT done.
• Regular reflection and process improvement.

Scrum framework

Scrum Roles

• Product Owner: Defines and prioritizes the Product Backlog. Represents business.
• Scrum Master: Facilitates Scrum process, removes impediments, coaches the team.
• Development Team: Cross-functional team including developers, testers, designers.

Scrum Artifacts

• Product Backlog: Ordered list of all requirements (User Stories, Bugs, Technical debt).
• Sprint Backlog: Items selected for the current sprint.
• Increment: Working, tested software delivered at sprint end.

Scrum Ceremonies

• Sprint Planning (start of sprint): Team selects backlog items for the sprint, discusses acceptance criteria.
• Daily Standup (every day, 15 min): What did I do yesterday? What will I do today? Any blockers?
• Sprint Review (end of sprint): Demonstrate completed work to stakeholders, get feedback.
• Sprint Retrospective (after review): Reflect on process — what went well, what to improve.

QA TESTER'S ROLE IN SCRUM — DAY BY DAY:

Sprint Planning

• Review User Stories for testability.
• Ask clarifying questions about acceptance criteria.
• Estimate testing effort for each story.
• Identify dependencies and risks.

During Sprint (Days 1–2): Test case creation for stories being developed.

During Sprint (Days 3–8): As development completes features, begin testing them immediately. Don't wait for all features to be done.

During Sprint (Days 8–10): Complete testing, raise defects, work with developers to fix and retest.

End of Sprint: Participate in Sprint Review, contribute to Retrospective.

DEFINITION OF DONE (DoD) — TESTING PERSPECTIVE:

In Agile, "Done" means: Feature coded + Unit tested by developer + QA tested + Defects resolved + Regression passed + Code reviewed + Deployed to staging. QA helps define and enforce the DoD.

Challenges for testers in agile

• Short sprints create time pressure.
• Requirements may not be fully defined at sprint start.
• Regression testing grows each sprint.
• Balance between testing new features and running regression.

Solutions: Automate regression, adopt BDD for clarity, prioritize by risk, do exploratory testing for unclear areas.

How to Prepare as a Fresher

• Say every answer out loud with one example of your own; one-line definitions don't get offers.
• Practise writing 8–10 test cases for a login page, a search box and a form in five minutes each.
• Learn the basics of one bug tracker (Jira) and SQL SELECT queries; both come up in fresher rounds.
• Next, read the questions for 1 year of experience so follow-up questions don't surprise you.