Unit 1 : Introduction to Software Testing

Q.1. What is bug, defect, error & failure give an example of each ?
Ans :
Bug
Definition : A bug is a mistake in the code that causes the program to behave incorrectly.
Example : A programmer types if (age > 18) instead of if (age >= 18) to check if a user is eligible,
which wrongly excludes users who are exactly 18 years old.
Defect
Definition : A defect is a deviation from the expected requirement or specification in the software.
Example : The requirement says that the system should send an email confirmation after registration,
but the system fails to send the email. This is a defect.
Error
Definition : An error is a human mistake while writing the code or designing the logic.
Example : A programmer types price * 0.2 instead of price * 0.1 to calculate a 10% discount.
Failure
Definition : A failure is the incorrect behavior of the software when it is run, resulting in unexpected
output.
Example : A user clicks the submit button, but the form crashes and the data is not saved. This is a
failure.

Q.2. What are the skill set required by software tester ?

Ans :
1. Technical Skill:
✔ Ability to write and execute test cases.
2. Analytical Skill:
✔ Strong attention to detail to find hidden defects.
3. Communication Skill:
✔ Clear documentation of bugs with steps to reproduce.
4. Domain Knowledge:
✔ Understanding user workflows for realistic testing.
5. Soft Skill:
✔ Patience to perform repetitive testing thoroughly.
6. API Testing Skills:
✔ Use tools like Postman to test backend services.
7. Time Management:
✔ Prioritize test cases to meet project deadlines efficiently.
8. Curiosity & Learning Mindset:
✔ Explore the application thoroughly to discover edge-case bugs.
Q.3. What are different levels of software testing? Explain in short.
Ans :

1. Unit Testing
o Tests individual parts (functions or modules) of the software.
o Ensures each part works correctly.
o Done by developers during development.
o Types:
▪ Black Box – tests inputs/outputs without checking the code.
▪ White Box – tests functionality by examining code.
▪ Gray Box – tests both functionality and code performance.
2. Integration Testing
o Tests how different modules work together.
o Finds issues when parts are combined.
o Done after unit testing.
o Approaches:
▪ Big Bang – all modules tested at once.
▪ Bottom-Up – starts from lower modules.
▪ Top-Down – starts from higher modules.
▪ Mixed – combination of both.
3. System Testing
o Tests the complete system as a whole.
o Checks if it meets requirements and customer expectations.
o Includes functional and non-functional testing like:
▪ Performance, Load, Stress, Scalability Testing.
4. Acceptance Testing
o Final test to see if the system is ready for use.
o Checks if it meets business requirements.
o Done by users or clients.
Q.4. Explain the Software testing principles.
Ans :

1. Testing shows the presence of defects

• Testing can prove that bugs exist, but it cannot prove that there are no bugs.
• Even if all tests pass, it doesn’t mean the software is flawless.
• Example: Finding that a login page fails when entering wrong credentials.

2. Exhaustive testing is impossible

• Testing every possible input, condition, or scenario is not practical due to time and cost constraints.
• Testers need to prioritize high-risk areas and representative test cases.
• Example: For an application with thousands of input combinations, only a subset is tested.

3. Early testing saves time and cost

• Testing activities should start as early as possible in the software development lifecycle.
• Detecting issues early reduces the cost and effort needed for fixes.
• Example: Finding a requirement error during the design phase rather than after coding.

4. Defect clustering
• A small number of modules often contain the majority of defects.
• Focus testing on these critical or error-prone parts to maximize effectiveness.
• Example: A module handling file uploads may have more defects than other parts.

5. Pesticide paradox
• Running the same tests repeatedly will stop finding new defects.
• Test cases need to be regularly reviewed, updated, or replaced to catch new issues.
• Example: After fixing known bugs, testers must add new test scenarios to uncover hidden defects.

6. Testing is context-dependent
• Different types of applications require different testing approaches.
• Testing methods for a banking system are not the same as for a game or social app.
• Example: A healthcare system needs stricter validation compared to an entertainment platform.

7. Absence of errors is not a proof of correctness

• Just because the software passes all tests doesn’t mean it meets user requirements.
• Testing should also verify that the software performs what it’s supposed to do.
• Example: A calculator might add numbers correctly but still not handle invalid inputs as expected.
Q.5. Explain Software Testing Goal.
Ans :

1. Immediate Goals
• Bug Discovery: The primary and immediate goal of software testing is to identify defects or bugs in
the software as early as possible.
2. Short-Term Goals
• Reliability: Ensure that the software performs consistently under expected conditions.
• Quality: Verify that the software meets functional and non-functional requirements.
• Customer Satisfaction: Deliver a product that meets user expectations and requirements.
• Risk Management: Reduce the risks associated with software failure by detecting issues early.
3. Post-Implementation Goals
• Reduced Maintenance Cost: Fixing defects early reduces long-term maintenance costs.
• Improved Testing Process: Enhance the efficiency and effectiveness of future testing activities.
• Bug Prevention: Prevent similar defects in future development cycles.

Q.6. Explain Software Testing Life Cycle (STLC) ?

Ans :

The Software Testing Life Cycle (STLC) is a sequence of activities or phases carried out during the testing
process to ensure software quality.
Characteristics of STLC:
• Part of SDLC, focusing only on testing phases.
• Begins once requirements are defined.
• Provides a step-by-step process to ensure software quality.
 • Early analysis defines testing scope, criteria, and test cases, reducing test cycle time.
• Test execution starts immediately after development, enabling early bug detection.
Software Testing Life Cycle (STLC) Phases:
1. Requirement Analysis
o First step in the STLC.
o Testers review the requirements to identify testable aspects.
o Objective: Understand what needs to be tested.
2. Test Planning
o Test strategy is created here.
o Defines scope, resources, schedule, testing types, and tools.
o Outcome: Test Plan document.
3. Test Case Development
o Design and prepare test cases and test data.
o Test cases are reviewed and approved before execution.
4. Test Environment Setup
o Prepare hardware, software, and network conditions for testing.
o Ensures that the environment mirrors real-world conditions.
5. Test Execution
o Execute the test cases in the prepared environment.
o Log defects for any deviations from expected results.
6. Test Closure
o Evaluate if testing objectives are met.
o Prepare Test Closure Report including metrics, lessons learned, and defect summary.

Q.7. What is Defect Management Process ?

Ans : It is a process where organizations manage:
• Defect Discovery (finding defects)
• Defect Removal (resolving defects)
• Process Improvement (learning from defects to prevent future ones)
The main goal is to detect defects early, resolve them efficiently, and reduce their impact on the software.
It is impossible to make software 100% defect-free, but DMP helps minimize defects and their effects.
Objectives of DMP:
• Expose defects early in the software development lifecycle.
• Enhance the software development process and implementation.
• Reduce the impact of defects on the software.
• Avoid defects through preventive measures.
• Resolve defects efficiently.
• Provide input for status reports and release decisions.
• Identify root causes to prevent recurrence.
Stages of the Defect Management Process:

1. Defect Prevention:
o Proactively reducing the risk of defects using standardized procedures and methodologies.
o Key steps: Estimate predictable impact, minimize expected impact, and identify critical risks.
2. Deliverable Baseline:
o Establishing a reference point (baseline) for deliverables to measure against when identifying
defects.
3. Defect Discovery:
o Identifying and logging defects through testing and other quality assurance activities.
4. Defect Resolution:
o Assigning, fixing, and verifying defects to ensure they are resolved.
5. Process Improvement:
o Analyzing defects to find root causes and improve processes to prevent future defects.
6. Management Reporting:
o Providing visibility into defect metrics, progress, and trends to support decision-making.
Advantages of Defect Management Process
1. Better Quality: Fewer bugs, more stable software.
2. Cost Saving: Early defect detection reduces fixing costs.
3. Efficiency: Streamlines tracking and resolving issues.
4. Data-Driven Decisions: Reports help assess project health.
5. Continuous Improvement: Prevents repeat defects.
Disadvantages of Defect Management Process
1. Time-Consuming: Can slow down development if overly strict.
2. Tool Cost: Requires investment in tracking and management tools.
3. Overhead: Too much documentation can reduce team agility.
4. False Sense of Security: Finding many bugs doesn’t guarantee a good product.
5. Resistance to Change: Teams may resist formal processes.
Q.8. Compare Verification and Validation.
Ans :
Verification Validation
Checks if the product is being built according to Checks if the final product meets user needs and
requirements. expectations.
Process-oriented: focuses on activities and Product-oriented: focuses on the actual software
documentation. product.
Done early in the software development lifecycle. Done later, after or during implementation.
Performed by QA team, analysts, or reviewers. Performed by testers and end-users.
Techniques: reviews, walkthroughs, inspections, Techniques: functional testing, system testing, user
static analysis. acceptance testing.
Purpose: ensure adherence to standards, Purpose: ensure the product works correctly in
specifications, and design. real-world scenarios.
Activity type: static, no code execution. Activity type: dynamic, involves executing the
software.
Detects defects in documents, design, or code Detects defects in the actual working product.
before implementation.
Helps in preventing defects early. Helps in validating that the right product is
delivered.
Example: reviewing requirement or design Example: testing the login feature of an application.
documents.

Q.9. Explain Positive Testing & Negative testing with example ?

Ans : Positive Testing
• Definition: Testing the software application by providing valid data sets as input. It checks if the
software behaves as expected with correct inputs.
• Purpose: To verify that the software application does exactly what it is supposed to do and meets the
specified requirements.
• Example:
o A text field is designed to accept only numbers from 0 to 99999.
o Positive Test: Entering values like 0, 500, or 99999.
o Expected Result: The system should accept these values without any errors.
Negative Testing
• Definition: Testing the software application by providing invalid or improper data sets as input. It
checks how the software handles unexpected or incorrect user inputs.
• Purpose: To ensure the software application is robust, stable, and does not crash when given invalid
data. It also checks for proper error messages.
• Example:
o The same text field designed to accept numbers from 0 to 99999.
o Negative Test: Entering values like abc, -10, 100000, or special characters like @.
o Expected Result: The system should not accept these values. It should either reject them or
display a clear error message (e.g., "Invalid input. Please enter a number between 0 and
99999.").
Key Elements to Consider in Both Test Types
For both positive and negative testing, the following must be defined:
1. Input Data: The data values used for testing.
2. Action: The specific operation performed (e.g., clicking a button after entering data).
3. Output Result: The expected system behavior or response.
Testing Techniques Used
The text highlights two core techniques used to design test cases for positive and negative testing:
1. Boundary Value Analysis (BVA)
• Concept: Test cases are designed to include values at the boundaries of input ranges.
• Positive Testing: Uses values within the boundary limits (e.g., 0, 1, 9, 10 for a range of 0-10).
• Negative Testing: Uses values just outside the boundary limits (e.g., -1 and 11 for a range of 0-10).
• Example: For a system that accepts numbers from 0 to 10, the boundary values tested would be -
1, 0, 1, 9, 10, 11.
2. Equivalence Partitioning (EP)
• Concept: Input data is divided into groups (partitions) that are expected to be processed the same
way by the system.
• Positive Testing: Uses values from valid equivalence partitions.
• Negative Testing: Uses values from invalid equivalence partitions.
• Example: For the same system (accepting 0-10), the partitions could be:
o Valid Partition: 0 to 10 (for positive testing).
o Invalid Partitions: Less than 0 (e.g., -10 to -1) and Greater than 10 (e.g., 11 to 20) (for negative
testing).

Q.10. Compare White Box & Black Box Testing.

Ans :
White Box Testing Black Box Testing
Tests internal logic, code, and structure of the Tests functionality without knowing the internal code or
application. structure.
Requires knowledge of programming and Does not require programming knowledge.
implementation.
Performed by developers or testers with Performed by testers or QA team without coding
coding skills. knowledge.
Type: Structural testing / Glass box testing. Type: Functional testing / Behavioral testing.
Focuses on code coverage (statements, Focuses on input-output validation and functional
branches, paths). requirements.
Helps find hidden errors, logical flaws, and Helps find functional errors, incorrect outputs, missing
security vulnerabilities. features.
Techniques: Statement coverage, branch Techniques: Equivalence partitioning, boundary value
coverage, path coverage, unit testing. analysis, decision table, user scenario testing.
Usually done during development phase (unit Usually done during later stages (system testing,
testing). acceptance testing).
More detailed, time-consuming, and costly. Less detailed, easier to perform, cost-effective.
Example: Testing whether a function correctly Example: Testing whether login works with valid and
handles all branches in code. invalid credentials.
 Unit 2 : Black Box Testing

Q.1. Demonstrate the black box testing. List black box testing [Link] is need of testing?
Ans : Black Box Testing is a software testing method in which the tester evaluates the functionality of an
application without knowing its internal code or structure. The tester focuses on inputs and expected
outputs, ensuring the software behaves correctly according to specifications.

Purpose/Need of Testing:
1. Detect defects early in the software to reduce cost of fixing later.
2. Ensure the software meets functional requirements.
3. Validate system reliability and quality.
4. Identify unexpected behavior or errors before release.
5. Confirm the software works for all possible input scenarios.
Black Box Testing Techniques
1. Equivalence Partitioning (EP)
o Divides input data into valid and invalid partitions where all inputs in a partition are expected
to behave similarly.
o Example: For an age input field that accepts 18–60:
▪ Valid partitions: 18–60
▪ Invalid partitions: <18, >60
2. Boundary Value Analysis (BVA)
o Tests the edges of input ranges, where defects often occur.
o Example: For age 18–60:
▪ Test values: 17, 18, 19, 59, 60, 61
3. Decision Table Testing
o Uses a table to represent combinations of inputs and their corresponding outputs.
o Example: Login system with conditions: Username (Valid/Invalid), Password (Valid/Invalid)
Username Password Action
Valid Valid Login Success
Valid Invalid Error Message
Invalid Valid Error Message
Invalid Invalid Error Message
4. State Transition Testing
o Focuses on system states and transitions caused by events.
o Example: ATM states: Idle → Card Inserted → PIN Entered → Transaction → Exit. Test
valid/invalid transitions.
5. Error Guessing
o Relies on tester experience to guess error-prone areas.
o Example: Enter special characters in a numeric field or leave mandatory fields blank.
 6. Graph-Based Testing Methods
o Uses graphs or flowcharts to model program logic for testing paths.
o Example: Represent a workflow with nodes as states and edges as transitions; test all paths
to ensure coverage.

Demonstration Example using Techniques

Suppose we have a registration form with fields: Age (18–60) and Email (valid format).
Technique Test Case Examples
Equivalence Partitioning Age: 25 (valid), 17 (invalid), 61 (invalid)
Boundary Value Analysis Age: 18, 19, 59, 60, 17, 61
Decision Table Testing Age valid & Email valid → Success, Age invalid & Email valid → Error
State Transition Testing Form states: Empty → Partially filled → Submitted → Error/Success
Error Guessing Age: “abc”, Email: “[Link]”
Graph-Based Testing Draw flow: Start → Enter Age → Enter Email → Submit → Success/Error

Q.2. Design the equivalence class test cases for a program that reads two integer pairs (m1, c1) and (m2,
c2) defining two straight lines of the form y=mx+c. The program computes the intersection point of the
two straight lines and displays the point of intersection.
Ans : The equivalence classes are the following:
• Parallel lines (m1 = m2, c1 ≠c2)
• Intersecting lines (m1 ≠m2)
• Coincident lines (m1 = m2, c1 = c2)
Now, selecting one representative value from each equivalence class, we get the required equivalence class
test suite {(2,2)(2,5),(5,5)(7,7), (10,10) (10,10)}

Q.3. Illustrate equivalence class partitioning technique with suitable example.

Ans Equivalence Class Partitioning (ECP) is a black box testing technique in which the input data is divided
into partitions or classes that are expected to exhibit similar behavior. Instead of testing every possible input,
test cases are selected from each class, assuming that if one test case in the class works, the others will likely
work too.

➤ Steps:
1. Identify valid and invalid input data classes.
2. Group the inputs that should be treated similarly.
3. Select one or more test cases from each class.
4.
 Example:
Problem Statement: A program accepts age as input. The valid age range is from 18 to 60 (inclusive). Any
input outside this range is invalid.
➤ Equivalence Classes:
Class Type Description Example Input
Valid Class Age between 18 and 60 25
Invalid Class 1 Age less than 18 15
Invalid Class 2 Age greater than 60 65

Test Cases:
1. Valid Class: Enter age = 25 → Expect successful operation.
2. Invalid Class 1: Enter age = 15 → Expect error message “Invalid age.”
3. Invalid Class 2: Enter age = 65 → Expect error message “Invalid age.”

Q.4. Describe boundry value analysis and write test suit for following scenerio: As per HR policy if the
applicant is between 0 to 12 years age, do not hire; if the applicant is between 12 to 18 years of age can
only hire as an intern; and if it between 18 to 65,can hire full time; and above 65, do not hire
Ans :
Boundary Value Analysis (BVA) is a software testing technique where test cases are designed to include
representatives of boundary values. The idea is that errors often occur at the edges of input ranges rather
than in the middle. So, by testing the boundaries, testers can catch defects that happen due to incorrect
handling of these edge cases.
In BVA, the typical approach is to test:
1. The exact boundary values (e.g., 12, 18, 65).
2. Just below the boundary (e.g., 11, 17, 64).
3. Just above the boundary (e.g., 13, 19, 66).
This technique helps ensure that the software correctly handles the transition between different conditions.

Test Scenario: Age-based Hiring Policy

Conditions:
1. 0–12 years → Do not hire
2. 12–18 years → Hire as an intern
3. 18–65 years → Hire full-time
4. Above 65 years → Do not hire

Boundary Values:
Boundary Test Values
Lower bound 0 -1, 0, 1
First boundary 12 11, 12, 13
Second boundary 18 17, 18, 19
Third boundary 65 64, 65, 66
 Test Suite using Boundary Value Analysis
Test Case ID Input Age Expected Result
TC01 -1 Do not hire (invalid age)
TC02 0 Do not hire
TC03 1 Do not hire
TC04 11 Do not hire
TC05 12 Hire as intern
TC06 13 Hire as intern
TC07 17 Hire as intern
TC08 18 Hire full-time
TC09 19 Hire full-time
TC10 64 Hire full-time
TC11 65 Hire full-time
TC12 66 Do not hire

Explanation
• For each boundary (12, 18, 65), we test values at, below, and above it.
• We also include invalid or unexpected inputs like -1 to test how the system handles them.
• This ensures that the hiring logic is implemented correctly at all critical points.

Q.5. To perform boundry value testing how many test cases required to test
Given f(x,y) with constraints a ≤ x ≤ b
c≤y≤d
Describe the test cases required .
Ans : Boundary value testing focuses on testing the values at the edges of the input domain, where errors
are more likely to occur. For a function f(x, y) with constraints:
• a≤x≤b
• c≤y≤d
We test:
• The lower boundary
• The upper boundary
• Just below and just above the boundary (if applicable)
• Nominal/typical values
➤ How many test cases are required?
For each variable (x and y), we test the following 3 boundary points:
1. The lower boundary: a
2. Just above lower boundary: a + 1
3. The upper boundary: b
4. Just below upper boundary: b - 1
Similarly for y:
1. The lower boundary: c
2. Just above lower boundary: c + 1
3. The upper boundary: d
 4. Just below upper boundary: d - 1
However, depending on the rigor, usually we take:
• Minimum value
• Just above minimum
• Nominal (middle)
• Just below maximum
• Maximum
That’s 5 values for x × 5 values for y = 25 test cases.
If only strict boundary testing is required (i.e., test at boundaries only), we pick:
• x: a, b
• y: c, d
And we combine them:
• 2 values of x × 2 values of y = 4 test cases.
If we include “just inside and just outside” boundary values, it becomes:
• 3 values of x × 3 values of y = 9 test cases.
s
Summary
Approach Values per variable Total Test Cases
Strict boundary testing 2 2×2=4
Boundary with adjacent values 3 3×3=9
Extended boundary testing 5 5 × 5 = 25