Software Testing
Interview Prep — Expected Questions
Fundamentals • Types of Testing • Bug/Defect • Agile • Automation & API • Scenario Questions
Contents
Manual Testing Fundamentals
1. Testing vs Debugging
Testing identifies defects/bugs in software (done by testers). Debugging finds the root cause and fixes the defect
(done by developers).
2. Verification vs Validation
Verification: “Are we building the product right?” — checks if the product meets specifications (reviews,
walkthroughs, static testing). Validation: “Are we building the right product?” — checks if it meets user needs
(actual execution, dynamic testing).
3. What is STLC?
Software Testing Life Cycle: Requirement Analysis → Test Planning → Test Case Development → Environment
Setup → Test Execution → Test Cycle Closure.
4. SDLC vs STLC
SDLC covers the entire development process (requirements → design → coding → testing → deployment →
maintenance). STLC is specifically the testing phase within it.
5. What is a Test Plan?
A document outlining testing strategy — scope, objectives, resources, schedule, test environment, entry/exit
criteria, and deliverables.
6. What is a Test Case?
A set of conditions/steps with expected results to verify specific functionality. Contains: Test Case ID, description,
preconditions, steps, expected result, actual result, status.
7. Test Scenario vs Test Case
Test Scenario: high-level “what to test” (e.g. “Verify login functionality”). Test Case: detailed “how to test it” with
specific steps and expected results.
8. Positive vs Negative testing
Positive testing verifies the system works correctly with valid input. Negative testing verifies the system handles
invalid input gracefully (error handling).
Types of Testing
1. Functional vs Non-Functional testing
Functional tests what the system does (features, business logic). Non-Functional tests how well it does it
(performance, usability, security, load).
2. Smoke Testing vs Sanity Testing
Smoke testing: a quick, broad check that critical functionalities work after a new build (build stability check). Sanity
testing: a quick, narrow check on a specific area/bug fix after minor changes.
3. What is Regression Testing?
Re-testing the application after code changes/bug fixes to ensure existing functionality still works and nothing
broke.
4. Retesting vs Regression Testing
Retesting verifies a specific bug is actually fixed. Regression testing checks that the fix didn't break anything else.
5. What is Integration Testing?
Testing the interaction/data flow between two or more integrated modules/components.
6. What is System Testing?
Testing the complete, fully integrated application against the overall requirements (end-to-end).
7. What is User Acceptance Testing (UAT)?
Final testing phase where actual end-users/clients validate the software meets business requirements before go-
live.
8. What is Exploratory Testing?
Simultaneous learning, test design, and execution — testing without predefined scripts, relying on tester
experience/intuition to find defects.
9. What is Ad-hoc Testing?
Informal, unplanned testing performed without test cases or documentation, often to find defects quickly.
10. Black Box vs White Box vs Grey Box Testing
Black Box: testing functionality without knowledge of internal code (tester's perspective). White Box: testing
internal code structure/logic (developer's perspective). Grey Box: a mix of both.
11. What is Boundary Value Analysis (BVA)?
A test design technique focusing on values at the edges of valid/invalid ranges (e.g. for age 18–60: test 17, 18, 60,
61) since bugs often occur at boundaries.
12. What is Equivalence Partitioning?
Dividing input data into groups (partitions) expected to behave the same way, then testing one representative
value from each group instead of every possible value.
13. What is Decision Table Testing?
A technique mapping combinations of inputs/conditions to expected outputs/actions, useful for complex business
logic with multiple conditions.
Bug / Defect Related
1. What is a Bug Life Cycle?
New → Assigned → Open/In Progress → Fixed → Retest → Verified → Closed (or Reopened if the fix fails, or
Rejected/Deferred/Duplicate as alternate paths).
2. Bug vs Defect vs Error vs Failure
Error: a mistake made by a developer in code. Defect/Bug: the result of that error found during testing (before
release). Failure: the system not working as expected in production (after release).
3. What should a good Bug Report include?
Bug ID, title/summary, steps to reproduce, expected vs actual result, severity, priority, environment
(browser/OS/device), screenshots/logs, and status.
4. Severity vs Priority
Severity: how serious the impact of the bug is on the system (technical impact, set by tester). Priority: how
urgently it needs to be fixed (business impact, often set by product/dev team). A bug can be high severity/low
priority or low severity/high priority.
5. Blocker bug vs Critical bug
Blocker: prevents further testing entirely (app crashes, can't proceed). Critical: major functionality broken, but
testing of other areas can continue.
Agile & Process
1. What is Agile Testing?
Testing practiced continuously throughout the Agile development cycle (in sprints), with close collaboration
between testers, developers, and product owners, rather than testing only at the end.
2. Role of QA in Agile/Scrum
Participates in sprint planning (estimating test effort), daily standups (reporting progress/blockers),
writes/executes test cases within the sprint, and joins retrospectives to improve process.
3. Test Case Management tools
Tools to organize, execute, and track test cases: TestRail, Zephyr, qTest, Xray (Jira plugin).
4. Bug tracking tools
JIRA, Bugzilla, Azure DevOps, Mantis (mention whichever you've actually used).
Automation & API Testing
1. Manual vs Automation Testing
Manual: executed by hand, good for exploratory/one-off tests. Automation: executed via scripts/tools, good for
repetitive tasks like regression, faster and more reliable for repeated runs.
2. When should you NOT automate a test case?
Tests that run only once, UI that changes frequently, exploratory/usability testing, or tests with very low ROI
compared to automation effort.
3. What is a Test Automation Framework?
A set of guidelines/rules combining tools, coding standards, and reusable functions to design and structure
automated test scripts efficiently (e.g. Data-Driven, Keyword-Driven, Hybrid, Page Object Model).
4. What is Page Object Model (POM)?
A design pattern that creates an object repository for web elements, separating test logic from UI element locators
— improves maintainability.
5. What is API Testing? What tools are used?
Testing APIs directly (without UI) to verify functionality, reliability, performance, and security of endpoints. Tools:
Postman, RestAssured, SoapUI.
6. REST vs SOAP APIs
REST: uses HTTP methods (GET, POST, PUT, DELETE), lightweight, typically JSON. SOAP: protocol-based, uses XML,
more rigid/structured, built-in error handling and security standards.
7. Common HTTP status codes
200 (OK), 201 (Created), 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), 500 (Internal
Server Error).
Scenario / Practical Questions
1. How would you test a login page?
Valid/invalid credentials, empty fields, case sensitivity, password masking, “Forgot Password” flow, session
timeout, SQL injection/XSS attempts, lockout after failed attempts, UI across browsers/devices.
2. How would you write test cases for an ATM machine / a lift / a pen?
Classic “test anything” question. Break it into: functional requirements, boundary conditions, negative scenarios,
usability, security, and performance — show structured thinking rather than a specific “correct” list.
3. How do you prioritize testing with limited time before release?
Focus on high-risk, high-impact areas first (core business flows, recently changed code), use risk-based testing, and
communicate what won't be covered.
4. What do you do if a developer disagrees that something is a bug?
Explain the expected behavior clearly (with requirements/spec reference), provide reproduction steps/evidence,
and involve the product owner/BA if disagreement continues — stay collaborative, not confrontational.