Ultimate Software Testing Interview Guide (2026)

A Test Scenario is a high-level documentation that describes "what to test" without getting into the "how". It represents a specific functionality or a feature of the application that needs verification. It effectively serves as a category or a bucket for multiple test cases.

Test Cases are the detailed, step-by-step instructions that describe "how to test" a specific scenario. A well-written test case is independent, clear, and contains Expected Results to verify against Actual Results. It is the fundamental unit of testing execution.

Test Data represents the specific input values fed into the application during test execution to verify logic. It distinguishes a "pass" from a "fail". Test data needs to be diverse, covering valid, invalid, boundary, and null values.

Boundary Value Analysis (BVA) checks the edges of input ranges. Bugs hide at the boundaries.

Simple Answer: We test the API BEFORE the UI (Website/App) is ready.

Think of it like a Car:

• API = Engine (The internal logic that makes it move).
• UI = Car Body/Paint (What the user sees).

We test the Engine (API) first. If the engine is broken, there is no point in painting the car (UI).

Fig 1: API testing fits in the stable middle layer.

These are different architectural styles and protocols.

Testing technique selection is driven by the nature of the requirement and the risk involved.

• Forms with ranges: Use BVA (Boundary Value Analysis). (e.g., Age 18-65).
• Dropdowns: Use Equivalence Partitioning.
  • Example (Pizza Sizes):
    Group 1 (Small): 7" - 10" (Valid).
    Group 2 (Medium): 11" - 13" (Valid).
    Group 3 (Invalid): 6" (Too Small) or 15" (Too Large).
• Complex logical rules: Use Decision Table Testing. (e.g., If Age > 18 AND Score > 600 -> Approve Loan).
• Workflow/Process: Use State Transition Testing.
  • Example (Order Status): New -> Processing -> Shipped -> Delivered.
    How to test: Verify "Processing" can move to "Shipped" (Valid), but "Shipped" cannot go back to "Processing" (Invalid).

We do NOT automate everything. Automation is an investment.

Regression is verifying that new code hasn't broken existing functionality.

Selection Criteria:

1. Critical Path: Functionality that blocks business (Login, Payment).
2. Recent Changes: Features directly modified in this sprint.
3. High Defect Areas: Modules that historically break often ("Fragile" parts).
4. Integration Points: Where updated modules talk to other modules.

When time is limited, we use the MoSCoW method.

First, a clarification: We NEVER test the external provider itself (like Stripe/PayPal).

Why?

1. Their Responsibility: It is their product, they typically have thousands of engineers testing it.
2. P.O.C (Proof of Concept): We already selected them because they are capable. If not, we would have chosen another.
3. Waste of Time: Building/testing a payment gateway from scratch is redundant.

However, we MUST test our Integration (The Connection - part of our P.O.C):

1. API Testing (Security & Logic): We test the "Pay" endpoint to ensure it deducts the exact amount, handles currency conversion correctly, and securely tokensizes card details.

2. UI Testing (User Experience): We verify the user is redirected to the bank page, the loading spinner appears, and the "Success" animation plays.

This is a common interview question for freshers. The interviewer wants to see if you can think of the basic "Happy Path" and "Negative Scenarios".

Simple Answer (What you should say): "I will verify if the item is correctly added and if I can pay for it."

This is usually decided as part of the P.O.C (Proof of Concept), but as testers, we must verify the integration points.

Testing 3rd party integrations (Stripe, PayPal) requires "Dummy Cards".

Sometimes you don't have formal requirements. In that case, we use:

1. Exploratory Testing: "Learning while testing." Navigate the app like a curious user.
2. Competitor Analysis: How does Gmail do this feature? Our email app should likely behave similarly.
3. Error Guessing: Using experience to guess where devs make mistakes (e.g., uploading a 1GB file, entering special characters in Name).

Errors should be graceful and informative. Use the "Oops" principle.

• User Perspective: Don't show "NullPointerException". Show "Something went wrong, please try again."
• Security: Error messages should not leak database info (e.g., "SQL Syntax Error at line 4").
• Logging: The actual technical error must be logged in the backend (Splunk/Datadog) for developers to fix.

API testing is the foundation. If the foundation (Logic/API) is broken, painting the house (UI) is a waste of time. If the API fails, the UI is USELESS.

1. Speed: API tests run much faster than UI tests because they don't need to load a browser or render simple graphics.
2. Early Testing (Shift Left): We can verify the backend logic before the UI is even built.
3. Business Logic Validation: Ensures the core rules (e.g., calculating interest) are correct independent of the screen.
4. Early Bug Detection: Finding bugs in the API layer is cheaper to fix than waiting for the UI.
5. Accuracy: Direct access to data ensures we are testing the exact values sent/received.
6. Security & Authentication:
   Real-Life Example (Kia Cars Hack):

   Researchers found a vulnerability where they could remotely start, unlock, and track millions of Kia cars using just the license plate number. This was due to a leaked/weak API token mechanism.

   Kia paid out significant bug bounties for reporting this critical API flaw.

   Source: Hacking Kia (Sam Curry)
7. System Stability: API tests ensure that integrations between different services (e.g., Payment -> Order) don't break.
8. Performance: We can easily load test an API with thousands of requests to check response times.
9. Stable APIs = Stable Application: If the backend is solid, the UI will likely be stable too.

Fig 3: We focus on the connection, not the external box.

We DO NOT test external applications because:

1. Third-Party Responsibility: Owned and maintained by vendors.
2. Proof of Concept (POC): Already validated.
3. Waste of Time (QA): We focus resources on our own code.