1|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Unit – VI
Software Testing
This PDF is watermarked and traceable. Unauthorized sharing will result in
permanent access ban and legal action.
Su

1. Software Testing
dh

Software Testing is the process of evaluating a software application to check if it meets the
an

required specifications and to identify any defects or bugs.

sh

It ensures that the product is reliable, functional, and user-friendly before it is released to
u

customers.
De

Purpose of Software Testing

sh

• To detect defects early.

m

• To ensure the quality of the software.

uk

• To verify that the software meets user requirements.

h

• To ensure the software works correctly under various conditions.

-+

Guidelines for a Successful Software Testing Strategy

91

1. Understand Requirements Clearly: Testers must fully understand what the software
90

is supposed to do to create accurate test cases.

75

2. Start Testing Early: Begin testing activities during the requirement and design phases
61

(early testing finds defects early).

62

3. Plan Testing Properly: Prepare a detailed test plan, covering scope, resources,
64

schedule, and testing methods.

4. Prioritize Test Cases: Focus first on testing critical and high-risk areas of the
application.

5. Use a Mix of Testing Types: Combine different types like functional, performance,
security, and usability testing for better coverage.
 2|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

6. Automate Where Possible: Use automation for repetitive tests to save time and
increase reliability.

7. Maintain Clear Communication: Ensure smooth communication between

developers, testers, and stakeholders.

8. Track and Manage Defects Well: Log defects clearly and track them through their
entire life cycle.
Su

9. Continuously Review and Improve: Regularly review the testing process, learn from
dh

mistakes, and improve strategies.

an

10. Ensure Good Test Environment Setup: Create a test environment that closely
sh

matches the real-world user environment.

u

1.1 A Strategic Approach to Software Testing

De

Software testing cannot be done randomly — it needs a strategic, planned approach to be

sh

effective.
A strategic approach to testing means planning how testing activities will be performed,
m

systematically uncovering defects, and ensuring the quality of the software product.
uk

It emphasizes that:
h
-+

• Testing should begin early in the software development life cycle (SDLC).
91

• Testing should be well-planned and organized — not an afterthought.

90

Key Points:
75

1. Early Testing: Testing starts at the requirements phase to catch errors early.
61

2. Systematic Progression: Testing moves from small units (unit testing) ➔ integration ➔
system testing ➔ acceptance testing.
62
64

3. Planned Testing: Test planning is done before coding, with clear objectives and methods.

4. V-Model Representation: Testing stages are aligned with development stages in a V-

shaped model:

o Left side: Development (requirements, design, coding)

o Right side: Testing (acceptance, system, unit testing)

 3|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

5. Risk-Based Focus: Focus more on critical, high-risk areas to use time and resources
efficiently.

1.2 Verification and Validation

Verification

Verification is the process of checking whether the software is being built correctly (according
Su

to the design and requirements).

dh

Purpose: To ensure the product is developed properly without any mistakes in the process.
an

Focus: On process and documents (like requirements, design, and code reviews).
sh

Examples:
u

o Reviewing requirements.
De

o Checking design documents.

sh

o Code inspections.
m

Question Answered: Are we building the product right?

uk

Validation
h

Validation is the process of checking whether the software meets the user's needs and works
-+

as expected.
91

Purpose: To ensure the final product is correct and satisfies user requirements.
90

Focus: On the actual product through execution and testing.

75

Examples:
61

o Functional testing.
62

o User acceptance testing.

64

Question Answered: Are we building the right product?

Difference between Verification and Validation

Aspect Verification Validation

Meaning Are we building the product right? Are we building the right product?
 4|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Focus Process, documents, and Actual software product and its

intermediate work products behavior

Purpose Ensure the software is developed Ensure the software meets user needs
correctly

Activities Reviews, inspections, walkthroughs Testing (functional, system, acceptance

tests)
Su

Execution Without executing the code With executing the code

dh

Timing Happens during development Happens after development (later

an

(early stages) stages)

sh

Type Static process Dynamic process

u

Examples - Reviewing design documents - Running the application

De

- Checking coding standards - Performing user acceptance testing

sh
m

1.3 Organizing for Software Testing

uk

Organizing for software testing means structuring the testing activities and responsibilities
properly within the project or company. It ensures that testing is well-planned, efficient, and
h

independent, leading to higher software quality.

-+

Key Aspects of Organizing for Testing:

91

1. Who Does the Testing?

90

• Developers:
75

o Perform unit testing on their own code.

61

o Check small components and modules.

62

• Independent Testers:
64

o Perform system testing, integration testing, and acceptance testing.

o They are separate from the development team to ensure unbiased testing.

• Specialized Testing Teams (in big projects):

o A dedicated team focuses only on testing activities.

 5|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

o They bring expertise in planning and executing different types of tests.

2. Levels of Testing Responsibility

• Unit Testing → Done by developers.

• Integration Testing → Done by developers or a testing team.

• System Testing → Done by independent testers.

Su

• Acceptance Testing → Done by customer/user representatives.

dh

3. Independent Testing Benefits

an

• Reduces bias (developers might overlook their own mistakes).

sh

• Improves objectivity and quality of testing.

u

• Helps find more defects from a user’s point of view.

De

1.4 Criteria for Completion of Testing

sh

The Criteria for Completion of Testing (also called Exit Criteria) define when testing
m

activities can be stopped. It ensures that enough testing has been done and the software is
uk

ready for release.

h

1. Entry Criteria: Entry Criteria define the conditions that must be met before testing can
-+

start. They ensure that the necessary requirements, resources, and readiness are in place for
91

testing.
90

Key Entry Criteria:

75

• Test Plan Approved: The overall test strategy and test plans are approved.
61

• Test Environment Set Up: The test environment (hardware, software, networks) is
configured and ready for testing.
62

Test Data Available: The necessary test data for different scenarios is prepared and
64

available.

• Code is Stable: The code has reached a point where it is stable enough for testing. All
critical features must be implemented and ready for testing.

• Test Team Ready: The testing team is properly trained, with resources, tools, and
knowledge required to perform the tests.
 6|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

• Requirements are Clear: The requirements and specifications of the software are
well-defined, and test cases are created accordingly.

2. Exit Criteria: Exit Criteria define the conditions that must be met before testing can be
considered complete. They help determine when testing is finished and the software is ready
for release or deployment.

Key Exit Criteria:

Su

• All Test Cases Executed: All planned test cases have been executed, and their results
dh

are documented.
an

• Defects Resolved: All major defects have been fixed and re-tested. Minor defects are
sh

either accepted or deferred for future releases.

u

• Test Coverage Achieved: All requirements (both functional and non-functional) have
De

been thoroughly tested, ensuring full coverage.

sh

• Performance Goals Met: The software has met its performance, security, reliability,
and other non-functional goals.
m
uk

• Defect Density Acceptable: The defect density is low enough to meet the quality
standards. Any remaining defects are considered acceptable based on the project's risk
h

tolerance.
-+

• Customer or Stakeholder Approval: The customer or key stakeholders are satisfied

91

with the test results, and the product meets their expectations.
90

• Test Reports Completed: Detailed test reports are completed, showing the results of
75

all testing, defects found, and final status.

61

1.5 Software Testing Life Cycle (STLC)

62

The Software Testing Life Cycle (STLC) is a series of steps followed during testing to ensure
64

software quality. It defines how testing is planned, executed, and completed in a structured
way.

Phases of STLC

1. Requirement Analysis: Testers study requirements to understand what needs to be tested.

2. Test Planning: The testing strategy is prepared: resources, tools, and timelines are decided.
 7|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

3. Test Case Development: Testers write detailed test cases and prepare test data.

4. Environment Setup: A testing environment (like servers, software) is set up, similar to the
real system.

5. Test Execution: Testers run the test cases and report any defects found.

6. Test Closure: After testing is done, results are documented, defects are verified, and the
Su

testing team gives a final test report.

dh

Example of Software Testing Life Cycle (STLC)

an

Suppose you are testing a shopping app:

sh

1. Requirement Analysis: Understand that users must add items to the cart.
u

2. Test Planning: Decide tools, resources, and schedule.

De

3. Test Case Development: Write test cases for adding items to the cart.
sh

4. Environment Setup: Prepare mobile devices and app environment.

m

5. Test Execution: Run tests, report if "Add to Cart" button fails.

uk

6. Test Closure: Finalize test report and close testing activities.

h

Advantages of STLC
-+

• Makes testing organized and systematic.

91

• Helps detect defects early in the development.

90

• Ensures better coverage of all features.

75

• Provides clear documentation and proof of testing activities.

61

Disadvantages of STLC
62

• Can be time-consuming if the project is very large.

64

• If requirements change frequently, earlier STLC phases may become invalid.

• Needs good coordination between testers, developers, and managers.

• Testing depends heavily on the completeness of requirements; poor requirements can

lead to poor testing.
 8|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

1.6 Defect Life Cycle (Bug Life Cycle)

The Defect Life Cycle is the process that a defect (bug) follows from the moment it is found
until it is fixed and closed. It describes all the stages a defect passes through in its lifetime.

Main Stages in Defect Life Cycle

1. New: Tester finds a new defect and reports it.

Su

2. Assigned: The defect is assigned to a developer for fixing.

dh

3. Open: The developer starts analyzing and working on the defect.

an

4. Fixed: The developer fixes the defect and updates its status.
sh

5. Retest: The tester retests to check if the defect is properly fixed.

u

6. Verified: If the defect is fixed correctly, the tester marks it as verified.

De

7. Closed: After verification, the defect is closed.

sh

Other Possible Statuses

m

• Rejected: Developer rejects the defect (not valid).

uk

• Deferred: Defect is postponed for a future release.

h
-+

• Duplicate: Defect already reported earlier.

91

• Reopened: Defect still exists after retesting.

90

Example: Suppose a tester finds an issue:

75

“Submit button on the registration form does not work.”

61

The life cycle would be:

62

1. New: Tester logs the defect in the bug tracking tool.

64

2. Assigned: Project manager assigns the defect to a developer.

3. Open: Developer starts analyzing the issue.

4. Fixed: Developer corrects the button functionality.

5. Retest: Tester tests the button again.

6. Verified: Button now works — tester marks the defect as verified.

 9|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

7. Closed: Defect is closed officially.

If the button still didn’t work, the tester would reopen the defect.

Advantages of Defect Life Cycle

• Helps track the status of every defect clearly.

• Ensures that all defects are handled properly (fixed, deferred, or closed).
Su

• Improves communication between testers, developers, and managers.

dh

• Enhances the quality of the final product by ensuring no defect is missed.

an

Disadvantages of Defect Life Cycle

sh

• Can be time-consuming if there are too many approval steps.

u

• Miscommunication may occur if statuses are not updated properly.

De

• If not managed well, defects may get stuck in certain statuses (like Assigned or Open).
sh

• Adds overhead when small or low-priority defects also go through the entire cycle.
m
uk

1.7 Strategic Issues

h

Strategic Issues in software testing refer to the important decisions and challenges that shape
-+

how testing will be conducted throughout the project. These issues address both planning and
execution of testing, ensuring that the testing efforts are aligned with business goals, deadlines,
91

and quality standards.

90

Key Strategic Issues:

75

1. Test Planning: When to start and what to test based on project priorities and risks.
61

2. Test Coverage: Balancing thorough testing with time/resources. Focus on high-risk areas.
62

3. Test Resources: Ensure the right team size, skills, tools, and infrastructure are in place.
64

4. Test Execution and Automation: Decide manual vs automated testing for efficiency and
accuracy.

5. Defect Management: Prioritize and track defects, ensuring critical issues are addressed
first.
 10 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

6. Test Metrics and Reporting: Track key metrics (defect density, coverage) and report
progress to stakeholders.

7. Test Environment and Data: Set up a realistic test environment and manage test data
effectively.

8. Time and Cost Constraints: Balance quality with time/budget limits, making trade-offs
where necessary.
Su

1.8 Test Strategies for Conventional Software

dh

Test strategies for conventional software involve structured approaches to ensure the
an

software meets its requirements, functions correctly, and is free from defects. These strategies
sh

focus on various testing levels, processes, and methodologies to deliver a reliable product.
u
De
sh
m
uk
h
-+
91
90
75
61
62

1. Unit testing - In this type of testing techniques are applied to detect the errors from each
64

software component individually.

2. Integration testing - It focuses on issues associated with verification and program

construction as components begin interacting with one another.

3. Validation testing - It provides assurance that the software validation criteria (established
during requirements analysis) meets all functional, behavioral and performance requirements.
 11 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

4. System testing - In system testing all system elements forming the system is tested as a
whole.

1.9 Unit Testing

Unit Testing is the process of testing individual components (like functions, classes, or
modules) of a software system in isolation to ensure that each one works correctly and
independently.
Su

• Purpose: To verify that each small piece of the program performs as designed.
dh

• Performed by: Developers during the coding phase.

an

• Tools: JUnit, NUnit, PyTest, Google Test, etc.

sh

The various tests that are conducted during the unit test are described as below.
u
De

1. Module interfaces are tested for proper information flow in and out of the program.
2. Local data are examined to ensure that integrity is maintained.
sh

3. Boundary conditions are tested to ensure that the module operates properly at
m

boundaries established to limit or restrict processing.

uk

4. All the basis (independent) paths are tested for ensuring that all statements in the
module have been executed only once.
h

5. All error handling paths should be tested.

-+
91
90
75
61
62
64

Errors Identified During Unit Testing

During unit testing, the following types of errors are typically detected:

1. Logic Errors: Mistakes in the algorithm or calculation.

2. Incorrect Functionality: Function does not produce the correct output for given inputs.
 12 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

3. Boundary Errors: Issues when input values are at their minimum, maximum, or just
outside expected ranges.

4. Exception Handling Errors: Failures to properly handle unexpected or invalid inputs.

5. Resource Leaks: Memory leaks, unclosed files, or database connections.

6. Interface Errors: Problems in the interaction between functions or with external

Su

components (e.g., wrong parameters).

dh

Driver and Stub

an

When doing unit testing, the module being tested might depend on other modules that are not
yet developed. To simulate these dependencies, drivers and stubs are used:
sh

• Driver:
u
De

o A temporary program that calls the unit being tested.

sh

o Simulates a higher-level module that would normally invoke the unit.

m

o Example: A main() function that passes input to a function for testing.

uk

• Stub:
h

o A temporary program that the unit under test calls.

-+

o Simulates a lower-level module that isn’t yet available.

91

o Example: A fake database response when the actual database module isn't ready.
90
75
61
62
64

1.10 Integration Testing

Integration Testing is the process of testing the interaction between two or more individual
software components after they have been unit-tested.
 13 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

• Purpose: To ensure that different modules work together properly when combined.

• Performed After: Unit Testing (once individual modules are tested).

Key Points:

1. Focus: Detect errors in module interactions, such as incorrect data sharing, wrong
function calls, or interface mismatches.
Su

2. Approach: Instead of testing modules individually, now test them combined to check
dh

if they integrate correctly.

an

3. Common Problems Found

sh

o Incorrect data passing between modules.

u

o Miscommunication between different parts of the program.

De

o Missing or wrong function calls.

sh

4. Need for Drivers and Stubs

m

o Still used if some modules are not yet ready.

uk

o Driver calls a module; Stub simulates a called module.

h

The integration testing can be carried out using two approaches.

-+

1. The non-incremental integration

91

2. Incremental integration
90
75
61
62
64

1. Non-Incremental Integration
 14 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Non-Incremental Integration, also called Big Bang Integration, is a method where all
modules are combined at once after unit testing, and the entire system is tested together.

Key Points:

• Approach: No gradual combining. All units/modules are integrated simultaneously.

• Testing: After combining everything, the system is tested as a whole.

Su

• Advantages:
dh

o Simple — no planning needed for the order of integration.

an

o Suitable for small systems with fewer modules.

sh

• Disadvantages:
u

o Difficult to debug errors because it’s hard to tell which module caused the problem.
De

o High risk — if many errors occur, finding and fixing them becomes time-
sh

consuming.
m

o Late discovery of interface problems between modules.

uk

2. Incremental Integration
h

An incremental construction strategy includes:

-+

i. Top-down integration
91

ii. Bottom-up integration

90

iii. Regression testing

iv. Smoke testing
75

i. Top-Down Integration Testing

61

Top-Down Integration Testing is a method where

62

testing starts from the top (main module) of the

64

software and progresses downward through the

control hierarchy.
 15 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Key Points:

• Approach:
Test the top-level module first, then gradually add and test lower-level modules.

• Use of Stubs:

o If a lower module is not yet ready, a stub is used to simulate its behavior.
Su

o Stub temporarily replaces the missing module and returns dummy results.
dh

• Process:
an

1. Start testing the main module.

sh

2. Add one lower-level module at a time.

3. Replace stubs with real modules as they are developed.
u
De

Advantages:
sh

• Early testing of major functionalities and important interfaces.

m

• Helps find design errors early in the upper modules.

uk

• Logical control and decision-making paths are tested first.

h

Disadvantages:
-+

• Requires writing many stubs to simulate missing lower modules.

91

• Lower-level functionality may not be tested thoroughly until late in the process.
90

Example: In an Online Shopping System, the main module "Shop System" controls login,
75

product search, and payment.

61

• Start testing Shop System first.

62

• Use stubs for "Login Module," "Product Search," and "Payment Module" if they aren't
ready.
64

• Gradually replace stubs with real modules and test their integration.

ii. Bottom-Up Integration Testing

Bottom-Up Integration Testing is a method where testing starts from the lowest (leaf)
modules and moves upward toward the main module.
 16 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.
Su
dh
an
sh
u
De

Key Points:
sh

• Approach: Begin by testing smallest, independent modules first, then combine them
m

step-by-step toward the top.

uk

• Use of Drivers: If a higher-level module is not ready, a driver is created to call and test
h

the lower-level modules.

-+

• Process:
91

1. Test individual lower-level modules.

90

2. Combine them and test their integration.

75

3. Move upward by integrating with higher modules.

61

Example (Short):
62

In a Banking System:
64

• Start by testing small modules like "Balance Checker", "Deposit", and "Withdraw".

• Use drivers to simulate the main system.

• After lower modules are tested, combine and integrate them into the main Banking
System.

Advantages:
 17 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

• Lower-level modules are tested early.

• No need for many stubs.

• Easy to isolate and fix errors in small modules.

Disadvantages:

• Higher-level modules (overall system flow) are tested late.

Su

• Need to create drivers for early testing.

dh

iii. Regressing Testing

an

Regression Testing is the process of retesting the existing software after any changes, bug
sh

fixes, or enhancements to make sure that the new code does not break the existing
u

functionality.
De

Key Points:
sh

• Purpose:
m

To check that the old (unchanged) code still works correctly after updates.
uk

• When to do it:
h

o After fixing a bug.

-+

o After adding new features.

91

o After changing system configuration.

90

• How it's done:

75

o Run previous test cases (especially the important ones) again.

61

o Confirm that no new errors have been introduced.

62

Example: Suppose you fix a bug in the payment module of an online shopping app.
64

In regression testing, you will also test login, cart, search features to make sure they still work
properly.

Advantages:

• Ensures stability of software after updates.

• Catches unexpected side effects of changes early.

 18 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Disadvantages:

• Can become time-consuming if not automated.

• Needs careful selection of test cases to avoid unnecessary work.

iv. Smoke Testing

Smoke Testing is a type of preliminary testing performed to check if the basic functions of
Su

a software application are working properly after a build or update.

dh

Key Points:
an

• Purpose: To quickly assess whether the core features of the system are working. It helps
sh

determine whether the build is stable enough for further, more detailed testing.
u

• When to perform:
De

o After a new build is deployed.

sh

o Before starting more detailed testing (like functional or regression testing).

m

• Focus: Test the critical and essential features of the software (e.g., login, navigation, basic
uk

workflows).
h

• Also known as: "Build Verification Testing."

-+

Example: In an e-commerce website, after a new build is deployed, smoke testing checks if:
91

• The login page works.

90

• The product search function works.

75

• The checkout process is functional.

61

If these core functions fail, further detailed testing is halted until the major issues are fixed.
62

Advantages:
64

• Quick way to ensure basic functionality.

• Helps identify major problems early, before deep testing starts.

• Saves time by catching critical issues early.

Disadvantages:
 19 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

• Only covers basic functionality, not deep testing.

• May not catch all bugs, especially in complex scenarios.

1.11 System Testing

System Testing is the process of testing the complete and integrated software system to
ensure that it meets the specified requirements and works as intended in the overall
Su

environment.
dh

Key Points:
an

• Purpose: To verify that the entire system functions correctly and satisfies the user
requirements.
sh

• Scope: It tests the whole system, including interactions between modules and external
u

interfaces, as a fully integrated entity.

De

• Types of Tests:
sh

o Functional Testing: Verifies that the system performs the required functions.
m
uk

o Non-Functional Testing: Tests for performance, security, compatibility, and other

non-functional requirements.
h

When to Perform: After integration testing, once all components of the system have been
-+

integrated.
91

Example: For a banking application, System Testing would involve:

90

• Testing the entire system including login, account management, transaction processing,
75

and reporting.
61

• Ensuring that the system performs well under load, handles edge cases, and interacts
62

correctly with external systems like payment gateways.

64

Advantages:

• Ensures the system works as a whole and meets all functional and non-functional
requirements.

• Identifies any integration issues between modules.

Disadvantages:
 20 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

• Can be time-consuming since it tests the entire system.

• Requires a complete environment (hardware, software) to test properly.

Various types of system tests are:

1. Recovery testing
2. Security testing
Su

3. Stress testing
4. Performance testing
dh

1. Recovery Testing
an

Recovery Testing is a type of testing that checks the software’s ability to recover from
sh

crashes, hardware failures, or other unexpected problems.

u

Key Points:
De

• Purpose: To ensure that the system can recover gracefully from various types of
sh

failure and continue functioning without data loss or corruption.

m

• How it's done: Simulate failure scenarios (e.g., power loss, system crashes) and verify
uk

that the system can restore itself to a stable state.

h

Example: In a banking app, recovery testing might simulate a server crash during a
-+

transaction. The test checks if the system can:

91

• Recover the transaction after reboot.

90

• Ensure that no data is lost or corrupted.

75

Advantages:
61

• Ensures system reliability during unexpected failures.

62

• Helps maintain data integrity after crashes.

64

Disadvantages:

• Requires simulating various failure scenarios, which can be complex.

• Might not always cover every possible failure scenario.

2. Security Testing
 21 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Security Testing is the process of verifying that a software application is protected from
unauthorized access, data breaches, and potential vulnerabilities.

Key Points:

• Purpose: To ensure that the system is secure against attacks and that sensitive data is
kept safe.
Su

• Focus Areas:
dh

o Authentication: Ensure only authorized users can access the system.

an

o Authorization: Ensure users only access data they are permitted to.
sh

o Data Protection: Ensure sensitive data is encrypted and stored securely.

u

o Vulnerability Scanning: Identify weaknesses that could be exploited by attackers.

De

Example: For an online banking system, security testing would check if:
sh

• The login process is secure (using strong passwords, multi-factor authentication).

m

• User data, like account balances, is encrypted.

uk

• The system is protected against SQL injection or other types of attacks.

h

Advantages:
-+

• Protects against data theft, fraud, and hacking.

91

• Ensures compliance with security standards and regulations.

90

Disadvantages:
75

• Requires specialized knowledge in security testing.

61

• Can be time-consuming and may require pen-testing (penetration testing).

62

3. Stress Testing
64

Stress Testing is a type of testing that evaluates how a software application behaves under
extreme conditions or when it is subjected to heavy loads beyond normal operational capacity.

Key Points:
 22 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

• Purpose: To determine the system's breaking point and ensure it can handle extreme
situations without crashing.

• Focus Areas:

o Performance under high load (e.g., many users or large data volumes).

o How the system behaves when resources are exhausted (e.g., memory, processing
Su

power).
dh

Example: For an e-commerce website, stress testing might involve simulating thousands of
users trying to access the website simultaneously during a big sale. This checks if the system
an

can handle the traffic load without crashing.

sh

Advantages:
u

• Identifies the limits of the system's capacity.

De

• Helps ensure stability under high stress or unexpected conditions.

sh

Disadvantages:
m
uk

• Can be resource-intensive to simulate extreme conditions.

h

• Sometimes may not reflect real-world usage scenarios.

-+

4. Performance Testing
91

Performance Testing is the process of evaluating how a software application performs in terms
of speed, responsiveness, and stability under various conditions.
90

Key Points:
75

Purpose: To ensure that the system performs efficiently under expected loads and meets
61

performance requirements.
62

• Focus Areas:
64

o Speed: How quickly the system responds to user inputs.

o Scalability: How well the system handles increased loads.

o Stability: How consistent the performance is over time or under stress.

Example: For an online gaming app, performance testing checks:

 23 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

• How fast the game loads and responds to user actions.

• Whether the app can handle increasing numbers of players without slowing down.

Advantages:

• Ensures the system meets performance expectations.

• Identifies performance bottlenecks early.

Su

Disadvantages:
dh

• Can be time-consuming to simulate different usage scenarios.

an

• Requires specialized tools and resources for accurate testing.

sh

1.12 Test Strategies for Object-Oriented Software

u

Testing object-oriented (OO) software requires strategies that consider the unique
De

characteristics of object-oriented design, such as encapsulation, inheritance, and

sh

polymorphism. These features require specific approaches to ensure software quality.

m

Key Points:
uk

1. Class Testing:
h

o Focus on testing individual classes to ensure their methods and behaviors are correct.
-+

o Unit testing is essential here, where each class is tested independently to check for
91

errors in functionality.
90

2. Integration Testing:
75

o Test interactions between objects to ensure proper communication.

61

o This involves checking method calls, inheritance hierarchies, and polymorphic

62

behaviors.
64

3. State-based Testing:

o Test how an object’s state changes in response to method calls.

o Verify that state transitions are correct according to the class's behavior.

4. Inheritance Testing:
 24 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

o Ensure that subclasses properly inherit behaviors from parent classes.

o Overridden methods and inherited features must be tested for correct functionality.

5. Polymorphism Testing:

o Test how polymorphic behavior works, ensuring that the correct method is called
when objects of different types are used interchangeably.
Su

6. Exception Handling Testing:

dh

o Ensure that objects handle exception scenarios properly.

an

o Check if objects can handle invalid inputs, errors, or unexpected conditions without
sh

breaking.
u

7. Interaction Testing:
De

o Focus on testing interactions between objects in a system to ensure that data flows
sh

correctly between them.

m

o Involves testing collaborations between objects in complex systems.

uk

Example: For a banking system, class testing might check the Account class, ensuring
h

methods like deposit() and withdraw() work correctly. Integration testing checks if
-+

Account and Transaction classes interact properly. Inheritance testing ensures that a
SavingsAccount correctly inherits from the Account class and adds its own behavior.
91

Advantages:
90

• Comprehensive coverage of OO features like inheritance and polymorphism.

75

• Identifies interaction issues between objects early.

61

Disadvantages:
62

• Complexity: OO systems can have many interdependencies, making testing more

64

challenging.

• Requires specialized techniques for state and interaction testing.

 25 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

1.13 Unit Testing in the OO Context

In the context of Object-Oriented (OO) programming, unit testing focuses on testing

individual classes and their methods in isolation to ensure they function as expected. Since
OO software is made up of interacting objects, unit testing ensures that each class behaves
correctly before it is integrated with other parts of the system.

Key Points of Unit Testing in OO Context:

Su

1. Testing Individual Methods: Each method within a class is tested to ensure it performs
dh

its expected behavior correctly.

an

2. Isolation: Classes are tested independently by mocking or stubbing dependencies, so

sh

interactions with other classes are not tested at this stage.

u

3. State and Behavior: Unit tests verify that objects maintain the correct state and exhibit
De

the correct behavior after methods are called.

sh

4. Class Invariants: Unit tests check if the class maintains its invariants (rules that must
always be true for the class) throughout its operation.
m
uk

Example:
h

For a Car class with a method accelerate(), unit testing would:

-+

• Verify if calling accelerate() increases the speed correctly.

91

• Test edge cases, like ensuring speed doesn't go below zero.

90

• Mock dependencies (e.g., a FuelSystem) if needed.

75

Advantages:
61

• Helps catch errors early.

62

• Promotes better code design.

64

• Simplifies testing by isolating classes.

Disadvantages:

• Requires complex mocking for external dependencies.

• Doesn't catch integration issues between components.

 26 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

1.14 Integration Testing in the OO Context

In Object-Oriented (OO) systems, integration testing checks how different classes and objects
work together after unit testing. The goal is to detect errors in interactions between classes.

Key Points of Integration Testing in OO Context:

1. Cluster Testing: Groups of related classes (called clusters) are tested together to verify
Su

correct interaction.
dh

2. Interaction Between Objects: Tests are designed to check how objects collaborate,
communicate, and pass data among themselves.
an

3. Incremental Integration: Classes are integrated and tested step-by-step rather than all
sh

at once to catch errors early.

u

4. Use of Drivers and Stubs: Sometimes drivers (temporary calling programs) and stubs
De

(dummy classes/methods) are used if some components aren't ready.

sh
m
uk
h
-+
91
90
75

As shown in the diagram, Integration Testing is divided into two main approaches:
61

1. Thread-Based Testing
62

• It tests a set of classes that work together to accomplish a specific function (a thread of
64

control).

• Classes are integrated and tested along a particular usage path.

• Focus is on testing behavior across multiple interacting objects.

Example: In an online shopping system, testing how Cart, Payment, and Order classes interact
when placing an order.
 27 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

2. Use-Based Testing

• It focuses on testing classes based on usage relationships (how one class uses
another). It is divided further into:

o Independent Class Testing:

▪ Classes that do not depend on others are tested first.

Su

▪ These classes are easy to test as they have minimal external requirements.
dh

o Dependent Class Testing:

an

▪ Classes that rely on others are tested after the classes they depend on are tested
sh

and stable.
u

Example: Test a Payment class (dependent) after confirming the Wallet class (independent)
De

works correctly.
sh

Advantages:
m

• Detects interaction errors: Catches problems in communication between classes early.

uk

• Validates collaboration: Ensures objects work correctly together as designed.

h

• Improves system reliability: Helps build a more stable and predictable system.
-+

Disadvantages:
91

• Complex due to OO features: Inheritance, polymorphism, and dynamic binding make

90

testing harder.
75

• Requires careful planning: Missing object interactions can lead to hidden bugs later.
61

1.15 Difference between OO Testing Strategy and Conventional Testing Strategy

62

Aspect Conventional Software Object-Oriented (OO) Software

Testing Testing
64

Unit Testing Tests individual functions or Tests individual classes and methods
Focus procedures separately. along with their internal states.

Integration Tests modules together in a Tests interactions between objects

Testing functional or sequential order. (messages, collaborations).
 28 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Testing Comparatively simpler, as More complex due to inheritance,

Complexity procedures are independent. polymorphism, and dynamic binding.

Data and Focuses separately on data and Focuses on both data and behavior
Behavior functions. (since they are combined inside
objects).

Test Case Based mainly on input/output Based on object interactions, state

Su

Design conditions and control flow. changes, and class hierarchies.

dh

Error Easier to localize errors in Harder to detect errors because behavior

an

Detection functions. is distributed among objects.

sh

1.16 Test Strategies for Web Apps

u
De

Testing web applications is important because they work over networks, interact with browsers,
and are used by many users at once.
sh

A good strategy covers functionality, performance, security, and compatibility.

m

Key Test Strategies:

uk

1. Functionality Testing: Ensure all links, forms, buttons, and workflows work correctly.
h
-+

2. Usability Testing: Test if the app is user-friendly, easy to navigate, and visually clear.
91

3. Interface Testing: Verify interactions between web server, application server, and
database server.
90

4. Compatibility Testing
75

o Test on different browsers (Chrome, Firefox, Safari) and devices (desktop,

61

tablet, mobile).
62

o Check for responsiveness and layout issues.

64

5. Performance Testing: Test load time, server response time, and behavior under heavy
user traffic.

6. Security Testing: Check for vulnerabilities like SQL injection, cross-site scripting
(XSS), and unauthorized access.
 29 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

7. Recovery Testing: Verify the web app can recover from crashes, server failures, or
network issues.

8. Localization and Globalization Testing (if needed): Ensure correct language

translations and date/time formats based on the region.

1.17 Validation Testing

Su

Validation Testing is done to ensure that the final software meets the customer requirements
and works as expected in the real-world environment.
dh

It answers the question: “Are we building the right product?”

an

Key Points:
sh

• Purpose: To ensure that the right product has been built according to user needs and
u

business goals.
De

• Focus Areas:
sh

o Correctness: Whether the software provides correct outputs for all inputs.
m
uk

o Completeness: Whether all required features are implemented.

h

o Usability: Whether the system is user-friendly and matches customer

expectations.
-+

Example:
91

For an online shopping website, validation testing checks:

90

• If the user can successfully browse products, add to cart, and complete payments.
75

If all business rules (like discounts, offers, shipping charges) are applied correctly.
61

Advantages:
62

Ensures the software fulfills real user requirements.

64

• Helps in finding missing functionalities before deployment.

Disadvantages:

• May require extensive documentation and customer involvement.

• Late discovery of issues can lead to more expensive fixes.

 30 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

1.18 User Acceptance Testing

Acceptance Testing is the process of verifying if the complete software system is ready for
delivery by ensuring it meets business requirements and is acceptable to the end user or
client.

Key Points:
Su

• Purpose: To confirm that the system works correctly and is acceptable for release.
dh

• Focus Areas:
an

o Functionality: Does the software behave as expected?

sh

o Usability: Is it easy and intuitive for users?

u

o Compliance: Does it meet the agreed requirements and regulations?

De

Example:
sh

For a food delivery app, acceptance testing checks:

m

• Can users place orders, track deliveries, and make payments easily?
uk

• Are delivery times, offers, and taxes calculated properly?

h

Advantages:
-+

• Ensures software is ready for real users.

91

• Reduces risk of failure after launch.

90

Disadvantages:
75

• Can be time-consuming if requirements are not clear.

61

• Changes found during acceptance can cause delays.

62

Types of Acceptance Testing:

64

1. Alpha Testing:

• Conducted in-house by internal staff (developers, testers) before releasing to real users.

• Done in a controlled environment to catch early issues.

 31 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Example: Developers testing a photo editing app in the office before it is given to selected
users.

2. Beta Testing:

• Conducted by actual users in the real-world environment.

• Feedback is collected from users to make final improvements.

Su

Example: Releasing a new social media app to a few thousand users before global launch to
dh

gather real-world feedback.

an

Difference between Alpha and Beta Testing

sh

Aspect Alpha Testing Beta Testing

u

Who Performs Internal staff (developers, Real users (external users)

De

testers)
sh

Environment Controlled (within company) Real-world environment

m

Purpose Find bugs before release to Gather user feedback for improvements
uk

users
h

Timing Before Beta Testing After Alpha Testing, before final release
-+

Access Limited to organization Limited public or selected real users

91

Feedback Type Technical issues mainly User experience and feature suggestions
90

1.19 Validation-Test Criteria

75

Validation Test Criteria are the conditions that must be satisfied to ensure that the software
61

correctly implements the customer's requirements and is ready for final acceptance.
62

Key Points:
64

• Purpose: To verify that the software system does what the user expects.

• Focus:

o Checking functional behavior (features work as specified).

o Checking performance (speed, responsiveness).

 32 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

o Checking usability and reliability.

Typical Validation Criteria:

• All functional requirements have been correctly implemented.

• All performance benchmarks (like response time) are met.

• Interfaces and outputs match the user expectations.

Su

• The software operates correctly in the target environment.

dh

Example: For a flight booking website, validation test criteria would ensure:
an

• Users can search flights, book tickets, and receive confirmations correctly.
sh

• The system responds within 2 seconds to a search query.

u

• Payment gateways work smoothly and securely.

De

1.20 Configuration Review

sh

Configuration Review is a formal process where the software’s technical and design aspects
m

are carefully examined to ensure that the system is complete, correct, and ready for
uk

validation testing.
h

Key Points:
-+

• Purpose: To verify that all required components (software modules, documents, data
91

files) are properly developed and organized.

90

• Focus Areas:
75

o All modules are coded and integrated correctly.

61

o Documentation (user manuals, installation guides) is complete and up-to-date.

62

o Interfaces between modules and external systems are properly defined.

64

o Configuration management (version control, change tracking) is properly

handled.

Example: Before launching a healthcare management system, a configuration review checks

if:

• All patient management modules are working together.

 33 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

• User manuals and help files are updated.

• Database version matches the latest software release.

1.21 White Box Testing

White Box Testing is a software testing method where the tester has full knowledge of the
internal code, logic, and structure of the application. The focus is on checking how the system
Su

works internally, not just what it outputs.

dh

Key Points:
an

• Requires Code Knowledge: Testers must understand the code and how the software is
built.
sh

• Test Case Design: Based on internal structures like functions, conditions, loops, and
u

paths.
De

• Focus: Tests internal logic, flow of data, and coding standards.

sh

Advantages:
m
uk

• Detects hidden errors in code logic.

h

• Helps improve code quality and security.

-+

Limitations:
91

• Requires programming skills.

90

• Can be time-consuming for large systems.

75

Example: Suppose you have a simple function:

61

int add(int a, int b) {

62

return a + b;
64

In White Box Testing, you would:

• Check if the function correctly adds different values like add(2, 3) and add(-1, 5).

• Verify all possible paths (although simple here, larger code would have multiple conditions
and loops to check).
 34 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

You are not just looking at the output, but also verifying that the logic and flow inside the
function are correct.

1.22 Black Box Testing

Black Box Testing is a software testing method where the tester checks the system's
functionality without any knowledge of its internal code or structure. The main focus is on what
the system does, not how it does it.
Su

Key Points:
dh

• No Code Knowledge: Testers only work with inputs and expected outputs.
an

• Test Case Design: Based on user requirements and specifications.

sh

• Focus: Tests whether the system behaves correctly for different inputs.
u
De

Advantages:
sh

• Easy to perform without programming skills.

m

• Focuses on user experience and system behavior.

uk

Limitations:
h

• Cannot find hidden errors in the code structure.

-+

• May miss internal bugs.

91

Example: Imagine a login page:

90

• Input: Username and password.

75

• Expected Output: If the credentials are correct, the user logs in; if incorrect, an error
61

message appears.
62

In Black Box Testing, you would:

64

• Enter correct and incorrect username/password combinations.

• Verify whether the system accepts or rejects them correctly, without checking how the
login is implemented inside.
 35 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Difference between White Box and Black Box Testing

Aspect White Box Testing Black Box Testing

Knowledge Tester must know the internal Tester does not need any
Required code and logic. knowledge of code.

Focus Tests internal structures (logic, Tests system functionality and

Su

loops, paths). behavior.

dh

Test Basis Based on program structure. Based on requirements and

specifications.
an

Performed By Developers or testers with Testers, QA team, or end users.

sh

programming skills.
u

Main Goal To verify internal working and To check if the system meets user
De

code quality. expectations.

sh

Advantages Finds hidden logical errors, Easy for non-programmers, focuses

m

improves code. on user needs.

uk

Limitations Time-consuming, complex for Cannot find internal code issues.

h

large systems.
-+

Examples Checking all conditions in a Testing a login form with different

91

function. inputs.
90

1.23 Path Testing in Software Engineering

75

Path Testing is a method that is used to design the test cases. In the path testing method, the
61

control flow graph of a program is designed to find a set of linearly independent paths of
62

execution. In this method, Cyclomatic Complexity is used to determine the number of linearly
independent paths and then test cases are generated for each path.
64

It gives complete branch coverage but achieves that without covering all possible paths of the
control flow graph. McCabe’s Cyclomatic Complexity is used in path testing. It is a structural
testing method that uses the source code of a program to find every possible executable path.

Path Testing Process

 36 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.
Su
dh
an

• Control Flow Graph: Draw the corresponding control flow graph of the program in which
sh

all the executable paths are to be discovered.

u

• Cyclomatic Complexity: After the generation of the control flow graph, calculate the
De

cyclomatic complexity of the program using the following formula.

sh

McCabe's Cyclomatic Complexity = E - N + 2P

m

where,
uk

E = Number of edges in the control flow graph

N = Number of vertices in the control flow graph
h

P = Program factor
-+

• Make Set: Make a set of all the paths according to the control flow graph and calculate
91

cyclomatic complexity. The cardinality of the set is equal to the calculated cyclomatic
90

complexity.
75

• Create Test Cases: Create a test case for each path of the set obtained in the above step.
61

Path Testing Techniques

62

• Control Flow Graph: The program is converted into a control flow graph by
64

representing the code into nodes and edges.

• Decision to Decision path: The control flow graph can be broken into various
Decision to Decision paths and then collapsed into individual nodes.

• Independent paths: An Independent path is a path through a Decision-to-Decision

path graph that cannot be reproduced from other paths by other methods.
 37 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Control Flow Graph (CFG)

A Control Flow Graph (CFG) is the graphical representation of control flow or computation
during the execution of programs or applications. Control flow graphs are mostly used in static
analysis as well as compiler applications, as they can accurately represent the flow inside a
program unit. The control flow graph was originally developed by Frances E. Allen.

Characteristics of Control Flow Graph

Su
dh

• The control flow graph is process-oriented.

• The control flow graph shows all the paths that can be traversed during a program
an

execution.
sh

• A control flow graph is a directed graph.

u

• Edges in CFG portray control flow paths and the nodes in CFG portray basic blocks.
De

There exist 2 designated blocks in the Control Flow Graph:

sh

• Entry Block: The entry block allows the control to enter into the control flow graph.
m
uk

• Exit Block: Control flow leaves through the exit block.

h

Hence, the control flow graph comprises all the building blocks involved in a flow diagram
-+

such as the start node, end node, and flows between the nodes.
91

General Control Flow Graphs

90

Control Flow Graph is represented differently for all statements and loops. The following
images describe it:
75

1. if-else 2. while
61
62
64
 38 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

3. do-while 4. for
Su
dh
an
sh

Example:
u

if A = 10 then
De

if B > C
sh

A = B
m
uk

else A = C
h

endif
-+

endif
91

print A, B, C
90

Flowchart of above example will be:

75
61
62
64
 39 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Control Flow Graph of above example will be:

Su
dh
an
sh
u
De

Advantage of CFG
sh

• Visualizes program flow: Easy to see how a program runs.

m

• Helps find errors: Detects unreachable code or infinite loops.

uk

• Useful for optimization: Improves program performance.

h
-+

• Aids testing: Ensures all parts of the code are tested.

91

Disadvantages of CFG
90

• Complex for big programs: Hard to understand.

75

• No unpredictable behavior: Can’t show unclear paths.

61

• No data info: Only shows program flow.

62

• Not scalable: Becomes messy for large projects.

64