R19CB452 – Software Testing Page 1 of 42

Ex. No: 1 Create Test Cases for the User Login Functionality of the
Date: E-commerce site

AIM:

The aim of this experiment is to develop a comprehensive test plan for testing the functionality and
usability of the e-commerce web/mobile application [Link]

PROCEDURE:

⮚ Step 1: Understand Requirements: Gather and review the functional and non-functional
requirements of the E-commerce application.
⮚ Step 2: Identify Modules: Break down the application into testable modules like Login,
Search, Product Page, Cart, Checkout, Payment, etc.
⮚ Step 3: Define Test Scenarios: Based on the modules, create high-level test scenarios.
⮚ Step 4: Write Test Cases: Convert scenarios into detailed test cases with clear inputs and
expected outputs.
⮚ Step 5: Assign Priorities: Tag each test case as High, Medium, or Low priority.
⮚ Step 6: Review and Approve: Peer review the test cases for accuracy and completeness.
⮚ Step 7: Execute and Report: Execute the test cases in a test environment and report bugs if any.
⮚ Step 8: Retest & Regression: Retest after fixes and run regression tests to ensure nothing else
is broken.

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 2 of 42

Sample Test Case Table:

Test Module Test Case Input Expected Output Priority

Case ID Description
TC001 Login Login with Username: user1 Redirect to High
valid Password: pass123 homepage; user is
credentials logged in
TC002 Login Login with Username: user1 Show error message: High
invalid Password: wrong "Invalid username
credentials pass or password"
TC003 Search Search for a Search keyword: Display list of High
product laptop laptops with
matching keyword
TC004 Cart Add product to Select product → Product is added to High
cart Click "Add to cart with correct
Cart" name and price
TC005 Checkout Checkout with Click on "Proceed Show message: Medium
empty cart to Checkout" with "Your cart is
empty cart empty"
TC006 Payment Payment with Card No: 1234 Show message: High
invalid card 5678 9012 3456, "Invalid card
Expired Date details"
TC007 Order View order Logged-in user Show list of past Medium
history clicks "My Orders" orders

Criterion Max Obtained

Preparation 20
Implementation 25
Result 20
Viva 10
Total 75

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 3 of 42

RESULT:

The designed test cases for the E-commerce application were successfully executed. All the
functionalities including login, product search, cart operations, checkout process, payment validation,
and order history retrieval performed as expected. Each test case met the expected outcomes without
any critical failures. Hence, the E-commerce application passed the basic functional testing phase.

Ex. No: 2 Design A Detailed Test Scenario Matrix that Covers all Potential Edge Cases
for the Payment Module in the E-Commerce Site
Date:

AIM:

To design a detailed test scenario matrix that covers all potential edge cases for the payment module
in the e-commerce site.
PROCEDURE:

⮚ Step 1: Choose an E-Commerce Website.

⮚ Step 2: Add a product to the Cart.
⮚ Step 3: Proceed to buy the product.

SAMPLE TEST CASES:

Test Case 1: Successful Payment – UPI.

Test Case 2: Successful Payment - Credit Card.
Test Case 3: Invalid Credit Card Details.
Test Case 4: Session Timeout.
Test Case 5: Payment Gateway Failure.
Test Case 6: Insufficient Funds.
Test Case 7: Payment Cancellation
Test Case 8: Multiple Payment Attempts

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 4 of 42

Sample Test Case 1: Successful Payment – UPI

Input: User enters valid UPI ID and approves payment.
Output: Payment is successfully processed, and order confirmation is received.

Sample Test Case 2: Insufficient Funds

Input: User attempts payment with insufficient funds.
Output: Payment is declined with an appropriate error message.

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 5 of 42

Sample Test Case 3: Payment Gateway Failure

Input: User tries to do payment after the session timed out.
Output: User receives an error message and is prompted to retry later.

Sample Test Case 4: Invalid UPI Pin

Input: User enters an invalid PIN.
Output: Payment is declined with an appropriate error message.

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 6 of 42

Sample Test Case 5: Session Timeout

Input: User takes too long to complete payment.
Output: Payment session expires, prompting the user to restart the process.

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 7 of 42

Criterion Max Obtained

Preparation 20
Implementation 25
Result 20
Viva 10
Total 75

RESULT:

All edge cases for the Payment Module were tested successfully in a controlled environment. The
module handled valid transactions smoothly and gracefully managed all invalid inputs and edge cases
with appropriate error handling. No critical bugs were encountered, and the system met all the
functional and non-functional requirements. Thus, the payment module passed the testing phase.

Ex. No: 3 Evaluate the need for White-Box Testing in

Complex Applications based on Lab Results.
Date:

AIM:

The aim of white-box testing is to verify the internal logic, flow, and code structure of the application
to ensure that it functions correctly, efficiently, and securely. By having full access to the source code,
the tester can design test cases that check the execution of specific code paths, identify potential
vulnerabilities, and detect logical errors or performance bottlenecks.

PROCEDURE:

Step 1: Understanding the Code Structure:

o Review the source code and understand the architecture, design, and functionality of
the application.
o Identify all the critical functions, methods, and code paths that need to be tested.

Step 2: Test Case Design:

o Develop test cases based on the internal logic of the code. This includes conditions,
loops, statements, and branches.
o Techniques like Statement Coverage, Branch Coverage, Path Coverage, and Loop
Testing can be used to design test cases.

Step 3: Test Execution:

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 8 of 42

o Execute the test cases on the application to ensure all logic and code paths are
thoroughly tested.
o Track the output and compare it against expected results to determine correctness.

Step 4:Code Review:

o Review the code for security vulnerabilities, potential performance issues, and
inefficient code.
o Check for logical errors, unused variables, and redundant code.

Step 5: Defect Reporting:

o Report any defects or vulnerabilities found during testing, including issues related to
incorrect logic, poor performance, or security flaws.

Step 6: Optimization & Refactoring:

o Based on the findings, suggest code optimizations or refactor the code to improve
performance or security.

Step 7:Regression Testing:

o After fixing the issues, rerun the tests to ensure the code modifications did not affect
the existing functionality.

CODE:

Backend:

// [Link] (Backend - [Link] & Express)

const express = require('express');
const mongoose = require('mongoose');
const bcrypt = require('bcrypt');
const jwt = require('jsonwebtoken');
const cors = require('cors');
const path = require('path');
require('dotenv').config(); // Load environment variables
const User = require([Link](__dirname, 'models', 'User'));
const app = express();
const PORT = [Link] || 5000;
[Link](cors());
[Link]([Link]());
[Link]('mongodb://localhost:27017/whiteboxtest', {
useNewUrlParser: true,
useUnifiedTopology: true,
}).then(() => [Link]('MongoDB Connected'))
.catch(err => [Link](err));
// Register Endpoint
[Link]('/register', async (req, res) => {
try {
const { username, password } = [Link];
if (!username || !password) {

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 9 of 42

return [Link](400).json({ message: 'Username and password

are required' });
}
const hashedPassword = await [Link](password, 10);
const user = new User({ username, password: hashedPassword });
await [Link]();
[Link](201).json({ message: 'User registered' });
} catch (error) {
[Link](500).json({ message: 'Server error' });
}
})
// Login Endpoint
[Link]('/login', async (req, res) => {
try {
const { username, password } = [Link];
const user = await [Link]({ username });
if (!user || !(await [Link](password, [Link]))) {
return [Link](401).json({ message: 'Invalid
credentials' });
}
const token = [Link]({ id: user._id }, 'secret', { expiresIn:
'1h' });
[Link]({ token });
} catch (error) {
[Link](500).json({ message: 'Server error' });
}
});
[Link](PORT, () => [Link](`Server running on port $
{PORT}`));

Frontend:

// frontend/src/[Link]
import React, { useState } from 'react';
import axios from 'axios';

function App() {
const [username, setUsername] = useState('');
const [password, setPassword] = useState('');
const [token, setToken] = useState('');
const [message, setMessage] = useState('');

const login = async () => {

try {
const res = await [Link]('[Link]
{ username, password });
setToken([Link]);
setMessage('Login successful!');
} catch (error) {
setMessage('Login Failed');
}
};

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 10 of 42

return (
<div>
<h2>Login</h2>
<input type='text' placeholder='Username' value={username}
onChange={(e) => setUsername([Link])} />
<input type='password' placeholder='Password' value={password}
onChange={(e) => setPassword([Link])} />
<button onClick={login}>Login</button>
<p>{message}</p>
{token && <p>Logged in! Token: {token}</p>}
</div>
);
}

export default App;

OUTPUT:

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 11 of 42

Criterion Max Obtained

Preparation 20
Implementation 25
Result 20
Viva 10
Total 75

RESULT:

White-box testing ensures that every part of the code, including statements, branches, and loops, is
tested for correctness and efficiency. By evaluating the internal logic and execution paths, it helps
identify errors, vulnerabilities, and performance issues. This approach improves code reliability,
security, and overall software quality.

Ex. No: 4 Apply Regression Testing Techniques to Validate the Changes made to a
Web-Based Project Management Application
Date:

AIM:

The aim of this experiment is to apply regression testing techniques to validate and ensure that recent
code changes in the web-based project management application have not adversely affected the
existing functionalities.

PROCEDURE:

⮚ Step 1: Identify the recent changes or updates made to the project management application
(e.g., new feature addition, bug fixes, UI changes).
⮚ Step 2: Define the scope of regression testing by identifying the core modules and
functionalities that could be impacted by the recent changes (e.g., task assignment, project
tracking, calendar integration).
⮚ Step 3: Prepare and update a regression test suite comprising previously executed test cases
that validate the unchanged parts of the system.
⮚ Step 4: Report the findings to the development team for necessary code corrections or
optimizations.

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 12 of 42

⮚ Step 5: Retest the affected modules after fixes are applied to confirm stability and revalidate
the regression suite if needed.
⮚ Step 6: Finalize and submit the regression testing report summarizing the scope, execution,
results, issues found, and resolution status.

Regression Testing Test Cases Table :

Status
Test Case Test Expected Actual
Module Test Steps (Pass/Fail
ID Scenario Result Result
)
1. Navigate
to login
Validate user page
User should be
TC_REG_ login with 2. Enter As
Login redirected to Pass
01 valid valid email Expected
dashboard page
credentials & password
3. Click
Login
1. Go to
Project
2. Click Task should
TC_REG_ Task Assign a task "Assign appear in the As
Pass
03 Assignment to a user Task" assigned user’s Expected
3. Select task list
user &
submit
Verify 1. Login All widgets and
TC_REG_ dashboard 2. Navigate summary boxes As
Dashboard Pass
04 loads with to should display Expected
widgets Dashboard correctly
1. Open task
Add a 2. Add Comment Commen
TC_REG_
Comments comment to a comment should appear t not Fail
05
task 3. Click under the task saving
Post
1. Assign
Receive
task Notification
TC_REG_ Notification notification As
2. Check should appear Pass
06 s on task Expected
notification instantly
assignment
bell

OUTPUT:

Total Test Cases Executed Passed Failed

6 5 1

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 13 of 42

Module Tested: Login, Project Management, Task Assignment, Dashboard, Comments, Notifications

Criterion Max Obtained

Preparation 20
Implementation 25
Result 20
Viva 10
Total 75

RESULT:

The regression testing was successfully conducted on the updated web-based project management
application. The test suite included major functionalities such as login, project creation, task
assignment, dashboard verification, comments, and notifications.

Ex. No: 5 Design a New Regression Test Plan for a Mobile Banking Application after
Date: Adding a New Feature

AIM:

To design and execute a Regression Test Plan for a Mobile Banking Application to ensure that the
new feature (e.g., QR Code Payments or Budget Tracker) does not affect existing functionalities and
integrates smoothly within the system.

SOFTWARE REQUIRED:

1. Java JDK: 8 or above JUnit Library: JUnit 4.13.2

2. Test Automation Tools: Selenium / Appium (optional for automation)
3. Bug Tracking Tool: Jira or Bugzilla

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 14 of 42

4. Device Emulators: Android Studio Emulator / iOS Simulator

5. Security Tools: OWASP ZAP, Burp Suite

PROCEDURE:

Step 1: Analyze the impact of the newly added feature on existing modules.
Step 2: Identify core modules for regression:
● Login & Authentication
● Account Overview
● Fund Transfers
● Security Features
● Cross-Platform Functionality
Step 3: Prepare test environment:
● Configure environment similar to production.
● Include real devices/emulators for testing UI responsiveness.
Step 4: Compare and contrast their roles, highlighting differences in scope, decision-making, and
execution.
Step 5: Execute tests:
● Run JUnit test cases manually or via script.
● Perform automation if applicable.
● Log all results and track bugs in a defect tracking tool.
Step 6: Verify and validate results:
● Retest failed cases.
● Run performance and security checks.
Step 7: Evaluate exit criteria based on severity of remaining issues.

PROGRAM:

File Name: [Link]

public class Calculator {

public int add(int a, int b) {
return a + b;
}
public int subtract(int a, int b) {
return a - b;
}
public int multiply(int a, int b) {
return a * b;
}
public int divide(int a, int b) {
if (b == 0) throw new ArithmeticException("Cannot divide by
zero");
return a / b;
}
}
File Name: [Link]
import static [Link].*;
import [Link];

public class CalculatorTest {

Sudhan R – 722822104163 Department of Computer Science and Engineering

R19CB452 – Software Testing Page 15 of 42

Calculator calc = new Calculator();

@Test
public void testAddition() {
assertEquals(10, [Link](5, 5));
}

@Test
public void testSubtraction() {
assertEquals(0, [Link](5, 5));
}

@Test
public void testMultiplication() {
assertEquals(25, [Link](5, 5));
}

@Test
public void testDivision() {
assertEquals(1, [Link](5, 5));
}

@Test(expected = [Link])
public void testDivideByZero() {
[Link](5, 0);
}
}
public void testSubtraction() {
assertEquals(0, [Link](5, 5));
}
public void testMultiplication() {
assertEquals(25, [Link](5, 5));
}
public void testDivision() {
assertEquals(1, [Link](5, 5));
}
@Test(expected = [Link])
public void testDivideByZero() {
[Link](5, 0);
}
}

OUTPUT:
JUnit version 4.13.2
Time: 0.012
OK (5 tests)

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 16 of 42

Criterion Max Obtained

Preparation 20
Implementation 25
Result 20
Viva 10
Total 75

RESULT:

All existing test cases passed successfully. Regression testing confirmed that the new feature did not
break or alter core functionalities of the mobile banking [Link] system is stable and ready for
release.

Ex. No: 6
White-Box Testing of Banking Transaction Function
Date:

AIM:

To implement white-box testing for a banking system by executing unit tests, analysing code
complexity, and performing coverage testing on the transaction (transfer Money) functionality.

SOFTWARE REQUIRED:

● Microsoft Word (for documentation)

● Any Project Management Tool (Trello)

PROCEDURE:

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 17 of 42

⮚ Step 1: Set up the testing environment by installing Jest and ESLint.

⮚ Step 2: Implement the transfer function to handle transactions securely.
⮚ Step 3: Write and execute unit test cases using Jest to validate scenarios like:

o Invalid input
o Non-existing accounts
o Insufficient balance
o Successful transaction

⮚ Step 4: Perform code complexity analysis using ESLint to ensure function simplicity and
maintainability.
⮚ Step 5:Run coverage testing using Jest to measure the percentage of code exercised.
⮚ Step 6: Refactor code if complexity or line limits are exceeded.
⮚ Step 7:Re-run tests to ensure correctness after changes.

PROGRAM:

File Name: [Link]

const db = require('./database');
async function transferMoney(fromAccount, toAccount, amount) {
if (!fromAccount || !toAccount || amount <= 0) {
throw new Error('Invalid transaction details');
}
const sender = await [Link](fromAccount);
const receiver = await [Link](toAccount);
if (!sender || !receiver) {
return { status: 400, message: 'Invalid account details' };
}
if ([Link] < amount) {
return { status: 400, message: 'Insufficient funds' };
}
[Link] -= amount;
[Link] += amount;
await [Link](sender);
await [Link](receiver);
return { status: 200, message: 'Transfer successful' };
}
[Link] = { transferMoney };

File Name: [Link]

const { transferMoney } = require('./transferMoney');

const db = require('./database');
// Mock database functions
[Link]('./database');
describe('White-Box Testing: Transfer Money Function', () => {
it('should throw an error for invalid input', async () => {
await expect(transferMoney(null, 'acc2',
100)).[Link]('Invalid transaction details');

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 18 of 42

await expect(transferMoney('acc1', null,

100)).[Link]('Invalid transaction details');
await expect(transferMoney('acc1', 'acc2', -
50)).[Link]('Invalid transaction details');
});
it('should return error for non-existing accounts', async () => {
[Link](null);
[Link]({ balance: 500 });
const response = await transferMoney('acc1', 'acc2', 100);
expect(response).toEqual({ status: 400, message: 'Invalid
account details' });
});
it('should return error for insufficient funds', async () => {
[Link]({ balance: 50 });
[Link]({ balance: 500 });
const response = await transferMoney('acc1', 'acc2', 100);
expect(response).toEqual({ status: 400, message: 'Insufficient
funds' });
});
it('should complete transaction successfully', async () => {
[Link]({ balance: 500 });
[Link]({ balance: 200 });
[Link](true);
[Link](true);
const response = await transferMoney('acc1', 'acc2', 100);
expect(response).toEqual({ status: 200, message: 'Transfer
successful' });
});
});

File Name: [Link]

{
"env": {
"node": true,
"jest": true
},
"extends": "eslint:recommended",
"rules": {
"complexity": ["error", { "max": 5 }],
"max-depth": ["error", 4],
"max-lines-per-function": ["error", 20]
}
}

White Box Test Cases Table:

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 19 of 42

Process Expected Actual

Test Case Steps Description Status Comment
No. Result Result
Call Throws
Invalid Input transferMoney Verify input 'Invalid As
TC001 Done -
Handling with null or validation transaction Expected
negative values details'
Returns
Non-Existing Pass a sender Verify error for
status 400, As
TC002 Sender account ID that invalid sender Done -
message Expected
Account doesn’t exist account
accordingly
Returns
Non-Existing Pass a receiver Verify error for
status 400, As
TC003 Receiver account ID that invalid receiver Done -
message Expected
Account doesn’t exist account
accordingly
Returns
Sender balance is Ensure
Insufficient status 400, As
TC004 less than transfer transaction is Done -
Balance insufficient Expected
amount blocked
funds
Valid sender, Returns
Ensure transfer is
Successful receiver, and status 200, As
TC005 completed Done -
Transaction sufficient success Expected
successfully
balance message

Complexity Validate Code within

Run ESLint and As Refactored
TC006 and Coverage maintainability Done limits, 100%
Jest coverage Expected for clarity
Check and completeness test coverage

OUTPUT:

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 20 of 42

Criterion Max Obtained

Preparation 20
Implementation 25
Result 20
Viva 10
Total 75

RESULT:

White-box testing of the transferMoney function helps ensure that the internal logic, control flows,
and data handling mechanisms operate correctly. This includes validating edge cases, reducing
function complexity, and maximizing test coverage to create a secure and maintainable transaction
system.

Ex. No: 7 Apply Test Management Techniques to Create a Detailed Test Plan for a
Date: Specific Module of a Mobile Banking Application

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 21 of 42

AIM:

To apply test management techniques and create a detailed test plan for the Fund Transfer module of a
Mobile Banking Application.

PROCEDURE:

⮚ Step 1: Identify the Scope: Determine the scope of testing, including the features and
functionalities that need to be tested.
⮚ Step 2: Define Test Objectives: Specify the primary objectives of testing, such as functional
testing, usability testing, performance testing, security testing, etc.
⮚ Step 3: Identify Test Environment: Define the platforms, browsers, devices, and operating
systems on which the application will be tested.
⮚ Step 4: Determine Test Deliverables: Decide on the documents and artifacts that will be
generated during the testing process, such as test cases, test reports, and defect logs.
⮚ Step 5: Test Case Design: Prepare detailed test cases based on the requirements and
functionalities of the e-commerce application.
⮚ Step 6: Test Data Setup: Arrange test data required for executing the test cases effectively.
⮚ Step 7: Test Execution:
⮚ Run the prepared test cases systematically in the defined test environment. Document the
actual outcomes and compare them with expected results to determine pass/fail status.
⮚ Step 8.: Defect Reporting: Log all identified defects with details like severity, steps to
reproduce, and screenshots. Monitor the status of each defect until it is fixed and verified.

TEST PLAN:

The test plan should cover the following sections:

1. Introduction: Briefly describe the purpose of the test plan and provide an overview of the e-
commerce application to be tested.
2. Test Objectives: List the primary objectives of testing the application.
3. Test Scope: Specify the features and functionalities to be tested and any limitations on testing.
4. Test Environment: Describe the hardware, software, browsers, and devices to be used for testing.
5. Test Strategy: Explain the overall approach to be followed during testing.
6. Test Schedule: Provide a detailed timeline for each testing phase.
7. Risk Analysis: Identify potential risks and the strategies to mitigate them.
8. Resource Planning: Specify the resources required for testing.
9. Test Case Design: Include a summary of the test cases developed for the application.
10. Test Data Setup: Describe the process of arranging test data for testing.
11. Defect Reporting: Explain the procedure for reporting and tracking defects.

TEST PLAN TABLE:

Test Case Feature Description Steps Expected Actual Result

No Result

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 22 of 42

TC1 User Verify login Enter valid redirected to Successfully

Authentication with valid username and home screen redirected to home
credentials password, tap screen
login
TC2 Account Verify Login, check Correct Correct balance
Balance balance balance on home balance shown
display on screen displayed
homepage
TC3 Fund Verify fund Select 'Transfer', Fund Fund transferred
Transfer transfer to enter recipient transferred successfully
valid account details, confirm successfully
TC4 Bill Payment Verify bill Navigate to 'Pay Bill paid and Bill paid and
payment Bills', select confirmation confirmation
functionality biller, enter a shown received
TC5 Logout Verify user Tap on profile or User redirected Successfully
Functionality can log out menu > select to login screen logged out
'Logout'

Criterion Max Obtained

Preparation 20
Implementation 25
Result 20
Viva 10
Total 75

RESULT:

The test plan is essential for outlining the testing strategy of the mobile banking application. It ensures
that key features like login, fund transfers, and account security are thoroughly validated. Systematic
documentation of test cases helps maintain quality and reliability.

Ex. No: 8
Test Process Maturity Model for the Mobile Banking App
Date:

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 23 of 42

AIM:

To develop and implement a Test Process Maturity Model (TPMM) tailored to a mobile banking
application in order to improve the quality, security, and reliability of the testing lifecycle.

PROCEDURE:

Step 1: Requirement Analysis

● Understand the features of the mobile banking app: Login, View Balance, Fund Transfer, Bill
Payment, Biometric Authentication, etc.
● Identify critical testing areas:
● Security testing (authentication, data encryption, session management)
● Performance testing (load handling, response time)
● Functional testing (validations, transaction flows)
● Usability testing (UI/UX, accessibility)
Step 2: Define the Customized Test Process Maturity Model (TPMM)
Adapt a 5-level TPMM similar to TMMi, tailored for mobile banking apps:

Level Maturity Level Description Focus Area Key Characteristics

Initial Ad Hoc / No formal testing Functional ● No documentation

Unstructured process; testing is Testing only ● Manual testing
reactive and ● No test planning or
inconsistent. metrics
● Unpredictable
results
Repeatable Basic Process Some structure Functional + ● Basic test plans
exists; repeatable test Basic ● Some reusable test
cases, but not Regression cases
standardized. ● Bug tracking
introduced
● Informal reporting
Defined Process Defined & Testing activities are Functional, ● Formal test strategy
Documented defined, Regression, ● Test case templates
documented, and Security and reviews
standardized. ● Security test
planning
● Tool adoption (e.g.,
Selenium, Appium)
Managed Metrics & Testing is measured Automation, ● Automated test
Automation and controlled using Performance, suites
Driven KPIs and Security ● Performance testing
automation. using tools (e.g.,
JMeter)
● Defect trend

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 24 of 42

analysis
● Test coverage
tracking
● Security tools
integration

Optimized Continuous Continuous process AI-based

Improvement & improvement using Testing, Risk-
Innovation advanced techniques. based Testing,
CI/CD
● Risk-based and
exploratory
testing
● AI/ML usage in
test prediction
● Continuous
Testing in CI/CD
● Predictive defect
analytics
● Feedback loops
from production
Step 3 : Assess the Current Maturity Level
● Use a TPMM checklist to assess current testing practices.
● Evaluate across categories:
o Test Planning
o Test Design
o Execution & Automation
o Defect Management
o Metrics & Monitoring
Step 4 : Design and Implement Improvements
● Develop missing documentation (test plan, traceability matrix, security test cases).
● Automate test cases using Appium.
● Integrate performance testing using JMeter.
● Add security testing using MobSF or Burp Suite.
● Set up a metrics dashboard for KPIs like defect density, coverage, and response time.

Step 5: Reassess the Maturity Level

● Reevaluate using the same TPMM checklist.
● Map the improvements to a new maturity level.
● Compare key performance metrics before and after improvement.

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 25 of 42

Sample Test Cases Table:

Level Test Case ID Test Case Objective Steps Expected Result

Name
Level 1 - TC1 Basic Check if 1. Open the User is logged in
Initial Functionality basic login mobile banking successfully.
Check functionality app.
works. 2. Enter valid user
credentials.
3. Click "Login".
Level 1 - TC2 Unexpected Check if the 1. Open the The app should
Initial Scenario app crashes mobile banking display an error
(Crash) under app. message and not
unexpected 2. Try to perform crash.
scenarios. a transaction
without entering
any amount.
3. Click "Submit".
Level 2 - TC3 Login with Ensure that 1. Open the The app displays
Managed Invalid invalid login mobile banking an error message:
Credentials credentials app. "Invalid username
trigger an 2. Enter invalid or password".
error login credentials.
message. 3. Click "Login".
Level 2 - TC4 Transfer Test basic 1. Log in with Transaction is
Managed Funds fund transfer valid credentials. successfully
Between functionality. 2. Go to completed, and
Accounts "Transfer" section. updated balance is
3. Enter amount shown.
and select
recipient.
4. Click "Submit".
Level 3 - TC5 Password Ensure that 1. Open the app. The user resets the
Defined Reset the password 2. Click on password and logs
Functionality reset "Forgot in with the new
functionality Password". credentials.
works. 3. Enter a valid
email.
4. Reset password
via link.
Level 3 - TC6 Multi-factor Verify the 1. Log in with User is
Defined Authentication MFA valid credentials. successfully
(MFA) During functionality 2. Enter OTP sent authenticated with
Login during login. to email/phone. MFA.
3. Log in.
Level 4 - TC7 Performance Ensure the 1. Open the The app should
Measured Test (App app launches mobile banking load within 2-3
Launch Time) within an app. seconds.
acceptable 2. Measure time to
time. load the home
screen.
Level 4 - TC8 Test for Ensure no 1. Perform Existing features
Measured Defect existing functionality tests. should work after
Leakage features 2. Verify old changes.
(Regression break after features still work
Testing) updates. after new changes.
Level 5 - TC9 Automated Ensure 1. Push code Automated tests

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 26 of 42

Optimized Regression automated changes to the run successfully,

Testing regression repository. and reports are
(CI/CD) tests run on 2. Monitor CI/CD generated.
each code pipeline for
commit. automated tests.
Level 5 - TC10 Risk-Based Test critical 1. Identify high- Critical
Optimized Testing for transactions risk transactions. transactions
Critical for edge 2. Test edge cases should handle
Transactions cases. using automated edge cases with
or manual tests. proper error
handling.

Criterion Max Obtained

Preparation 20
Implementation 25
Result 20
Viva 10
Total 75

RESULT:
The implementation of a customized Test Process Maturity Model for the mobile banking app resulted
in significant improvements in testing efficiency, quality assurance, and risk management. The
maturity level increased from Level 2 (Repeatable) to Level 4 (Managed), showcasing clear progress
in testing processes, documentation, automation, and monitoring.

Ex. No: 9 Design and Implement a Comprehensive Automated Test Suite for an
E-Commerce Website Using Selenium.
Date:

AIM:

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 27 of 42

To design and implement an automated test script using Selenium WebDriver for testing the core
functionalities of an e-commerce website such as Amazon, including launching the browser,
performing a product search, selecting a product, adding it to the cart, and verifying successful
addition — simulating a typical user journey for quality assurance in web applications.

Tools and Software Required:

● Java Development Kit (JDK) (Version 8 or above)

● IntelliJ IDEA / Eclipse IDE
● Selenium WebDriver
● Google Chrome Browser
● Chrome Driver Executable
● Maven or Manual Jar Management

Procedure:

⮚ Step 1: Install JDK and set up Java on your system.

⮚ Step 2: Install IntelliJ IDEA or Eclipse and create a new Java project.
⮚ Step 3: Add Selenium WebDriver library to the project.
⮚ Step 4: Download the appropriate ChromeDriver for your version of Chrome and set the path
or Maven.
⮚ Step 5: Write a Java program to:

⮚ Launch Chrome browser

⮚ Open e
⮚ Enter the text “xyz(e-commerce web site)” in the search bar
⮚ Press ENTER key

⮚ Step 6: Run the program and observe the automated search in Chrome.

Code:

package firsttest;
import [Link];
import [Link];
import [Link];
import [Link];

public class nexttest {

public static void main(String[] args) {
// [Link]("[Link]",
"path/to/chromedriver");
WebDriver Window = new ChromeDriver();
[Link]("[Link]
[Link]([Link]("APjFqb")).sendKeys("[Link]",
[Link]);
[Link]([Link]("h3")).click(); // Basic,
assumes first result is correct

[Link]([Link]("twotabsearchtextbox")).sendKeys("laptop",
[Link]);
[Link]([Link](".s-main-slot .s-result-
item h2 a")).click();

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 28 of 42

[Link]([Link]("add-to-cart-button")).click();
WebElement confirmationMessage =
[Link]([Link]("#sw-gtc .a-button-input"));
if ([Link]()) {
[Link]("Test Passed: Item added to cart
successfully.");
} else {
[Link]("Test Failed: Item not added to
cart.");
}
[Link]();
}
}

Screenshots:

Sudhan R – 722822104163 Department of Computer Science and Engineering

R19CB452 – Software Testing Page 29 of 42

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 30 of 42

Criterion Max Obtained

Preparation 20
Implementation 25
Result 20
Viva 10
Total 75

RESULT:

The automated test script was successfully executed using Selenium WebDriver. The script opened
the browser, navigated to Google, searched for "[Link]", visited the Amazon website, searched
for a product, selected the first item from the results, and added it to the cart.

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 31 of 42

Ex. No: 10 Design A Data-Driven Automated Testing Solution using Selenium that can
Dynamically Generate Test Cases based on Different Sets of Input Data
Date:

AIM:

To design and implement a data-driven automated testing solution using Selenium WebDriver that
dynamically generates and executes test cases based on different sets of input data, thereby improving
test coverage and reducing redundancy.

Procedure

⮚ Step 1: Set up Selenium WebDriver and ChromeDriver.

⮚ Step 2: Prepare an external data source (e.g., a 2D array, CSV, Excel, or database) containing
multiple test inputs (e.g., different product names).
⮚ Step 3: Loop through the input data and:

o Open browser
o Navigate to Amazon via Google
o Search each product
o Click the first result
o Attempt to add the item to cart
o Log the result (pass/fail)

⮚ Step 4: Close the browser after all test cases have executed.
⮚ Step 5: Print the summary of test results.

Code:

package firsttest;
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];

public class DataDrivenTest {

public static void main(String[] args) {

String[] products = {"laptop", "headphones", "smartphone"}

for (String product : products) {
WebDriver driver = new ChromeDriver();
[Link]().window().maximize();
[Link]().timeouts().implicitlyWait(10,
[Link]);
try {
[Link]("[Link]
[Link]([Link]("q")).sendKeys("[Link]
m", [Link]);
[Link]([Link]("h3")).click(); //
Open Amazon

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 32 of 42

[Link]([Link]("twotabsearchtextbox")).sen
dKeys(product, [Link]); // Search product
[Link]([Link](".s-main-slot .s-
result-item h2 a")).click(); // First product
[Link]([Link]("add-to-cart-
button")).click(); // Add to cart
if ([Link]([Link]("#sw-gtc .a-
button-input")).isDisplayed()) {
[Link]("PASS: " + product + " added
to cart.");
} else {
[Link]("FAIL: " + product + " not
added.");
}
} catch (Exception e) {
[Link]("ERROR: Test for '" + product +
"' failed due to " + [Link]());
} finally {
[Link]();
}
}
}
}

Dynamically Generate Test Cases Table:

Test Case ID Test Scenario Test Steps Test Data Expected Output
(Input)
TC_DDT_001 Add multiple products 1. Open "laptop" Laptop added to cart
to cart (DDT) browser successfully
2. Navigate to
Google
3. Search for
Amazon
4. Open
Amazon
5. Search
product
6. Click first
result
7. Add to cart
8. Confirm
added

TC_DDT_002 Same as above Same as above "headphones" Headphones added to

cart successfully
TC_DDT_003 Same as above Same as above "smartphone" Smartphone added to
cart successfully

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 33 of 42

Screenshort:

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 34 of 42

Criterion Max Obtained

Preparation 20
Implementation 25
Result 20
Viva 10
Total 75

RESULT:

The data-driven automated testing solution was successfully implemented using Selenium WebDriver.
The script dynamically executed test cases for multiple input products by performing search and add-
to-cart operations on the Amazon website. Each test case ran independently and validated the addition
of the product to the shopping cart. The results for each test case were printed on the console,
confirming successful execution and dynamic test generation based on input data.
Ex. No: 11 Mini Project – Library Management System

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 35 of 42

Date:

TITLE: Library Management System

PROBLEM DESCRIPTION:
Managing physical and digital library assets manually leads to inefficiencies such as delayed book
tracking, difficulty in monitoring borrowed/returned books, limited availability status, and lack of
real-time access. Additionally, libraries face challenges in maintaining user records, handling
concurrent requests, and ensuring data consistency in a distributed environment.
PROPOSED SOLUTION:

The Library Management System is a web-based application developed using Vite + React for a fast
and responsive frontend, styled with Tailwind CSS, and backed by Cloudflare KV Database for a
low-latency, globally distributed storage layer. The system was deployed using Cloudflare, ensuring
high availability and performance.

The application supports features such as:

● Admin management for adding/removing books

● User management and login system
● Book search and filter
● Real-time inventory update
● Persistent storage of users and book data in Cloudflare KV

OBJECTIVES:

1) To apply Object-Oriented Analysis and Design (OOAD) principles such as abstraction,

encapsulation, and modularity to design a structured and maintainable Library Management
System.
2) To use UML diagrams (like Use Case Diagram, Class Diagram, and Sequence Diagram) to
visually model the system's behavior, structure, and interactions among components.
3) To implement a working prototype of the Library Management System using Vite + React,
Tailwind CSS, and Cloudflare KV Database with real-time functionalities like book issuing,
returning, and user management.
4) To ensure software quality by conducting systematic testing (unit testing, integration testing,
and manual functional testing) to verify correctness, reliability, and performance of the
application.

SYSTEM REQUIREMENTS

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 36 of 42

a. Functional Requirements

1) User registration and login functionality

2) Admin functionalities: add, update, delete books
3) Users can search, filter, and view book details
4) Persistent data storage using Cloudflare KV

b. Non-Functional Requirements

1) Performance: Fast page load and low-latency responses using Cloudflare Edge deployment
2) Security: Basic authentication mechanisms, secure data transfer over HTTPS
3) Usability: Simple, responsive UI using Tailwind CSS for ease of use on all devices
4) Scalability: Globally distributed Cloudflare KV ensures scalability across users and locations

TOOLS & TECHNOLOGIES

1) Programming Language: Typescript

2) Frontend Framework: React (with Vite for fast development)
3) Styling: Tailwind CSS
4) Deployment Platform: Cloudflare Pages & Workers
5) Database: Cloudflare KV (Key-Value based distributed storage)
6) UML Tool: Lucidchart or [Link] (for Use Case, Class, Sequence Diagrams)
7) Testing: Manual browser-based testing
8) Version Control: Git + GitHub

DESIGN PATTERN:
1) Component-Based (React-Specific MVC Adaptation)
o The application follows an MVC-like structure, where:

▪ View: React components (e.g., BookCard, Dashboard, LoginForm)

▪ Model: Cloudflare KV data (users, books, transactions)
▪ Controller logic: JavaScript functions managing actions (e.g., handleBorrow,
handleLogin)
2) Singleton Pattern
o You likely created a single shared interface to read/write from Cloudflare KV.
Example: A single kvClient or utility module for database operations used across
components.
3) Factory Pattern
o You probably used functions to generate standardized data objects like books or
users before storing them.
Example: createBookEntry(title, author, available) returns a book object.
4) Observer Pattern (React State System)

Sudhan R – 722822104163 Department of Computer Science and Engineering

R19CB452 – Software Testing Page 37 of 42

o React’s useState, useEffect hooks behave like the observer pattern:

When state changes (e.g., book list updates), the UI re-renders automatically.
5) Facade Pattern
o You likely built utility functions (e.g., getAllBooks(), issueBookToUser()) to hide
Cloudflare KV’s complexity.
These act as a simple interface for your UI components to interact with the backend.
SYSTEM DESIGN (OOAD)
● Class Diagram

● Use Case Diagram

Sudhan R – 722822104163 Department of Computer Science and Engineering

R19CB452 – Software Testing Page 38 of 42

● State Diagram

● Activity Diagram

Sudhan R – 722822104163 Department of Computer Science and Engineering

R19CB452 – Software Testing Page 39 of 42

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 40 of 42

SOFTWARE TESTING
• Testing Types Used:
● Unit Testing
● Integration Testing
● System Testing
• Tools Used:
● Manual Testing
● Browser DevTools (for UI behavior)
● Jest (for unit testing React components)
• Sample Test Cases:

Expected Actual
[Link] Test Case Steps Description Status
Result Result

Enter book
List of List of
name in
To test search matching matching
TC001 Book Search search input Passed
functionality books books
→ Click
shown shown
search

Login as user
Book status Book status
→ Click To verify
TC002 Book Borrow Passed updated to updated to
borrow on a borrow process
"borrowed" "borrowed"
book

Login as
librarian → To test book Book Book
Add Book
TC003 Fill form → addition Passed appears in appears in
(Librarian)
Click add functionality catalog catalog
book

Enter wrong
Test error Error Error
credentials
TC004 Invalid Login handling on Passed message message
→ Click
login displayed displayed
login

Responsive Responsive
UI Open site on Test UI
TC005 Passed layout layout
Responsiveness mobile/tablet responsiveness
shown shown

• Bug Tracking:
● No formal tool used. Bugs and fixes tracked manually during development using a shared
Notion page.

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 41 of 42

• Test Reports Summary:

● All core modules (Book Search, View, Borrow, Add, Delete) passed functional tests.
● No critical bugs found in final version.
● UI passed basic cross-browser and mobile device checks.
RESULTS & SCREENSHOTS
Login Page

Home Page

Sudhan R – 722822104163 Department of Computer Science and Engineering

 R19CB452 – Software Testing Page 42 of 42

About Website:

Comments

CONCLUSION:

The Library Management System project successfully demonstrated the application of Object-
Oriented Analysis and Design (OOAD) principles in building a structured and scalable software
solution. The system allowed users to search, borrow, and return books, while administrators could
efficiently manage book inventory—all through a clean, responsive interface developed using Vite +
React and Tailwind CSS. Data persistence and performance were ensured through the integration of
Cloudflare KV, providing global access with low latency.

Sudhan R – 722822104163 Department of Computer Science and Engineering