UNIVERSITY INSTITUTE OF ENGINEERING

AND TECHNOLOGY, KURUKSHETRA

PRACTICAL FILE
SOFTWARE VERIFICATION VALIDATION AND
TESTING
Session (2021-2025)

SUBMITTED TO: SUBMITTED BY:

Mrs Sona Nakshatra
Asst. Professor CSE – A
Dept. CSE 252102055

1
 INDEX
Sno Practical Page Date Signature
Name No

To identify the role of software in today’s

1. world across a few significant domains
related to day to day life.

2. To identify any scenario and identify suitable

software development model for the given
scenario.
To classify the requirements into
3. functional and non- functional
requirements. Write at least four
functional and non-functional
requirements, for any two scenarios.
4. Do comparative study of various Software
development models.
Preparation of requirement document for
5. standard application problems in standard

format .(eg Library Management System,

Railway Reservation system, Hospital
management System, University Admission

system)
To identify the usage of Regression Testing
6.

To identify the usage of Agile Testing

7.

8. To understand the importance of SDLC and

STLC process.

2
 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
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.

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).

3
 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

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

4
 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.

1. 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

5
 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.

2. 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.
Digitalization of Tasks

Digitalization boosts the efficiency of manual and tedious, timeconsuming

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
6
 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
channels.

3. 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.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.

7
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.

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.

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.

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.

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

8
 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. 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.

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-

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 Risk

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.

9
3.Changing Requirement
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.Prototype 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.
At the end, planning for the next phase is started.

10.Risk Handling in Spiral Model

A risk is any adverse situation that might affect the successful completion of a software
project. Such risk resolutions are easier done by developing a prototype. The spiral model

10
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.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.

Spiral Model is also called as 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 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

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

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: 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.

11
4.Difficulty in time management: As the number of phases is unknown at the start of the
project, so time estimation is very difficult.

Conclusion

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.
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 understand the They help to understand the system's
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 testing, There is non-functional testing such as
system, integration, etc. usability, performance, stress, security, etc.
Examples of the functional requirements are - Examples of the non-functional requirements
Authentication of a user on trying to log in to are- The background color of the screens should
the system. be light blue.

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

12
Scenario 1: Ecommerce Website
Functional Requirements:

1.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.

2.Product Management: - The system should support the addition, modification, and removal
of products by administrators. - Users should be able to view detailed information about
products. - Shopping carts must allow users to add, remove, and update items.
3.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.

4.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

1.Performance: - The system should load product pages within 3 seconds. - Concurrent user
support: The website must handle at least 1000 simultaneous users.

2.Security: - User data must be encrypted during transmission. - The system should implement
secure coding practices to prevent common vulnerabilities.

3.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.

4.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:

1.Book Management: - Librarians should be able to add, edit, and delete book records. – User
must be able to search for books based on title, author, or genre. - The system should display
real-time availability status for each book.

2.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.

3.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.

13
4.Reporting: - Librarians should have access to reports on popular books, overdue books, and
member statistics.

Non Functional Requirements

1.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.

2.Data Integrity: - The system must ensure the integrity of the book and member data.
Transactions and updates should be atomic to prevent data corruption.

3.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.

4.Compliance: - The system should adhere to privacy regulations regarding user data. – The
interface should comply with accessibility standards.
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.1 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

14
process into the phases as shown in the figure 1.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.

Fig 4.1: Classical Waterfall model

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 behaviour 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

15
 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 organised 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. The SRS document serves as a contract between the
development team and the customer. Therefore it is an important document which must be
thoroughly understood by all the developers and periodically reviewed jointly with the
customer.

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

16
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

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.

17
Advantages

• Easy to understand even by non-technical person ie., 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.
• 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

4.2 Prototype Life Cycle Model

The prototype model suggest 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 requirements 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

18
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.

Fig 4.2 prototype model

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.

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 Mode

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

19
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
requirements 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 suboptimal

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 loose interest in the
project.
• Poor documentation.

4.3 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.

20
 Fig 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
designDefines 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
Advantages

• The model is simple and easy to use.

• The model focuses on verification and validation of the intermediate products, not
only the final software.

21
 • 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

• 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.

4.4 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.
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.

22
 Fig 4.4 Iterative model 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.
• Product is delivered in parts, total development cost is higher
• Well defined interfaces are required to connect modules developed with each phase.

4.5 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.

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

23
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.
Figure 5: Spiral life cycle model

• 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

24
 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.

Figure 6: Detailed spiral model

Advantages
25
• 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 base
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. 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.

26
 PRACTICAL – 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.
Scope: -
The Software Requirements Specification captures all the requirements in a singledocument.
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.

27
4.The system should allow searching for a particular book/journal and also list for
books/journals.
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 of it.

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:

28
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

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.

Fig 5.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.

29
 • 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.
• 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
An “Active” member makes a request to the Admin.
The request will be in “pending”
Admin can view all pending request and he/she can approve or reject the
request

30
 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.

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:

 Student (Transaction and view)

 Faculty (Transaction and view)
 Author (view)
 Publisher (view)
• Users of the system have the following function.
• System provides search engine to make user an easy task to
search books. Query parameters are specified below

• Book name
• Subject
• Author
• Publisher
• User can view the list book details. The fields are mentioned
below
• Book Id
• Book Name
• Author
• Status (Reserved / Borrowed / Cancelled/ Available)

31
 • Due date
• Reservation date
• Borrowed User ( In case if the status is “Borrowed”)
• User can make a request to reserve the book. The request will
be posted to administrator for approval.
• 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.
• User can reserve book in case the book is borrowed by other
members.
• User should able to cancel the reservation.
• System sends a notification after registering the book. The
notification will be sent through Email 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

Fig

3: Book Request process

Fig 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 is explained below
1. Pending

32
 • The book status will be in “Pending”, once the member
makes a request for the book
2. Approved
• The current status will be maintained once the Admin
approves the member request.
•
3. Rejected / Canceled
• The current status will be maintained in case Admin rejects the requested
book
4. Borrowed
• The current status will be maintained, in case, if book is borrowed from
other members.
• Administrator should change the status to “Borrowed” from
“Approved” status after member collects the book.
5. Available
• 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
6. Not Available
• If the book stock is not available then the status of the book will be “Non
available”
7. Not Available
• 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

33
 • 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 entity of the storage
are mentioned below

o Member/ Admin Information

o Book Information o Book
Transactions o Audit Log

Non-Functional Requirements: -

1. Availability : 24*7 availability is provided.

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.

34
 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.
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
35
 functionalities that would affect usability on breaking and write detailed tests for
each of them. This technique is t ime- 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:

36
 • 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.

• 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
 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.

• Flexible approach: Agile development is a flexible approach. Teams can

change the requirements at any time during the development process.

Agile Testing Life Cycle

38
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.

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.

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.

39
 • 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.

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:

40
 • 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.

41
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.

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:

42
• 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.
• 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:

43
 • 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.

2. 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.

STLC Phases

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

44
STLC Model Phases

Requirement Analysis
Test Planning
Test case development
Test Environment setup
Test Execution
Test Cycle closure

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

• Test Planning:

• Importance: Test planning involves defining the testing approach,

scope, resources, and schedule. This ensures that testing efforts are
organized and align with project goals.

• 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:

• Importance: Testers create detailed test cases based on the

requirements and design specifications. Well-designed test cases
cover various scenarios to ensure comprehensive testing.

• 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.

• Test Execution:

• Importance: This phase involves running the tests according to the

test plan and documenting the results. It helps identify and report
any defects.

• 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.

45
 • Defect Tracking and Reporting:

• Importance: Defect tracking involves documenting and prioritizing

identified issues. Reporting helps stakeholders understand the status
of the application's quality.

• Regression Testing:

• Importance: As changes are made to the application, regression

testing ensures that existing functionalities remain unaffected. It
helps catch unintended side effects.

• 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.

46