Chapter 5: Software Testing (Final Year Project Handout)

(Part 1: Testing Strategy + Test Plan)

5.0 Introduction to Software Testing

Software testing is a critical phase of the Software Development Life Cycle (SDLC). It ensures
that the developed system works correctly, meets requirements, and is free from major defects.

In Final Year Projects (FYPs), testing demonstrates:

 System correctness
 Functional completeness
 Error handling capability
 Real-world usability

Simple Definition:
Software testing is the process of executing a program to find errors and verify that it meets its
requirements.

5.1 Testing Strategy

A testing strategy defines how the software will be tested, what levels of testing will be used,
and the approach to ensure quality.

In FYP reports, students should describe testing at four main levels:

1. Unit Testing
Definition

Unit testing is the testing of individual components or modules of a system in isolation.

Purpose

 To verify that each function/module works correctly

 To detect errors early in development
Who performs it?

Usually developers (students in FYP context)

Example (FYP Context)

In a Student Management System:

 Test AddStudent() function

 Test CalculateGrade() function
 Test LoginValidation() function

Example Test Case

 Input: Username = "admin", Password = "1234"

 Expected Output: Successful login
 Actual Output: Successful login
 Status: Pass

Key Point for Report Writing

“Each module of the system was individually tested to ensure correctness of logic and
functionality before integration.”

2. Integration Testing
Definition

Integration testing verifies the interaction between two or more modules.

Purpose

 To ensure modules work together correctly

 To detect interface errors

Common Integration Approaches

 Top-down integration
 Bottom-up integration
 Big-bang integration

Example (FYP Context)

In an Online Shopping System:

 Product module + Cart module

 Cart module + Payment module

Example Scenario

 Add product to cart → system updates total price → checkout works correctly

Key Point for Report Writing

“Integration testing was performed to verify that all modules communicate correctly and data
flows properly between components.”

3. System Testing
Definition

System testing evaluates the complete and integrated system as a whole.

Purpose

 Validate end-to-end functionality

 Ensure system meets requirements

Focus Areas

 Functional requirements
 Performance
 Security
 Usability

Example (FYP Context)

For a Hospital Management System:

 Patient registration → appointment booking → billing → discharge

Example Scenario

 A full workflow is tested from login to report generation

Key Point for Report Writing

“System testing ensures that the complete application works as expected in a real-world
environment.”

4. Acceptance Testing
Definition

Acceptance testing is performed to determine whether the system meets user requirements.

Types

 Alpha Testing (inside development environment)

 Beta Testing (real users in real environment)

Example (FYP Context)

A shop owner tests a Billing System:

 Checks invoice generation

 Verifies total calculation
 Confirms usability

Key Point for Report Writing

“Acceptance testing was conducted with end users to validate that the system fulfills business
requirements.”

5.2 Test Plan

A test plan is a document that defines:

 What to test
 How to test
 When to test
 Who will test

1. Testing Objectives
The main objectives of testing in an FYP system are:

 To identify defects in the system

 To ensure all requirements are implemented correctly
 To verify system functionality
 To ensure data accuracy
 To ensure system stability under normal usage

2. Scope of Testing
The scope defines what will be tested and what will not be tested.

Included in Scope

 User login and authentication

 Core modules (e.g., Sales, Purchase, Reports)
 Data validation
 CRUD operations

Excluded from Scope

 Third-party APIs (if not developed by student)

 External hardware integration (if any)
 Advanced load testing (if not required)

3. Testing Approach
The testing approach defines the method used to test the system.

Common Approach Used in FYPs

Manual Testing

 Performed by students or users manually

 No automation tools required

Black Box Approach

 Testing without knowing internal code

 Focus on input and output
White Box Approach (Optional)

 Testing internal logic and code structure

Sample Test Plan (FYP Ready)

Project Name: Student Management System

Testing Strategy:

The system will be tested using unit testing, integration testing, system testing, and acceptance
testing.

Testing Tools:

 Manual testing
 MS Excel (for test cases documentation)

Test Environment:

 Windows 10/11
 Visual Studio / Web Browser
 SQL Server Database

Entry Criteria:

 All modules developed

 Database connected
 Basic functionality completed

Exit Criteria:

 All critical test cases passed

 No major unresolved bugs
 User acceptance achieved

5.3 Test Cases

1. What is a Test Case?
A test case is a set of conditions or steps used to verify whether a specific feature of the
software works correctly.

Simple Definition

A test case checks:

 What input is given?

 What should happen?
 What actually happens?

2. Standard Test Case Format

Most FYP reports use this format:

Field Description
Test Case ID Unique identifier (TC-01, TC-02...)
Description What is being tested
Input Data entered by user
Expected Output What system should show
Actual Output What system actually shows
Status Pass / Fail

3. Guidelines for Writing Good Test Cases

 Each test case should test only one functionality
 Inputs should be realistic
 Expected output must match requirements
 Include both valid and invalid inputs
 Cover boundary conditions (minimum/maximum values)

4. Sample Test Cases (FYP Projects)

Below are 20 real-world test cases from common Final Year Projects.

A. Login System (Common in all projects)

 ID Description Input Expected Actual Status
Output Output
TC- Valid login Username: admin, Login Login Pass
01 Password: 1234 successful successful
TC- Invalid Username: admin, Error message Error message Pass
02 password Password: 0000
TC- Empty fields Username: "", Password: Validation Validation Pass
03 "" error error

B. Student Management System

ID Description Input Expected Actual Status
Output Output
TC- Add new student Name: Ali, Roll No: Student added Student added Pass
04 101
TC- Duplicate roll Roll No: 101 again Error message Error message Pass
05 number
TC- Empty student Name: "", Roll No: Validation error Validation Pass
06 name 102 error

C. Inventory / Trading System

ID Description Input Expected Actual Status
Output Output
TC- Add product Product: Rice, Price: Product saved Product saved Pass
07 200
TC- Negative Price: -50 Error message Error message Pass
08 price
TC- Update stock Stock: 100 → 120 Stock updated Stock updated Pass
09

D. Sales Module
ID Description Input Expected Actual Output Status
Output
TC- Create sale invoice Product: Rice, Invoice Invoice Pass
10 Qty: 2 generated generated
TC- Insufficient stock Qty > available Error message Error message Pass
11 stock
TC- Auto total 2 × 200 Total = 400 Total = 400 Pass
12 calculation
E. Reports Module
ID Description Input Expected Actual Output Status
Output
TC- Generate report Date range Report displayed Report Pass
13 selected displayed
TC- Empty report No transactions "No data found" "No data found" Pass
14 data

F. User Management
ID Description Input Expected Output Actual Output Status
TC-15 Create user Username: user1 User created User created Pass
TC-16 Duplicate username user1 again Error message Error message Pass

G. Validation & Security

ID Description Input Expected Actual Status
Output Output
TC- SQL injection attempt ' OR '1'='1 Login blocked Login blocked Pass
17
TC- Special characters in Name: Validation error Validation Pass
18 name @Ali# error

H. Boundary Testing
ID Description Input Expected Output Actual Output Status
TC- Minimum quantity Qty = 1 Sale allowed Sale allowed Pass
19
TC- Maximum allowed Qty = system System handles System handles Pass
20 stock limit correctly correctly

5. Important Notes for Students

✔ Always include:
  Valid inputs (positive test cases)
 Invalid inputs (negative test cases)
 Boundary cases

✔ Minimum requirement:

 15–30 test cases (as per FYP guideline)

✔ Common mistake:

❌ Only writing “valid inputs”

✔ Must include error handling cases too

5.3 How to Write in Report (Ready

Paragraph)
“The system was tested using a structured set of test cases covering all major modules including
login, data entry, transaction processing, and reporting. Both valid and invalid inputs were tested
to ensure system reliability and correctness.”

5.4 Black Box Testing

1. Definition
Black Box Testing is a software testing technique in which the tester does not know the
internal code structure of the system. The focus is only on:

 Inputs
 Outputs
 System behavior

Simple Definition

“Testing software by checking whether it produces correct output for given input, without
knowing internal code logic.”

2. Key Characteristics
  No knowledge of internal code required
 Focus on user requirements
 Tests functionality only
 Used in most FYP testing sections

3. Common Black Box Testing Techniques

A. Equivalence Partitioning

Input data is divided into valid and invalid groups.

Example (Age Field in Registration System):

 Valid: 18–60
 Invalid: <18 or >60

Input Expected Output

25 Accepted
10 Rejected
70 Rejected

B. Boundary Value Analysis (BVA)

Testing values at edges of input range.

Example:

If valid age = 18 to 60:

Input Expected
17 Invalid
18 Valid
60 Valid
61 Invalid

C. Decision Table Testing

Used when system behavior depends on multiple conditions.

Example (Login System):

Username Valid Password Valid Result

Yes Yes Login Success
Yes No Error
No Yes Error
No No Error

D. State Transition Testing

System changes state based on actions.

Example:

 Logged out → Logged in → Logged out

4. Black Box Testing Example (FYP Context)

Project: Online Shopping System

 User adds product to cart

 System calculates total
 User places order

Test focuses on:

 Correct total calculation

 Correct cart updates
 Proper order placement

5. Report Writing Paragraph

“Black box testing was performed to validate system functionality based on input-output
behavior. The internal code was not considered during testing. Various techniques such as
equivalence partitioning and boundary value analysis were applied to ensure correctness of
system features.”
5.5 White Box Testing (Optional Section)

1. Definition
White Box Testing is a testing technique where the tester has full knowledge of internal code
structure.

Simple Definition

“Testing based on internal logic, code paths, and structure of the program.”

2. Key Focus Areas

 Code logic
 Conditions (if/else)
 Loops
 Paths in program

3. Types of White Box Testing

A. Statement Coverage

Ensures that each line of code is executed at least once.

Example:

if (marks > 50)

result = "Pass";
else
result = "Fail";

Test cases:

 marks = 60 → Pass path executed

 marks = 40 → Fail path executed
B. Branch Coverage

Ensures every decision branch is tested.

 True condition tested

 False condition tested

C. Path Coverage

Ensures all possible paths in code are tested.

Used in:

 Complex logic
 Nested conditions

4. FYP-Level Example
Login Code:
if(username == "admin")
{
if(password == "1234")
login = true;
}

Test Cases:

 Correct username + password → login success

 Correct username + wrong password → login fail
 Wrong username → login fail

5. Report Writing Paragraph

“White box testing was performed to verify internal logic and code execution paths. Statement
and branch coverage techniques were used to ensure that all possible conditions and code
branches were tested.”
5.6 Bug Reports

1. What is a Bug Report?

A bug report is a document that describes errors or issues found during testing.

2. Standard Bug Report Format

Field Description
Bug ID Unique identifier
Module System area (Login, Sales, etc.)
Description Problem explanation
Steps to Reproduce How to generate bug
Expected Result What should happen
Actual Result What happens instead
Severity Low / Medium / High
Status Open / Fixed / Closed

3. Sample Bug Reports

Bug 1: Login Failure Issue

Field Details
Bug ID BUG-01
Module Login
Description System allows empty login submission
Steps Open login page → click login without input
Expected Show validation error
Actual System crashes or proceeds
Severity High
Status Fixed

Bug 2: Incorrect Total Calculation

 Field Details
Bug ID BUG-02
Module Sales
Description Total price not calculated correctly
Steps Add product quantity and check total
Expected Correct multiplication result
Actual Wrong total shown
Severity High
Status Open

Bug 3: Duplicate Entry Allowed

Field Details
Bug ID BUG-03
Module Product
Description Duplicate product names allowed
Steps Add same product twice
Expected Error message
Actual Duplicate saved
Severity Medium
Status Fixed

4. Severity Levels Explanation

 High: System crash or wrong calculation
 Medium: Functional issue but system runs
 Low: UI or minor issue

5. Report Writing Paragraph

“During testing, several bugs were identified and documented using a structured bug reporting
format. Each bug was categorized based on severity and tracked until resolution.”

Final Summary of Chapter 5

After completing this chapter, students should understand:
 Different levels of software testing
 How to create a test plan
 How to write test cases (very important for FYP)
 Black box and white box testing concepts
 How to document bugs professionally