PRACTICAL FILE

OF
SOFTWARE VERIFICATION & VALIDATION &
TESTING LAB

(SESSION 2020-2024)

University Institute of Engineering and Technology

Department of Computer Science and Engineering
Kurukshetra University
Kurukshetra-136119

Submitted to: Submitted by:

Dr. Naresh Kumar Kashish
CSE Department, UIET KUK 252002027
CSE A
7th Semester

1|Page
 INDEX

S.No. Practical Date Page. Signature

No.
To identify role of software in today’s
1. world across a few significant domains
3-7
related to day-to-day life.

To identify any scenario and identify

2. suitable software development model for
8-11
the given scenario.
To classify the requirement into functional
3. and non-functional requirements and list
12-13
four functional and non-functional
requirements for any scenario.

Do comparative study of various software

4. development models.
14-26

5. Preparation of requirement document for 27-34

standard application problems in standard
format. (e.g. Library Management System,
Railway Reservation system, Hospital
management System, University
Admission system)
To identify the usage of Regression
6. Testing.
35-37
To identify the usage of Agile Testing.
7. 38-40
To understand the importance of SDLC and
8. STLC process.
41-44

2|Page
 PRACTICAL 1
AIM: To identify the role of software in today’s world across a few significant domains related
to day-to-day life.
1. Health Care
2. Airlines
3. Banking Insurance
4. Retail
5. Education

1. Health Care:
The rise of information technology has delivered numerous benefits in various industries,
including healthcare. Health institutions and medical firms are now shifting their focus
towards the application of IT by the healthcare software systems.

What is Healthcare Software?

Healthcare software refers to IT programs based on knowledge, decision support, which
provide assistance, guidance and feedback in the healthcare setting.
Many hospitals now turn to the Electronic Health Record (EHR) platform as their main patient
file server. Nursing departments now utilize appointment scheduling software for better
tracking and scheduling of shifts. The software for handling medical equipment is also used
to monitor patients at the ICU (intensive care units).

How software has been leveraged in healthcare?

Google, Apple, Microsoft and Amazon, or “The Big Four” as they are commonly referred to,
are already using their expertise to transform the multi-trillion-dollar health industry in the
US.
According to Ernst and Young, Google’s parent company Alphabet has filed 186, Microsoft 73
and Apple 54 patents in Life Sciences, totaling 313 patents between 2013 and 2017!
Google leads the way mainly with AI and big data solutions, leveraging these in all areas of
healthcare from diagnosis to insurance.
Apple plays at the intersection between software and hardware, developing medical devices
and “patient-facing products” (Healthcare Weekly).

Key benefits of healthcare software

• Less day-to-day paperwork: There is no need for clinical specialists to deal with loads
of routine paperwork, freeing up more time to do what matters: providing patients
with superb health care. This can also help reduce physician burnout.
• Increased collaboration with other clinical specialists: Healthcare software enables
physicians, doctors, and other clinicians to share knowledge and ideas, and to
collaborate seamlessly even if they’re in different geographic locations.
• Efficient Practice Management: clinical specialists can leverage EMRs and EHR
software to easily and effectively manage their practices.

3|Page
2. Airlines:
The airline industry is entering a significant disruption period by transforming the passenger
experience. Airline industry solutions are key to creating an Omni-channel experience for
increasing the revenue opportunity, cost optimization, improving operational efficiency and
enhancing the customer experience.

Airlines Operations-
They can be divided into four types: landside operations, airside operations, billing and
invoicing, and information management.
Landside operations are aimed at serving passengers and maintenance of terminal buildings,
parking facilities, and vehicular traffic circular drives. Passenger operations include baggage
handling and tagging. Terminal operations comprise resource allocation and staff
management.
Airlines operations include aircraft landing and navigation, airport traffic management,
runway management, and ground handling safety.
Billing and invoicing operations cover aeronautical and non-aeronautical revenue. Ledger or
accounting systems contain information regarding airport finances: flight bills, handling
invoices, cash, sales within the airport (points-of-sales), staff payrolls, etc.
Information management relates to the collection and distribution of daily flight information,
storing of seasonal and arrival/departure information, as well as the connection with airlines.

Air Traffic Management-

Software providers: AIS, Adacel, Transoft, Pacific Controls, SITA, ACAMS Airport Tower
Solutions
Airside operations comprise control and facilitation of aircraft handling and parking. This
includes air traffic control equipment and management solutions for air navigation. Most
airside solutions are oriented toward aeronautics and plane allocation. Aeronautical Fixed
Telecommunication Network (AFTN) Systems. AFTN Systems handle communication and
exchange of data including navigation services. Usually, airports exchange traffic environment
messages, safety messages, information about the weather, geographic material, disruptions,
etc. They serve as communication between airports and aircraft.

Invoicing and billing-

Software providers: Amadeus IT Group, AIS, Damarel Systems International LTD, iFIDS.com
Inc.
Each flight an airport handles generates a defined revenue for the airport paid by the airline
operating the aircraft. Aeronautical invoicing systems make payment possible for any type
and size of aircraft. It accepts payments in cash and credit in multiple currencies. The billing
also extends to ATC services.

Information management – Airport information systems (AIS)-

Software providers: Rockwell Collins, Siemens, Ultra Electronics Holdings, Amadeus IT Group,
SITA, iFIDS.com Inc.
This category includes all types of software that collect, distribute, and update information
from around the airport, including public address systems and flight information display
systems (FIDS).

4|Page
3. Banking Insurance:
By nature, the banking, financial services, and insurance (BFSI) sector have always been data-
driven. However, today, institutions in the BFSI sector are increasingly striving to adopt a full-
fledged data-driven approach that can only be possible with Big Data technologies. With Big
Data Analytics, companies in the BFSI sector can not only grow their business but also work
towards increasing customer satisfaction.

Big Data allows BFSI institutions to obtain a comprehensive understanding of customers,

products/services, markets, industry regulations, competitors, and advertising channels.

The most significant areas of application of Big Data in the BFSI industry are:

Improved levels of customer insight and engagement

By leveraging Big Data technologies to dissect the data derived from digital channels (like
social media), BFSI institutions to enhance their quality of products/services as they can gain
a deeper understanding of customer pain points, preferences, and needs.

Improved fraud detection and prevention

It is not an unknown fact that the BFSI sector has long been the victim of fraud. Over time,
the techniques and methods of hacks and breaches have evolved and upgraded to become
more complex and sophisticate.

Enhanced risk management

When it comes to risk management, Big Data finds application in areas like operational risks,
integrated risk management, fraud management, credit management, and market and
commercial loans. Big Data tools can:
• Exponentially boost the predictive power of risk models,
• Enhance the system response time and effectiveness,
• Offer more extensive risk coverage, and,
• Create opportunities for optimum cost savings
The risk management teams can obtain highly accurate risk intelligence by gathering data
from disparate sources in real-time.

Enhanced employee engagement

Apart from all the ‘technical’ benefits, Big Data has another pivotal benefit – enhancing the
employee experience. By leveraging Big Data tools and techniques correctly, companies can
track, monitor, and analyze the performance metrics of their employees. This will help
identify the strongest performers in the company as well as the weak or unhappy performers.

4. Retail:
Automation in the retail space improves efficiency, enhances the quality of service, and
reduces the cost for all stakeholders. Retailers who realize this fact strive to offer innovative
products and solutions, based on automation technology, to differentiate themselves from
competitors.

5|Page
Digitalization of Tasks
Digitalization boosts the efficiency of manual and tedious, time-consuming internal tasks.
While most progressive retailers have already applied IT applications and solutions in a big
way, the emergence of IoT has given rise to newer solutions that take efficiency and quality
improvements to a whole new level.

Automation of Key Processes

Automation of critical processes such as inventory control, filling out employee timesheets,
invoicing, entering information from various PoS terminals to the accounting platform,
financial management, point of sale transactions, etc., can improve efficiency and bring about
big cost savings. An integrated point-of-sale system, for instance, spares the need to manually
key in transaction information into the card reader or other systems.

Personalize Customer Experience

A major objective of applying automation technology is to enhance customer experience.
Customers are the lifeblood of any business. In today’s age where choice is plenty, customers
who feel dissatisfied or have to put up with difficulties to complete the transaction will leave.
As such, retailers strive to create high-value, personalized interactions with customers.

Retailers may personalize each customer’s experience by harvesting the growing volumes of
customer data available across social and other channel.

5. Education:
Software engineering plays a significant role in education for several important reasons:

1. Enhanced Learning Tools: Software engineers develop educational software and tools,
such as learning management systems (LMS), interactive simulations, and educational apps.
These tools enhance the learning experience by making it more engaging, interactive, and
accessible.

2. Personalized Learning: Software can adapt to the needs and pace of individual learners.
Adaptive learning platforms use algorithms to personalize content and assessments, ensuring
that students receive tailored educational experiences.

3. Remote and Online Learning: In recent years, the importance of software engineering in
education has become even more evident with the rise of remote and online learning.
Software enables students to access educational resources and engage in classes from
anywhere, breaking down geographical barriers.

4. Efficient Administration: Educational institutions use software to manage administrative

tasks, such as student enrollment, scheduling, grading, and resource allocation. This
streamlines the operations of schools and universities, making them more efficient.

5. Data Analysis and Assessment: Educational software can collect and analyze data on
student performance. This data-driven approach helps educators identify areas where
students may need additional support and allows for continuous improvement in teaching
methods.

6|Page
6. Global Accessibility: Online courses and educational resources created through software
engineering can be accessed by learners worldwide. This has expanded access to education
for people who may not have had traditional opportunities for learning.

7. Collaboration and Communication: Software tools facilitate communication and

collaboration among students, teachers, and parents. Learning management systems, video
conferencing software, and collaborative platforms foster effective communication and
teamwork.

8. Real-World Skills: Teaching software engineering in educational curricula equips students

with valuable, practical skills that are in high demand in the job market. It prepares them for
careers in technology and fosters problem-solving and critical thinking.

9. Continuous Improvement: Software allows for the continuous improvement of

educational content and methods. Educators can easily update and adapt materials to reflect
the latest knowledge and teaching techniques.

10. Accessibility for Diverse Learners: Software engineering can lead to the development of
tools and applications that cater to diverse learning needs, including individuals with
disabilities. This ensures that education is inclusive and accessible to all.

Summary
In summary, software engineering is crucial in education because it enables the development
of innovative tools, platforms, and methodologies that enhance the learning experience,
improve administrative efficiency, and provide access to education on a global scale. It
empowers both educators and learners, making education more effective and inclusive.

7|Page
 PRACTICAL 2
AIM: To identify any scenario and identify suitable software development model for the given
scenario.

Scenario: Developing a New Online Banking System.

Explanation: The most suitable model is spiral model.

Spiral Model
Spiral model is one of the most important Software Development Life Cycle models, which
provides support for Risk Handling. In its diagrammatic representation, it looks like a spiral
with many loops. The exact number of loops of the spiral is unknown and can vary from
project to project. Each loop of the spiral is called a Phase of the software development
process. The exact number of phases needed to develop the product can be varied by the
project manager depending upon the project risks. As the project manager dynamically
determines the number of phases, so the project manager has an important role to develop
a product using the spiral model.
The Radius of the spiral at any point represents the expenses (cost) of the project so far, and
the angular dimension represents the progress made so far in the current phase. The below
diagram shows the different phases of the Spiral Model:

Each phase of the Spiral Model is divided into four quadrants as shown in the above figure.
The functions of these four quadrants are discussed below-

8|Page
1. Objectives determination and identify alternative solution
Requirements are gathered from the customers and the objectives are identified, elaborated,
and analyzed at the start of every phase. Then alternative solutions possible for the phase are
proposed in this quadrant.

2. Identify and resolve Risks

The development of an online banking system involves a high level of risk due to the
sensitivity of financial transactions and the need for security. The Spiral Model allows for
thorough risk analysis and management at each iteration, ensuring that potential risks are
identified and mitigated early in the development process.

3. Changing Requirements
In the banking industry, requirements are likely to change over time due to evolving
regulations, market demands, and technological advancements. The Spiral Model
accommodates changes through its iterative nature, allowing for the incorporation of new
requirements in subsequent spirals.

4. Prototyping and User Feedback

Users in the banking sector might have specific requirements regarding the user interface,
security features, and functionality. The Spiral Model facilitates the creation of prototypes in
each iteration, allowing users to provide feedback and ensuring that the final product aligns
with their expectations.

5. Gradual Development and Delivery

The Spiral Model supports incremental development, meaning that the project is developed
and delivered in small parts. This can be beneficial for the banking system as it allows for the
gradual introduction of features, ensuring that each component is thoroughly tested and
validated before being integrated into the complete system.

6. Complex System Architecture

Developing an online banking system involves a complex architecture with multiple
components, including user interfaces, transaction processing, security modules, and
databases. The Spiral Model allows for the gradual development and refinement of these
components, ensuring that the overall architecture is robust and well-designed.

7. Verification and Validation

The Spiral Model emphasizes verification and validation at each iteration. This is crucial for a
banking system where accuracy and security are paramount. Regular testing and validation
ensure that the system meets the required standards and is free from critical errors.

8. Develop next version of the Product

During the third quadrant, the identified features are developed and verified through testing.
At the end of the third quadrant, the next version of the software is available.

9. Review and plan for the next Phase

In the fourth quadrant, the Customers evaluate the so far developed version of the software.

9|Page
At the end, planning for the next phase is started.

Risk Handling in Spiral Model

A risk is any adverse situation that might affect the successful completion of a software
project. The most important feature of the spiral model is handling these unknown risks after
the project has started. Such risk resolutions are easier done by developing a prototype. The
spiral model supports coping up with risks by providing the scope to build a prototype at every
phase of the software development.
The Prototyping Model also supports risk handling, but the risks must be identified completely
before the start of the development work of the project. But in real life project risk may occur
after the development work starts, in that case, we cannot use the Prototyping Model. In each
phase of the Spiral Model, the features of the product dated and analyzed, and the risks at
that point in time are identified and are resolved through prototyping. Thus, this model is
much more flexible compared to other SDLC models.

Why Spiral Model is called Meta Model?

The Spiral model is called a Meta-Model because it subsumes all the other SDLC models. For
example, a single loop spiral actually represents the Iterative Waterfall Model. The spiral
model incorporates the stepwise approach of the Classical Waterfall Model. The spiral model
uses the approach of the Prototyping Model by building a prototype at the start of each phase
as a risk- handling technique. Also, the spiral model can be considered as supporting the
Evolutionary model – the iterations along the spiral can be considered as evolutionary levels
through which the complete system is built.

Advantages of Spiral Model:

Below are some advantages of the Spiral Model.
1. Risk Handling
The projects with many unknown risks that occur as the development proceeds, in that case,
Spiral Model is the best development model to follow due to the risk analysis and risk handling
at every phase.
2. Good for large projects
It is recommended to use the Spiral Model in large and complex projects.
3. Flexibility in Requirements
Change requests in the Requirements at later phase can be incorporated accurately by using
this model.
4. Customer Satisfaction
Customer can see the development of the product at the early phase of the software
development and thus, they habituated with the system by using it before completion of the
total-product.

Disadvantages of Spiral Model:

Below are some main disadvantages of the spiral model.
1. Complex
The Spiral Model is much more complex than other SDLC models.
2. Expensive
Spiral Model is not suitable for small projects as it is expensive.
3. Too much dependability on Risk Analysis

10 | P a g e
The successful completion of the project is very much dependent on Risk Analysis. Without
very highly experienced experts, it is going to be a failure to develop a project using this
model.
4. Difficulty in time management
As the number of phases is unknown at the start of the project, so time estimation is very
difficult.

Summary
In summary, the Spiral Model is suitable for the development of a new online banking system
due to its ability to manage risks effectively, accommodate changing requirements, facilitate
prototyping and user feedback, support gradual development, and emphasize verification
and validation throughout the development process.

11 | P a g e
 PRACTICAL 3
AIM: To classify the requirements into functional and non-functional requirements. Write at
least four functional and non-functional requirements, for any two scenarios.

Functional Requirements Non-functional Requirements

Functional requirements help to They help to understand the system's
understand the functions of the system. performance.
Functional requirements are mandatory. While non-functional requirements are not
mandatory.
They are easy to define. They are hard to define.
They describe what the product does. They describe the working of the product.
It concentrates on the user's requirement. It concentrates on the expectation
and experience of the user.
It helps us to verify the software's functionality. It helps us to verify the
software's performance.
These requirements are specified by the user. These requirements are specified by the
software developers, architects, and
technical persons.
There is functional testing such as API There is nonfunctional testing such
testing,system, integration, etc. asusability, performance, stress, security,
etc.
Examples of the functional requirements are - Examples of the non-functional
Authentication of a user on trying to log in to the requirements are - The background color of
system. the screens should be light blue.

These requirements are important to These are not always the

system operation. important requirements; they may be
desirable.
Completion of Functional requirements While the system will not work only
allows the system to perform, irrespective of with non-functional requirements.
meeting the non-functional requirements.

Scenario 1: E-commerce Website

Functional Requirements:
a. User Registration and Authentication: - The system must allow users to register with a valid
email address and password. - Users must be able to log in securely with their credentials. -
Registered users should have personalized profiles.
b. Product Management: - The system should support the addition, modification, and removal
of products by administrators. - Users should be able to view detailed information about

12 | P a g e
products. - Shopping carts must allow users to add, remove, and update items.
c. Order Processing: - Users must be able to place orders securely. - The system should
generate order confirmations with detailed information. - Administrators should have access
to order history and processing tools.
d. Payment Integration: - The system must support secure online payments. - Users should
be able to choose from various payment methods (credit card, PayPal, etc.).

Non-functional Requirements:
a. Performance: - The system should load product pages within 3 seconds. - Concurrent user
support: The website must handle at least 1000 simultaneous users.
b. Security: - User data must be encrypted during transmission. - The system should
implement secure coding practices to prevent common vulnerabilities.
c. Scalability: - The system should scale to accommodate a 20% increase in users over the next
year. - Database scalability: The database should handle a 30% increase in product entries.
d. Usability: - The website should be accessible and usable on major web browsers. - Mobile
responsiveness: The interface must adapt to various screen sizes.

Scenario 2: Library Management System

Functional Requirements:
a. Book Management: - Librarians should be able to add, edit, and delete book records. –
Users must be able to search for books based on title, author, or genre. - The system should
display real-time availability status for each book.
b. Member Management: - Librarians should be able to register new members and update
member information. - Users should have the ability to view their borrowing history. - The
system must send overdue notifications to members.
c. Checkout and Return: - Users must be able to check out books, and the system should
update availability. - The system must track and manage return dates for borrowed items.
d. Reporting: - Librarians should have access to reports on popular books, overdue books, and
member statistics.

Non-functional Requirements:
a. Reliability: - The system should be available 99.9% of the time. - Backup and recovery:
Regular backups must be performed, and data recovery should be possible within 24 hours.
b. Data Integrity: - The system must ensure the integrity of the book and member data. -
Transactions and updates should be atomic to prevent data corruption.
c. Response Time: - The system should respond to book search queries within 2 seconds. -
Check-out and return processes should be completed in less than 5 seconds.
d. Compliance: - The system should adhere to privacy regulations regarding user data. – The
interface should comply with accessibility standards.

13 | P a g e
 PRACTICAL 4
AIM: Do comparative study of various Software development models.

A software process model is an abstraction of the software development process. The models
specify the stages and order of a process. So, think of this as a representation of the order of
activities of the process and the sequence in which they are performed.
Every software development process model includes system requirements as input and a
delivered product as output. Many such model have been proposed over the years. Let us
look at several most popular models to understand their commonalities and differences.
There are many kinds of process models for meeting different requirements. We refer to
these as SDLC models (Software Development Life Cycle models).
The most popular and important SDLC models are as follows:
1. Classical waterfall life cycle Model
2. Prototype life cycle Model
3. V- life cycle Model
4. Iterative enhancement life cycle Model
5. Spiral life cycle development Model

4. a: Classical Waterfall Life Cycle Model

This model is also known by other names such as original or conventional or traditional
waterfall software life cycle model. This model divides the life cycle of a software
development process into the phases as shown in the figure 1. This life cycle model is named
"Waterfall model" because its diagrammatic representation resembles a cascade of
waterfalls. The different phases of this model are feasibility study, requirement analysis and
specifications design, coding and unit testing, integration and system testing and
maintenance. The different phases starting from the feasibility study to the integration and
system testing are known as the development phases.

Figure 1: Classical Waterfall Model

14 | P a g e
During each phase of the life cycle, a set of well-defined activities are carried out. Each phase
typically requires relatively different amount of efforts.

Each phase of the life cycle has a well-defined starting and ending point. Therefore, the
development engineers know precisely when to stop a phase and start the next phase. Most
organizations usually define standards on the outputs (deliverable) produced at the end of
every phase and the entry and exit criteria for every phase. We now briefly discuss the main
activities carried out during each phase and the corresponding entry and exit criteria.

Feasibility Study
The aim of feasibility study is to determine whether developing the product is financially and
technically feasible or not. The feasibility study involves analysis of the problem and collection
of data which would be input to the system, the processing required to be carried out on
these data, the output data required to be produced by the system, as well as study of various
constraints on the behavior of the system. The collected data are analyzed to arrive at the
following:
• An abstract definition of the problem.
• Formulation of the different solution strategies.
• Examination of alternate solution strategies and their benefits.
• A cost/benefits analysis is performed to determine which solution is the best.

Requirement Analysis and Specification

The aim of this phase is to understand the exact requirements of the customer and to
document them properly. This phase consists of two distinct activities:
1. Requirement analysis
2. Requirement specification

1. Requirement Analysis
The goal of the requirement analysis is to collect and analyze all related data and information
with a view of understanding the customer requirements clearly and weeding out
inconsistencies and incompleteness in these requirements.
Requirement analysis starts with the collection of all relevant data regarding the product from
the users through interviews and discussion. For example, to perform requirement analyst
has to interview all the accountants of the organization to ascertain their requirements The
data collected from a group of users usually contain several contradictions and ambiguities
because each user typically has only a partial and incomplete view of the system. After all
ambiguities, inconsistencies and incompleteness have been resolved and all the requirements
properly understood, the requirements are systematically organized into a Software
Requirements. Specification (SRS) documents.

2. Requirement Specification
During requirement specification, the user requirements are properly organized and
documented in a SRS document. The SRS documents address the functional requirements,
the non-functional requirements and the special requirements on the maintenance and
development of the software product, if any.
The SRS document serves as a contract between the development team and the customer.

15 | P a g e
Therefore, it is an important document which must be thoroughly understood by all the
developers and periodically reviewed jointly with the customer.
The SRS document must specify all functional and performance requirements, the format of
inputs, outputs, any required standard to be followed and all design constraints.

Design
The design phase translates the SRS into the design document which depicts the overall
modular structure of the program and the interaction between these modules In technical
terms, through the design phase we derive the software architecture from the SRS document.
Two distinct design approaches are being followed in different industries.

1. Traditional design approach

This design approach requires two different activities to be performed. First a structural
analysis of the requirements specification is carried out and then this structured analysis is
transformed into software design also called as software architecture.

2. Object-oriented design
This is a relatively new technique. In this technique. various objects that occur in the problem
domain and the solution domain an first identified and different kind of relationships that
exist among these objects are identified. This object structure is further refined to obtain the
detailed design. This approach has several advantages such as less development effort and
time and better maintainability.

Coding and Unit Testing

The purpose of this phase (also called the implementation phase) of software development
is to translate the software design into source code. During this phase, each component of
the design is implemented as a program module, and each of these programs module is unit
tested, debugged and documented.

The purpose of unit testing is to determine the correct working of the individual modules.
Unit testing involves a precise definition of the test cases, testing criteria and management of
test cases. The end-product of the implementation phase is a set of programs modules that
have been individually tested.

Integration and System Testing

During this phase the different modules are integrated in a planned manner. The different
modules making up a system are never integrated in a single shot. Integration is normally
carried out through a number of steps. During each integration step, the partially integrated
system is tested. Finally, when all the modules have been successfully integrated and tested,
system testing is carried out. The goal of system testing is to ensure that the developed
system functions according to its requirements as specified in the SRS document. The system
testing usually consists of three different kind of testing activities:
• α-testing
• β-testing
• Acceptance testing

Testing is carried out according to a system test plan document. The system test plan

16 | P a g e
identifies all the testing-related activities that must be performed and it also specifies the
schedule and allocates resources. The system test plan prepared during the requirements
specification phase lists all the different test cases and the expected outputs. The final output
of the testing phase is the TEST REPORT.

Maintenance
It is estimated that maintenance of any software product requires much more effort than the
effort necessary to develop the product. Many studies indicate that the relative effort of
development of a typical system to its maintenance effort is roughly in the 40 :60 ratio.
Maintenance involves performing any one or more of the following kinds of activities:

1. Corrective Maintenance
Correcting errors that were not discovered during the product development phase. This is
called corrective maintenance.
2. Perfective Maintenance
Improving the implementation of the system and enhancing the functionalities of the system
according to the customer's requirements. This is called perfective maintenance.
3. Adaptive Maintenance
Porting the software to a new environment e.g, to a new computer or to a new operating
system. This is called adaptive maintenance.

Advantages
• Easy to understand even by non-technical person i.e., customer.
• Each phase has well defined inputs and outputs e.g., input to system design stage is
Requirement Specification Document (RSD) and output is the design document.
• Easy to use as software development proceeds.
• Each stage has well defined deliverable or milestones. Helps the project manager in
proper planning of the project.
• It provides a template into which methods for analysis, design, code, test, and support
can be placed.
• It works well when quality requirements dominate cost and schedule requirements.
• When correctly applied, defects may be found early, when they are relatively
inexpensive to fix.
• It allows staff who have completed their phase activities to be freed up for other
projects.
• It provides structure to a technically weak or inexperienced staff. It tackles complexity
in an orderly way, working well for projects that are well understood but still complex.

Disadvantages
• This model is just like a one-way street. Once the phase X is complete and the next
phase Y has started, then there is no provision of going back. In other words, this
model is sequential in nature.
• It lacks overlapping and interactions among phases.
• Users have little interaction with the project team. Their feedback is not taken during
development.
• After the development process starts changes cannot be accommodated easily.
• Model do not support delivery of system in pieces.

17 | P a g e
 • Not suitable for new projects because of uncertainty in the specification.
• Customers gets opportunity to review the product very late in life cycle because the
working version of product is available very late in software development life cycle.
• Model is very rigid because output of each phase is pre-requisite for successive stage.

4. b: Prototype Life Cycle Model

The prototype model suggests that before developing the actual software, a working
prototype of the system should be built. A prototype is a partially developed product. It has
limited functional capabilities, low reliability and inefficient performance.
The model starts with an initial requirement gathering phase. A quick design is carried out
and the prototype model is built using several shortcuts. The shortcut might involve using
inefficient, inaccurate, or dummy functions e.g., a function may produce the desired result by
using a table look-up rather than performing the actual computation. The prototype product
usually turns out to be a very crude version of the actual system. The prototype model is
shown in the figure 2.
The developed prototype is submitted to the customer for his evaluation. Based on the user
feedback, the requirements are refined. This cycle continues until the user approves the
prototype. The actual system is then developed using the classical waterfall model.

Figure 2: Prototype model

18 | P a g e
The prototype may be a usable program, but is not suitable as the final software product. The
reason may be poor performance, maintainability or overall quality. The code for the
prototype is thrown away, however the experience gathered from developing the prototype
helps in developing the actual system. Therefore, the development of a prototype might
involve extra cost, but overall cost might turn out to be lower than that of an equivalent
system developed using the waterfall model.

Types of Prototype Model

There are two different types of prototype model:

1. Exploratory Development Prototype Model

Objective of exploratory development is to work with the user to explore their requirements
and deliver a final system. It starts with the parts of the system that are understood and then
evolve as the user proposes new features.
2. Throw away Prototype Model
Objective of throw away prototype is to understand the users’ requirements and develop a
better requirements definition for the system. It concentrates on poorly understood
components. In exploratory development, developers refine an initial prototype into the final
system based on feedback from users, while in throwaway prototyping, developers use a
prototype together and validate requirements, then discard the prototype and proceed with
a different development process.

Advantages
• A partial product is built in the initial stages. Therefore, customers get a chance to see the
product early in the life cycle and thus gives necessary feedback.
• Requirements become more clear resulting into an accurate product new requirement can
be easily accommodated, as there is scope for refinement.
• Flexibility in design and development is also supported by the model.
• As user is involved from the starting of the project, he tends to be more secure, comfortable
and satisfied.

Disadvantages
• Developers in a hurry may build prototypes and end up with sub-optimal solutions. After
seeing an early prototype, the users may demand the actual system to be delivered soon.
• End users may not like to know the difference between a prototype and a well-engineered
fully developed system.
• If not managed properly, the interactive process of prototype demonstration and
refinement can continue for long duration.
• If end user is not satisfied with initial prototype, he may lose interest in the project.
• Poor documentation.

4. c: V-Life Cycle Model

This model was developed to relate the analysis and design activities with the testing activities
and thus focuses on verification and validation activities of the product. As this model relates
the analysis and design phase to testing phase, testing activities are done in parallel as shown
in figure 3.

19 | P a g e
 Figure 3: The V-shaped software development life cycle model

Phases in the V-Shaped Model

The following list contains a brief description of each phase of the V-shaped from project and
requirements planning through acceptance testing:
• Project and requirements planning
Determines the system requirements and how the resources of the organization will be
allocated to meet them. (Where appropriate, this phase allocates functions to hardware and
software.)
• Product requirements and specification analysis
Includes analysis of the software problem at hand and concludes with a complete
specification of the expected external behavior of the software system be built.
• Architecture or high-level design
Defines how the software functions are to implement the design Detailed Design-Defines and
documents algorithms for component that was defined during the architecture phase. These
algorithms will be transited into code.
• Coding
Transforms the algorithms defined during the detailed design phase into software.
• Unit testing
Checks each module for errors.
• Integration and testing
Interconnects the sets of previously unit-tested modules to ensure that the sets behave as
well as the independently tested modules did during the unit-testing phase.

20 | P a g e
Advantages of V-shaped Model
• The model is simple and easy to use.
• The model focuses on verification and validation of the intermediate products, not only the
final software.
• The model plans for verification and validation activities early in the life cycle thereby
enhancing the probability of building an error free and good quality product.
• The V-shaped model encourages definition of the requirements before designing the
system, and it encourages designing the software before building the components.
• It defines the products that the development process should generate; each deliverable
must be testable.
• It enables project management to track progress accurately, the progress of the project
follows a time-line, and the completion of each phase is a milestone.

Disadvantages of V-shaped Model

• The model does not support iteration of phases and change in requirements throughout the
life cycle.
• It does not take into account risk analysis.
• The model is not equipped to handle dynamic changes in requirements throughout the life
cycle.
• The requirements are tested too late in the cycle to make changes without affecting the
schedule for the project.
• It does not easily handle concurrent events.

When to Use the V-Shaped Model

Like its predecessor, the waterfall model, the V-shaped model works best when all knowledge
of requirements is available up-front. A common modification to the V shaped model, to
overcome weaknesses, includes the addition of iteration loops to handle the changing of
requirements beyond the analysis phase.

It works well when knowledge of how to implement the solution is available, technology is
available, and staff have proficiency and experience with the technology.
The V-shaped model is an excellent choice for systems that require high reliability, such as
hospital patient control applications and embedded software for air-bag chip controllers in
automobiles.

4.d: Iterative Enhancement Life Cycle Model

This model has the same phases as the waterfall model, but with some restrictions. The
phases occur in the same order as in the waterfall model, but these may be conducted in
several cycles, with each release providing additional functionality.

During the first requirement analysis phase, customers and developers specify as may
requirements as possible and prepare a SRS document. Developers and customer then
prioritize these requirements. Developers implement the specified requirements one or more
cycles of design, implementation and test based on the defined priorities The model is given
in figure 4.

21 | P a g e
 Figure 4: Iterative enhancement model

The aim of the waterfall and prototype models is the delivery of a complete, operational and
good quality product. In contrast, this model does deliver an operational quality product at
each release, but one that satisfies only a subset of the customer's requirements.

The complete product is divided into releases, and the developer delivers the product release
by release. A typical product will usually have many releases as shown in the figure.

At each release, customer has an operational quality product that does a portion of what is
required. The customer is able to do some useful work after first release. With this model,
first release is available within few weeks or months, whereas the customer generally waits
months or years to receive a product using other models.

Advantages
• Limited number of persons can be put on project because work is to be delivered in parts.
• Product is to be delivered in parts; total cost of project is distributed.
• Customers or end users get the choice to see the useful functionality only in the software
development life cycle.
• End user's feedback requirements for successive releases become more clear.
• As functionality is incremented in steps, testing also becomes easily.
• Risk of failure of a product is decreased as users start using the product early.

Disadvantages
• Model requires well defined project planning schedule to distribute the work properly.
• Testing of modules results into overhead and increased cost.

22 | P a g e
• Product is delivered in parts, total development cost is higher
• Well defined interfaces are required to connect modules developed with each phase.

4. e: Spiral Life Cycle Development Model

The traditional software life cycle development models do not deal sufficiently with the
uncertainty, which is inherent to software projects. Important software projects have failed
because project risks were neglected and nobody was prepared when something unforeseen
happened. Barry Boehm recognized this and tried to incorporate the "project risk factor into
a life cycle model. As a result, he proposed a spiral model, which was presented in 1986 and
is shown in the figure 5.

Figure 5: Spiral life cycle model

The spiral model encompasses the strengths of the waterfall model while including risk
analysis, risk management, and support and management processes. It also allows for the
development of the product to be performed using a prototyping technique or rapid
application development through the use of fourth-generation (and beyond) languages and
development tools.

It reflects the underlying concept that each cycle involves a progression that addresses the
same sequence of step as the waterfall process model, for each portion of the product and
for each of its levels of complexity, from an overall statement of need to the coding of each
individual program.

In the spiral model, software development is carried out in four main phases which are shown
as the four quadrant of figure 5.

23 | P a g e
• Determine objectives, alternatives, and constraints
The first quadrant, identifies the objectives of the product and alternative solutions possible.
Objectives such as performance, functionality, ability to accommodate change, hardware/
software interface, and critical success factors are identified. Alternative means of
implementing this portion of the product (build reuse, buy, subcontract, etc.) are determined;
constraints imposed on the application of the alternatives (cost, schedule, interface,
environmental limitations, etc.) are determined. Risks associated with lack of experience, new
technology, tight schedules, poor processes, and so on are documented.

• Evaluate alternatives, and identify and resolve risks

In the second quadrant, the alternative solutions are evaluated and the potential project risks
are identified and dealt with by developing an appropriate prototype. A project risk is
essentially an adverse circumstance that might hamper successful completion of the software
project. Thus, the spiral model provides direct support for coping with project risks.
Alternatives relative to the objectives and constraints are evaluated; the identification and
resolution of risks (risk management, cost-effective strategy for resolving sources, evaluation
of remaining risks where money could be lost by continuing system development [go/no-go
decisions), etc.) occurs.

• Develop next-level product

The activities in the third quadrant consist of developing and verifying the next level of the
project. Typical activities in this quadrant could be creation off design, review of a design,
development of code, inspection of code, testing, and packaging of the product. The first build
is the customer's first look at the system. After this, a planning phase begins-the program is
reset to respond to customer's reaction. With each subsequent build, a better idea of
customer requirements is developed. The degree of change from one build to the next
diminishes with each build, eventually resulting in an operational system.

• Plan next phase

Finally, the fourth stage consists of reviewing the result of the stages traversed so far with the
customer and planning the next iteration around the spiral. Typical activities in this quadrant
could be development of the project plan, development of the configuration management
plan, development of the test and development of the installation plan.

With each iteration around the spiral (beginning at the center and moving outwards), a more
complete version of the software gets build progressively. Usually, after several iterations
along the spiral, all risks are resolved and the software is ready for development. At this point
a waterfall model of software development is adopted. A detailed figure of spiral life cycle
model is shown in figure 6.

The radius of the spiral at any point represents the cost incurred so far in the project, and the
angular dimension represents the progress.

24 | P a g e
 Figure 6: Detailed spiral model

Advantages
• A wide range of options are available to accommodate the good features of other life cycle
models.
• Model incorporates software quality objectives into software development. The risk
analysis and validation steps eliminate errors in the early phases of development.
• The model makes use of techniques like reuse, prototyping and component based design.
• It does not rely on the impossible task of getting the design perfect.
• It provides early and frequent feedback from users to developers, ensuring a correct product
with high quality.
• Management control of quality, correctness, cost, schedule, and staffing is improved though
reviews at the conclusion of each iteration.
• It provides productivity improvement through reuse capabilities.
• The model allows for flexible design by embracing the strengths of the waterfall model while
allowing for iteration throughout the phases of that model.
• All the money needed for the project need not be allocated up-front when the spiral model
is adopted. It allows users to be closely tied to all planning, risk analysis, development, and
evaluation activities.

25 | P a g e
Disadvantages
• Model is not suitable for small project as cost of risk analysis may exceed the actual cost of
the project.
• Model requires expertise in risk management and excellent management skills.
• Different persons involved in the project may find it complex to use.
• The spiral may continue indefinitely, generated by each of the customer's responses to the
build initiating a new cycle; closure (convergence on a solution) may be difficult to achieve.
• The large number of intermediate stages can create additional internal and external
documentation to process.
• Use of the model may be expensive and even unaffordable-time spent planning resetting
objectives, doing risk analysis, and prototyping may be excessive.
• Developers must be reassigned during non-development-phase activities.
• It can be hard to define objective, verifiable milestones that indicate readiness to proceed
through the next iteration.
• The lack of a good prototyping tool or technique can make this model clumsy to use.

When to Use the Spiral Model

A project manager may feel confident that the spiral model is appropriate when several of
the following conditions are met:
• When the creation of a prototype is the appropriate type of product development;
• When it is important to communicate how costs will be increasing and to evaluate the
project for costs during the risk quadrant activities;
• When organizations have the skills to tailor the model;
• For projects that represents medium to high risk;
• When it is unwise to commit to a long-term project due to potential changes in economic
priorities, and when these uncertainties may limit the available time frame;
• When the technology is new and tests of basic concepts are required;
• When users are unsure of their needs;
• When requirements are complex;
• For a new function or product line;
• When significant changes are expected, as with research or exploration;
• When it is important to focus on stable or known parts while gathering knowledge about
changing parts.

26 | P a g e
 Practical No 5
AIM: Preparation of requirement document for standard application problems in standard
format. (e.g. Library Management System, Railway Reservation system, Hospital
management System, University Admission system)

INTRODUCTION:

Borrowing books, returning books or viewing the available books at the library of the local
University is currently done manually where in the student has to go to the library and check
the available books.
Then the librarian checks the student id and allows the member to check out the book and
the librarian then updates the member database and also the books database.
This takes at least one to two hours if the member is available at the nearby place otherwise
it may take more time.
We have decided to investigate the use of an Online Library Management System. This system
would be used by members who may be students or professors of that University to check
the availability of the books and borrow the books, and by the librarian to update the
databases.

Purpose:

1. The main objective of this document is to illustrate the requirements of the project Online
Library Management system.
2. The document defines and describes the operations, interfaces, performance, and quality
assurance requirements of the Online Library System description.
3. The document also describes the nonfunctional requirements such as the user interfaces.
4. The document is developed after a number of consultations and considering the complete
requirement specifications of the given Project.
5. It also describes the design constraints that are to be considered when the system is to be
designed, and other factors necessary to provide a complete and comprehensive description
of the requirements for the software.
6. The final product of the team will be meeting the requirements of this document

Scope:

The Software Requirements Specification captures all the requirements in a single document.
The Online Library System is supposed to have the following features:
1. The system should provide login facility to the users.
2. The system provides the members with the option to check their account and/or change
their options like password of the account whenever needed all through the day during the
library hours.
3. The system should allow seeing the status of the books/journals borrowed/reserved by him
and the respective due dates and other relevant details.
4. The system should allow searching for a particular book/journal and also list for
books/journals.

27 | P a g e
5. The system should allow to cancel the reservation made earlier for a particular
book/journal.
6. It should allow reserving a particular book/journal borrowed by others currently.
7. The system allows the Librarian to create the books catalog, add/delete books and maintain
the books catalog.
8. The system should be able to send an automatic mail as soon as a reservation is made for
a particular book, to the person who made the reservation. Then, a mail should be sent to
people who are having the book currently, stating a reservation has been made on that book.

Definitions, Acronyms and Abbreviations:

Abbreviation Description
Administrator Librarian who controls the operation of library, all the
transactions in the library.
Transaction Borrowing or reservation of a book.

View List of all books in the library and all the details ofit.

XSD XML schema definition

SOA Service oriented architecture

WSDL Web service definition language

SOAP Simple object access protocol

JSP Java server pages

HTML Hyper Text Markup Language

XML Extensible Markup Language

J2EE Java 2 Enterprise Edition

AJAX Asynchronous Java script and XML

Users Student, faculty, author and publisher

Business rules:
• Library management system will be accessible in Intranet for browsing and viewing
purposes
• Library management system will be accessible only through HTTP mode.
• System participants access the application using standard internet browser
• In order to login to the application, user should be active and he/ she must have valid
username and password
• Application will provide different access level and admin rights.

28 | P a g e
 OVERALL DESCRIPTION

Product Perspective:
• The Online Library System is a package to be used by Libraries to improve the efficiency of
Librarians and Users.
• The Online Library System to be developed benefits greatly the members and the Librarian
of University.
• The system provides books catalog and information to members and helps them decide on
the books to borrow from the library.
• The Librarian can keep the books catalog updated all the time so that the members
(students and the professors) get the updated information all the time.

Librarian

Online library Internet

management system

Users

Figure 1: system overview

Product Functions:
• The Online Library System provides online real time information about the books available
in the library and the user information.
• The Product functions are more or less the same as described in the product perspective.
The functions of the system include the system providing different type of services based on
the type of users [Member/Librarian].
• The member should be provided with the updated information about the books
catalog.
• Provisions for the members to borrow the books they want, if all the other required
rules hold good.
• The member is given a provision to check his account information and change the
account information any time in the given valid period.
• The members should be allowed to see the status of the books/journals
borrowed/reserved by him and the respective due dates and other relevant details.

29 | P a g e
 • The members should be able to place requests for purchasing new books to the
library, by giving details about the name of the book, name of the author, publisher.
• The librarian is provided with interfaces to add/delete the books available in the book
catalog.

Design Constrains:

Constraints Description
Software Technologies
Application Server / Web Web sphere application server (WAS)
Server
Programming language Java / J2EE
J2EE Services Core java, Servlets, JSP, JDBC, JNDI, JAXB
SOA / Web services SOAP, WSDL, XML, XSD, AJAX
Scripting CSS, JavaScript
database DB2
IDE RAD
Language Constraints
Language English to be known

Functional Requirements:
The functional requirements are explained as below:

1. Administrator login
• In login screen, the authorized administrator will login to the system using username and
password.
• The authorized administrator has the following functions:
• An authorized user can register the member. The process happens physically, where
member fills in the register form manually and this would be keyed in to system by
administrator to create membership.
• System provides Inbox to the admin users to view all the requests. The process defined
below:
o An “Active” member makes a request to the Admin.
o The request will be in “pending”.
o Admin can view all pending request and he/she can approve or reject the request.
o If the request is approved then notification will be sent to the requester and status
will be marked to “Borrow” with end date.
• Administrator can check the status of all the books whether the book has been
issued/reserved. He can check all the details of the book.
• Search facility is provided to administrator, he can Search for all the books based on the
title, subject, author, publisher.
• Administrator can add new books to the library based on the requests made by the users
for the same with all the details of the new book.
• Administrator can remove any book from the library.

30 | P a g e
 Add / Remove Book
Search Book

Modify Book
Approve / reject
Request

Admin User

Block / Unblock
Register Membership
member

Figure 2: Admin Use case

2. User Login
• In login screen, the authorized users will login to the system using username and
password.
• Users of the system include four categories:
o Student (Transaction and view)
o Faculty (Transaction and view)
o Author (view)
o Publisher (view)
• Users of the system have the following function.
o System provides search engine to make user an easy task to search books. Query
parameters are specified below
•Book name
•Subject
•Author
•Publisher
o User can view the list book details. The fields are mentioned below
• Book Id
• Book Name
• Author
• Status (Reserved / Borrowed / Cancelled/ Available)
• Due date
• Reservation date
• Borrowed User ( In case if the status is “Borrowed”)
o User can make a request to reserve the book. The request will be posted to
administrator for approval.
o System provides interface to the user to post request for the non-availability of the
book. Admin will view the request through his inbox and he/she can reject or accept
the request.
o User can reserve book in case the book is borrowed by other members.
o User should able to cancel the reservation.
o System sends a notification after registering the book. The notification will be sent
through email.
o In case of the due date, system keeps track and sends reminder at regular interval of
time. A static value of 4 days will be set in system.

31 | P a g e
 Figure 3: Book Request process

Figure 4: user use case

3. Book Status
To maintain status of the book, the system as predefined status to maintain the life cycle of
the book. The status and the behavior are explained below
• Pending
o The book status will be in “Pending”, once the member makes a request for the book
• Approved
o The current status will be maintained once the Admin approves the member request.
• Rejected / Canceled
o The current status will be maintained in case Admin rejects the requested book
• Borrowed
o The current status will be maintained, in case, if book is borrowed from other
members.
o Administrator should change the status to “Borrowed” from “Approved” status after
member collects the book.
• Available

32 | P a g e
 o If the book is not occupied by any member then the status of the book will be in
available status, so that member can reserve the book
• Not Available
o If the book stock is not available then the status of the book will be “Non available”

4. Search Engine
Books can be searched based on the name, subject, status, author and publisher. A book
listing is given with all the required columns along with details of the transaction made on
that particular book for both user and administrator.

Report:
System provides a standard report for the administrator to view the information. System
provides a section “report” for the user to view and select the report.

Book
• Book Id
• Book Name
• Author
• Status (Reserved / Borrowed / Cancelled/ Available)
• Due date
• Reservation date
• Borrowed User (In case if the status is “Borrowed”)

Database Storage:
Database is the storage device, in which the application information will be stored in
database. The information is normalized in the form of tables. The main entities of the storage
are mentioned below

• Member/ Admin Information

• Book Information
• Book Transactions
• Audit Log

Figure 5: Entity Diagram

Non-Functional Requirements:

1. Availability
24*7 availability is provided.

33 | P a g e
2. Security
All the information in the library database and the transaction is secured, authentication is
provided to all the users, only authenticated users can use the system.

3. Performance
All the components are simple with all the features and services, thus there is no complication
and complexity in the design which enhances the performance.

4. User Documentation
• The product will include user manual.
• The user manual will include product overview, complete configuration of the used
software, technical details, backup procedure and contact information which will
include email address.

5. User Manual Requirements

User Manuals will be provided covering all the features of this product in DOC format.

34 | P a g e
 PRACTICAL 6
AIM: To identify the usage of Regression Testing

Regression Testing is a type of software testing that ensures that new code changes or
modifications to an existing system do not negatively impact the existing functionality of the
software. Its primary purpose is to verify that the new changes haven't introduced new
defects or caused unintended side effects in the previously tested features.

Importance of Regression Testing

Typically, it involves writing a test for a known bug and re-running this test after every change
to the code base. This aims to immediately identify any change that reintroduces a bug.

With a push for agility in software development, there is an emphasis on adopting an iterative
process – push new code often and break things if necessary. Regression testing ensures that
with frequent pushes, developers do not break things that already work. The regression
testing example below emphasizes its importance.

Regression Testing Techniques

1. Unit Regression Testing approach uses a bird’s-eye view philosophy to test code. This is a
simple method in which the tester has a list of items to test every time a change occurs. This
is the best way to start regression testing in an existing project.

2. Partial Regression Testing approach divides the project into logical, coherent units that
work together to form the whole application. Select the units that are most critical to the
application and define specific test cases for them while performing unit regression testing
for the rest of the modules.

35 | P a g e
3. Complete Regression Testing, which is the most detailed form of regression testing. In this
case, one takes a comprehensive view of the codebase to identify all functionalities that
would affect usability on breaking and write detailed tests for each of them. This technique is
time- consuming but highly beneficial if applied from the early stages of project development.

Usage of Regression Testing

Here are some scenarios and examples to help you identify the usage of regression testing:

1. Code Changes:
• Scenario: Developers have made updates or enhancements to certain features in the
software.
• Example: Suppose a social media platform introduces a new feature allowing users to
share links with previews. After implementing this feature, regression testing is performed
to ensure that existing features like user profiles, friend requests, and messaging still work
as expected.

2. Bug Fixes:
• Scenario: Developers have fixed bugs or issues reported in the previous testing cycles.
• Example: If users reported a bug where certain images were not displaying correctly, the
development team fixes the issue. Regression testing is then carried out to confirm that
the fix didn't introduce new problems elsewhere in the application.

3. Integration of Modules:
• Scenario: New modules or components are integrated into the existing software.
• Example: Consider an e-commerce platform adding a new payment gateway for
additional payment options. After integrating this module, regression testing ensures that
product listings, shopping cart functionality, and order processing remain unaffected.

4. Environment Changes:
• Scenario: There are changes in the deployment environment, such as an operating system
upgrade or database migration.
• Example: If a company decides to migrate its application to a cloud-based environment,
regression testing is essential to ensure that the application functions correctly in the new
cloud environment and that the migration didn't introduce new issues.

5. Configuration Changes:
• Scenario: Configuration settings, such as server configurations or application settings, are
modified.
• Example: Suppose an e-learning platform decides to change its server configurations to
accommodate a larger user base. Regression testing would be performed to verify that
the change doesn't negatively impact features like course enrollment, video playback, or
assessments.

6. Periodic Releases:
• Scenario: The software undergoes periodic releases with new features, enhancements, or
bug fixes.

36 | P a g e
• Example: A project management software regularly releases updates to improve user
experience and add new functionalities. After each release, regression testing is
conducted to ensure that existing project management features, such as task creation and
collaboration, still work seamlessly.

7. Automated Testing Suites:

• Scenario: Organizations use automated test suites to perform repeated testing tasks
efficiently.
• Example: An e-commerce platform has an automated regression test suite that includes
test cases for core functionalities like product search, order placement, and payment
processing. Whenever there's a code change, the automated suite is executed to quickly
validate the overall system integrity.

8. Continuous Integration/Continuous Deployment (CI/CD) Pipelines:

• Scenario: CI/CD pipelines automatically build, test, and deploy code changes.
• Example: In a CI/CD setup, every code commit triggers an automated build and regression
testing process. This ensures that any code changes are thoroughly tested before being
deployed to the production environment, reducing the risk of introducing defects to end-
users.

Summary
In essence, regression testing acts as a safety net, assuring that the software remains robust
and reliable as it undergoes changes, updates, and improvements throughout its
development lifecycle. It helps maintain the integrity of the existing features, reducing the
likelihood of introducing new issues when modifications are made to the codebase.

37 | P a g e
 PRACTICAL 7
AIM: To identify the usage of Agile Testing.

Agile Testing is an integral part of the Agile software development methodology, which
emphasizes flexibility, collaboration, and incremental development. In Agile, testing is not a
separate phase but is integrated throughout the development lifecycle.

Main Principles of Agile Testing

The main principles of agile testing are:

• Early and continuous testing: Testers should start testing the software early in the
development process. They should also test the software continuously throughout the
development cycle.
• Whole team approach: In agile development, all team members are responsible for
ensuring the quality of the product. This includes developers, testers, business analysts, and
product owners.
• Frequent deliveries: Agile teams deliver working software frequently, typically every two
weeks.
• Close collaboration: There is close collaboration between all team members in an agile
project. This helps to ensure that everyone is on the same page and that there are no
surprises.
• Customer involvement: Customers involve themselves throughout the agile development
process. They provide feedback at each iteration, which helps the team to make constant
improvements.
• Working software: Agile teams focus on quality software management during each
iteration. This is more important than documentation or other deliverables.
• Flexible approach: Agile development is a flexible approach. Teams can change the
requirements at any time during the development process.

Agile Testing Life Cycle

The agile testing life cycle is the process that agile teams use to plan, execute, and track their
testing activities.
The agile testing life cycle consists of four main phases:

• Planning: The team decides which features are testable and which tests are necessary.
• Execution: The team executes the tests.
• Tracking: The team tracks the results of the tests and defect reports.
• Closure: The team reviews the test results and closes out any remaining defects.

38 | P a g e
Usage of Agile Testing
Here are key aspects of Agile testing with examples:

1. Iterative Development:
• Usage: Agile follows an iterative and incremental approach to development. Testing is
conducted continuously during each iteration.
• Example: In a two-week Agile sprint, the development team works on user stories. Testers
create and execute test cases for each user story throughout the sprint, providing quick
feedback to developers.

2. Cross-Functional Teams:
• Usage: Agile teams are cross-functional, with members having various skills, including
testing. This allows testing expertise to be integrated into the development team.
• Example: A cross-functional Agile team may consist of developers, testers, designers, and
product owners. Testers collaborate with developers to understand requirements and
contribute to the definition of acceptance criteria.

3. Test-Driven Development (TDD):

• Usage: TDD is a practice where tests are written before the corresponding code is
developed. It ensures that the code meets the specified requirements.
• Example: Before implementing a new feature, a developer writes a failing test case. The
code is then modified or written to make the test pass. This process continues, ensuring
that the code is always accompanied by passing tests.

4. Continuous Integration (CI):

• Usage: CI involves automatically integrating code changes from multiple contributors and
running automated tests to detect integration issues early.
• Example: Developers commit code changes to a shared repository several times a day.
Automated tests, including unit tests and integration tests, are triggered upon each
commit to ensure that the new changes do not break existing functionality.

39 | P a g e
5. Automation Testing:
• Usage: Automation is a key aspect of Agile testing to enable quick and repeated testing of
code changes.
• Example: Regression test suites are automated to ensure that previously developed
features continue to work after each iteration. Automated tests are run regularly as part
of the CI/CD pipeline to maintain code quality.

6. User Stories and Acceptance Criteria:

• Usage: Agile projects are driven by user stories and acceptance criteria, which define the
expected behavior of features.
• Example: A user story for an e-commerce application may be "As a user, I want to be able
to add items to my shopping cart." Testers work with product owners to define
acceptance criteria, such as verifying that the correct items are added and the total is
updated accurately.

7. Continuous Feedback:
• Usage: Agile emphasizes continuous feedback through regular meetings like sprint
reviews and retrospectives. Testing feedback is crucial for improving processes.
• Example: After the completion of a sprint, the team holds a sprint review where testers
provide feedback on the functionality developed. Retrospectives allow the team to
discuss testing practices and suggest improvements for the next sprint.

8. Exploratory Testing:
• Usage: Agile testing embraces exploratory testing, where testers explore the application
dynamically, uncovering defects and verifying functionality.
• Example: Testers explore different paths within the application without predefined test
scripts. This approach helps uncover usability issues, edge cases, and unexpected
behaviors.

9. Regression Testing:
• Usage: With frequent code changes, regression testing is crucial to ensure that new
features do not break existing functionality.
• Example: After each sprint, testers execute automated regression tests to verify that
previously developed features still work. This ensures that the continuous development
and integration do not introduce unintended side effects.

Summary
In summary, Agile testing is deeply integrated into the Agile development process, promoting
collaboration, continuous feedback, and flexibility. It aims to deliver high-quality software in
a dynamic and iterative manner, responding to changing requirements and customer
feedback throughout the development lifecycle.

40 | P a g e
 PRACTICAL 8
AIM: To understand the importance of SDLC and STLC process.

SDLC (Software Development Life Cycle):

The Software Development Life Cycle is a systematic process used by software developers to
design, develop, test, and deploy high-quality software. The importance of SDLC lies in its
ability to provide a structured and organized approach to software development, ensuring
that the final product meets customer expectations, is delivered on time, and is within
budget.

The following figure is a graphical representation of the various stages of a typical SDLC.

Let's consider the development of a web application using SDLC. The SDLC typically consists
of several phases:

• Requirements Gathering:
• Importance: Clearly understanding the client's requirements is essential for building
a successful web application. This phase involves discussions with stakeholders to
gather and document the functional and non-functional requirements.
• Example: The client specifies that the web application should allow users to create
accounts, post content, and interact with other users.

41 | P a g e
• Design:
• Importance: In the design phase, developers create a blueprint for the application
based on the requirements. This phase ensures that the system will be scalable,
maintainable, and aligned with the client's vision.
• Example: Designers create wireframes and architecture diagrams to depict how the
web application's pages and components will look and function.

• Development:
• Importance: This phase involves coding the actual application based on the design.
The goal is to implement the features outlined in the requirements while adhering to
coding standards.
• Example: Developers write the code for user registration, content creation, and other
features as per the specifications.

• Testing:
• Importance: Quality assurance is crucial to ensure that the application functions as
intended. Testing at this stage helps identify and fix bugs before the application is
deployed.
• Example: Testers conduct unit testing to check individual components, integration
testing to verify that different parts work together, and system testing to assess the
entire application.

• Deployment:
• Importance: Deployment involves releasing the application to a production
environment for users to access. A well-planned deployment ensures a smooth
transition from development to the live environment.
• Example: The web application is deployed to a server accessible to users, and the
necessary configurations are made to make it publicly available.

• Maintenance:
• Importance: Even after deployment, the software requires maintenance. This phase
involves addressing issues, updating features, and ensuring the continued
functionality of the application.
• Example: Developers regularly release updates to fix bugs, enhance security, and add
new features based on user feedback.

STLC Importance:

The Software Testing Life Cycle (STLC) is a systematic approach to testing a software
application to ensure that it meets the requirements and is free of defects. It is a process that
follows a series of steps or phases, and each phase has specific objectives and deliverables.
The STLC is used to ensure that the software is of high quality, reliable, and meets the needs
of the end-users.

The main goal of the STLC is to identify and document any defects or issues in the software
application as early as possible in the development process. This allows for issues to be
addressed and resolved before the software is released to the public.

42 | P a g e
STLC Phases

There are following six major phases in every Software Testing Life Cycle Model (STLC Model):

STLC Model Phases

1. Requirement Analysis

2. Test Planning

3. Test case development

4. Test Environment setup

5. Test Execution

6. Test Cycle closure

Now, let's focus on the testing aspect of the example:

• Test Planning:
o Importance: Test planning involves defining the testing approach, scope,
resources, and schedule. This ensures that testing efforts are organized and align
with project goals.
o Example: Testers plan to conduct functional testing to verify user registration and
content creation, performance testing to assess system responsiveness, and
security testing to identify vulnerabilities.

• Test Design:
o Importance: Testers create detailed test cases based on the requirements and
design specifications. Well-designed test cases cover various scenarios to ensure
comprehensive testing.
o Example: Testers design test cases to validate user registration with valid and
invalid inputs, verify that users can post content, and assess the application's
response to multiple concurrent users.

43 | P a g e
• Test Execution:
o Importance: This phase involves running the tests according to the test plan and
documenting the results. It helps identify and report any defects.
o Example: Testers execute the test cases, recording whether each test passes or fails.
They document any issues, such as a user registration process not functioning
correctly.

• Defect Tracking and Reporting:

o Importance: Defect tracking involves documenting and prioritizing identified issues.
Reporting helps stakeholders understand the status of the application's quality.
o Example: Testers use a defect tracking system to log issues, categorize them based on
severity, and communicate with developers to resolve the problems.

• Regression Testing:
o Importance: As changes are made to the application, regression testing ensures that
existing functionalities remain unaffected. It helps catch unintended side effects.
o Example: After fixing a defect in the user registration process, testers perform
regression testing to confirm that this fix didn't introduce new issues in other parts of
the application.

Summary
In summary, SDLC provides a systematic framework for the entire software development
process, while STLC focuses specifically on testing activities to ensure the quality and
reliability of the software. Together, they contribute to the successful delivery of a functional,
high-quality web application.

44 | P a g e