Agile Development Process

Software Engineering & Project Management | Ms.Snehal Shinde 96

Agile Development :

 Agile Software Development is a software development methodology that values flexibility,

collaboration, and customer satisfaction. It is based on the Agile Manifesto, a set of principles for
software development that prioritize individuals and interactions, working software, customer
collaboration, and responding to change.

 Agile Software Development is an iterative and incremental approach to software development

that emphasizes the importance of delivering a working product quickly and frequently. It
involves close collaboration between the development team and the customer to ensure that the
product meets their needs and expectations.

Fig. Agile Development

The Agile Software Development process typically consists of the following steps:

1. Requirements Gathering: The customer’s requirements for the software are gathered and
prioritized.
2. Planning: The development team creates a plan for delivering the software, including the
features that will be delivered in each iteration.

Software Engineering & Project Management | Ms.Snehal Shinde 97

 3. Development: The development team works to build the software, using frequent and
rapid iterations.
4. Testing: The software is thoroughly tested to ensure that it meets the customer’s
requirements and is of high quality.
5. Deployment: The software is deployed and put into use.
6. Maintenance: The software is maintained to ensure that it continues to meet the
customer’s needs and expectations.

 Agile Software Development is widely used by software development teams and is considered
to be a flexible and adaptable approach to software development that is well-suited to changing
requirements and the fast pace of software development.

 Agile is a time-bound, iterative approach to software delivery that builds software

incrementally from the start of the project, instead of trying to deliver all at once.

Advantages of Agile Methodology :

1. Customer satisfaction is rapid, continuous development and delivery of useful software.

2. Customer, Developer, and Product Owner interact regularly to emphasize rather than
processes and tools.

Software Engineering & Project Management | Ms.Snehal Shinde 98

 3. Product is developed fast and frequently delivered (weeks rather than months.)
4. A face-to-face conversation is the best form of communication.
5. It continuously gave attention to technical excellence and good design.
6. Daily and close cooperation between business people and developers.
7. Regular adaptation to changing circumstances.
8. Even late changes in requirements are welcomed.

Disadvantages of Agile methodology:

1. It is not useful for small development projects.

2. There is a lack of intensity on necessary designing and documentation.
3. It requires an expert project member to take crucial decisions in the meeting.
4. Cost of Agile development methodology is slightly more as compared to other
development methodology.
5. The project can quickly go out off track if the project manager is not clear about
requirements and what outcome he/she wants.

Agile Manifesto :

 The Agile Manifesto was founded in February 2001 at a ski resort in Snowbird, Utah. 17
representatives from various programming and development backgrounds gathered to discuss
Agile methodologies and find a solution to the older processes with which they had become
frustrated. It is believed that by signing the manifesto, the authors “launched the ship” for Agile
software development.

 The Agile Manifesto is a document that outlines the central values and principles of Agile
software development. Officially referred to as the Manifesto for Agile Software Development,
the guide aims to provide an effective model for teams to successfully adopt the philosophy of
Agile project management and use it to improve their work process.

 The lightweight framework of the Agile Manifesto was designed to improve upon existing
software development processes, which were more complex and contained a lot of

Software Engineering & Project Management | Ms.Snehal Shinde 99

documentation. The founders wanted to speed up these processes and create a more efficient
working model for teams.

The four Agile Manifesto values :

The Agile Manifesto was founded on four key values, which are as follows:

1. Individuals and interactions over processes and tools

-The first value gets straight to the core of Agile methodology: the focus is on the people. You
can use the best processes and tools available to support your projects, but they will only work if
your people are doing their best work. Your team is your most valuable resource.

-Communication plays a key role here — when people interact with each other regularly and
share their ideas, they build better products.

2. Working software over comprehensive documentation

-Before Agile practices were fully implemented, teams would spend hours creating exhaustive
documents with technical specifications, requirements, and more. These lists would be prepared
before developers started to write the code, meaning the whole process was delayed as the
documentation took so long to compile.

3. Customer collaboration over contract negotiation

-The third value of the Agile Manifesto highlights the importance of customer collaboration.
This is viewed as superior to contract negotiation, which involves outlining product requirements
with the customer before commencing the project and then renegotiating these deliverables at a
later stage. The issue here is that the customer is not engaged throughout the development cycle,
so teams lose out on user feedback that could enhance the product.

-When you bring your customers into the development process, you can ask for their opinions
regularly and take their suggestions on board

4. Responding to change over following a plan

Software Engineering & Project Management | Ms.Snehal Shinde 100

-Traditional methodologies advocated for as little change as possible, recognizing that significant
alterations could cost time and money. The aim was to create a comprehensive plan that followed
a structured, linear path and avoided obstacles where possible.

-The Agile mentality turns this rigid method on its head, arguing that change can benefit the
software development process. When you embrace change, you open yourself up to new
possibilities and ways to improve. Agile teams work in short, iterative cycles, meaning they can
react quickly and implement changes on a continuous basis. This ultimately leads to better
products.

These four values form the basis of Agile software development, highlighting key priority areas
for teams to focus their energies on. The core values are supported by the 12 Agile Manifesto
principles.
The 12 Agile Manifesto principles :

The Agile Manifesto lists 12 principles to be followed by software developers:

1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.

What is the number one rule in software development? Keep your customer happy. Aim to
deliver software to your users at regular intervals throughout the project life cycle, rather than
keep them waiting for one final deliverable.

2. Welcome changing requirements, even late in development. Agile processes harness

change for the customer's competitive advantage.

Software developers should be capable of handling last-minute changes to a project. They should
be flexible enough to turn these changes into improvements quickly, minimizing delays and
ensuring an uninterrupted flow of work.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.

Software Engineering & Project Management | Ms.Snehal Shinde 101

Agile teams break large projects down into short timelines to guarantee regular delivery. In the
Scrum methodology, these timelines are known as sprints, which often run between one and four
weeks long.

4. Business people and developers must work together daily throughout the project.

As mentioned, collaboration is key to Agile project management. When the project stakeholders
communicate on a daily basis, it minimizes the risk of confusion and ensures that everyone’s
goals remain aligned.

5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.

When you have the right people for the task, the project is more likely to be successful. Spend
time choosing the perfect team, equip them with the resources they need, and trust them to
deliver exceptional results.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.

Barriers are broken easily when teams can converse in person. Co-locate teams where possible to
promote good communication and boost the flow of information. In a remote working situation,
Zoom is a great alternative to phone or email, enabling people to interact more effectively via
camera.

7. Working software is the primary measure of progress.

To keep your customers satisfied, you must deliver high-quality software. That is your ultimate
priority and your metric for success — everything else is a secondary consideration.

8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.

Agile teams must be consistent throughout their project life cycle, maintaining their speed
throughout. This means they can sustain a constantly evolving environment without succumbing
to delays.

9. Continuous attention to technical excellence and good design enhances agility.

Software Engineering & Project Management | Ms.Snehal Shinde 102

In Agile, you don’t just deliver one good product and call it a day — your focus should be on
continuous improvement and innovation. Each iteration should bring with it a new update,
feature, or advancement of some kind.
10. Simplicity — the art of maximizing the amount of work not done — is essential.

The Agile approach is to not overcomplicate things: meet your requirements and do just enough
to complete the task. Don’t waste time with additional steps that don’t add any real value to your
product.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Why micromanage teams when they are skilled enough to work on their own? By allowing them
to work within their own structures, you create more room for ideas to flourish, ultimately
delivering better results.

12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

When you review team performance regularly, you can spot issues before they escalate, as well
as potential areas for improvement. A healthy Agile team is one that self-reflects in order to
eliminate unhelpful practices and advance skills.

Agility and Cost of Change :

What is “Agility-

◼ Effective (rapid and adaptive) response to change

◼ Effective communication among all stakeholders

◼ Drawing the customer onto the team

◼ Organizing a team so that it is in control of the work performed

◼ Rapid, incremental delivery of software

Software Engineering & Project Management | Ms.Snehal Shinde 103

 The conventional wisdom in software development is that the cost of change increases
nonlinearly as a project progresses (Figure, solid black curve). A usage scenario might have to be
modified, a list of functions may be extended.

 The change requires a modification to the architectural design of the software, the design and
construction of three new components, modifications to another five components, the design of
new tests, and so on. Costs escalate quickly, and the time and cost required to ensure that the
change is made without unintended side effects is nontrivial.

 Agility argue that a well-designed agile process “flattens” the cost of change curve (Figure,
shaded, solid curve), allowing a software team to accommodate changes late in a software
project without dramatic cost and time impact.

Myths of Planned Development :

Myth 1 – Agile is new

Agile is certainly not new. Agile methods have been around for a long time. The frameworks that
are now known collectively as agile mainly evolved in the late 1980s and 1990s, which means
agile is mature and an approach that is inherently familiar to many people.

Software Engineering & Project Management | Ms.Snehal Shinde 104

Myth 2 – Implementing agile is easy

I some organisations is that they try to implement an agile operating model or a single agile
framework “by the book” and without understanding the transformational complexity. Therefore,
they either fail to implement agile, or they do achieve some success but at significantly higher
cost and pain than they would have done if they had managed the transformation more
effectively.

Myth 3 – Agile gives instant benefit

While a transformation to agile can deliver huge benefits, the reality is that the majority of
transformations go through a learning curve. While people and organisations are learning, the
delivery capability can actually go downwards before it makes the step-change upwards and
begins to achieve the improved delivery capability.

Myth 4 – Agile means no documentation

It is important to understand that the manifesto does not say that documentation is not required, it
says the focus is on producing working software instead of spending exhaustive amounts of time
creating detailed documentation up front.

Myth 5 – Agile means “hacking” code together with little thought of architecture or design

“Hacking” in agile means cobbling together an IT system with little or no design or architectural
thinking.

Myth 6 – Agile is a silver bullet

Agile is not the answer to all IT problems. There is no single answer to all IT problems, rather
it’s about integrating different frameworks each of which provides part of the answer.

Myth 7 – Agile: just read a book

Understanding agile is not something that can be achieved by simply reading a book. It is a very
good idea to select some of the agile books from the leading agile exponents and read those, but
just reading a book cannot replace the practical experience that is essential to enabling an agile
mindset and successfully transforming an organisation or team to become agile.

Software Engineering & Project Management | Ms.Snehal Shinde 105

Myth 8 – Agile only relates to software delivery

It is true that the Agile Manifesto describes agile in the context of software delivery, but agile
can be applied successfully in business environments that are not exclusively software-related

Myth 9 – Agile should replace everything all at once in a big bang transformation

Transforming capability is a long-term process of learning and change. Businesses evolve and so
does the best way to do business. It is therefore a mistake to implement a big bang agile
transformation and then just assume further improvement is no longer necessary.

Myth 10 – Agile means no planning, just do it

The vast majority of agile frameworks involve frequent, regular and evolutionary planning. If a
team is largely doing maintenance work or defect fixing, or there is no need for the customer to
look any further than a couple of weeks when creating a product, they will probably only be
planning in single iterations/sprints. Agile isn’t “just do it” – there is significant planning and re-
planning involved when required.

Extreme Programming (XP):

 Extreme programming is a software development methodology that’s part of what’s

collectively known as agile methodologies. XP is built upon values, principles, and practices,
and its goal is to allow small to mid-sized teams to produce high-quality software and adapt to
evolving and changing requirements.

 XP’s origin dates back to the 90s when Kent Beck – who would later become one of the
authors of the Agile Manifesto – created it when hired to lead Chrysler’s Comprehensive
Compensation System team.

 What sets XP apart from the other agile methodologies is that XP emphasizes the technical
aspects of software development. Extreme programming is precise about how engineers work
since following engineering practices allows teams to deliver high-quality code at a sustainable
pace.

Software Engineering & Project Management | Ms.Snehal Shinde 106

XP Values :

1. Communication: Lack of communication prevents knowledge from moving freely within

a team. When an issue arises, it’s common for someone to have the solution already.
However, a lack of communication stops people from being informed of the issue or
participating in its resolution. As a result, the issue is resolved twice, creating waste.
2. Simplicity: You should constantly try to perform the simplest thing that works, according
to simplicity. It’s frequently misinterpreted as being the easiest thing ever, omitting the
part that says “that works.” It’s also important to keep in mind how contextualized
simplicity is. Depending solely on the abilities, knowledge, and experience of each team,
what is simple for one team may be complicated for another.
3. Feedback: Feedback is frequently “too little, too late” in more conventional, waterfall-
style software development approaches.
4. Courage: “Effective action in the face of dread” is how Kent Beck describes courage.
You have many things to be afraid of and many chances to display bravery as a software
engineer.
5. Respect: One of the core tenets of XP software development is that everyone is invested
in their work. If there is no care and respect, no amount of technical excellence can save a
project.

XP Process :

Software Engineering & Project Management | Ms.Snehal Shinde 107

 1. Planning: The customer meets with the development team during the planning stage to
present the requirements in the form of user stories that explain the desired outcome.
After that, the team estimates the stories and develops a release plan that is divided into
the number of iterations required to complete the desired functionality piece by piece. So-
called spikes can be created if one or more of the stories cannot be estimated, indicating
the need for greater study.
2. Designing: Although it is actually a step in the planning process, designing might be
mentioned separately to highlight its significance. It relates to simplicity, one of the key
XP characteristics that we’ll cover next.
3. Coding: is the stage of the project where the real code is written using XP techniques like
pair programming, continuous integration, and collective code ownership (the entire list
is described below).
4. Testing: The heart of XP in software engineering is testing. It is a routine activity that
includes both acceptance tests and unit tests, which are automated tests to see if the built
feature functions as intended (customer testing to verify that the overall system is created
according to the initial requirements).
5. Listening: Continuous feedback and communication are key components of listening.
Customers and project managers are involved in describing the intended value and
business reasoning.

Industrial XP :

The industrial XP (IXP) can be defined as the organic evolution of XP. It is customer
centric. It has expanded role for customers and advanced technical practices. Various new
practices that are appended to XP to create IXP are as follows –

1. Readiness Assessment : In this assessment, following issues are assessed –

i. Proper environment must be available to support XP.

ii. Team should contain appropriate and skilled stakeholder.

iii. The organization should support quality programs and continuous improvement.

Software Engineering & Project Management | Ms.Snehal Shinde 108

iv. The organizational culture should support new values of agile team.

2. Project Community : Skilled and efficient people must be chosen as the agile team members
for the success of the project. The team is referred as the community when extreme programming
approach is considered. The project community consists of technologies, customers, and other
stakeholders who play the vital role for the success of the project. The role of the community
members must be explicitly defined.

3. Project Chartering : Project chartering means assessing the justification for the project as a
business application. That means, the IXP team assess whether the project satisfies the goals and
objectives of the organization.

4. Test Driven management : For assessing the state of the project and its progress the industrial
XP needs some measurable criteria. In test driven management the project is tested with the help
of these measurable criteria.

5. Retrospectives : After delivering the software increment, the specialized review is conducted
which is called as retrospective. The intention of retrospectives is to improve the industrial XP
process.

6.Continuous learning : The team members are inspired and encouraged to learn new methods
and techniques that can improve the quality of the product.

SCRUM :

 Scrum is an agile project management framework that helps teams structure and manage their
work through a set of values, principles, and practices. Much like a rugby team (where it gets its
name) training for the big game, scrum encourages teams to learn through experiences, self-
organize while working on a problem, and reflect on their wins and losses to continuously
improve.

 While the scrum I’m talking about is most frequently used by software development teams, its
principles and lessons can be applied to all kinds of teamwork. This is one of the reasons scrum

Software Engineering & Project Management | Ms.Snehal Shinde 109

is so popular. Often thought of as an agile project management framework, scrum describes a set
of meetings, tools, and roles that work in concert to help teams structure and manage their work.

Scrum Process Flow (Cycle Description):

1. Establish the Product Backlog.

2. The product owner and development team conduct Sprint Planning. Determine the scope
of the Sprint in the first part of Sprint Planning and the plan for delivering that scope in
the second half of Sprint Planning.
3. As the Sprint progresses, the development team performs the work necessary to deliver
the selected product backlog items.
4. On a daily basis, the development team coordinates their work in a Daily Scrum.

5. At the end of the Sprint, the development team delivers the Product Backlog Items
selected during Sprint Planning. The development team holds a Sprint Review to show
the customer the increment and get feedback. The development team and product owner
also reflect on how the Sprint has proceeded so far and adapted their processes
accordingly during a retrospective.
6. The Team repeats steps 2–5 until the desired outcome of the product has been met.

Scrum Terminologies :

Software Engineering & Project Management | Ms.Snehal Shinde 110

  Scrum Roles-

1) The Product Owner- The product owner is a role team responsible for managing the product
backlog in order to achieve the desired outcome that the team seeks to accomplish.

2) The Scrum Master- The scrum master is the team role responsible for ensuring the team lives
agile values and principles and follows the processes and practices that the team agreed they
would use.

3) The Development Team- The development team consists of the people who deliver the
product increment inside a Sprint.

 Sprint-

The heartbeat of scrum. Each Sprint must bring the product closer to the product goal and lasts
one month or less.

 Sprint Planning (meeting)-

-A team starts out a Sprint with a discussion to determine which items from the product backlog
they will work on during the Sprint. The end result of Sprint Planning is the Sprint Backlog.

 Daily Scrum (meeting)-

The Daily Scrum is a short (usually limited to 15 minutes) discussion where the team coordinates
their activities for the following day.

 Sprint Review-

At the end of the Sprint, the entire team (including the product owner) reviews the results of the
sprint with stakeholders of the product. The purpose of this discussion is to discuss, demonstrate,
and potentially give the stakeholders a chance to use, the increment in order to get feedback.

 Sprint Retrospective-

At the end of the Sprint following the sprint review, the team (including the product owner)
should reflect upon how things went during the previous sprint and identify adjustments they
could make going forward.
Software Engineering & Project Management | Ms.Snehal Shinde 111
  Product Backlog-

A pop-up, ordered list of what is needed to improve the product and includes the goal of the
product.

 Sprint Backlog-

The Sprint Backlog is the collection of product backlog items selected for delivery in the Sprint,
and if the team identifies tasks, the tasks necessary to deliver those product backlog items and
achieve the Sprint Goal.

 Burn-down Chart :

 A burn down chart is a graphical representation of work left to do versus time. It is often used
in agile software development methodologies such as Scrum. However, burn down charts can be
applied to any project containing measurable progress over time.

 Typically, in a burn down chart, the outstanding work is often on the vertical axis, with time
along the horizontal. It is useful for predicting when all of the work will be completed. In
the Daily Scrum the Development Team updates the Sprint Burn Down and plots the remaining

Software Engineering & Project Management | Ms.Snehal Shinde 112

work of the day. A burndown chart is almost a “must” have tool for a Scrum team for the
following main reasons:

1) Monitoring the project scope creep

2) Keeping the team running on schedule

3) Comparing the planned work against the team progression

Agile Practices :

1.Test Driven Development :

 Test Driven Development (TDD) is software development approach in which test cases are
developed to specify and validate what the code will do. In simple terms, test cases for each
functionality are created and tested first and if the test fails then the new code is written in order
to pass the test and making code simple and bug-free.

 The simple concept of TDD is to write and correct the failed tests before writing new code
(before development). This helps to avoid duplication of code as we write a small amount of

Software Engineering & Project Management | Ms.Snehal Shinde 113

code at a time in order to pass tests. (Tests are nothing but requirement conditions that we need
to test to fulfill them). TDD sometimes also called as Test First Development.

 TDD cycle defines-

1. Write a test
2. Make it run.
3. Change the code to make it right i.e. Refactor.
4. Repeat process.

2.Refactoring :

 Refactoring or Code Refactoring is defined as systematic process of improving existing

computer code, without adding new functionality or changing external behaviour of the code. It
is intended to change the implementation, definition, structure of code without changing
functionality of software.

 It improves extensibility, maintainability, and readability of software without changing what it

actually does.

 Why should we refactor our code when it works fine? The goal of refactoring is not to add new
functionality or remove an existing one. The main goal of refactoring is to make code easier to
maintain in future and to fight technical debt.

Software Engineering & Project Management | Ms.Snehal Shinde 114

 We do refactor because we understand that getting design right in first time is hard and also
you get the following benefits from refactoring:

 Code size is often reduced

 Confusing code is restructured into simpler code
 Both of the above benefits greatly improve maintainability which is required because
requirements always keep changing. When do we refactor?
 Before you add new features, make sure your design and current code is “good” this will
help the new code be easier to write.
 When you need to fix a bug
 When you do a peer review
 During a code review

3.Pair Programming :

 Pair programming is a development technique in which two programmers work together at

single workstation. Person who writes code is called a driver and a person who observes and
navigates each line of the code is called navigator. They may switch their role frequently.

 Sometimes pair programming is also known as pairing. Pairing Variations : There are three
pairing variations –

Newbie-newbie pairing can sometimes give a great result. Because it is better than one solo
newbie. But generally, this pair is rarely practiced.

Expert–newbie pairing gives significant results. In this pairing, a newbie can learn many things
from expert, and expert gets a chance to share his knowledge with newbie.

Expert–expert pairing is a good choice for higher productivity as both of them would be expert,
so they can work very efficiently.

 Advantages of Pair Programming :

Software Engineering & Project Management | Ms.Snehal Shinde 115

1) Two brains are always better than one – If driver encounters a problem with code, there will
be two of them who’ll solve problem. When driver is writing code, navigator can think about a
solution to problem.

2) Detection of coding mistakes becomes easier – Navigator is observing each and every line of
code written by driver, so mistakes or error can be detected easily.

3) Mutual learning – Both of them can share their knowledge with each other and can learn many
new things together.

4) Team develops better communication skills – Both of them share knowledge and work
together for many hours a day and constantly share information with each other so this can help
in developing better communication skills, especially when one of members is a newbie and
other is an expert.

 Disadvantages of Pair Programming :

1) Team Fit – High-intensity communication of pair programming is not a good fit for every
developer. Sometimes, drivers are supposed to speak loud as they write code. Some people may
not agree on idea of sitting, literally shoulder-to-shoulder, with a colleague for eight hours a day.
Some experienced developers are more productive in solo rather than in pair programming.

2) Newbie-newbie pairing problem – Newbie–newbie pairing can produce results better than two
newbie working independently, although this practice is generally avoided because it is harder
for newbie to develop good habits without a proper role model.

4.Continuous Integration :

 Continuous integration is the developer practice of constantly integrating code into your code
base. The idea is to make small changes and commit these code changes into a shared repository
frequently — at least once daily but usually multiple times a day. Each integration is verified by
an automated build, which includes testing to detect any integration errors.

Software Engineering & Project Management | Ms.Snehal Shinde 116

  Smaller code changes have fewer unintended consequences. By checking in code
continuously, problems with the build are limited and addressed much earlier in the development

process. This significantly reduces integration issues and makes fixing a broken build easier. It
also helps reduce the backlog of non-critical defects because these problems are remediated
before the pressure for new features builds. Frequent check-ins also promote collaboration across
teams and allow developers to get better quality software out the door to customers faster.

 Automation is a large part of successfully integrating and validating these continuous code
changes. CI relies heavily on automation tools such as source code management systems and
continuous integration servers to make it possible to build, package, and test software.

5.Exploratory and Scripted Testing :

1) Scripted testing:

In Scripted testing to test specific functionality a tester follows a detailed step-by-step systematic
approach. For this testing in advance, the tester has to define the test cases of the functionality
along with its instructions to perform it and finally the expected outcome of the test. Testers
follow the testing instructions and steps but in case they may deviate from the script which is
very minimal in the case of scripted testing. It ensures that every functionality must be tested and
passed. In this scripted testing skilled resources, well-scripted instructions test cases and
verification are required.

2) Exploratory testing:

Software Engineering & Project Management | Ms.Snehal Shinde 117

Exploratory testing is more toward learning and the experience-based testing approach means it
depends more on the responsibility of a tester. So, a tester can apply this exploratory testing to
any test technique and at any time development stage. The key aspect of exploratory testing is it
depends on the skills and experience of individual testers. As it is adaptable to changes, it is very
good for rapidly changing development processes and well suited for the agile development
approach.

Difference between Scripted testing and Exploratory testing :

S.NO SCRIPTED TESTING EXPLORATORY TESTING

1 The test scripts can be traced back to the In this testing no well-documented, clear,
original requirements and specifications to and measurable test coverage.
demonstrate test coverage.
2 The application is verified against the The application is verified and compared
specifications. against the expectations and understanding
of the tester.
3 The testing can be easily reproduced. Whereas in exploratory testing, testing can
not be reproduced, but the defects can be.

4 This approach emphasizes prediction and This approach emphasizes adaptability and
decision-making. learning.
5 At the end of the test cycle bugs are This approach focuses more on test design.
detected.
6 Testers need to follow the sequence and Testers can alter tests on the fly.
steps of test cases which are designed in
advance.
7 Feedback is slower. Enables rapid feedback.
8 In this testing, all test scripts and test cases As with scripted testing, in this test cases
are designed and reviewed in advance. cannot be reviewed in advance.
9 At the end of the testing cycle, testers can As there are no clear and documented test
confirm if all the requirements have been cases, there is no way to check and confirm
met or not. that all the requirements have been met.
10 Managing test coverage is easier. Managing test coverage is challenging.

11 It can be automated. It cannot be automated.

Software Engineering & Project Management | Ms.Snehal Shinde 118