UNIT 4

Q1. Explain the different types of testing strategies: Black-box testing,

White-box testing, and integration testing.

Black Box Testing

Black box testing is a software testing technique in which the functionality of the
software is tested without looking into its internal code structure or logic.
The tester only knows what the system is supposed to do, not how it does it.
The system is treated as a “black box,” and testing is based solely on
input–output behavior. This method verifies whether the software meets its
functional requirements and behaves correctly for different user inputs.
Objectives of Black Box Testing
• To validate the software against its specified requirements and functionalities.
• To detect incorrect or missing functions, interface errors, and data handling
problems.
• To ensure that the software produces correct outputs for all valid and
invalid inputs.
• To check user interactions and system behavior under various condition
Approaches / Techniques of Black Box Testing
(i) Equivalence Class Partitioning (ECP)
• Input data is divided into classes or partitions that are expected to behave
similarly.
• Only one representative value from each class is tested.
• Example:
For input age (1–100), partitions are:
o Less than 1 → Invalid
o Between 1 and 100 → Valid
o Greater than 100 → Invalid
(ii) Boundary Value Analysis (BVA)
• Errors often occur at the boundaries of input ranges.
• Test cases are designed for values just below, at, and just above boundary
limits.
• Example:
If valid range is 1–100, test 0, 1, 100, and 101.
(iii) Decision Table Testing
• Used when software has multiple conditions that combine to produce different
outcomes.
• Conditions and actions are represented in a table format.
• Ensures coverage of all combinations of inputs.
• Example:
In a login system:
o Correct ID & Password → Access granted
o Wrong ID or Password → Access denied
(iv) State Transition Testing
• Used for systems whose behavior changes based on state and events.
• Tests valid and invalid transitions between states.
• Example:
ATM states: “Card Inserted” → “PIN Entered” → “Transaction Selected.”
(vi) Error Guessing
• Based on tester’s experience and intuition.
• The tester guesses where errors are likely to occur (e.g., empty fields,
invalid formats, special characters).
Advantages
• Tests software from the user’s perspective. Helps identify functional and
interface defects.
• Effective for large systems with well-defined requirements. Does not require
programming knowledge.
 Limitations
• Cannot identify hidden code errors or logical flaws.
• Incomplete test coverage compared to white box testing.
• Depends heavily on the quality of specifications.
WHITE BOX TESTING
• White-box testing (Structural/Glass-box testing) tests the internal code logic.
• Test cases are designed using source code analysis.
• Two main strategies:
1. Coverage-based – aims to execute certain code elements.
2. Fault-based – aims to detect specific faults (e.g., mutation testing).
1. Coverage-Based Testing
• Focus on Execute program elements to find errors.
• Testing Criterion The specific program elements a test suite must cover.
• Stronger vs Weaker Strategies:
o A stronger strategy covers all elements of a weaker strategy plus more.
o Complementary strategies cover different elements.
Approaches / Techniques of White Box Testing
White box testing uses several structural approaches to ensure complete code
coverage.
(i) Statement Coverage
• Ensures that every statement in the code is executed at least once.
• Helps identify unused or dead code.
• Example:
• if (x > 0)
• y = y + 1;
→ Test with x > 0 and x ≤ 0 to cover both branches.
(ii) Branch Coverage (Decision Coverage)
• Ensures that every possible branch (true/false) of each decision point is
executed at least once.
• Provides better coverage than statement testing.
• Example:
For if (a > b), both conditions (true and false) must be tested.
(iii) Condition Coverage
• Ensures that each individual condition in a decision is tested for both true
and false outcomes.
• Focuses on complex conditions (e.g., if (A && B)).
(iv) Path Coverage
• Ensures that every possible path through the program is executed at least once.
• Provides the most thorough level of coverage but may be complex for large
programs.
(v) Data Flow Testing
• Focuses on the points where variables receive values (definitions) and where
those values are used.
• Detects issues like uninitialized variables or incorrect data usage.
Advantages
• Ensures maximum code coverage and helps find hidden logical errors.
• Detects programming errors early in development.
• Helps in code optimization and improving software efficiency.
• Enables verification of all loops, conditions, and branches.
Limitations
• Requires deep programming knowledge.
• Time-consuming and expensive for large programs.
• Cannot detect missing functionality (since it focuses only on existing code).
 • Not suitable when the source code is unavailable.
Mutation Testing ( Fault-Based Testing)
• A fault-based white-box testing technique where small changes (mutants)
are introduced into a program to check whether the existing test suite
can detect faults.
• Measures the effectiveness of a test suite.
Process
1. Design an initial test suite (using coverage-based methods).
2. Generate mutants by applying mutation operators (small program changes).
3. Run the test suite on each mutant:
o Dead Mutant: detected by test case ✅
o Live Mutant: not detected ❌ → indicates weak tests
o Equivalent Mutant: behaves same as original ⚠️ → ignored
4. Enhance the test suite to kill surviving mutants.
5. Repeat until adequate coverage is achieved.
Mutation Operators
• Arithmetic: + → -
• Relational: > → <
• Logical: AND → OR
• Statement: delete or modify statements
• Constants: change literal values
Advantages
• Detects weaknesses in the test suite.
• Improves software reliability.
• Quantitative measure of test adequacy.
Limitations
• Computationally expensive for large programs.
 • Requires automation.
• Identifying equivalent mutants can be challenging.
Example
Original: if(x > 10) y = y + 1;
Mutant 1: if(x >= 10) y = y + 1; // relational change
Mutant 2: if(x > 10) y = y - 1; // arithmetic change
Mutant 3: y = y + 1; // delete condition
• Test suite detects Mutant 1 → killed
• Mutant 2 survives → test suite improvement needed

[Link] the concept of software quality management and the role of

ISO 9000 standards.

A Quality Management System (QMS) is the methodology used by organizations

to ensure software products meet desired quality.
It includes structures, responsibilities, procedures, and standards to maintain and
improve quality.
Managerial Structure & Responsibilities
• The entire organization is responsible for quality.
• A separate quality department performs QMS activities.
• Top management support is essential — without it, quality practices are not
taken seriously.
Quality System Activities
A good QMS performs the following key tasks:
1. Auditing projects to check if processes are followed.
2. Collecting and analyzing metrics (process and product).
3. Reviewing the quality system for improvements.
4. Developing standards, procedures, and guidelines.
 5. Reporting system effectiveness to top management.
Documentation is vital — without it, quality control becomes ad hoc and
inconsistent.
International standards like ISO 9000 guide how to organize a quality system.
Evolution of Quality Systems
Product Inspection: Focused on detecting defects by identifying and rejecting
defective products.
Quality Control (QC): Goes beyond detection to find and correct the causes of
defects, reducing rejection rates.
Quality Assurance (QA): Emphasizes improving the development process to prevent
defects from occurring.
Total Quality Management (TQM): Aims at continuous process improvement,
optimizing processes for higher efficiency and quality.
Product Metrics vs. Process Metrics
Product Metrics: Measure characteristics of the software product, such as size,
effort, or time. Examples include LOC, Function Points, Person-Months, and
Development Time. Product metrics → what was built
Process Metrics: Measure the performance of the development process.
Examples include review effectiveness, defects per hour, defect correction time,
productivity, and failures per LOC. Process metrics → how it was built
ISO 9000
ISO 9000, introduced by the International Standards Organization (ISO) in 1987,
provides a set of quality management standards to ensure organizations
follow repeatable, well-defined processes.
It focuses on process quality rather than the product itself.
ISO 9000 Certification:
• Serves as a reference for contracts, showing adherence to quality standards.
• Guarantees well-documented, reliable, and repeatable processes.
• Does not guarantee product quality.
ISO 9000 Series:
• ISO 9001: Design, development, production, servicing – applicable to software
organizations.
• ISO 9002: Production only – steel, car manufacturing.
• ISO 9003: Installation and testing – product testing/installation firms.
For Software Industry:
• Generic standard; difficult to interpret due to software intangibility and
lack of raw materials.
• ISO 9000-3 (1991) provides software-specific guidance.
Benefits of Certification:
• Increases customer confidence, especially for exports.
• Ensures documented and repeatable processes. Improves efficiency, cost-
effectiveness Identifies weak areas for improvement.
Certification Process:
1. Application → Apply to registrar.
2. Pre-assessment → Initial evaluation.
3. Document review & adequacy audit → Check documentation.
4. Compliance audit → Ensure adherence.
5. Registration → Certificate awarded.
6. Continued surveillance → Periodic monitoring.
ISO 9001 Key Requirements:
• Management Responsibility (4.1): Quality policy, authority, audits.
 • Quality System (4.2): Maintain documented system.
• Contract Review (4.3): Ensure capability before contracts.
• Design Control (4.4): Manage design inputs, outputs, verification, and
changes.
• Document Control (4.5): Proper approval and management.
• Purchasing (4.6–4.7): Check purchased or client-supplied materials.
• Product Identification (4.8): Maintain configuration management.
• Process Control (4.9): Identify and manage quality requirements.
• Testing & Inspection (4.10–4.12): Maintain test records.
• Corrective Action (4.14): Fix errors and improve process.
• Training (4.18): Identify and meet training needs.
Salient Features:
• Document control via configuration management.
• Planning and monitoring of progress.
• Independent review of documents.
• Testing against specifications.
• Independent quality team reporting to top management.
ISO 9000:2000 Revision:
• Introduced continuous process improvement using metrics.
• Emphasized top management role and measurable objectives.
Shortcomings:
• Process adherence ensured, not process quality.
• Lack of single international accreditation → variations in certification.
• May undervalue individual expertise.
• Does not automatically lead to continuous improvement (TQM needed).
[Link] the difference between Black-box testing and White-box
testing. Discuss when each is used.

Parameter Black Box Testing White Box Testing

Testing without knowledge of internal Testing with full knowledge of

Definition
code or structure. internal code and structure.

To verify logic, code correctness, and

Objective To verify functionality as per requirements.
efficiency.

Equivalence Partitioning, Boundary Control Flow Testing, Data Flow

Methods Used
Value Analysis, Error Guessing. Testing, Statement/Path Coverage.

Knowledg Requires programming and design

No programming knowledge needed.
e Required knowledge.

Functional level testing (System & Structural level testing (Unit, Integration,
Scope
Acceptance levels). System levels).

Implementation Code not required. Code implementation is required.

Performed By Testers or QA team. Developers.

Focus Tests behavior/output of software. Tests internal logic and structure.

Testing Level Functional testing. Structural testing.

Initiation Basis Based on requirements and specifications. Based on design and code details.

Time
Less time-consuming. More time-consuming.
Consumption

Algorithm Testing Not suitable. Suitable for algorithms.

Approach Trial and error, input-output based. Focus on code paths and data domains.

Testing a login page by entering Checking loop conditions or logic

Example
credentials. inside the login function.

Exhaustiveness Less exhaustive. More exhaustive.

[Link] various testing strategies such as unit testing, integration
testing, and system testing.
Unit Testing
• Unit testing is carried out after a module’s coding is complete, all syntax errors
are fixed, and the code has been reviewed.
• It is Performed by Usually the programmer of the module during the coding
phase.
• Before testing, unit test cases are designed, and a suitable test environment is
developed.
Environment for Unit Testing
To test a single module, all relevant code that the module interacts with is required:
1. Procedures from other modules that the module calls.
2. Non-local/global data structures accessed by the module.
3. A procedure to call the module’s functions with appropriate parameters.
Since some of these modules may not be available yet (they themselves may be
untested), stubs and drivers are used to simulate the missing parts.

Stub Modules
• A stub procedure is a dummy function with the same parameters as the real
function but with simplified behavior.
• It Act as placeholders for modules called by the module under test.
Driver Modules
• A driver contains the non-local data structures and the code to call the
module’s functions with appropriate parameters for testing.
• Simulate the part of the program that calls the module under test.
Integration Testing
Integration testing is performed after unit testing to verify that different
modules work together properly.
It focuses on detecting errors at module interfaces (e.g., parameter
mismatches) rather than within individual modules.
Objectives
• Ensure modules interface correctly.
• Detect errors in parameter passing between modules.
• Verify the system behaves as expected when modules are combined.
Integration Plan
• Modules are integrated in a planned manner using an integration plan.
• The module dependency graph/structure chart guides the order of
integration.
• After each integration step, the partially integrated system is tested.
Approaches to Integration Testing
(i) Big-Bang Approach
• All modules are integrated at once and tested.
• Simple but difficult to debug because errors may exist in any module.
• Suitable only for small systems.
(ii) Bottom-Up Approach
• Start by integrating lower-level modules first to form subsystems.
• Use drivers to test higher-level modules.
• Advantages: thorough testing of low-level modules, multiple subsystems
tested simultaneously.
• Disadvantage: complex when many subsystems exist.
(iii) Top-Down Approach
• Start with the top-level module, integrate lower-level modules gradually.
• Use stubs to simulate lower-level modules.
• Advantages: easier to test high-level logic early.
• Disadvantage: difficult to test I/O operations before lower modules are ready.
(iv) Mixed (Sandwiched) Approach
• Combines top-down and bottom-up approaches.
• Testing can start as modules become available.
• Requires both stubs and driver.
Phased vs Incremental Integration

Type Description Advantage

Add one module at a time to partially Easier to locate interface

Incremental
integrated system errors

Add a group of related modules at a Fewer integration steps

Phased
time required

System Testing:
System testing is carried out after all units are integrated to validate the complete
system against its requirements (SRS).
It ensures both functional and non-functional requirements are met.
It is the same for procedural and object-oriented programs.
Types of System Testing
1. Alpha Testing: Conducted by the test team within the developing
organization.
2. Beta Testing: Conducted by select customers.
 3. Acceptance Testing: Conducted by the customer to decide on system delivery.
Difference lies in who carries out the testing, not the test cases.
Pre-System Testing
• Smoke Testing: Quick check to ensure main functionalities work before
full system testing.
Example: For a library system, verify book/member creation, deletion, and
loan/return operations.
System Test Classification
1. Functionality Testing: Checks functional requirements as per SRS.
2. Performance Testing: Checks non-functional requirements
(e.g., speed, reliability).
Types of Performance Testing
• Stress Testing: Evaluates performance under extreme or abnormal loads.
• Volume Testing: Checks data structures under large volumes of data.
• Configuration Testing: Tests system in different hardware/software setups.
• Compatibility Testing: Ensures proper interaction with external systems.
• Regression Testing: Ensures modifications don’t introduce new errors.
• Recovery Testing: Verifies recovery from faults, power loss, or resource failure.
• Maintenance Testing: Checks diagnostic and maintenance tools.
• Documentation Testing: Verifies manuals exist and are accurate.
• Usability Testing: Ensures the user interface meets requirements.
• Security Testing: Protects against unauthorized access and attacks.
Error Seeding
• Error Seeding is the process to Estimate residual errors in software by
Introduce known errors (seeded) and track detection during testing.
 • Formula:
𝑆⋅𝑛
Total defects 𝑁 = ; Residual defects = 𝑁 − 𝑛
𝑠
• Condition: Seeded errors should match actual error types and frequency.
[Link] is Coding and Explain their guidelines and Standards.?
Definition:
Coding is the process of converting the design document into source code using a
high-level programming language.
It aims to implement the design and perform unit testing of each module.
Coding Standards
Coding standards are mandatory rules that every programmer must follow while
writing code.
Representative Coding Standards
Rules for Global Variables:
o Limit the use of global data.
o Clearly specify what data can be declared global.
Standard Module Header Format:
Each module should include:
o Module name
o Date created
o Author’s name
o Modification history
o Synopsis (brief description)
o Functions with input/output parameters
o Global variables used or modified
Naming Conventions:
o Global variables → Start with Capital letter (e.g., GlobalData)
 o Local variables → Start with small letter (e.g., localData)
o Constants → All capitals (e.g., CONSTDATA)
Error Handling Conventions:
o Standardize error return values (e.g., 0 for success, 1 for failure).
o Consistency helps in debugging and reusability.
Advantages:
1. Gives uniform appearance to code.
2. Improves code readability and reusability.
3. Promotes good programming practices.
Coding Guidelines
Coding guidelines are general suggestions to help developers write better
and more maintainable code. They are not mandatory.
Representative Coding Guidelines:
Avoid Overly Clever Coding:
• Code should be simple and easy to understand.
• Cryptic code makes debugging and maintenance difficult.
Avoid Obscure Side Effects:
• Functions should not modify global variables or perform hidden I/O
operations.
• Behavior must be clear from the function’s name and header.
Do Not Use Identifiers for Multiple Purposes:
• Each variable should have a single purpose and descriptive name.
• Using the same variable for multiple purposes causes confusion and errors.
Code Documentation:
• Add at least one comment for every three lines of code.
• Helps in understanding and maintenance.
Function Length:
• Keep each function short (preferably under 10 lines).
• Long functions are harder to debug and understand.
Avoid GO TO Statements:
• GO TO makes code unstructured.

• Use structured programming constructs instead (like loops and conditionals).

[Link] Code Review and their types along with Software Documentation.
A code review is a systematic examination of code to find logical and
programming errors before testing.
Purpose is to detect errors early and ensure the code follows standards.
There are two types of Code Review, they are:
Code Inspection
Code Walkthrough
Code Inspection:
Code inspection is a formal code review technique where the code is carefully
examined to find common programming errors and check whether coding
standards have been followed.
Main Objective:
• To detect common types of programmer mistakes and oversights.
• To ensure adherence to coding standards.
Process:
1. The code is inspected line by line by a review team.
2. Team members look for frequent programming errors using a prepared
checklist.
3. Unlike walkthroughs, inspection does not involve manual execution of code.
4. Feedback is given to the programmer on style, algorithm choice, and coding
techniques.
Benefits:
• Helps find and fix common coding errors early.
• Improves programming style and quality.
 • Reviewers learn from each other’s mistakes.
• Increases maintainability and reliability of code.
Common Errors Checked During Code Inspection:
1. Use of uninitialized variables.
2. Jumps into loops or improper loop control.
3. Non-terminating loops.
4. Incompatible assignments (wrong data types).
5. Array indices out of bounds.
6. Improper memory allocation or deallocation.
7. Mismatch between actual and formal parameters in function calls.
8. Incorrect logical operators or wrong precedence.
9. Improper modification of loop variables.
[Link]-point equality comparison errors.
Code Walkthrough:
Code walkthrough is an informal code analysis technique. In this technique, a
module is reviewed after it has been coded, compiled successfully, and all syntax
errors are removed.
The main objective of a code walkthrough is to discover algorithmic and
logical errors not the Syntax error in the code before testing.
Process:
1. The code is distributed to a few members of the development team a few days
before the walkthrough meeting.
2. Each member selects some test cases and simulates the code execution
manually (mentally traces through the code).
3. The aim is to check whether the code logic works correctly.
4. During the walkthrough meeting, all members discuss the errors found, in the
presence of the coder of the module.
Guidelines for Effective Walkthrough:
1. The team size should be 3 to 7 members – not too large or too small.
2. Discussion should focus on finding errors, not on fixing them.
3. Managers should not attend the meeting — to promote free discussion and
cooperation among developers.
4. Reviewers should prepare before the meeting by studying the code carefully.
Cleanroom Technique
The Cleanroom Technique is a software development approach pioneered by
IBM. It focuses on preventing defects rather than detecting them through
testing.i.e., It replaces testing with formal verification, walkthroughs, and
inspections to produce highly reliable software.
Main Idea:
• Programmers do not test their code by executing it.
• Only syntax checking using a compiler is allowed.
• Errors are removed through walkthroughs, inspections, and formal
verification instead of execution-based testing.
• The name “Cleanroom” comes from semiconductor manufacturing, where
defects are prevented by maintaining a dust-free environment.
Key Characteristics:
1. No execution-based testing by programmers.
2. Heavy use of formal methods, walkthroughs, and code inspections.
3. Emphasis on error prevention rather than error correction.
4. Produces highly reliable and maintainable software.
5. Relies on mathematical verification of program correctness.
Advantages:
• Results in more reliable and maintainable code.
• Reduces the number of defects entering later stages.
 • Encourages disciplined development practices.
Disadvantages:
• Time-consuming, as walkthroughs and inspections take effort.
• Testing effort increases since simple errors are hard to catch manually.
• Some runtime errors may escape manual verification.
Software Documentation
Software documentation is the set of written materials created during software
development, including executable files, source code, and supporting documents
such as SRS, design, testing, installation, and user manuals.
Importance of Documentation:
1. Improves understandability of the code.
2. Reduces maintenance time and effort.
3. Helps users understand and operate the software.
4. Solves manpower turnover issues.
5. Helps project managers track progress.
Types of Documentation:
1. Internal Documentation
• Provided within the source code.
• Examples: comments, meaningful variable names, code indentation, modular
structure, use of constants and data types.
• Most useful: Meaningful variable names (more than comments).
• Comments should explain logic, not trivial actions.
2. External Documentation
• Includes supporting documents: SRS, design document, test document, user
manual, installation manual.
• Should be consistent with the code, clear, and up-to-date.
 • Must suit the intended reader’s understanding.
Gunning’s Fog Index
• It was Developed by Robert Gunning (1952).
• To Measure the readability of documents.
• Indicates years of education needed to understand a text.
Formula:
Words
Fog Index = 0.4 × ( + %of words with 3+ syllables)
Sentences
[Link] Testing Concept in Detail.
Software Testing
Testing is the process of executing a program with the intention of finding
defects.
It helps ensure that the software behaves as expected, though it cannot
guarantee that the program is completely error-free.
Importance of Testing:
• Identifies most defects before delivery.
• Improves software quality and reliability.
• Reduces maintenance cost.
• Ensures that the software meets user requirements.
Limitations of Testing:
• It’s impossible to test all inputs (especially for large input domains).
• Testing can show the presence of defects but not their absence.
Software Testing Terminologies
1. Mistake: Human error by the programmer (e.g., forgetting to initialize a
variable).
2. Error / Fault / Bug / Defect: Result of a mistake causing incorrect program
behavior (all are synonyms).
 3. Failure: Program behaves incorrectly during execution (e.g., crash, wrong
output).
4. Test Case: A triplet [Input, State, Expected Result], e.g., [“abc”, edit mode,
“abc displayed”].
5. Test Scenario: Abstract description of what to test without specifying
input/output.
6. Test Script: Program automating execution of test cases.
7. Positive Test Case: Checks expected behavior (e.g., correct login).
8. Negative Test Case: Checks invalid/unexpected behavior (e.g., wrong
password).
9. Test Suite: Collection of all test cases for a program.
[Link]: Ease of testing a program; simpler programs are more testable.
[Link] Mode: Observable type of failure (e.g., crash, wrong result).
[Link] Faults: Different bugs causing the same failure (e.g., divide by zero
or illegal memory access → crash).
Testing Activities
Major activities involved in testing are:
1. Test Suite Design:
o Test cases are carefully designed using various test case design
techniques to detect errors efficiently.
o A well-designed test suite is better than random testing, as random test
cases may miss important errors.
2. Running Test Cases & Checking Results:
o Each test case is executed, and the actual results are compared with
expected results.
o Any mismatch indicates a failure. Failed test cases are noted for
debugging.
[Link] Error:
o After observing failures, the programmer analyzes the symptoms to
locate the specific errors in the code.
 [Link] Correction:
o Once errors are located, the code is modified to correct the mistakes.
o Debugging is often the most time-consuming part of testing.
Why Design Test Cases?
• Using random inputs is ineffective because it may not uncover all errors.
• Example:
• if (x > y) max = x;
• else max = x; // should be max = y
o A carefully chosen test suite can detect this error, whereas a larger
random suite may not.
• Goal: Create a minimal but effective test suite that detects maximum errors
at minimum cost.
Test Case Design Approaches
1. Black-box Testing (Functional Testing):
o Test cases are designed based only on input-output behavior
(functional specification).
o No knowledge of internal code is required.
2. White-box Testing (Structural Testing):
o Test cases are designed using the internal structure of the code.
o Requires thorough understanding of the program logic and code.
• Both approaches are complementary:
o Some bugs are detected only by black-box tests, others only by white-
box tests.
Levels of Testing
1. Unit Testing (Testing in the Small):
o Individual modules/functions are tested immediately after coding.
 o Makes debugging easier.
2. Integration Testing:
o Modules are incrementally integrated and tested together.
3. System Testing (Testing in the Large):
o Entire integrated system is tested for correctness against requirements.
Tests as Bug Filters
• Test suites act as bug filters: each test removes a portion of the existing bugs.
• Using multiple test case design strategies successively reduces the number of
bugs.
• Example: If each of 10 test strategies detects 30% of bugs and initial bugs =
1000:
o Remaining bugs after all strategies = 1000 × (0.7)10 = 28
• Even a well-designed test suite cannot guarantee complete absence of bugs.
Verification vs Validation
• Verification: Checks whether each development phase’s outputs conform to
previous phase
• Validation: Checks whether the final software meets user requirements.
• Verification is about phase containment of errors; validation ensures the right
product is built. Phase Containment Principle: Errors should be detected as
close as possible to where they occur. Detecting errors early reduces cost and
effort than fixing them later.
• Both activities together are called “V & V” activities, and together constitute
error detection techniques.
Q8. Explain the process of debugging, including its common approaches and
guidelines. Also, discuss the role of program analysis tools in software
development.
Definition:
Debugging is the process of locating and fixing errors (bugs) in a program after a
failure is detected. It involves identifying the exact statements causing the error and
correcting them.
Approaches to Debugging:
1. Brute Force Method:
o Insert print statements or use a symbolic debugger with breakpoints
and watchpoints.
o Perform single-stepping to execute one statement at a time.
o Advantage: Simple.
o Disadvantage: Time-consuming and inefficient.
o Example: Printing intermediate values to track where incorrect results
appear.
2. Backtracking:
o Start from the point where the error appears and trace the code
backwards to find its cause.
o Disadvantage: Complex with loops and multiple decision paths.
o Example: Tracing calculations backwards when the final total is
incorrect.
3. Cause Elimination Method:
o Identify all possible causes of the symptom and eliminate them one by
one through testing.
o Uses Software Fault Tree Analysis (SFTA).
o Example: A negative variable value may be caused by initialization
errors, wrong calculations, or bad input.
 4. Program Slicing:
o Focus only on statements that affect a specific variable at a point in the
program.
o Example: Find all statements that modify a variable total to locate the
origin of an incorrect value.
Debugging Guidelines:
• Understand the program design completely.
• Fix the actual error, not just the symptom.
• Perform regression testing to ensure no new errors are introduced.
Program Analysis Tools
Automated tools that help analyze program characteristics such as size, complexity,
coding standard compliance, and testing adequacy.
Types:
1. Static Analysis Tools:
o Analyze source code without executing it.
o Compute metrics like size, cyclomatic complexity, comment percentage,
unused/uninitialized variables.
o Check coding standard compliance.
o Examples: Code walkthrough, code inspection, compilers.
o Limitation: Cannot detect runtime errors (e.g., pointer issues or
dynamic memory).
o Often visualized using Kiviat (Radar) charts.
2. Dynamic Analysis Tools:
o Analyze runtime behavior of the program.
o Instrument code to collect runtime data.
o Measure coverage (statement, branch, path) and identify untested
parts.
 o Suggest redundant or missing test cases.
o Results often visualized with histograms or pie charts.

Q9. Explain the challenges of testing object-oriented programs. Discuss how

object-oriented features impact testing. Describe suitable strategies for unit and
integration testing in OOP, highlighting the role of grey-box testing and UML-based
test design.
• Object-Oriented Programming (OOP) was initially believed to make testing
easier due to features like encapsulation, inheritance, abstraction, and
polymorphism.
• In practice, testing OOP systems is more complex and expensive than testing
procedural programs because these features introduce new types of bugs and
testing challenges.
Suitable Unit for Testing
• In procedural programs, functions are the basic unit of testing.
• In OOP, methods share data within a class, and their behavior depends on the
state of the object.
• Therefore, the object (not the method) is considered the basic unit of testing.
• Unit testing involves testing each object in isolation, followed by cluster
(integration) testing and system testing.
Impact of Object-Oriented Features on Testing
a) Encapsulation
• Hides internal data → improves modularity.
• Problem: Tester cannot directly access internal states.
• Solution: Add “state-reporting methods” to observe internal states.
b) Inheritance
• Promotes code reuse.
 • Problem: Inherited methods may fail in the derived class even if base class is
correct.
• Solution: Retest inherited methods in the context of derived classes.
c) Dynamic Binding
• Method to be called is decided at runtime.
• Problem: Hard to test because all possible bindings must be verified.
• Example: A base class variable pointing to multiple subclasses requires
checking each possible method call.
d) Object States
• Objects exist in different states (e.g., Active, Closed, Issued).
• Methods may behave differently in each state.
• Requirement: Test all states and verify state transitions using state diagrams.
Why Traditional Techniques Are Not Satisfactory
• Procedural testing (e.g., statement coverage) is insufficient.
• OOP features like inheritance and polymorphism need special test cases.
• OOP testing relies on design models (UML diagrams) rather than just code.
• Hence, OOP testing uses a Grey-Box Approach (between white-box and black-
box testing).

Grey-Box Testing Techniques in OOP

• State Model-Based Testing: State coverage, transition coverage, transition
path coverage.
• Use Case-Based Testing: Scenario coverage for main and alternate scenarios.
• Class Diagram-Based Testing: Test derived classes, inherited methods,
associations, and aggregations.
• Sequence Diagram-Based Testing: Method coverage and message path
coverage.
Integration Testing of OOP
• Procedural top-down/bottom-up approaches are unsuitable as class
structures form graphs, not trees.
• Thread-Based Testing: Test all classes collaborating in a single use case.
• Use-Based Testing: Test independent classes first, then integrate classes that
depend on them.
Q10. Discuss the general issues in software testing and Explain the types of
automated testing tools used in software development.

General Issues in Software Testing

Test Documentation
• Purpose: To maintain a record of testing outcomes for each subsystem.
• Test Summary Report includes:
o Total tests executed.
o Number of successful and unsuccessful tests.
o Degree of failure (complete or partial).
Regression Testing
• Definition: Rerunning previously executed test cases after changes or bug
fixes to ensure existing functionalities remain unaffected.
• Scope: Applies to unit, integration, and system testing.
• Key Points:
o Only test cases related to modified code may be rerun if changes are small.
o Resolution testing: Confirms that defects are fixed.
o Regression testing: Ensures no new errors in existing functionality.
• Automation: Helps rerun large test suites efficiently, reducing errors and
monotony.
Test Automation
• Purpose: Reduce time, effort, and human error in testing, especially for large
software systems.
• Benefits:
o Faster execution of numerous test cases.
o Enables sophisticated test-case design techniques.
o Facilitates regression testing after each change.
o Ensures reliable and repeatable results.
Types of Automated Testing Tools
1. Capture and Playback: Records manual input/output and replays it
automatically. Useful for regression [Link]: high maintenance cost
if code changes.
2. Test Scripts: Automated scripts provide inputs and record outputs efficiently.
Requires maintenance when code changes.
3. Random Input Testing: Generates random inputs to try and crash the program.
Cost-effective but limited in checking correctness.
4. Model-Based Testing: Uses program models (structural or behavioral) to
generate tests covering all possible states. Example: state-based models.
[Link] software reliability in detail and explain how statistical testing contributes to
improving and measuring software reliability.
Software Reliability
Software reliability is the probability of a software product working correctly over a
specified period under specified conditions.
Dependence Factors:
• Number of defects: Fewer bugs → higher reliability.
• Location of defects: Errors in core modules affect reliability more than those in
 rarely used modules.
• Usage profile: Reliability is user-dependent; different users may experience
different reliability.
Hardware vs Software Reliability

Aspect Hardware Software

Cause of failure Wear and tear Bugs/errors

Repair effect Restores reliability May increase or decrease reliability

Reliability pattern Bathtub curve High initial failure, decreases as errors are fixed

Reliability Metrics
• ROCOF (Rate of Occurrence of Failure): Failures per unit time.
• MTTF (Mean Time to Failure): Average runtime between failures.
• MTTR (Mean Time to Repair): Average time to fix a failure.
• MTBF (Mean Time Between Failures): MTBF = MTTF + MTTR.
• POFOD (Probability of Failure on Demand): Likelihood of failure per service
request.
• Availability: Probability system is operational at a given time.
Failure Classification
• Transient: Occurs for specific inputs.
• Permanent: Always occurs for certain functions.
• Recoverable: System recovers without restart.
• Unrecoverable: System requires restart.
• Cosmetic: Minor issues with no effect on correctness.
Reliability Growth Models
• Jelinski-Moranda Model (1972):
o Step-function model assuming perfect bug fixes.
o Each fix increases reliability by a constant amount.
o Limitation: Unrealistic, as not all fixes are perfect.
• Littlewood-Verall Model:
o Models imperfect bug fixes and diminishing returns.
o Reliability improvement per fix decreases over time.
• Goel-Okutomo Model:
o Assumes time between failures follows an exponential distribution.
o Uses Non-Homogeneous Poisson Process (NHPP).
o Cumulative failures:
𝑚(𝑡) = 𝑁(1 − 𝑒 −𝑏𝑡 )

where N = total defects, b = rate of reliability improvement.

Statistical Testing
Definition:
Statistical testing aims to measure software reliability rather than detect errors.
Operation Profile:
• Defines how different users use various functions.
• Each functionality 𝑓𝑖 is assigned a probability 𝑝𝑖 indicating usage frequency.
• Example: In library software, a librarian adds/deletes books; a member searches or
issues books.
Steps in Statistical Testing:
1. Determine the operation profile.
2. Generate test data according to the profile.
3. Execute tests and record time between failures.
4. Compute reliability after sufficient failures are observed.
Assumptions:
• Large number of statistically significant test cases.
• Rare/unlikely inputs must be included.
Advantages:
• Focuses on frequently used parts of the system.
• Provides realistic reliability estimates for end-users.
Limitations:
• Difficult to define accurate operation profiles.
• Requires large, varied test data.
• Rare failure-causing inputs are hard to generate automatically.
[Link] the concept of software quality. Discuss the main software quality
attributes and compare at least three software quality models.
Software Quality
Software quality goes beyond functional correctness. It measures how well software
meets user requirements and other attributes like usability, maintainability,
readability, and adaptability.
Main Software Quality Attributes:

Attribute Meaning

Portability Easy to use in different hardware/OS environments

Usability Easy for all types of users to operate

Reusability Modules can be reused in other systems

Correctness Requirements implemented correctly

Maintainability Easy to fix bugs, modify, or add new functions

Software Quality Models

Quality models provide a structured framework to measure software quality via
attributes and sub-attributes.
Garvin’s Quality Dimensions
• Harvard Business School model defining 8 general product quality attributes:
1. Performance: How well it performs tasks
2. Features: Presence of required features
3. Reliability: Probability of correct operation
4. Conformance: Degree of meeting requirements
5. Durability: Expected product life
6. Serviceability: Ease and speed of maintenance
7. Aesthetics: Look and feel
8. Perceived Quality: User’s opinion
McCall’s Quality Model
• Divides software quality into three categories:
1. Product Operation: Performance during use — Correctness, Reliability,
Efficiency, Integrity, Usability
2. Product Revision: Ease of changes — Maintainability, Flexibility, Testability
3. Product Transition: Adaptability to new environments — Portability,
Reusability, Interoperability
Dromey’s Quality Model
• Focuses on hierarchical evaluation:
o High-level properties: Correctness, Internal characteristics, Contextual
characteristics, Descriptive properties
o Each property depends on measurable low-level attributes
• Advantage: Provides structured evaluation linking measurable attributes to overall
quality
Boehm’s Quality Model
• Defines software quality with three high-level characteristics:
1. As-is Utility: Ease, reliability, and efficiency in use
2. Maintainability: Ease of understanding, modifying, and retesting
3. Portability: Ease of adapting to new environments
• Emphasizes practical usability and maintainability
ISO 9126 Quality Model
• International standard defining 6 main quality characteristics:

Characteristic Meaning

Functionality Correctness of implemented functions

Reliability Maintain performance under conditions

Usability Effort required to use the software

Efficiency Resource usage (CPU, memory, etc.)

Maintainability Effort to make changes

Portability Effort to move to other environments

• Focuses purely on product quality, not the process.

[Link] the SEI Capability Maturity Model (CMM) in detail and its comparison
with ISO 9000.
The SEI Capability Maturity Model (CMM) was developed by the Software Engineering
Institute (SEI), Carnegie Mellon University, USA. It is based on Philip Crosby’s five-stage
quality maturity grid.
• Purpose:
o Assess an organization’s software process maturity.
o Predict likely outcomes of future projects.
• Uses:
Capability Evaluation: By clients or contracting authorities to assess vendor
performance.
Software Process Assessment: By organizations themselves to improve internal
processes.
Five Maturity Levels of CMM
Level 1 – Initial: No defined processes; success depends on individual effort.
Level 2 – Repeatable: Basic project management and configuration control; processes
can be repeated.
Level 3 – Defined: All processes are documented and standardized; training and
peer reviews implemented.
Level 4 – Managed: Quantitative process and product metrics are collected; project
performance is measured statistically.
Level 5 – Optimising: Focus on continuous improvement, process refinement, and
innovation across the organization.
Key Process Areas (KPAs)

Level Key Process Areas

2 (Repeatable) Software Project Planning, Configuration Management

3 (Defined) Process Definition, Training Programs, Peer Reviews

4 (Managed) Quantitative Process Metrics, Software Quality Management

Defect Prevention, Process Change Management, Technology Change

5 (Optimising)
Management

Advantages of SEI CMM

• Structured framework for gradual process improvement.
• Helps identify and address weak areas systematically.
• Leads to better quality, predictable schedules, and cost control.
Shortcomings:
• Guidance gap: Explains what to improve, not how.
• Over-documentation may conflict with Agile principles.
• Measurement issue: Focuses on activities rather than effectiveness of outcomes.
Comparison with ISO 9000

Aspect ISO 9000 SEI CMM

Developer International Standards Organization

SEI, Carnegie Mellon

Applicability Generic, all industries Specifically software industry

Purpose Certification of process quality Framework for process improvement

Nature Pass/Fail 5 maturity levels (gradual improvement)

Recognition Internationally certifiable Primarily internal appraisal

TQM Relation Equivalent to CMM Level 3 Leads beyond Level 3 towards TQM
Applicability to Small Organizations:
• Full CMM may be too heavy.
• Focus on project management, configuration control, reviews, documentation,
and gradual process improvement at lower levels.
[Link] CMMI, SPICE, PSP, and Six Sigma and their roles in improving software
quality and process maturity.
CMMI (Capability Maturity Model Integration)
• Successor to SEI CMM.
• Integrates multiple models (Software CMM, SE-CMM, PCMM, SA-CMM) into a
single framework.
• Applicable across multiple domains, not just software.
• Retains the five maturity levels of the original CMM.
Other Models
Although ISO 9001 and SEI CMMI are the most widely used, other standards like SPICE and
PSP also play an important role in software quality improvement.
SPICE (Software Process Improvement and Capability Determination)
Standard: ISO/IEC 15504
Purpose:
To assess and improve the capability and maturity of software development processes
within an organization.
Key Features:
• It is an ISO standard integrating multiple process models into a unified framework.
• Covers various process types:
o Engineering processes
o Management processes
 o Customer–supplier processes
o Support processes
• Defines six capability maturity levels, similar to SEI CMM.
• Provides:
o Process Reference Model (PRM) – describes best practices.
o Process Assessment Model (PAM) – used to evaluate process capability.
Objective:
To guide organizations in evaluating and improving software development and
management processes.
PSP (Personal Software Process)
Developed by: Watts S. Humphrey (SEI, 1997)
Purpose:
To help individual software engineers measure, manage, and improve their own
development process — a personal version of CMM.
Key Principles:
• Time Measurement: Track time spent on each activity (design, coding, testing)
to improve estimation accuracy.
• Personal Planning: Estimate effort, size (LOC), and schedule before starting a
project; compare planned vs. actual data.
• Continuous Improvement: After each project, review results (postmortem) and
refine the process for better quality and efficiency.
PSP Levels:

Level Focus / Activities

PSP0 Basic process with time and defect logging

PSP0.1 Adds coding standards and size measurement

PSP1 Adds project planning and estimation

PSP1.1 Improves planning using historical data

PSP2 Introduces defect management with code/design reviews

PSP2.1 Enhances quality through defect prevention

PSP3 Focuses on iterative development and optimization

SPICE vs PSP – Comparison

Aspect SPICE (ISO 15504) PSP (Humphrey)

Scope Organization-level Individual-level

Improve organizational process Improve personal productivity and

Purpose
capability quality

Structure 6 capability levels 6 PSP levels (0 → 3)

Emphasis Process capability & assessment Personal discipline & measurement

Standard TypeISO standard SEI framework (non-ISO)

[Link] Six sigma,its Roles and Methodologies

Six-Sigma
Origin and Purpose:
Six Sigma was introduced by Motorola in the 1980s and later popularized by General
Electric (GE) in 1995. Its primary goal is to improve processes to achieve better quality,
faster performance, and lower costs.
Meaning:
Six Sigma is a data-driven and disciplined approach for process improvement and defect
elimination. It aims for near perfection, allowing no more than 3.4 defects per million
opportunities (DPMO). A defect is any result that does not meet customer expectations or
specifications. The objective is to achieve process improvement and reduce variation
through measurement-based and statistical methods.
Six Sigma Methodologies:
1. DMAIC (for existing processes)
o Define: Identify the problem and customer requirements; understand
project goals.
o Measure: Collect current process data to quantify performance.
o Analyze: Determine root causes of defects and identify sources of
variation.
o Improve: Implement solutions to eliminate root causes.
o Control: Monitor the process to sustain improvements.
2. DMADV (for new or redesigned processes)
o Define: Establish project goals and customer needs.
o Measure: Identify critical quality characteristics and key metrics.
o Analyze: Develop design alternatives and optimize options.
o Design: Create a detailed design and build the new process.
o Verify: Test and validate the design to ensure customer satisfaction.
Six Sigma Roles:
• Green Belt: Works part-time on Six Sigma projects.
• Black Belt: Leads project teams and mentors members.
• Master Black Belt: Oversees multiple projects and provides expert guidance.