Laboratory file

on
SOFTWARE ENGINEERING AND METHODOLOGY

School of Engineering and Technology

Department of Computer Science and Engineering

Subject code – CSP 357

SUBMITTED BY: SUBMITTED TO:

Name : Ujjawal Rajput Mr. Ashish Kumar
System Id: 2023516542

Sharda University
Greater Noida, Uttar Pradesh
 DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

SHARDA UNIVERSITY, GREATER NOIDA

COURSE L T P C
CODE COURSE TITLE
Software Engineering and Testing
CSP 357 Methodologies 0 0 2 1

CO1: Examine the need of developing software solutions.

CO2: Understanding the modeling language (UML) .
CO3: Adapt techniques and tools necessary for software testing practices.
CO4: Prepare test plan and cases for different applications.
CO5: To develop skills in software test automation and management using latest tools
CO6: Design test plan for an application and test the software for performance
measures

Sign. of Course Coordinator Sign. of Lab. Coordinator Sign. of HOD

Name of Course Coordinator Name of Lab. Coordinator Prof. (Dr.) Sudeep Varshney
 LIST OF EXPERIMENTS
COURSE DATE
S.NO. EXPERIMENT NAME OUTCOME

Design requirement analysis and develop Software Requirement

Specification Sheet (SRS) for suggested system in IEEE
1 standard. CO1

Draw the user‘s view analysis for the suggested system: Use case
2 diagram, Activity Diagram and State chart Diagram. CO2

Draw the structural view diagram for the system: Class

3 diagram, object diagram and Sequence diagram. CO2

Perform Unit testing of calculator program using Junit testing

4 framework. CO3

Perform Integration testing of calculator program using

5 Junit testing framework. CO3

Design Test Case for Inventory Management System based on

6 System Specification. CO4

Design Test cases and perform manual testing of login module

7 of FlipKart (as an example). CO5

VALUE ADDED EXPERIMENTS

COURSE
S.NO. EXPERIMENT NAME OUTCOME

A Selenium API setup and creation of Maven project. CO6

B Perform automation testing using methods Maximise, minimize CO6

and window close.

C Identification of web elements using X-Path and CSS. CO6

D Perform automation testing of checkbox , radio button of CO6

application.

E Perform isDisplayed, isSelected and isEnabled in for validation CO6

in testing.
 Date:18th July, 2025
Experiment: 01

Aim: Design requirement analysis and develop Software Requirement Specification Sheet (SRS) for
IndieKart- E-commerce platform for local handicrafts in IEEE standard.

1. Introduction
1.1 Purpose
This SRS outlines the functional and non-functional requirements for IndieKart, an e-commerce
platform aimed at promoting and selling locally made handicrafts. The document is intended for
developers, testers, project managers, and stakeholders involved in the design, development, and
deployment of the system.

1.2 Scope
IndieKart allows local artisans to showcase their products and reach wider markets. The system includes
modules for user registration, product browsing, cart management, checkout process, event discovery,
wishlist features, and order tracking. The final product will be a responsive web application.

1.3 Definitions, Acronyms, and Abbreviations

 UI: User Interface
 DBMS: Database Management System
 SKU: Stock Keeping Unit
 COD: Cash on Delivery
 SRS: Software Requirement Specification

2. Overall Description
2.1 Product Perspective
IndieKart is a standalone e-commerce platform focused on the Indian handicrafts market. It may
integrate with third-party payment gateways and shipping services.

2.2 Product Functions

 User Registration & Login
 Browse and search products
 Add to Cart and Wishlist
 Secure Checkout with multiple payment options
 Order Management and Confirmation
 Admin panel for managing products and orders
 Event listing for workshops and fairs

2.3 User Classes and Characteristics

 Customer: General users with basic tech knowledge
 Artisan/Seller: Skilled craftspeople; need simple product upload system
 Admin: Technical users managing the platform

2.4 Operating Environment

 Frontend: HTML5, CSS3, JavaScript
 Browser: Chrome, Firefox, Safari
 OS: Windows, Linux, Android
2.5 Design and Implementation Constraints
 Use of open-source technologies
 Mobile responsiveness required
 Compliance with standard web security practices

2.6 Assumptions and Dependencies

 Users have stable internet connection
 Payment gateway integration is available
 Artisans provide accurate product information

3. Specific Requirements
3.1 External Interfaces
3.1.1 User Interfaces
 Responsive UI with navigation bar, product cards, filters
 Admin dashboard with tabs for Products, Orders, Users

3.1.2 Hardware Interfaces

 None specific; runs on user’s web browser

3.1.3 Software Interfaces

 Firebase / MongoDB for DB
 Payment APIs (Razorpay/Paytm)
 Optional: Email API for notifications

3.1.4 Communication Interfaces

 HTTPS for secure data transfer
 REST APIs for data interaction

3.2 Functional Requirements

 FR1: The system shall allow users to register and log in
 FR2: Users shall be able to browse and search products
 FR3: Products shall be filterable by category, price, or popularity
 FR4: Users can add/remove items from cart and wishlist
 FR5: Users can checkout with multiple payment methods
 FR6: Admin can add/edit/delete products
 FR7: The system shall display order history to users

3.3 Performance Requirements

 Page load time < 2 seconds
 Handle 100+ concurrent users
 Real-time cart updates

3.4 Design Constraints

 Use Firebase or Node.js for backend
 Frontend must use vanilla JS or a framework like Angular

3.5 Quality Attributes

 Usability: Simple and intuitive design
 Reliability: 99% uptime
 Security: Encrypted login, secure payment
  Maintainability: Modular architecture
 Scalability: Future integration of Android/iOS apps

3.6 Documentation Requirements

 User Manual
 Developer Guide
 Admin Control Documentation

3.7 Security Requirements

 User authentication with session management
 Encrypted payment and personal data
 Role-based access control

3.8 Legal and Compliance Requirements

 Must comply with Indian e-commerce policies

3.9 Change Management and Version Control

 Git-based version control
 All changes logged in GitHub with version tagging

3.10 Maintenance and Support

 Bug fixes and feature updates every month

Result: The SRS for IndieKart has been successfully developed following the IEEE 830-1998 standard.
It clearly outlines the system’s scope, functional and non-functional requirements, and external
interfaces. The document provides a solid foundation for designing, developing, and testing the e-
commerce platform. It ensures better communication among stakeholders and supports structured
development with defined performance, security, and usability goals.
 Date:25th July, 2025
Experiment: 01 (Part 2)

Aim: In your opinion, what is the most frustrating software you’ve ever used, and why?

In my opinion, the older version of the IRCTC ticket booking website was one of the most frustrating
pieces of software I’ve used. It had poor design decisions and lacked proper functional and non-
functional requirements, especially noticeable during Tatkal booking hours when speed and reliability
are critical.

Functional Requirements (Poorly implemented):

1. User Authentication and Session Management
o Sessions would expire too quickly and often while filling forms, leading to user
frustration.
2. Train Search and Seat Availability
o The displayed availability was often not in real-time, causing booking errors or failed
transactions.
3. Ticket Booking Workflow
o The booking process was unnecessarily long and required too many steps without
guidance.
4. Payment Integration
o Payments would frequently fail due to poor integration with banks and gateways.

Non-Functional Requirements (Lacked or weakly implemented):

1. Performance and Scalability
o The system would crash or hang during high traffic times like Tatkal bookings.
2. Usability and User Experience (UX)
o The interface was cluttered, confusing, and not user-friendly, especially for first-time
users.
3. Reliability and Fault Tolerance
o If a payment failed, there was no smooth retry mechanism or Instant refund confirmation.
4. Mobile and Accessibility Support
o The site wasn’t responsive or accessible for differently-abled users or mobile phone
users.

Result:
The IRCTC website is a perfect case study of how missing or poorly defined functional and non-
functional requirements can lead to user frustration. Over time, many of these issues were addressed, but
the early version is a good reminder of why clear, user-centered software design is essential.
 1. Draw the user‘s view analysis for the suggested system: Use case diagram, Activity
Diagram and State chart Diagram.

Use Case Diagram:

A use case diagram illustrates the system's functionality from the user's perspective. It shows the interactions
between actors (users or external systems) and use cases (specific functionalities or features).
Actors: These represent the external entities interacting with the system. Actors can be people, other systems,
or even time-triggered events.
Use Cases: These are specific functionalities or features that the system offers to its users. Each use case
represents a specific interaction or task that a user can perform.
Activity Diagram:

An activity diagram illustrates the workflow or process flow of a specific use case or scenario. It can help you
detail how a particular use case is carried out.
Actions: These represent specific steps or actions within the workflow.

Control Flow: Arrows show the sequence of actions, indicating the order in which they occur.
Decision Nodes: These represent decision points where the workflow can take different paths based on
conditions.
Fork and Join Nodes: These indicate parallel processing and synchronization of flows.
State Chart Diagram:

A state chart diagram shows the different states that an object or system can be in and the transitions between
these states. It's often used to model the behavior of an entity over time.
States: These represent conditions or phases that an object can be in.
Transitions: Arrows show the triggers and conditions that cause an object to move from one state to another.
Events: Events are triggers or stimuli that initiate state transitions.
Actions: Actions represent the activities or operations that occur when a state transition happens.
 2. Draw the structural view diagram for the system: Class diagram, object diagram and
Sequence diagram.

Class Diagram:

A class diagram is used to represent the static structure of a system, showcasing the classes, their attributes,
methods, and their relationships.
Classes: Rectangles represent classes. Each class includes the class name, attributes, and methods.
Attributes: These are represented as name: type pairs within the class rectangle.
Methods: These are listed beneath the class name within the class rectangle.
Associations: Lines connecting classes represent associations or relationships between classes. You can label
associations to indicate their nature (e.g., one-to-many).
Inheritance: An open arrowhead line indicates inheritance or a parent-child relationship between classes.
Sequence Diagram:

A sequence diagram illustrates the interactions and messages exchanged between objects or components in a
particular scenario or use case.
Lifelines: Vertical lines represent the lifelines of objects or actors involved in the scenario.
Messages: Horizontal arrows show the flow of messages between objects. Labels on the arrows describe the
type of message or method call.
Activation Bars: Activation bars show the period during which an object is active and processing a message.
Return Messages: Dashed arrows represent return messages when an object responds to a message.

Object Diagram:

An object diagram represents a specific snapshot of a system at a particular point in time, showing instances of
classes and their relationships.
Objects: These are represented by rectangles with the object's name and its class name inside.

Links: Lines connecting objects show relationships between objects. Label these lines to describe the nature of
the relationship.
Attributes and Values: You can show the values of the object's attributes within the object rectangle.
 3. Perform Unit testing of calculator program using Junit testing framework.

import org.junit.Test;
import static org.junit.Assert.assertEquals;

public class CalculatorTest {

@Test
public void testAddition() {
Calculator calculator = new Calculator();
assertEquals(5, calculator.add(2, 3));
}

@Test
public void testSubtraction() {

Calculator calculator = new Calculator();

assertEquals(2, calculator.subtract(5, 3));
}

@Test
public void testMultiplication()
{ Calculator calculator = new
Calculator();
assertEquals(15, calculator.multiply(5, 3));
}

@Test
public void testDivision() {
Calculator calculator = new Calculator();
assertEquals(2, calculator.divide(10, 5));
}
}
 4. Perform Integration testing of calculator program using Junit testing framework
you have a Calculator class that provides methods for performing arithmetic operations:
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("Division by zero");
}
return a / b;
}
}

Now, let's create an integration test for the Calculator class to verify that the operations work correctly when
combined:
java

import org.junit.Test;
import static org.junit.Assert.assertEquals;
public class CalculatorIntegrationTest {
@Test
public void testAdditionAndSubtraction()
{ Calculator calculator = new Calculator();
int result = calculator.subtract(calculator.add(5, 3), 2);
assertEquals(6, result);
}
 @Test
public void testMultiplicationAndDivision()
{ Calculator calculator = new Calculator();
int result = calculator.divide(calculator.multiply(4, 6), 2);
assertEquals(12, result);
}
}
 5. Design Test Case for Inventory Management System based on System Specification.
Designing test cases for an Inventory Management System (IMS) based on system specifications involves
creating scenarios and inputs to validate that the system functions correctly. Below, I'll provide a sample set of
test cases that cover various aspects of an IMS. Please note that this is a simplified example, and in a real-
world scenario, you would need to create more extensive test cases.
1. Test Case: Adding a New Item
Input:
Item Name: "Widget A"
Item Category: "Electronics"
Item Quantity: 100
Item Price: $10.99
Expected Output:
Item "Widget A" is added to the inventory with the correct details.
The total number of items in the inventory is updated to 101.

2. Test Case: Updating Item Information

Input:
Select item "Widget A"
Update Item Name to "Super Widget"
Update Item Category to "Gadgets"
Update Item Price to $12.99
Expected Output:
Item information is updated correctly.
Item "Widget A" is now "Super Widget" in the "Gadgets" category with a price of $12.99.

3. Test Case: Deleting an Item

Input:
Select item "Super Widget"
Delete item
Expected Output:
Item "Super Widget" is removed from the inventory.
The total number of items in the inventory is reduced by 1.

4. Test Case: Stock Replenishment

Input:
Select item "Super Widget"
Add 50 units to the existing stock
Expected Output:
The stock quantity for "Super Widget" is updated to 150.
The total number of items in the inventory is adjusted accordingly.

5. Test Case: Selling an Item

Input:
Select item "Super Widget"
Sell 10 units
Expected Output:
The stock quantity for "Super Widget" is reduced to 140.
The system records the sale and updates revenue and sales history.

6. Test Case: Generating Reports

Input:
Generate a sales report for the last month

Expected Output:
The system generates a report with accurate sales data for the specified period.

7. Test Case: User Permissions

Input:
Log in as a regular employee and try to delete an item
Expected Output:
The regular employee should receive a permission error when attempting to delete an item.

8. Test Case: Searching for Items

Input:

Search for items containing the keyword "Widget"

Expected Output:
The system returns a list of items with names or descriptions containing "Widget."
9. Test Case: Handling Invalid Input
Input:
Attempt to add an item with a negative price
Expected Output:
The system should display an error message indicating that the price is invalid.

10. Test Case: Performance and Scalability

Input:
Add a large number of items to the inventory (e.g., 10,000 items).
Expected Output:
The system should handle this load without significant performance degradation.
 6. Design Test cases and perform manual testing of login module of FlipKart (as an
example).
Test Cases for Flipkart Login Module:

Valid Login Credentials:

Input: Valid username and password.
Expected Output: Successful login; user is directed to their account page.

Invalid Username:
Input: Invalid/Non-existent username and a valid password.
Expected Output: An error message indicating that the username is incorrect.

Invalid Password:
Input: Valid username and an incorrect password.
Expected Output: An error message indicating that the password is incorrect.

Blank Username:
Input: Leaving the username field blank and providing a valid password.
Expected Output: An error message indicating that the username is required.

Blank Password:
Input: Providing a valid username and leaving the password field blank.
Expected Output: An error message indicating that the password is required.

Password Case Sensitivity:

Input: Valid username and password with incorrect case (e.g., "Password" instead of "password").
Expected Output: An error message indicating that the password is case-sensitive and incorrect.

Forgot Password Link:

Input: Clicking on the "Forgot Password" link.
Expected Output: The user is directed to a password recovery/reset page.

Remember Me Option:
Input: Checking the "Remember Me" checkbox during login.
Expected Output: The user's login session persists even after closing and reopening the browser.

Account Lockout After Multiple Failed Attempts:

Input: Providing incorrect login details multiple times (e.g., three times).
Expected Output: The account is locked, and the user is informed to reset their password or contact customer
support.

Login with Social Media Account:

Input: Logging in using a social media account (e.g., Google or Facebook).
Expected Output: Successful login and association of the social media account with the Flipkart account.
 VALUE ADDED EXPERIMENTS
A. Selenium API setup and creation of maven project
Selenium Setup:

• Install Java: Make sure you have Java Development Kit (JDK) installed on your system.
• Install Eclipse: You can use Eclipse as your integrated development environment (IDE).
• Install Maven: Maven can simplify project management.
• Download Selenium WebDriver: Download the WebDriver bindings for your preferred
programming language (e.g., Java) from the Selenium website.
• Create a Project Folder: Create a directory for your Selenium project.
• Setup WebDriver: Add the WebDriver executable (e.g., chromedriver.exe for Chrome) to
your project directory. Maven Project Setup:

• Open Eclipse: If you're using Eclipse, open it.

• Create a New Maven Project: Use the "File" menu to create a new Maven project and select
the appropriate archetype (e.g., Quickstart).
• Configure Project Details: Provide the group and artifact ID, and set the project location.
• Add Dependencies: In your pom.xml file, add dependencies for Selenium WebDriver and
any other libraries you plan to use.
• Build the Project: Use the Maven "clean" and "install" goals to build your project.

Step 1:- Go to File-> Go to New-> Others -> Maven Project to create a new Java project.

Step 2:- Add the dependencies to pom.xml file

Step 3:- Create the packages under the src/main/java folder and the src/test/java folder and start
writing the piece of code.

Step 4:- Write the code to perform tasks as per requirements specified.

B. Perform automation testing using methods Maximise, minimize and window close.
Output Analysis:-

Opened the chrome browser ,resized the browser, wait for a few seconds and closed the
browser.[ By automation ]
C. Identification of web elements using css and path
D. Perform automation testing of checkbox, radio button of application