Software Testing

Definition:​
Software testing is the process of evaluating a program to ensure that it:

1.​ Performs as intended​

2.​ Does not contain defects before it is released for use​

Goals of Testing
1. Validation

●​ To demonstrate that the software meets its requirements​

●​ Ensures the system behaves as expected by developers and customers​

2. Defect Detection

●​ To discover situations where the software:

●​ The aim of verification is to check that the software meets its stated functional and
non-functional requirements.
●​
○​ Behaves incorrectly​

○​ Produces undesirable results​

○​ Does not conform to its specification​

●​ Helps improve software reliability and quality before deployment​

Software inspection is a manual review process where developers (or a team) carefully
examine code, design documents, or requirements to find errors without running the program.

Think of it like proofreading an essay before submitting it—mistakes are caught just by reading
and analyzing, not by “executing” anything.

🔍 Key idea
●​ Inspection = checking by reading
●​ Testing = checking by running

✅ Advantages of software inspection over testing

1.​ Errors don’t hide each other
○​ In testing, one bug can mask another (like one wrong output hiding deeper
issues).
○​ In inspection, each line is checked independently, so more defects can be found.
2.​ Works even on incomplete systems
○​ Testing needs a runnable program.
○​ Inspection can be done early (design stage, partial code), saving time and cost.
3.​ Covers overall quality, not just bugs
○​ Inspection also checks:
■​ Coding standards
■​ Portability
■​ Maintainability
○​ Testing mainly checks if the program works correctly.
4.​ More effective for finding defects
○​ Many logical and structural errors are easier to spot by reading than by running.

⚠️ Limitations of inspection
●​ Cannot replace testing
●​ Not good for detecting:
○​ Interaction issues between modules
○​ Timing-related problems
○​ Performance issues (speed, memory usage)
Software Testing Process
•​ Manual
•​ Automatic
•​ In practice, the testing process usually involves a mixture of manual and auto mated
testing.
Testing phases

[Link] Testing
Definition:​
Development testing is the testing performed during the software development process to
identify bugs and defects early.

Main Purpose
●​ Detect errors as early as possible
●​ Improve code quality before system release
●​ Reduce cost of fixing defects later

(Fixing a mistake early is much easier and cheaper than fixing it after release.)

Who Performs Development Testing?

1. System Designers and Programmers

●​ Developers test their own code

●​ Unit testing and integration testing are common

2. Programmer/Tester Pairs

●​ One writes code

●​ The other tests simultaneously
●​ Helps catch mistakes quickly

3. Separate Testing Group (for Critical Systems)

●​ In safety-critical systems (e.g., medical, aviation, banking),​

a dedicated testing team inside the development team may perform testing
 ●​ Ensures higher reliability and independence

Key Characteristics
●​ Happens during development, not after completion
●​ Focuses on finding technical defects
●​ Includes unit testing, integration testing, and component testing

Here is a clear and structured explanation of Unit Testing:

[Link] Testing
Definition
Unit testing is the process of testing individual program units, such as:

●​ Functions
●​ Methods
●​ Classes
●​ Modules

The goal is to ensure each unit works correctly in isolation.

Focus of Unit Testing

Unit testing mainly checks the functionality of objects or methods.

When testing object classes, tests should:

 1.​ Test all operations associated with the object
○​ Every method or function must be tested
2.​ Set and check all attributes
○​ Assign values to object variables
○​ Verify correct behavior after changes
3.​ Test all possible states
○​ If an object can be in different states (e.g., active, inactive, empty, full),​
test behavior in each state

Why Careful Test Case Selection is Important

●​ Testing is expensive and time-consuming
●​ Poor test selection wastes time
●​ Good test cases increase defect detection efficiency

So, effective strategies are needed.

Strategies for Choosing Unit Test Cases

1. Partition Testing
Concept:

Inputs are divided into groups (partitions) that behave similarly.

Instead of testing every possible input:

●​ Select one or a few test cases from each group

Example:

If a function accepts numbers from 1 to 100:

●​ Valid inputs (1–100) → choose some representative values

●​ Invalid inputs (<1) → test one case
●​ Invalid inputs (>100) → test one case

This reduces effort but still gives good coverage.

2. Guideline-Based Testing
Concept:

Test cases are chosen using experience-based guidelines.

These guidelines are based on:

●​ Common programming mistakes

●​ Past defect patterns

Examples:

●​ Test boundary values (0, max, min)

●​ Test empty input
●​ Test null values
●​ Test incorrect data types

This approach uses past experience to predict likely errors.

Here is a clear explanation of Component Testing:

[Link] Testing
Definition
Component testing happens when individual units (modules/classes) are combined
(integrated) to form a larger component or subsystem.

Example:​
If components A, B, and C are integrated together, they form a bigger subsystem. Testing now
focuses on how they work together, not individually.

Main Focus of Component Testing

The main focus is on component interfaces.

An interface is the connection point where:

●​ Data is passed
●​ Functions are called
●​ Modules communicate
Most integration problems happen at these interfaces.

Common Problems During Integration

When components are put together, several issues may occur:

1. Data Loss Across Interface

●​ Data passed from one module to another may be:

○​ Missing
○​ Incorrectly formatted
○​ Truncated

2. One Module Adversely Affects Another

●​ A change in one module may:

○​ Break another module
○​ Overwrite shared memory
○​ Cause unexpected behavior

3. Combined Sub-functions May Fail

●​ Individually working functions may not produce the correct overall result when combined
●​ Example:
○​ A calculates correctly
○​ B processes correctly
○​ But together they produce wrong output

4. Error Magnification

●​ Small acceptable errors in each module

●​ When combined, errors accumulate and become unacceptable
5. Problems with Global Data Structures

●​ Shared/global variables may:

○​ Be modified unexpectedly
○​ Create side effects
○​ Cause inconsistent system state

[Link] Testing
Definition
System testing is the process of testing the complete and integrated system to ensure that:

●​ All components are compatible

●​ Components interact correctly
●​ Data is transferred properly
●​ Timing and coordination are correct across interfaces

It checks the behavior of the entire system as a whole.

Relationship with Component Testing

System testing overlaps with component testing because both involve integration.

However, there are two important differences:

1. Integration of Different Types of Components

During system testing:

●​ Newly developed components

●​ Reusable components
●​ Off-the-shelf (commercial) systems

are integrated together and tested as a complete system.

This makes system testing more complex than component testing.

2. Collective Testing Process
●​ Components may be developed by different teams or groups
●​ Integration happens at a larger scale
●​ Testing becomes a collective effort, not just individual testing

System testing ensures that independently developed parts work properly when combined.

Main Focus Areas

System testing checks:

●​ Interface compatibility
●​ Correct interaction between subsystems
●​ Data flow correctness
●​ Timing and synchronization
●​ Overall system functionality

Here is a clear and structured explanation of Release Testing and Requirements-Based

Testing:

[Link] Testing
Definition
Release testing is the process of testing a specific version (release) of a system that is intended
for use outside the development team.

It is performed just before the system is delivered to customers.

Differences Between System Testing and Release Testing
1. Independent Testing Team

●​ Release testing is conducted by a separate team

●​ The team has not been involved in development
●​ This ensures objectivity and unbiased evaluation

2. Different Objective

●​ The goal is validation, not just defect detection

●​ It checks whether:
○​ The system meets its requirements
○​ The system is good enough for external use

Requirements-Based Testing
Concept
A good requirement should be testable.

Requirements-based testing is a structured approach where:

●​ Each requirement is taken one by one

●​ Test cases are designed specifically to verify that requirement

Process
1.​ Identify a requirement
2.​ Design test cases to verify it
3.​ Execute tests
4.​ Confirm whether the requirement is satisfied

Here is a clear explanation of Scenario Testing:

Scenario Testing
Definition
Scenario testing is a release testing approach where realistic usage situations (scenarios) are
created and test cases are developed based on them.

What is a Scenario?
A scenario is:

●​ A story describing how the system may be used

●​ Based on real-world situations
●​ Related to actual user behavior

It explains:

●​ Who is using the system

●​ What they want to do
●​ How they interact with the system
●​ What outcome is expected

Key Characteristics of Good Scenarios

●​ Realistic
●​ Practical
●​ Easy for real users to relate to
●​ Based on actual use cases

Purpose of Scenario Testing

●​ Validate that the system works in real-life situations
●​ Ensure user requirements are satisfied
●​ Check complete workflows rather than individual functions
Example
For an online shopping system:

Scenario:​
A customer logs in, searches for a product, adds it to the cart, makes payment, and receives
confirmation.

Testing will verify:

●​ Login works
●​ Search works
●​ Cart updates correctly
●​ Payment is processed
●​ Confirmation is generated

Here is a clear explanation of Emergent Property Testing and Performance Testing:

Emergent Properties in System Testing

Definition
Emergent properties are system characteristics that appear only after all components are
integrated.

They cannot be tested properly at:

●​ Unit level
●​ Individual component level

They become visible only when the complete system works together.

Examples of Emergent Properties

●​ Performance
●​ Reliability
●​ Security
 ●​ Scalability

Performance Testing
Purpose
Performance testing ensures that the system:

●​ Handles its expected workload

●​ Responds within acceptable time limits
●​ Maintains stability under stress

How Performance Testing is Done

Performance tests are designed to:

1.​ Simulate normal system load

2.​ Gradually increase the load
3.​ Monitor system behavior
4.​ Continue increasing until performance becomes unacceptable

Unacceptable performance may include:

●​ Slow response time

●​ System crashes
●​ Resource exhaustion
●​ Timeout errors

Types of Performance Testing

●​ Load Testing: Test system under expected load
●​ Stress Testing: Push system beyond normal limits
●​ Volume Testing: Test with large amounts of data
●​ Endurance Testing: Test performance over long periods
Here is a clear explanation of User Testing, including Alpha, Beta, and Acceptance Testing:

[Link] Testing
Definition
User testing involves users or customers providing input and advice during system testing.

It ensures the system works properly from the user’s perspective, not just the developer’s
perspective.

Types of User Testing

1. Alpha Testing
●​ Conducted at the developer’s site
●​ Real users work closely with the development team
●​ Users test the software in a controlled environment
●​ Developers are present to observe and fix issues quickly

Purpose:​
Identify problems before releasing the software externally.

2. Beta Testing
●​ A release version of the software is given to selected users
●​ Testing occurs in a real-world environment
●​ Users experiment with the system
●​ They report bugs and usability issues to developers

Purpose:​
Discover problems that only appear in actual usage conditions.
3. Acceptance Testing
●​ Performed after release testing
●​ Common in custom system development
●​ The customer formally tests the system

Main Goal:

To decide whether the system should be accepted or rejected

Acceptance means:

●​ The system meets agreed requirements

●​ Payment should be made to the developer

Six Stages of Acceptance Testing

1.​ Define Acceptance Criteria
○​ Clearly state what conditions must be satisfied
2.​ Plan Acceptance Testing
○​ Decide schedule, responsibilities, and test environment
3.​ Derive Acceptance Tests
○​ Create test cases based on requirements
4.​ Run Acceptance Tests
○​ Execute the test cases
5.​ Negotiate Test Results
○​ Discuss issues found
○​ Decide required corrections
6.​ Reject or Accept the System
○​ If requirements are satisfied → Accept
○​ If not → Reject or request modifications
Here is a clear and structured explanation of Test Case Development Strategies:

Test Case Development Strategies

Test case development strategies help in selecting effective test cases to detect maximum
defects with minimum effort.

1. Boundary Value Analysis (BVA)

Concept
Errors often occur at the boundaries of input ranges.

Instead of testing only normal values, focus on:

●​ Minimum value
●​ Maximum value
●​ Just below minimum
●​ Just above maximum

Example
If valid input range is 1 to 100, test:

●​ 0 (below minimum)
●​ 1 (minimum)
●​ 2 (just above minimum)
●​ 99 (just below maximum)
●​ 100 (maximum)
●​ 101 (above maximum)

Why Important?
Programmers often make mistakes in:

●​ ≥ instead of >
 ●​ ≤ instead of <

2. Equivalence Partitioning
Equivalence Partitioning is a black-box testing technique where the input data is divided
into groups (called equivalence classes), and testing is done using one value from each group
instead of testing every possible input.

👉 Idea: If one value in a group works (or fails), all values in that group are expected to behave
the same.

🧠 Simple understanding
Instead of testing 100 similar inputs, pick just 1 representative from that group.

Example:​
If valid age is 18–60

●​ Testing 25 is enough to represent all valid ages

●​ No need to test 26, 27, 28… separately

📌 Types of Equivalence Classes

There are two main types:

●​ Valid class → acceptable inputs

●​ Invalid class → unacceptable inputs

📊 Guidelines for defining equivalence classes

1.​ Range Input Condition
○​ Example: 1 ≤ x ≤ 100
○​ Classes:
■​ Valid: 1–100
■​ Invalid: x < 1
■​ Invalid: x > 100
 2.​ Specific Value Condition
○​ Example: x = 10
○​ Classes:
■​ Valid: x = 10
■​ Invalid: x < 10
■​ Invalid: x > 10

3.​ Set of Values Condition

○​ Example: Input must be {Red, Blue, Green}
○​ Classes:
■​ Valid: any of these values
■​ Invalid: anything outside the set

4.​ Boolean Condition

○​ Example: True/False input
○​ Classes:
■​ Valid: True
■​ Invalid: False (or vice versa depending on requirement)

✅ Why use equivalence partitioning?

●​ Reduces number of test cases
●​ Saves time and effort
●​ Still provides good coverage

🧾 Short exam definition

Equivalence partitioning is a black-box testing technique that divides input data into valid and
invalid classes, where test cases are derived by selecting representative values from each
class.

If helpful, boundary value analysis (which is often asked together with this) can also be
explained next.
3. Basis Path Testing
These steps describe Basis Path Testing, a white-box testing technique that ensures every
independent path in a program is tested at least once.

📌 Steps to derive the basis set (explained simply)

1.​ Draw a flow graph
○​ Convert the program logic into a diagram.
○​ Nodes → statements or blocks

👉
○​ Edges → flow of control (like arrows showing execution)
2.​ Think of it like a map of how the program flows.

2.​ Calculate cyclomatic complexity

○​ This tells how many independent paths exist.
○​ Formula:
3.​ V(G)=E-N+2P​
Where:
○​ E = number of edges
○​ N = number of nodes

👉
○​ P = number of connected components (usually 1)
4.​ This value = number of test paths needed

3.​ Identify independent paths

○​ A path is independent if it introduces at least one new edge not used before.

👉
○​ Total independent paths = cyclomatic complexity
4.​ These paths form the basis set

4.​ Design test cases

○​ Create test inputs that force the program to follow each independent path.
○​ Each path must be executed at least once.
🧠 Simple analogy
●​ Flow graph → road map
●​ Cyclomatic complexity → number of unique routes
●​ Independent paths → different routes to reach destination
●​ Test cases → vehicles that travel each route

✅ Key point
●​ Ensures complete logical coverage
●​ Helps find logical errors in code structure

🧾 Short exam answer

Basis path testing is a white-box testing technique in which a flow graph is constructed,
cyclomatic complexity is calculated, independent paths are identified, and test cases are
designed to execute each path at least once.

If needed, a solved example (with flow graph and paths) can be shown step-by-step.

4. Control Structure Testing

This focuses on testing different control structures in code.

Includes:

a) Condition Testing

●​ Test logical conditions (true/false cases)

b) Loop Testing

●​ Test loops with:

○​ Zero iterations
○​ One iteration
○​ Typical iterations
○​ Maximum iterations

c) Data Flow Testing

●​ Track variable definitions and usage

●​ Ensure variables are properly initialized and used
Here is a clear and structured explanation of Software Evolution Processes:

Software Evolution Process

Definition
Software evolution refers to the process of modifying and updating software after it has
been delivered and put into use.

Software must evolve because:

●​ User requirements change

●​ Business rules change
●​ Technology changes
●​ Bugs are discovered
Variation in Evolution Processes
Software evolution processes are not the same everywhere. They vary depending on:

1. Type of Software

●​ Small applications may have simple update processes

●​ Large or safety-critical systems require strict change control

2. Development Processes Used

●​ Organizations using Agile may evolve software continuously

●​ Organizations using plan-driven models may follow structured change procedures

3. Skills of the People Involved

●​ Experienced teams may manage changes efficiently

●​ Less experienced teams may require more documentation and supervision

Informal Evolution Process

In some organizations:

●​ Change requests come through conversations

●​ Users directly communicate with developers
●​ Minimal documentation is created
●​ Changes are implemented quickly

This approach is flexible but may lack control.

Formal Evolution Process

In other organizations:

●​ Change requests are formally submitted

●​ Impact analysis is conducted
●​ Structured documentation is created
●​ Approval is required before implementation
●​ Testing and validation follow strict procedures

This approach provides:

●​ Better traceability
●​ Risk control
●​ Clear accountability

This is about software evolution—how a system is continuously updated after it is delivered.

🧾 What is Software Evolution?

Software evolution is the process of modifying and updating software over time to fix bugs,
improve features, or adapt to new requirements.

👉 Software is never “finished”; it keeps changing throughout its life.

🔄 Key Ideas Explained Simply

1. Evolution process varies

●​ Depends on:
○​ Type of software (simple app vs large system)
○​ Organization’s development process
○​ Skills of developers

👉 Some teams are very structured, others are more flexible.

2. Informal vs Formal process

●​ Informal process
 ○​ Changes come through discussions or direct communication
○​ Less documentation
○​ Faster but less controlled
●​ Formal process
○​ Structured steps and proper documentation
○​ Change requests are recorded and analyzed
○​ More reliable for large systems

3. Change proposals = main driver

All evolution starts from change proposals.

Sources include:

●​ Unimplemented requirements
●​ New feature requests
●​ Bug reports from users
●​ Improvement ideas from developers

👉 These are like “requests for change.”

4. Evolution is cyclic 🔄
●​ Identify change
●​ Analyze it
●​ Implement it
●​ Update system

👉 This repeats throughout the system’s lifetime.

5. Linking changes to components

●​ Each change proposal must be connected to:

○​ Specific modules/components in the system

👉 This helps to:

●​ Estimate cost
●​ Understand impact
●​ Avoid unexpected problems
6. Role of change management

This whole process is part of change management, which ensures:

●​ Changes are controlled

●​ Risks are minimized
●​ System remains stable

1. Change Requests
This is the starting point of the cycle. Requests for changes can come from various
stakeholders, including end-users, developers, or management. These requests typically fall
into categories like:

●​ Reporting a bug.
●​ Requesting a new feature.
●​ Adapting to a new business requirement.

2. Impact Analysis
Once a request is received, the team evaluates the consequences of making that change. They
ask:

●​ How much will this cost?

●​ What other parts of the system will break if we change this?
●​ Is the change technically feasible?
●​ A decision is then made to either accept, reject, or postpone the request.

3. Release Planning
If the change is approved, it is slotted into a specific software release. This stage involves
deciding which changes are high priority and can be grouped together. As shown in the
diagram, this stage branches into three primary types of maintenance:

●​ Fault Repair: Fixing discovered bugs or vulnerabilities.

●​ Platform Adaptation: Updating the software to work on new operating systems,
browsers, or hardware.
●​ System Enhancement: Adding new functionality or improving performance to increase
the value for the user.

4. Change Implementation
This is the "work" phase. Developers write the code, modify the system architecture, and update
documentation. It is essentially a mini-development cycle where the proposed changes are
actually built and integrated into the existing codebase.

5. System Release
The modified software is packaged and deployed to the users. This stage includes final testing
and quality assurance to ensure the new changes haven't introduced "regressions" (new bugs).

The Feedback Loop

The arrows pointing back from System Release and Change Implementation to Change
Requests and Release Planning indicate that this is a continuous, iterative cycle. As soon as a
new version is released, users will inevitably find new bugs or think of new features, starting the
whole process over again.

Software maintenance

software maintenance is the process of modifying and updating software after it has been
delivered to fix errors, improve performance, or adapt it to a changing environment.

Here is a more in-depth explanation of software maintenance, especially the four types,
with clearer understanding and examples.

🧾 Software Maintenance (In-depth)

Software maintenance is not just “fixing bugs”—it is a continuous engineering activity that
ensures software remains useful, efficient, and reliable over time.

After deployment, most of the cost of a software system (often 60–80% of total cost) goes into
maintenance.

🔧 Types of Software Maintenance

(Detailed)
1. Corrective Maintenance
👉 Goal: Fix errors that already exist
🔍 What it involves:
 ●​ Debugging code
●​ Fixing logical mistakes
●​ Resolving user-reported issues

📌 Example:
●​ Login system crashes when wrong password is entered
●​ Calculation gives incorrect result

👉 This is reactive (done after problem occurs)

2. Adaptive Maintenance
👉 Goal: Make software work in a new or changed environment
🔍 What it involves:
●​ Updating for new OS or hardware
●​ Supporting new browsers/devices
●​ Adjusting to new regulations or policies

📌 Example:
●​ Updating software to run on a new version of Windows
●​ Modifying system due to new tax rules

👉 This is environment-driven change

3. Perfective Maintenance
👉 Goal: Improve system performance or add enhancements
🔍 What it involves:
●​ Adding new features
●​ Improving UI/UX
●​ Optimizing speed and efficiency

📌 Example:
 ●​ Adding dark mode to an app
●​ Making a website load faster

👉 This is user-driven improvement

4. Preventive Maintenance
👉 Goal: Reduce future risks and improve maintainability
🔍 What it involves:
●​ Refactoring code (cleaning structure)
●​ Improving documentation
●​ Removing unused or complex code

📌 Example:
●​ Rewriting messy code to make it easier to understand
●​ Adding comments and proper structure

👉 This is proactive (done before problems occur)

🔄 Maintenance Process (Conceptual

Flow)
1.​ Change request received
2.​ Impact analysis
3.​ Design modification
4.​ Code update
5.​ Testing
6.​ Release

👉 This cycle repeats continuously.

⚠️ Challenges in Software Maintenance
●​ Poor documentation
●​ Complex/old code (legacy systems)
●​ Lack of original developers
●​ Risk of introducing new bugs

This topic is about legacy systems and software reengineering—a very common exam
concept. Here’s a clear and structured explanation.

🧾 Legacy Systems (Problem)

Legacy systems are old software systems that are still in use but are hard to understand and
modify.

❗ Why are legacy systems difficult?

1.​ Optimized for performance, not readability
○​ Code may be fast but very hard to understand
2.​ Structure gets damaged over time
○​ Continuous changes (patches, fixes) make the design messy
3.​ Poor or outdated documentation
○​ Hard to know how the system actually works
4.​ Old technologies
○​ Written in outdated programming languages

🔧 Solution: Software Reengineering

Software reengineering is the process of improving the internal structure of existing
software without changing its functionality.
👉 Important:​
✔ Functionality stays the same​
✔ Only structure and quality improve

🔄 What reengineering may include

1.​ Redocumentation
○​ Creating or updating system documentation
2.​ Refactoring architecture
○​ Improving overall system design
3.​ Code translation
○​ Converting old language → modern language
4.​ Data restructuring
○​ Improving database structure or data formats

⚠️ Key rule
●​ Avoid major changes to system architecture
●​ Focus on improving maintainability and clarity

✅ Benefits of Reengineering (vs

Replacement)
1. Reduced Risk

●​ Rebuilding software from scratch is risky

●​ Business-critical systems may fail if redeveloped

👉 Reengineering keeps existing working system intact

2. Reduced Cost

●​ Cheaper than developing a new system

 ●​ Saves time and resources

🧩 Reengineering Activities (Detailed)

1. Reverse Engineering
👉 Understanding the system by analyzing it
●​ Study code, design, and behavior
●​ No changes are made

📌 Like reading someone else’s notes to understand them

2. Code Restructuring
👉 Improving code organization
●​ Remove unnecessary complexity
●​ Improve readability

📌 Same logic, cleaner code

3. Refactoring
👉 Step-by-step improvement of internal code design
●​ Rename variables
●​ Simplify functions
●​ Break large code into smaller parts

📌 Behavior remains unchanged

4. Data Restructuring
👉 Improving data organization
●​ Normalize databases
●​ Update data formats

📌 Makes system more efficient and maintainable

5. Documentation Improvement
👉 Creating clear system documentation
●​ Helps future developers understand the system
●​ Reduces maintenance difficulty

Software change
Software change → a single modification made to the system

Software maintenance → the overall process of managing and applying many changes over
time

1. Change Identification Process

This is the "discovery" phase. It is triggered by the environment, the market, or the users.

●​ What happens: Stakeholders identify gaps between what the current system does and
what it should do.
●​ Inputs: User complaints, competitor feature launches, new security threats, or changes
in government regulations (like tax law updates).

2. Change Proposals
Once a need is identified, it must be formalized. You don't just start coding; you propose a
solution.

●​ What happens: This involves documenting exactly what needs to change. It links back
to the Impact Analysis we discussed earlier.
●​ Outcome: A formal document or "ticket" that outlines the cost, the benefit, and the
technical requirements of the change.

3. Software Evolution Process

This is where the actual engineering happens. This stage is a "black box" that contains the
entire flow from your first image (Analysis $\rightarrow$ Planning $\rightarrow$ Implementation).

●​ What happens: The technical team takes the proposal and modifies the existing source
code, updates the database schema, and ensures the new version integrates with the
old data.

4. New System
The cycle completes when the "New System" (the updated version) is released to the users.

●​ What happens: The software is deployed. However, as soon as it becomes the "New
System," it starts being used in the real world, which inevitably leads back to the
Change Identification Process because new usage patterns will reveal new needs.

Here’s a clear, organized explanation of testing methods based on what was written,
cleaned up and structured for exams.

🧾 Software Testing Methods

1. Black-Box Testing (Behavior Testing)
Definition:​
Testing the software without knowing its internal code or structure.

👉 Focus is only on inputs and outputs

🔍 Key Features
●​ No access to source code
●​ No need to understand internal logic
●​ Tests functionality of the system as a whole
●​ Also called behavior testing

🎯 What it focuses on
●​ Functional requirements
●​ User perspective

❗ Errors found
1.​ Incorrect or missing functions
2.​ Interface errors
3.​ Errors in data structures or database access
4.​ Behavior or performance errors

🛠 Techniques in Black-box testing

●​ Equivalence Partitioning
●​ Boundary Value Analysis
●​ Graph-Based Testing
●​ Orthogonal Array Testing

2. White-Box Testing (Structural Testing)

Definition:​
Testing where internal structure and code are visible.

👉 Focus is on how the program works internally

🔍 Key Features
 ●​ Requires knowledge of source code
●​ Used by developers and testers
●​ Very effective for finding logical errors

🧠 Also called:
●​ Glass Box Testing
●​ Open Box Testing
●​ Transparent Testing

🎯 What it focuses on
●​ Code structure
●​ Logic and paths
●​ Internal working of program

🛠 Techniques in White-box testing

1. Basis Path Testing

●​ Uses flow graph

●​ Identifies independent paths

2. Control Structure Testing

Includes:

●​ Condition testing
●​ Data flow testing
●​ Loop testing

3. Gray-Box Testing
Definition:​
A combination of black-box and white-box testing.

👉 Tester has partial knowledge of internal structure

🔍 Key Features
●​ Some knowledge of code/design
●​ Tests both functionality and internal logic
●​ Useful for finding hidden defects

🎯 Purpose
●​ Improve test coverage
●​ Detect defects more effectively

📊 Comparison Table
Feature Black Box White Box Gray Box

Knowledge of code No Yes Partial

Focus Functionality Structure Both

Performed by Testers Developers/Tester Testers

s

Level System level Unit/Integration Integration

Goal Check output Check logic Find hidden

defects