Software Testing

1. What is a Test Case?

A test case is a detailed document containing a set of conditions, steps, inputs, and expected results used by quality assurance (QA) professionals to verify if a software application behaves correctly.

Example:
For a login page, a test case can be:

• Enter a valid username.
• Enter a valid password.
• Click the Login button.
• Expected result: The user should successfully log in.

Main Types of Test Cases

• Functional Test Cases: Checks if a feature performs exactly as business requirements dictate (e.g., adding an item to a cart updates the total).
• Integration Test Cases: Verifies that two or more interacting software modules or APIs work smoothly together.
• Negative Test Cases: Tests how the system handles invalid input or abnormal conditions to check error handling (e.g., typing a letters into a phone number field).
• Security & Performance Test Cases: Checks the software's data integrity limits, load thresholds, and potential system vulnerabilities.

2. What is a Test Scenario?

The fundamental difference is that a test scenario defines what to test, while a test case defines how to test it.

Example:

"Test the Login functionality."

A single test scenario can contain multiple test cases.

3. What are Negative Test Cases?

Negative test cases verify how a software application behaves when given invalid inputs, unexpected actions, or error conditions.

Examples:

• Entering an incorrect password.
• Leaving the username field empty.
• Entering an invalid email address.

4. What are Positive Test Cases?

Positive test cases are instructions that check if software works the right way when you give it correct and expected data.

Key Features

• Uses valid, expected inputs
• Follows standard user steps
• Tests ideal conditions
• Confirms correct outputs

What is the difference between positive and negative test cases?

Positive test cases check if a system works with valid data. Negative test cases check how a system handles invalid data or errors. Both are vital for software quality.

Positive Test Cases

• What they do: Test normal, expected behavior.
• Input type: Valid data.
• Goal: Confirm the system performs correctly.
• Example (Login): Enter a valid username and correct password. The system logs you in.
• Example (Age field): Enter 25 into a field that takes ages 1 to 100. The system accepts it.

Negative Test Cases

• What they do: Test error handling and system safety.
• Input type: Invalid or unexpected data.
• Goal: Ensure the system fails gracefully without crashing.
• Example (Login): Enter a wrong password. The system shows an error message and denies access.
• Example (Age field): Enter -5 or abc. The system blocks the entry and shows an error.

6. What is Unit Testing?

A unit test is a small block of code written by developers to isolate and verify that a single, specific component of an application (like a function or method) behaves correctly.

7. What is Integration Testing?

Integration testing is a software testing phase where individual modules, components, or applications are combined and tested as a group.

Common Approaches

• Big Bang: All components are integrated simultaneously and tested together.
• Top-Down: Testing flows from top-level modules to lower-level ones using "stubs."
• Bottom-Up: Testing flows from lowest-level components upward using "drivers."
• Sandwich (Hybrid): A combination of top-down and bottom-up strategies.

9. Difference Between Stub and Driver

In software testing, stubs and drivers are temporary dummy

• A stub simulates a lower-level module called by the code under test.
• A driver simulates a higher-level module that calls the code under test.

Top-Down → Stub

Bottom-Up → Driver

10. Difference Between Error, Bug and Defect

• An Error is a mistake made by a developer or programmer.
• A Bug is an issue in the software caused by an error.
• A Defect is a deviation between the actual result and the expected result or requirement.

11. Difference Between Top-Down and Bottom-Up Testing

• In Top-Down Integration Testing, testing starts from the higher-level modules and moves toward the lower-level modules. Stubs are used for unavailable lower-level modules.
• In Bottom-Up Integration Testing, testing starts from the lower-level modules and moves toward the higher-level modules. Drivers are used for unavailable higher-level modules.

12. Difference Between BRS, SRS and FRS

• BRS – Business Requirement Specification: Describes what the business needs.
• SRS – Software Requirement Specification: Describes what the software should provide.
• FRS – Functional Requirement Specification: Describes the detailed functional behavior of the system.