Introduction to Software Verification and

Validation
Lab Manuals

Name: Muhammad Uzair

Roll No: 2K22/SWE/86
Subject: Verification & Validation
Teacher Name: Sir Asif Ali Jamali
 List of Contents
[Link] Title [Link]
1 Introduction 4
2 Requirements Verification using Checklists 7
3 Requirements Validation using Prototyping 9
4 Design test Cases Control and Decision- 12
Making Statements
5 Test Cases For OTP, Image Upload, Age 16
Verification in Registration
6 GUI Checkpoint For Single Property 21
7 Identify system specification & design test 33
cases for Sales Invoice Management.
Introduction to Software Verification and Validation LAB 1
Abstract— Software Verification and Validation (V&V) are Verification activities include:
essential components of the software development lifecycle.
While both aim to ensure that a software system meets its
required functionality, they serve different purposes. • Reviews: Inspections and walkthroughs of the
Verification ensures that the system is built correctly, while design and code.
validation confirms that the system meets the user’s needs. This
paper introduces the concepts of software verification and • Static Analysis: Analyzing the code without
validation, explores the methods and techniques employed in executing it, often using tools to detect potential
these processes, and emphasizes their importance in ensuring errors.
software quality. Understanding these processes helps in the • Unit Testing: Testing individual components or
early detection of errors, compliance with industry standards,
and user satisfaction.
modules to ensure they function as expected.
• Integration Testing: Ensuring that different
Keywords— Software Verification, Software Validation, components of the system work together correctly.
Quality Assurance, Software Testing, Software Lifecycle, System
Testing, Acceptance Testing.

III. Software Validation

I. Introduction Validation is the process of checking whether the
Software systems are integral to modern technology, and software meets the needs and expectations of the end-users
ensuring their correctness and reliability is paramount.
Verification and Validation (V&V) are critical activities and stakeholders. Unlike verification, which focuses on
within the software development process that help achieve conformance to specifications, validation ensures that the
high-quality software. software solves the intended problem and performs its
Verification ensures that the software is built according to
design specifications, whereas validation confirms that it
satisfies user requirements. This paper explores the
difference between verification and validation, their Aspect Verification Validation
respective roles in the software lifecycle, and the Ensures the software is Ensures the software
techniques used to implement them effectively. Objective being built according to fulfills its intended
specifications. purpose.
Question "Are we building the "Are we building the
II. Software Verification
Answered system right?" right system?"
Software verification is the process of ensuring that a
software system complies with its specifications and is User satisfaction and
Adherence to design and
built correctly. This involves a series of checks and Focus system performance in
activities to verify that each part of the system adheres requirements.
real-world use.
to the design and requirements. Verification is primarily
focused on detecting defects early in the development System testing,
Inspections, walkthroughs,
phase. Methods acceptance testing, user
static analysis, unit tests.
feedback.
2.1 Techniques for Verification Performed throughout the Performed after the
Timing
development process. software is developed.
required functions. Validation answers the question: "Are we software developers can deliver highquality software that
building the right system?" meets both technical requirements and user expectations.

Validation activities include:

VI. Acknowledgment
• System testing to verify the system’s behavior in a
simulated environment.
• Acceptance testing, often performed by the client or The author would like to express gratitude to the software
end-users, to confirm the software meets their needs. engineering team at [Organization Name] for their valuable
• Beta testing to gather real-world feedback from users. insights and contributions to the development of verification
and validation methodologies. Additionally, appreciation is
The objective of validation is to confirm that the software extended to the research community whose work continues
satisfies the actual requirements and performs its tasks to shape the field of software quality assurance.
effectively in real-world scenarios.

VII. References
IV. Importance of V &V
Both verification and validation contribute to:

• Early Detection of Errors: Reducing the cost 1. IEEE Std 610.12-1990, IEEE Standard Glossary of
of fixing defects by identifying them early in the Software Engineering Terminology. IEEE, 1990.
process. 2. Boehm, B. W., "Software Engineering Economics,"
• Customer Satisfaction: Validation ensures that Prentice Hall, 1981.
the final product aligns with user expectations. 3. Sommerville, I., Software Engineering, 10th ed.,
• Regulatory Compliance: Ensuring the software Boston: Addison-Wesley, 2015.
meets industry standards, particularly in high-risk 4. Pressman, R. S., Software Engineering: A
domains like healthcare and aerospace. Practitioner's Approach, 8th ed., New York:
McGraw-Hill, 2005.
V. Conclusion 5. IEEE Std 1012-2016, IEEE Standard for System
and Software Verification and Validation, IEEE,
In conclusion, software verification and validation are vital
2016.
processes to ensure the quality and reliability of software
systems. Verification ensures that the software is built 6. Kitchenham, B. A., & Charters, S., "Guidelines for
correctly according to its specifications, while validation Performing Systematic Literature Reviews in
ensures that it meets the actual needs of the users. By Software Engineering," EBSE Technical Report,
employing rigorous verification and validation techniques, 2007.
 Lab 2 – Requirements Verification using Checklists (Hospital
Management System)
Reference: Lab 2 template provided by the user. See attached file for pattern.
Sample SRS Extract (Hospital Management System)
This extract contains selected functional requirements for a Hospital Management System (HMS).
1. Patient Registration: The system shall allow staff to register a patient with fields: PatientID,
FullName, DOB, Gender, ContactNumber, Address, EmergencyContact, and InsuranceID.
2. Appointment Booking: The system shall allow patients (or staff) to book an appointment with a
doctor for a specified date and time. The system shall prevent double-booking of the same doctor
slot.
3. Electronic Medical Records (EMR): The system shall store and retrieve patient medical records
including diagnoses, prescriptions, lab results, and treatment history.
4. Prescription Management: The system shall allow doctors to create, edit, and sign electronic
prescriptions; the prescription shall be printable and exportable as PDF.
5. Billing and Invoicing: The system shall generate invoices for services and medicines, calculate
taxes, apply insurance coverage, and mark invoices as Paid/Unpaid.
6. Lab Test Requests: The system shall allow doctors to request lab tests and receive results; lab
results must be linked to the patient record.

Checklist Criteria Table

Criteria Description
Clarity Is the requirement clearly stated
without vague terms?
Completeness Does it include all necessary
details or conditions?
Testability Can we test it (verify it
objectively)?
Non-Ambiguity Is it free from multiple
interpretations?
Evaluation Table (✔ / ✖)
Requirement Clar Complete Testabi Non- Remar
ity ness lity Ambig ks
uity
1. Patient ✔ ✔ ✔ ✔ Well-
Registrati defined
on: The fields
system and
shall format.
allow
staff to
register a
patient
with
fields:
PatientID,
FullName
, DOB,
Gender,
ContactN
umber,
Address

2. ✔ ✔ ✔ ✔ Specifi
Appointment es
Booking: The prevent
system shall ion of
allow patients double-
(or staff) to bookin
book an g.
appointment
with a doctor
for a
specified date
and time. The
system shall
 prevent
double-
booking of
the same
doctor slot.

3. Electronic Needs
Medical ✔ ✖ ✔ ✔ retentio
Records n
(EMR): The policy
system shall and
store and access
retrieve rules.
patient
medical
records
including
diagnoses,
prescriptions,
lab results,
and treatment
history.

Identified Errors & Suggested Improvements

No. Problematic Suggested

Requirement Improvement
1 Electronic Medical Specify retention
Records (EMR) period (e.g., retain
records for 10
years), define
access levels
(doctor, nurse,
admin), and
encryption method
(e.g., AES-256 for
data at rest).

2 Billing and Specify tax

Invoicing percentage rules,
insurance claim
workflow, and
 define payment
methods (Cash,
Card, Insurance).
Provide sample
invoice format.
Conclusion / Expected Result
Using the verification checklist, we reviewed selected HMS requirements and identified unclear or
incomplete items. By refining requirements to include measurable, testable, and unambiguous details
(examples shown), the overall SRS quality improves and becomes ready for implementation and
testing.
Template adapted from user-provided Lab 2 document.

Lab 3
Requirements Validation using Prototyping

Objective:
To confirm and refine software requirements by creating and testing a simple prototype.

Theory:
Prototyping is used to check if the gathered requirements truly meet user needs. It involves making an early version of
the system so users can see and test how it might work. This helps in identifying missing or unclear requirements early,
saving time and cost later in development.

Procedure:
Step 1: Select a Small System
Selected System: Library Management System (LMS)
Step 2: Design a Simple Prototype (Low-Fidelity)
A low-fidelity prototype was created using a simple design tool such as PowerPoint or Figma. It focuses on layout and
basic navigation rather than visuals or animations.
Main Features Validated:
- Librarian login
- Book search by title, author, or ISBN
- Displaying book details and status
- Checking out and checking in books Step 3: Stakeholder Feedback
The prototype was shown to a librarian and a library member. The librarian suggested showing book and
borrower details during check-in and requested an overdue books report. The member suggested having a public
search screen without checkout options.

Expected Result:
The prototype confirmed the basic requirements such as login, search, and book transactions. It also revealed new
needs like a confirmation step for check-ins and an overdue books report. This feedback will help improve the
Software Requirements Specification before development begins.

Questions:
1. What is the difference between low-fidelity and high-fidelity prototypes?
Low-fidelity prototypes are simple sketches or wireframes used to test ideas early, while high-fidelity prototypes look
and behave more like the final product and are used for usability testing.
2. Why is prototyping important in requirement validation?
Prototyping helps clarify unclear requirements, gather user feedback early, and reduce costly changes later. It improves
understanding between developers and users by turning written requirements into visual examples.
 Lab 4
Design Test Cases Control and Decision-
Making Statements

Write program and design test cases for the following Control and Decision-Making Statements:
1. For Loop
2. If…Else
3. Switch…Case
4. Do…While

A. Objective
To assess the behavior of software under various conditions by applying control and decision-making
statements, and to design effective test cases that validate program correctness.

B. Expected Program Outcomes (POs)

1. Apply basic programming knowledge to solve problems.
2. Analyze problems and derive program logic.
3. Design solutions using control and decision-making statements.
4. Apply testing techniques to verify correctness.

C. Programs and Test Cases 1)

For Loop
Program: <?php function
calculateSum($n) {
$sum = 0; for ($i = 1; $i
<= $n; $i++) {
$sum += $i;
}
return $sum;
} echo "Sum of numbers from 1 to 5 is: " .
calculateSum(5); ?>
Test Cases:

Test Input Expected Remarks

Case ID Output
TC1 5 15 Valid positive
input

TC2 0 0 Boundary case

TC3 10 55 Valid input

TC4 -3 Error/Undefined Negative input

TC5 Hello Error/Undefined Invalid input

2) If…Else
Program: <?php function
checkNumber($x) {
if ($x > 0)
{ return
"Positive"; } else if
($x < 0) { return
"Negative"; } else {
return "Zero";
}
} echo checkNumber(-
5);
?>
Test
Cases:
Test Input Expected Remarks
Case ID Output
TC1 10 Positive Positive number

TC2 -7 Negative Negative number

TC3 0 Zero Boundary case

TC4 abc Error/Undefined Invalid input

 3) Switch…Case
Program: <?php function getDayMessage($day)
{ switch ($day) { case "Monday": return
"Start of the week!"; case "Friday": return
"Almost weekend!"; case "Sunday": return
"Holiday!"; default: return "Regular day.";
}
} echo
getDayMessage("Friday");
?>

Test Cases:
Test Case Input Expected Remarks
ID Output
TC1 Monday Start of the week! Valid input

TC2 Friday Almost weekend! Valid input

TC3 Sunday Holiday! Valid input

TC4 Wednesday Regular day. Other valid day

TC5 Holiday123 Regular day. Invalid input

4) Do…While Loop
Program: <?php
function printNumbers($n) {
$counter = 1;
$result = ""; do
{
$result .= $counter . " ";
$counter++; } while
($counter <= $n); return
trim($result);
}
echo printNumbers(5);
?>
 Test Cases:

Test Case Input Expected Remarks

ID Output
TC1 5 12345 Valid input
TC2 1 1 Minimum valid input

TC3 0 1 Executes at least once

TC4 -3 1 Executes once, then stops

D. Conclusion
By writing programs for control and decision-making statements (for, if…else, switch…case, do…
while) and designing corresponding test cases, we ensured the correctness of program behavior under
different input conditions. This practical strengthened our understanding of program control
structures and systematic software testing.
 Lab 5

Design test cases for different tasks (OTP Verification, Image upload, Age
verification in Registration) in any software modules using Equivalence
partitioning, boundary value analysis, and decision table testing
techniques of Black Box Testing.

Black Box Test Cases for OTP Verification, Image Upload, and Age Verification

OTP Verification:
Equivalence Partitioning: OTPs are often required to be a specific length of digits. For example, many
systems accept exactly 6-digit numeric codes[1]. Equivalence classes can be: Valid: exactly 6 digits
(numeric). Invalid: fewer digits, more digits, or non-digit characters. Testing one representative from
each class is sufficient.
Test Case Input Expected Output Remark
(OTP)
Valid 6 123456 OTP accepted (verification Valid case (correct
digits succeeds) format)
Too short 1234 Error: Invalid OTP length Invalid (short length)
Too long 1234567 Error: Invalid OTP length Invalid (long length)
Non- ABC123 Error: Invalid OTP format Invalid (contains
numeric letters)
Empty input "" Error: OTP required Invalid (no input)

Boundary Value Analysis: When OTP must be exactly 6 digits, focus on boundary lengths around 6.
Typical boundary values are 5 and 7 digits (just outside valid) and representative valid values (e.g.
lowest and highest 6-digit). Testing these catches off-by-one errors[2].

Test Case Input Expected Output Remark

(OTP)
 One less than 99999 Error: Invalid OTP length Edge case: 5 digits
minimum (invalid)
Minimum valid 100000 OTP accepted (verification Boundary: 6 digits
(lower) succeeds) (valid)
Maximum valid 999999 OTP accepted (verification Boundary: 6 digits
(upper) succeeds) (valid)
One more than 1000000 Error: Invalid OTP length Edge case: 7 digits
maximum (invalid)

Decision Table Testing: We consider combinations of conditions: OTP format and correctness. For
example, conditions can be “OTP format valid (6-digit)” and “OTP matches expected code”. The
decision table enumerates all combinations and expected outputs[3].

Test Case Input Expected Output Remark

(OTP)
Correct format, 123456 OTP accepted Valid case (correct code)
match (success)
Correct format, no 654321 Error: Incorrect OTP Valid format but wrong
match code
Invalid format 12345 Error: Invalid OTP Invalid (wrong length)
(short) format
Invalid format ABCDEF Error: Invalid OTP Invalid (non-numeric
(letters) format characters)
Image Upload:
Equivalence Partitioning: For an image upload feature, inputs include file type and size. Typical
classes are: Valid: allowed image formats (e.g. JPEG/PNG) within size limit; Invalid: unsupported
format (e.g. PDF) or file too large[4]. One example from each class suffices to test.
Test Case Input (File) Expected Output Remark
Valid image [Link] Upload succeeds Valid (allowed type
(JPEG) (500KB) & size)
Valid image [Link] Upload succeeds Valid (allowed type
(PNG) (200KB) & size)
Unsupported [Link] (300KB) Error: Unsupported file Invalid (wrong type)
format format
Exceeds size [Link] (2MB) Error: File too large Invalid (size > limit)
limit

Boundary Value Analysis: Suppose the size limit is 1 MB. Key boundary sizes are just below, at, and
just above this limit[2]. Test values around 1 MB check for off-by-one errors in size handling.

Test Case Input (Size) Expected Output Remark

Just below 999KB JPEG Upload succeeds Edge case (0.999 MB, valid)
limit
At the limit 1024KB PNG Upload succeeds Boundary (1 MB, valid)
Just above 1100KB Error: File too Edge case (>1 MB, invalid)
limit JPEG large
 Test Case Input (Size) Expected Output Remark
Very small file 1KB PNG Upload succeeds Edge case (minimal size,
valid)

Decision Table Testing: Combine conditions (file type and size). For example, “Is format JPEG/PNG?”
and “Is size within limit?” determine the outcome. The decision table ensures all condition
combinations are tested[5].

Test Case File Size Expected Remark

Format Output
Good type & JPEG 800KB Upload Both conditions true
good size succeeds (allowed)
Good type & JPEG 1200KB Error: Invalid Size over limit
too large image (invalid)
Bad type & PDF 800KB Error: Invalid Unsupported format
good size image (invalid)
Bad type & too GIF 1200KB Error: Invalid Both conditions false
large image (invalid)
Age Verification:
Equivalence Partitioning: For age verification, inputs partition into “underage” vs “of-age.” For
instance, if the minimum age is 18, classes could be Invalid: age < 18, and Valid: age ≥ 18[6]. We test
one example of each.
Test Case Input (Age) Expected Output Remark
Under minimum age 17 Access denied Invalid (age < 18)
Exactly minimum 18 Access granted Valid (age = 18, boundary)
Above minimum 25 Access granted Valid (age > 18)
Unrealistic age 150 Error: Invalid age Invalid (age not realistic)
Boundary Value Analysis: Focus on ages around the threshold (e.g. 18 years). Test values just below
and above 18 detect off-by-one errors[7].
Test Case Input Expected Output Remark
(Age)
Just below threshold 17 Access denied Edge case (17, invalid)
At threshold 18 Access granted Boundary (18, valid)
Just above threshold 19 Access granted Edge case (19, valid)

Decision Table Testing: Add a second condition such as parental consent for minors. For example,
conditions: “Age ≥ 18?” and “Parental consent provided?”. The decision table enumerates
combinations:

Test Case Age ≥ Parental Expected Remark

18? Consent? Output
Adult, no Yes No Access Age ≥ 18 (consent
consent granted irrelevant)
Adult, with Yes Yes Access Age ≥ 18 (consent
consent granted redundant)
Minor with No Yes Access Under 18 but consent
consent granted given
Minor without No No Access Under 18, no consent
consent denied
Each table above focuses only on the input and expected output of the module (black-box testing).
Sources discuss these techniques and examples[1][5] to ensure thorough coverage of valid and invalid
cases.

Lab 6
GUI Checkpoint For Single Property

Objective

Test: Check Button Click and Select List Item

Navigate to W3Schools.

Interact with a button.

Select an item from a dropdown list.

Step 1: Install Selenium IDE

Install the Extension:
Open Chrome and go to the Selenium IDE Chrome Extension page.

Add it to your browser.

Performing "GUI Checkpoint for Single Property" Using

Selenium IDE Chrome Extension

Selenium IDE is a browser-based tool for creating and running automation tests.
You can use it to check single properties of GUI elements. Below is a step-by-step
guide to perform this experiment.

Step 1: Install Selenium IDE

Install the Extension:

Open Chrome and go to the Selenium IDE Chrome Extension page.

Add it to your browser.

Open Selenium IDE:

Click the Selenium IDE icon in your browser's extensions.

Step 2: Create a New Project

Create a Project:

In Selenium IDE, click Create a New Project.

Name your project LabTest.

Open the Target Website:

Open the website where you want to perform the GUI checkpoint
Step 3: Perform the Actions

Click a Button:

On the Tryit Editor page, locate the Run button and click it.

Selenium IDE will record this action.

Select a List Item:

I page has a dropdown list, click the dropdown and select an option

go to [Link]

Step 4: Stop Recording

After performing the actions, stop the recording in Selenium IDE.

The recorded actions will appear in the test.

Here’s how you can perform the test for clicking a button and selecting a list item
using Selenium IDE on W3Schools:

Test: Check Button Click and Select List Item

We will:

Navigate to W3Schools.

Interact with a button.

Select an item from a dropdown list.

Check Title and text

Test Steps with Selenium IDE
Step 1: Open Selenium IDE
Launch Selenium IDE in your browser.

Create a new project (e.g., GUI_Check_Test).

Step 2: Start Recording

Click Record a New Test in Current Project.

Enter the URL: [Link]

filename=tryhtml_default.

Click Start Recording.

Step 3: Perform

the Actions

Click a Button:

On the Tryit Editor page, locate the Run button and click it.

Selenium IDE will record this action.

Select a List Item:

If the page has a dropdown list (you can find one on other examples like forms),
click the dropdown and select an option.

For example, go to [Link]

filename=tryhtml_select.

Step 4: Stop Recording

After performing the actions, stop the recording in Selenium IDE.

The recorded actions will appear in the test.

Step 5: Add Assertions (Optional but Recommended)
To verify the button click was successful:

Add the command assertElementPresent for an element that appears after the
button is clicked.

To verify the dropdown selection:

Add the command assertValue to check if the correct value is selected.

Step 6: Run the Test

Click Run Current Test in Selenium IDE.

Observe the test execution in the browser.

Test Results

Step Expected Result Actual Result

Open URL Page loads successfully Success

Click Button Button is clicked, output appears Success

Select List Item Dropdown option is selected Success

Assertions Button click and dropdown selection are verified Success

Button Click Testing
Button Text Check
DropDown Click
DropDown Present
Button Value
Input Typing Check
Title
Text
 LAB 7

Specification Description
No.
1 Invoice Creation System must allow creation of new invoices with
accurate customer, product, quantity, and amount
details.
2 Invoice Editing Authorized users can edit existing invoices with audit
trails.
3 Duplicate Invoice System must prevent duplicate invoice numbers.
Prevention
4 Invoice Deletion Authorized users can delete invoices.
5 Invoice Reporting System should generate reports (daily, weekly,
monthly) for analysis.

Identifysystemspecification&designtestcasesforSal
esInvoiceManagement.

SYSTEM SPECIFICATION
 Test Cases for Sales Invoice Management System

Test Case ID Test Case Description Test Data Test Steps Expected Actual Status Date Created
Title Result Result By
TC_SIM_001 Verify Invoice Verify if user can Customer: Ali 1. Login 2. System As Pass 05- Sarmad
Creation create new Khan, Product: Navigate to generates Expected Nov-
invoice Laptop, Qty: 2, “Create invoice ID 2025
successfully. Amount: Invoice” 3. and displays
200,000 PKR Enter all confirmatio
required n message.
fields 4.
Click
“Submit”

TC_SIM_002 Verify Invoice Verify that user Invoice ID: 1. Login as System As Pass 05- Sarmad
Editing with edit INV102, New authorized updates Expected Nov-
permission can Qty: 3 user 2. invoice 2025
update invoice Search details and
details. Invoice maintains
INV102 3. change log.
Edit
Quantity 4.
Save
changes
TC_SIM_003 Prevent Ensure duplicate Invoice ID: 1. Create System As Pass 05- Sarmad
Duplicate invoice number INV105 invoice with displays Expected Nov-
Invoice is not allowed. (already exists) existing ID error 2025
Numbers INV105 2. “Duplicate
Submit Invoice ID
not
allowed.”

TC_SIM_004 Verify Invoice Ensure only Invoice ID: 1. Login as System As Pass 05- Sarmad
Deletion authorized users INV109 unauthorized displays Expected Nov-
can delete user 2. Try access 2025
invoices. to delete denied
invoice message.

TC_SIM_005 Verify Invoice Verify that Date Range: 1. Login 2. System As Pass 05- Sarmad
Report reports can be 01-Nov-2025 Navigate to displays Expected Nov-
Generation generated to 05-Nov- Reports 3. accurate 2025
successfully. 2025 Select date report
range 4. summary.
Generate
report
Design Test Cases for Flight Ticket Booking
System
System Specifications

No. Specification Description

1 User Authentication System should allow secure login for
registered users.
2 Flight Search User can search flights by destination,
date, and class.
3 Reservation Process User can book selected flight and seat.
4 Payment & Billing Secure payment handling and accurate
billing.
5 Booking Modification & Users can modify or cancel bookings as
Cancellation per policy.
6 Flight Status Notification Users receive flight status updates.
7 Mobile Responsiveness The system should work smoothly on all
devices.
 Test Cases for Flight Ticket Booking System
Test Case ID Test Case Description Test Data Test Steps Expected Actual Status Date Created
Title Result Result By
TC_FBS_001 Verify User Verify login Username: 1. Open login System As Pass 05- Sarmad
Login with valid user1, page 2. Enter redirects to Expected Nov-
credentials. Password: credentials 3. user dashboard. 2025
pass123 Click Login

TC_FBS_002 Verify Flight Check if user From: 1. Login 2. Go List of As Pass 05- Sarmad
Search can search Karachi, To: to “Search available Expected Nov-
Function available Dubai, Date: Flights” 3. flights 2025
flights. 10-Nov-2025 Enter criteria displayed.
4. Click
Search

TC_FBS_003 Verify Seat Ensure user Flight ID: 1. Login Confirmation As Pass 05- Sarmad
Reservation can book a EK605, Seat: 2. Search and message with Expected Nov-
flight seat. 12A select flight booking ID 2025
3. Choose seat shown.
4. Confirm
booking

TC_FBS_004 Verify Validate Card: 1234- 1. Proceed to System As Pass 05- Sarmad
Payment secure 5678-9012- payment processes Expected Nov-
Functionality payment 3456, 2. Enter payment and 2025
processing. Amount: details 3. generates e-
75,000 PKR Confirm ticket.
payment

TC_FBS_005 Verify Ensure user Booking ID: 1. Login Booking status As Pass 05- Sarmad
Booking can cancel BK1007 2. Go to “My changes to Expected Nov-
Cancellation booking. Bookings” “Cancelled”. 2025
3. Select
booking
4. Click
“Cancel”

TC_FBS_006 Verify Flight Ensure user Booking ID: 1. Change User receives As Pass 05- Sarmad
Status receives BK1007 flight status in notification via Expected Nov-
Notification notifications. admin panel 2. email/SMS. 2025
Observe
notification
 Practical Related Exercise Answers

No. Question Correct Option Explanation

1 What is the role of a test ✅c. To ensure the Test cases validate that software
case in SDLC? quality of the software meets requirements and
functions correctly.
2 Which of the following is ✅c. Test Plan Test plan is a higher-level
NOT a component of a document; test case focuses on
test case? individual scenarios.
3 When is the best time to ✅d. During the Writing test cases early ensures
create test cases in requirements phase requirements are testable.
SDLC?
4 Which of the following is ✅c. Bug Report Bug reports are written after test
not a component of a test execution, not as part of the test
case? case.
5 What is the purpose of ✅c. To provide input Test data ensures the system is
test data in a test case? values for the test case tested with valid and invalid
inputs.