AGILE MANAGEMENT 1
CCC403
Quality in Project Management
When asking "what is quality in project management", it's important to
understand that quality refers to quality assurance. According to the American
Society for Quality (ASQ), quality assurance is "the planned and systematic
activities implemented in a quality system so that quality requirements for a
product or service will be fulfilled." Now that you know the definition of quality
assurance, it's time to learn what is quality assurance in project management.
You can think of quality assurance as the management and regulation of the
products and services the project delivers to ensure they are at the required
quality level. This process is extremely important to maintain not only the
quality of products and services but also consistency.
How to Create a Project Management Plan
A Project Management Plan (PMP not to be confused with the Project
Management Professional certification) defines not only when a project will be
delivered, but also how it will be delivered. If a document only contains what will
be done and by when, it is not a true Project Management Plan. This can be
confusing, as there are a number of explainers on how to create a project
management plan or a project plan that leaves out key components. A complete
project management plan must include guidelines on how a project is executed,
monitored, and controlled.
According to the Project Management Institute, it should answer all of the
questions listed below:
1. What is to be done?
2. When will it occur?
3. How much will it cost?
4. Who will do it?
5. What product(s) or service(s) will be delivered as a result of the effort?
6. What is the responsibility of both the developer and the user?
7. Who is responsible for accepting the product as completed?
8. What determines task completion?
9. What mechanics will be employed to deal with mechanics formally?
10. How will actual progress be measured?
1|Page
How to write a project management plan
The creation of your plan should start with a project management plan template.
The length and level of detail included in the plan will depend on your
organization and project. Many companies will already have an internal template
they prefer to use, that outlines the level of information they need. The plan
should always begin with a title page, version history, and table of contents. A
strong project management plan will include all of the following information:

Project scope baseline & scope management plan

Project schedule baseline & schedule management plan

Project cost baseline & cost management plan

Human resource management plan

Communications management plan

Risk management plan
Depending on project, there may also be additional supplemental plans such as:

Issues management plan
Quality management plan

Procurement management plan

Requirement management plan

Configuration management plan

Process management plan

Change management plan

Stakeholder management plan

Training plan

Appendices to the plan may also include:

The approved business case for the plan

The approved Project Charter

Key terms and acronyms

Any additional relevant information such as:

Statement of Work

Customer requirements documentation

RACI (responsibility matrix)

Stakeholder management plan
2|Page
The project manager’s role
Unless you’re working in a small organization, you likely have a procurement
team within your company. Therefore, it’s natural to ask what their typical role
is with project procurement management, and about the responsibility of the
project manager. The details will depend on your organization and the
procurement roles present. Some companies have procurement managers who
work alongside the project manager and take care of the majority of these
processes. In other cases, the procurement team may only be responsible for the
transactional tasks. Here are some general guidelines of what you will be
responsible for as a project manager, regardless of what the procurement
management department in your company looks like:

The planning process: As the project manager, you will not create the plan
in isolation. It will likely be undertaken with the input of your entire
project team, including the procurement team, legal team (if you have
one), and any other relevant subject matter experts within the company.
This may include estimators, finance, scheduling, design or engineering,
operations, etc.

Controlling procurements: The project manager does not generally conduct
the procurements. However, you are still responsible for ensuring they are
conducted appropriately. This means you need to be aware of the status of
procurements. If something is late, you need to know how it impacts the
rest of your project schedule and mitigate it appropriately. If there is a
conflict between department requirements, it will be up to you to resolve
it. For example, imagine that you are told a key material has a 10-week
lead time. Unfortunately, your schedule shows you need it in eight weeks.
You’re told they can get it in eight weeks if you pay an extra 15% for air
transport. Do you allow the two-week delay, or do you accept the cost
overrun? Is there a third option, such as finding a different supplier? As
the project manager, the decision will be your responsibility.
What Is an Activity in Project Management?
If you have spent any time creating or following a project management plan,
you’ve heard the term “activity” used many times.
3|Page
An activity is typically one stage of a project management plan. Each activity
consists of one or more actions that, upon completion, will lead to the next
project stage. Taken together as a series, the activities will result in the final
deliverable. Each activity has a defined start and end, as well as a deadline or
time period within which it must be completed.
When you are planning a project, one of the key steps is to define the activities
required to bring that project to fruition. This generally involves creating an
activity list, which is exactly what it sounds like a list of all the actions required
for the project. For example, let’s say you are planning a large event. Some
activities that might be involved include:

Mailing invitations

Booking the venue

Hiring a caterer
Each activity will likely consist of several sub-tasks; sending out the invitations,
for example, will require gathering and confirming attendees’ addresses, printing
the invitations and envelopes, and then mailing the completed invitations.
Booking a venue will require site visits, RFPs, price negotiation, signing a
contract, and so on.
Once the activities have been defined, it’s up to the project manager and other
stakeholders to sequence them in other words, to place them in the appropriate
order, and then track and manage them. Activities are typically tracked with
either a network diagram, representing all the activities for a project in a
sequential, workflow format or a Gantt chart, which represents tasks via
horizontal bars that demonstrate their length and duration.
Example of a Gantt chart:
Many modern project management software solutions blend elements of Gantt
charts with network diagrams to produce a robust tracking document that
visually represents a project’s activities, dependencies (which activities are
connected to others), and workflow.
What Is Cost in Project Management?
Virtually every project that an organization undertakes will cost money. In fact,
cost is traditionally considered to be one of the three primary constraints of any
4|Page
project, along with time and scope. And it’s up to the project manager with input
from the project’s other stakeholders to determine how much a project will cost,
create a reasonable budget to allocate the appropriate resources, and manage
the budget
to maximize value and minimize spend. The first step to
understanding cost in project management is to define the types of expenses
that a project will likely incur.
They typically fall into two categories:
1. Direct costs: Examples of direct costs include fixed labor, materials, and
equipment. They are typically one-off costs that come from a single
department or the project itself.
2. Indirect costs: Examples of indirect costs include utilities and quality
control. Incurred by the organization at large, indirect costs occur at the
same time as the project, but are not necessarily caused by it.
Next, the project manager will need to undertake the process of cost estimation,
which is used to predict the resources needed to complete a project within a
defined scope, and determine whether the project will be green lighted.
Cost estimation factors in elements such as:
1. Labor: The cost of team members’ wages and time working on the project
2. Materials and equipment: Physical tools, software, legal permits, etc.
3. Facilities: The use of external workspaces
4. Vendors: Third-party vendors and/or contractors
5. Risk: Contingency plans to reduce risk
If the project is a go, the project manager must devise a budget based on the
cost estimation document, allocating resources properly. Managing that budget
is key to the project’s success. If certain pieces of the project end up costing
more or less than anticipated, the project manager will need to manage the risk
and reallocate funds as necessary.
What Is Planning in Project Management?
You may have a great idea for a project, but without planning, your project will
remain just that an idea. Planning is the critical step to take a project from an
intangible theory to a tangible result.
5|Page
What does project planning entail?
To bring a project to fruition, the project manager will need to assemble a project
plan. The project plan describes the cost, scope, and schedule for the project. It
lays out exactly what activities and tasks will be required, as well as the
resources needed, from personnel to equipment to financing, and where they can
be acquired. Good project planning also factors in risk and how to manage it,
including contingency plans, and details a communication strategy to keep all
stakeholders up to date and on board.
Project planning and management
Planning the project typically involves the following steps:
1. Initiation: This step typically occurs before the project is greenlit. It
usually involves putting together a business case document that explains
the need for the project, followed by a feasibility study to determine the
viability of the project in terms of its cost and projected benefits.
2. Stakeholder
involvement:
Identify
your
project
sponsors
and
key
stakeholders. To ensure the success of the project, meet with them to
discuss their needs and expectations. Map out the project scope, budget,
and timeline with them, and make sure to get their complete buy-in.
3. Prioritizing goals: A project and a team can only do so much. Prioritize
your goals to make fulfilling them clearer and easier.
4. Identifying deliverables: What are the specific deliverables that you and
your team are expected to produce? You’ll need to know exactly what is
expected of you, as well as when (i.e., the deadlines for each output). You’ll
also want to define what success looks like for each deliverable and
develop metrics to track and rank each one.
5. Scheduling: Using the information in the previous step, you’ll need to map
out the project's timeline.
6. Developing a project plan: As previously described, a project plan lays out
the steps needed to bring the project to fruition. It includes all the
activities and tasks required in the appropriate order and workflow. The
project plan will draw from all the previous steps.
7. Bake in contingency plans: No project is without hiccups. Make sure you
plan for any bumps in the road by assessing the risks associated with
your project and putting plans in place to address them.
6|Page
Once the project has been mapped out, it will need to be presented to the
stakeholders, edited if necessary, and then managed. Project plan management
includes troubleshooting when issues arise, keeping the project on schedule,
and moderating the budget.
What Is Project Management Experience?
If you’ve ever applied for a project management position or looked into getting a
project management certification, you’ve likely come across a requirement for
“project management experience.” For example, consider that, for a Project
Management Professional (PMP) certification, PMI requires you to demonstrate at
least 4,500 hours of experience leading and directing projects. For the Certified
Associate in Project Management (CAPM) degree, you need 1,500 hours of
experience or 23 hours of related education. But while project management
experience is a prerequisite for many job and educational opportunities, you
may be wondering what qualifies as project management experience and how
you can go about getting it.
What qualifies as project management experience?
Experience in project management refers to time spent planning, leading,
directing, and managing projects. For example, some typical responsibilities of a
project manager include:


Planning: Project managers create a blueprint that will guide the entire
project from ideation to fruition, clarifying its scope, necessary resources,
anticipated timeframe, communication strategy, and more.
Leading: Project managers lead the project team through the process,
meaning they have excellent communication and people skills.

Execution: A project manager is likely to engage in the tangible activities
required for moving the project forward.

Time management: Project managers keep everyone on schedule and,
when issues arise, are responsible for resolving them and communicating
effectively with team members and other stakeholders.

Budget: A key responsibility for project managers includes coming up with
and sticking to a budget for the project. If unexpected financial issues
arise, it’s up to the project manager to manage them and reallocate
resources where necessary.
7|Page

Documentation: Project managers keep a record of each project’s progress
with tools such as data collection and status reports.

Maintenance: It’s crucial to come up with a plan for the ongoing success of
the deliverable; this includes troubleshooting and maintenance.
Participating in any of these activities can qualify as experience in project
management.
How to get project management experience
First things first: You don’t have to have “project manager” in your job title to get
project management experience. As industry veteran Frank Ryle told Fast
Company several years ago: “Lots of people have projects in their work, they just
don’t know it. Software has automated a lot of things, but not goals, resources,
and products. That’s something you can find in all kinds of work.”
On-the-job work doing any of the activities listed above counts as project
management experience; review your past roles and responsibilities to see if you
already have some related experience under your belt. If you find that you don’t
already have a track record in those areas, you could consider volunteering to
manage small projects for your company, shadowing a mentor, or completing
an apprenticeship. This will introduce you to important project management
practices and principles and help you form the networks you need to get your
first project management job. If your organization has a Project Management
Office, get in touch and offer to pitch in however you can. If your company
doesn’t have a PMO, consider speaking to your supervisor and human resources
department about setting one up. The experience of doing it as well as the
initiative you’re showing will go a long way.
Software Development Life Cycle (SDLC)
The software development life cycle (SDLC) is a structured process that is used
to
design,
develop,
and
test
good-quality
software. SDLC,
or
software
development life cycle is a methodology that defines the entire procedure of
software development step-by-step. The goal of the SDLC life cycle model is to
deliver high-quality, maintainable software that meets the user’s requirements.
SDLC in software engineering models outlines the plan for each stage so that
each stage of the software development model can perform its task efficiently to
8|Page
deliver the software at a low cost within a given time frame that meets users’
requirements. The SDLC model involves six phases or stages while developing
any software. SDLC is a collection of these six stages, and the stages of SDLC
are as follows:
Stages of Software Development Life Cycle Model
Stage-1: Planning and Requirement Analysis
Planning is a crucial step in everything, just as in software development. In this
same stage, requirement analysis is also performed by the developers of the
organization.
This
is
attained
from
customer
inputs,
and
sales
department/market surveys. The information from this analysis forms the
building blocks of a basic project. The quality of the project is a result of
planning.
Stage-2: Defining Requirements
In this stage, all the requirements for the target software are specified. These
requirements get approval from customers, market analysts, and stakeholders.
This is fulfilled by utilizing SRS (Software Requirement Specification). This is a
sort of document that specifies all those things that need to be defined and
created during the entire project cycle.
Stage-3: Designing Architecture
SRS is a reference for software designers to come up with the best architecture
for the software. Hence, with the requirements defined in SRS, multiple designs
for the product architecture are present in the Design Document Specification
9|Page
(DDS). This DDS is assessed by market analysts and stakeholders. After
evaluating all the possible factors, the most practical and logical design is
chosen for development.
Stage-4: Developing Product
At this stage, the fundamental development of the product starts. For this,
developers use a specific programming code as per the design in the DDS.
Hence, it is important for the coders to follow the protocols set by the
association. Conventional programming tools like compilers, interpreters,
debuggers, etc. are also put into use at this stage. Some popular languages like
C/C++, Python, Java, etc. are put into use as per the software regulations.
Stage-5: Product Testing and Integration
After the development of the product, testing of software is necessary to ensure
its smooth execution. Although, minimal testing is conducted at every stage of
SDLC. At this stage, all the probable flaws are tracked, fixed, and retested. This
ensures that the product confronts the quality requirements of SRS.
Documentation, Training, and Support: Software documentation is an essential
part of the software development life cycle. A well-written document acts as a
tool and means to information repository necessary to know about software
processes,
functions,
and
maintenance.
Documentation
also
provides
information about how to use the product. Training in an attempt to improve
the current or future employee performance by increasing an employee’s ability
to work through learning, usually by changing his attitude and developing his
skills and understanding.
Stage 6: Deployment and Maintenance of Products
After detailed testing, the conclusive product is released in phases as per the
organization’s strategy. Then it is tested in a real industrial environment. It is
important to ensure its smooth performance. If it performs well, the
organization sends out the product as a whole. After retrieving beneficial
feedback, the company releases it as it is or with auxiliary improvements to
make it further helpful for the customers. However, this alone is not enough.
Therefore, along with the deployment, the product’s supervision.
10 | P a g e
Below are the top five most popular SDLC models;
1. Waterfall Model
It is the fundamental model of the software development life cycle. This is a
very simple model. The waterfall model is not in practice anymore, but it is the
basis for all other SDLC models. Because of its simple structure, the waterfall
model is easier to use and provides a tangible output. In the waterfall model,
once a phase seems to be completed, it cannot be changed, and due to this less
flexible nature, the waterfall model is not in practice anymore.
2. Agile Model
The agile model was mainly designed to adapt to changing requests quickly.
The main goal of the Agile model is to facilitate quick project completion. The
agile model refers to a group of development processes.
3. Iterative Model
In the iterative model, each cycle results in a semi-developed but deployable
version; with each cycle, some requirements are added to the software, and the
final cycle results in the software with the complete requirement specification.
4. Spiral Model
The spiral model is one of the most crucial SDLC models that provides support
for risk handling. It has various spirals in its diagrammatic representation; the
number of spirals depends upon the type of project. Each loop in the spiral
structure indicates the Phases of the Spiral model.
5. V-Shaped Model
The V-shaped model is executed in a sequential manner in V-shape. Each stage
or phase of this model is integrated with a testing phase. After every
development phase, a testing phase is associated with it, and the next phase
will start once the previous phase is completed, i.e., development & testing. It
is also known as the verification or validation model.
6. Big Bang Model
The Big Bang model in SDLC is a term used to describe an informal and
unstructured approach to software development, where there is no specific
planning, documentation, or well-defined phases.
11 | P a g e
Traditional project management approaches
Some of the most well-known project management approaches were developed
for industries like manufacturing or engineering, which produce physical
products such as buildings, cars, or computers. They include:

Waterfall: Perhaps the most common way to plan out a project, the
Waterfall method is a simple sequential approach. Each project phase
must be completed before beginning the next one, leading to the end
deliverable. These project plans can be easily replicated for future use.

Critical path method: Similar to the Waterfall methodology, the critical
path method is a sequential approach that allows project managers to
prioritize resources, putting more emphasis and investment into the most
important work and rescheduling lower-priority tasks that may be slowing
down the team.

Critical chain project management (CCPM): This methodology focuses on
the resources needed for each task in the project. Using this approach, the
project manager identifies and allocates resources for the most crucial,
high-priority tasks the “critical chain” and builds in buffers of time around
these tasks to ensure the project’s main deadlines are met.
Waterfall Model
The Waterfall Model was the first Process Model to be introduced. It is also
referred to as a linear-sequential life cycle model. It is very simple to understand
and use. In a waterfall model, each phase must be completed before the next
phase can begin and there is no overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for software
development. The waterfall Model illustrates the software development process in
a linear sequential flow. This means that any phase in the development process
begins only if the previous phase is complete. In this waterfall model, the phases
do not overlap.
Waterfall Model - Design
Waterfall approach was first SDLC Model to be used widely in Software
Engineering to ensure success of the project. In "The Waterfall" approach, the
whole process of software development is divided into separate phases. In this
12 | P a g e
Waterfall model, typically, the outcome of one phase acts as the input for the
next phase sequentially. The following illustration is a representation of the
different phases of the Waterfall Model.

Requirement Gathering and analysis: All possible requirements of the
system to be developed are captured in this phase and documented in a
requirement specification document.

System Design: The requirement specifications from first phase are
studied in this phase and the system design is prepared. This system
design helps in specifying hardware and system requirements and helps in
defining the overall system architecture.

Implementation: With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next
phase. Each unit is developed and tested for its functionality, which is
referred to as Unit Testing.

Integration and Testing: All the units developed in the implementation
phase are integrated into a system after testing of each unit. Post
integration the entire system is tested for any faults and failures.

Deployment of system: Once the functional and non-functional testing is
done; the product is deployed in the customer environment or released
into the market.

Maintenance: There are some issues which come up in the client
environment. To fix those issues, patches are released. Also to enhance
the product some better versions are released. Maintenance is done to
deliver these changes in the customer environment.
13 | P a g e
All these phases are cascaded to each other in which progress is seen as flowing
steadily downwards (like a waterfall) through the phases. The next phase is
started only after the defined set of goals are achieved for previous phase and it
is signed off, so the name "Waterfall Model". In this model, phases do not
overlap.
Waterfall Model - Application
Every software developed is different and requires a suitable SDLC approach to
be followed based on the internal and external factors. Some situations where
the use of Waterfall model is most appropriate are;

Requirements are very well documented, clear and fixed.

Product definition is stable.

Technology is understood and is not dynamic.

There are no ambiguous requirements.

Ample resources with required expertise are available to support the
product.

The project is short.
Waterfall Model - Advantages
The
advantages
of
waterfall
development
are
that
it
allows
for
departmentalization and control. A schedule can be set with deadlines for each
stage of development and a product can proceed through the development
process model phases one by one. Development moves from concept, through
design, implementation, testing, installation, troubleshooting, and ends up at
operation and maintenance. Each phase of development proceeds in strict order.
Some of the major advantages of the Waterfall Model are as follows:

Simple and easy to understand and use

Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.

Phases are processed and completed one at a time.

Works well for smaller projects where requirements are very well understood.

Clearly defined stages.

Well understood milestones.

Easy to arrange tasks.

Process and results are well documented.
14 | P a g e
Waterfall Model - Disadvantages
The disadvantage of waterfall development is that it does not allow much
reflection or revision. Once an application is in the testing stage, it is very
difficult to go back and change something that was not well-documented or
thought upon in the concept stage.
The major disadvantages of the Waterfall Model are as follows;

No working software is produced until late during the life cycle.

High amounts of risk and uncertainty.

Not a good model for complex and object-oriented projects.

Poor model for long and ongoing projects.

Not suitable for the projects where requirements are at a moderate to high
risk of changing. So, risk and uncertainty is high with this process model.

It is difficult to measure progress within stages.

Cannot accommodate changing requirements.

Adjusting scope during the life cycle can end a project.

Integration is done as a "big-bang at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.
Understanding Agile Methodology
In today's fast-paced technological world, Agile Methodology is a crucial
component. It is a highly effective tool for project management and problemsolving. Agile Methodology can spearhead you to drive successful projects and
result-driven problem-solving techniques. The term Agile Methodology refers to a
certain mindset and approach towards software development that focuses on
delivering high-quality work in a timely and efficient manner.
Definition of Agile Methodology
It's a systematic approach to handling changes in a project’s scope. This method
is often used in IT project management, as it accommodates the unpredictable
and rapid changes often encountered during the development of technological
solutions. Agile Methodology is a project management approach that involves
breaking down a large project into smaller, manageable tasks, called iterations
or sprints. The priority is quick responses to changes and continuous
development.
15 | P a g e
Adopting Agile Methodology, allows you to benefit from:

Clear visibility into the project’s progress

Effective responses to changes in project scope and requirements

Increased productivity and efficiency in delivering a final product
What is the 3M’s of Agile Project Management?
Certain imperatives need to be observed in executing a project. There are 3M’s
- methodology, mindset, and metrics. These determine the direction and the
route of the project:
1. Methodology
It is how the project needs to be addressed. It needs to be measured for what
is required. Here a method has to be crafted so that every phase of the project
is measured for its success or progress toward the ultimate goal. The
methodology is a set of predetermined principles and processes that would be
followed when executing a project. This guide helps in prioritizing the work
portioned out within the project. The project team has the option to apply
Agile, Kanban, Scrum, Waterfall, or even hybrid methodologies.
2. Mindset
Here, it is the attitudes and influences of the project management team that
guides it toward the best approach. The tactics and the control that is required
to be practiced for managing the resources marked out for a project. It involves
several elements that constitute a mindset prepared to measure performanc e
objectively, namely:

Critical Thinking: It is the ability of the project personnel to be able to view
a project multidimensionality and find solutions for its completion. This
will reveal the hidden risks and issues that might assume unmanageable
proportions during the project.

Initiative: when the project personnel is self-motivated and does not to be
told what to do; that denotes his ability to take the initiative without being
commanded. Success is more likely.

Collaboration: Having a team spirit while working on a project is hugely
important for its success. There should be no personal or professional
conflicts within the team, for that would mean sure failure. So success has
to be obvious to be measured.
16 | P a g e
3. Metrics
There are metrics to determine the success or failure of any project.
Comprehending the project in its entirety is what leads to its positive
completion. The pre-set milestones lead to well-informed decisions about the
next steps. Then there are metrics related to costs to evaluate performance,
productivity,
Return
on
investment,
customer
satisfaction,
employee
satisfaction, and schedule variance. Keeping a set of metrics alongside the
project would make execution and assessment much easier and less timeconsuming. Transform your management approach with agile trainings.
Embrace adaptability, teamwork, and creativity for unparalleled achievement.
Key Agile Development Concepts
User Stories: The team divides the work into functional units known as
"user stories" in consultation with the client or product owner. Each user story
must add something valuable to the final product.
Daily Meeting: The team meets every day at the same time to update everyone on
the information necessary for coordination:
Personas: When the project requires it, the team creates in-depth, fabricated
biographies of hypothetical users of the intended product.
Team: A small group of individuals assigned to the same project or effort, almost
all of whom work full-time, is referred to as a "team" in the Agile context.
Incremental Development: Agile teams prefer to use an incremental development
strategy, which in an Agile setting means that each iteration of the product
improves on the one before it by including user-visible functionality.
Iterative development: Agile projects intentionally permit "repeating" software
development activities and the potential for "revisiting" the same work products,
known as iterative development.
Milestone Retrospective: After a project has been running for a while, the team
dedicates one to three days to examine the key moments.
Introduction to the Pillars of Agile
Agile has emerged as a powerful methodology that helps organizations adapt to
change, deliver value faster, and improve collaboration. But what exactly makes
Agile so effective? The answer lies in its foundational pillars.
17 | P a g e
We shall be discussing extensively the core principles that underpin Agile, often
referred to as the “four pillars of Agile.” These pillars are the guiding lights that
inform Agile practices and ensure teams can respond swiftly to changing
environments. These Agile pillars help guide teams as they navigate their
projects.
Agile values and principles
Agile project management is constructed out of four key values and 12 main
principles. The four main values help clarify that APM is collaborative and
people-oriented, with the goal of creating functional software that delivers value
to the end user. These four values are as follows:
What are the 4 pillars of Agile?
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
The four Agile pillars are as follows:
1. Individuals and interactions over processes and tools
The first of the Agile pillars outlines the most important priority: people. You
should communicate regularly with your and ensure each member feels like a
valued employee. Processes and tools are useful assets to have, but they are
there to support your teams, not overshadow them. The best Agile projects will
be driven by engaged individuals that interact well with one another.
2. Working software over comprehensive documentation
The Agile Manifesto was designed to remove the frustrations of “documentationdriven, heavyweight software development processes.” Instead of wasting time
preparing detailed product specifications, Agile teams summarize all relevant
information in a single user story. This streamlined approach means developers
can get to work right away and prepare their software for release. The idea here
is to get a working deliverable out and refine it later, rather than trying to
document everything before the work even begins.
3. Customer collaboration over contract negotiation
Customer collaboration is one of the most well-known Agile pillars. It is viewed
as favorable to contract negotiation, where the customer’s desired deliverables
18 | P a g e
are noted in a legal contract before the software development process begins. If
the finished product does not meet expectations, a contract renegotiation has to
take place. Under the Agile philosophy, however, customers are invited to
collaborate with developers throughout the software development life cycle,
offering their thoughts and potential suggestions while the product is being
built. This way, their feedback is baked into the development process, meaning
the end deliverable is more likely to be compatible with the user’s specific needs.
4. Responding to change over following a plan
Merriam-Webster’s definition of the word ’agile’ is “having a quick, resourceful,
and adaptable character.” This matches the description of Agile team members,
who are open to change and willing to adapt their software to ensure that the
final deliverable is the best it can be. This Agile mindset contrasts with
traditional methodologies such as Waterfall, which aims to avoid change and
stick to the original project plan as much as possible.
The advantages of Agile Methodology are inherent in its 12 Principles, as
outlined by the Agile Alliance:
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software. Customer satisfaction and
quality deliverables are the focus.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage. Don’t fight
change, instead learn to take advantage of it.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale. Continually provide
results throughout a project, not just at its culmination.
4. Business people and developers must work together daily throughout the
project. Collaboration is key.
5. Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done. Bring talented
and hardworking members to the team and get out of their way.
6. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation. Eliminate as many
opportunities for miscommunication as possible.
19 | P a g e
7. Working software is the primary measure of progress. It doesn’t need to be
perfect, it needs to work.
8. Agile
processes
promote
sustainable
development.
The
sponsors,
developers, and users should be able to maintain a constant pace
indefinitely. Slow and steady wins the race.
9. Continuous attention to technical excellence and good design enhances
agility. Don’t forget to pay attention to the small stuff.
10. Simplicity the art of maximizing the amount of work not done is
essential. Trim the fat.
11. The best architectures, requirements, and designs emerge from selfOrganizing teams. Related to Principle 5, you’ll get the best work from
your team if you let them figure out their own roles.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly. Elicit and
provide feedback, absorb the feedback, and adjust where needed.
Agile Model Vs Waterfall Model
Agile and Waterfall model are two different methods for software development
process. Though they are different in their approach, both methods are useful at
times, depending on the requirement and the type of the project.
S/N Agile Model
1
Agile
Waterfall Model
methodologies
propose Waterfall Model: Development of the
incremental and iterative approach software
to software design
2
The Agile
engineering
sequentially
from
start point to end point.
process in
is
flows
software The design process is not broken
broken
into into an individual models
individual models that designers
work on.
3
The
customer
has
early
and The customer can only see the
frequent opportunities to look at the product at the end of the project
product and make decision and
changes to the project
20 | P a g e
4
Agile
model
unstructured
is
considered Waterfall model are more secure
compared
to
the because they are so plan oriented
waterfall model
5
Small projects can be implemented All sorts of project can be estimated
very quickly. For large projects, it is and completed.
difficult to estimate the development
time.
6
Error can be fixed in the middle of Only at the end, the whole product
the project.
is tested. If the requirement error is
found or any changes have to be
made, the project has to start from
the beginning
7
Development process is iterative, The development process is phased,
and the project is executed in short and the phase is much bigger than
(2-4) weeks iterations. Planning is iteration. Every phase ends with the
very less.
detailed
description
of
the
next
phase.
8
Documentation attends less priority Documentation is a top priority and
than software development
can even use for training staff and
upgrade the software with another
team
9
Every iteration has its own testing Only after the development phase,
phase.
It
allows
implementing the
testing
phase
is
executed
regression testing every time new because separate parts are not fully
functions or logic are released.
10
functional.
In agile testing when an iteration All features developed are delivered
end,
shippable
product
is
features
delivered
of
to
the at
once
after
the
long
the implementation phase.
customer. New features are usable
right after shipment. It is useful
when you have good contact with
customers.
21 | P a g e
11
Testers
and
developers
work Testers
together
12
separately
from
developers
At the end of every sprint, user User acceptance is performed at the
acceptance is performed
13
work
It
requires
with
close
developers
end of the project.
communication Developer
and
does
not
involve
in
together requirement and planning process.
analyze requirements and planning
Usually, time delays between tests
and coding
Agile Process
Agile methodology process to deliver successful systems quickly are as follows;
Scrum
SCRUM is an agile development method which concentrates specifically on how
to manage tasks within a team-based development environment. Basically,
Scrum is derived from activity that occurs during a rugby match. Scrum believes
in empowering the development team and advocates working in small teams
(say- 7 to 9 members).
Agile and Scrum consist of three roles, their responsibilities explained as follows:
22 | P a g e
Scrum Master is responsible for setting up the team, sprint meeting and
removes obstacles to progress.
Product owner creates product backlog, prioritizes the backlog and is
responsible for the delivery of the functionality at each iteration
Scrum Team Its own work, organizes the work to complete the sprint or cycle.
Product Backlog This is a repository where requirements are tracked with
details on the no of requirements (user stories) to be completed for each
release. It should be maintained and prioritized by Product Owner, and it
should be distributed to the scrum team. Team can also request for a new
requirement addition or modification or deletion.
Scrum Practices are described in detailed:
23 | P a g e
Process flow of scrum testing is as follows:
1.
Each iteration of a scrum is known as Sprint
2.
Product backlog is a list where all details are entered to get the end-product
3.
During each Sprint, top user stories of Product backlog are selected and
turned into Sprint backlog
4.
Team works on the defined sprint backlog
5.
Team checks for the daily work
6.
At the end of the sprint, team delivers product functionality
Extreme Programming (XP)
Extreme Programming technique is very helpful when there is constantly
changing demands or requirements from the customers or when they are not
sure about the functionality of the system. It advocates frequent “releases” of the
product in short development cycles, which inherently improves the productivity
of the system and also introduces a checkpoint where any customer
requirements can be easily implemented. The XP develops software keeping
customer in the target.
Business requirements are gathered in terms of stories. All those stories are
stored in a place called the parking lot. In this type of methodology, releases are
based on the shorter cycles called Iterations with span of 14 days time period.
Each iteration includes phases like coding, unit testing and system testing
24 | P a g e
where at each phase some minor or major functionality will be built in the
application.
Phases of eXtreme programming: there are 6 phases available in Agile XP
method, and those are explained as follows:
1. Planning

Identification of stakeholders and sponsors

Infrastructure Requirements

Security related information and gathering

Service Level Agreements and its conditions
2. Analysis

Capturing of Stories in Parking lot

Prioritize stories in Parking lot

Scrubbing of stories for estimation

Define Iteration SPAN (Time)

Resource planning for both Development and QA teams
3. Design

Break down of tasks

Test Scenario preparation for each task

Regression Automation Framework
4. Execution

Coding

Unit Testing

Execution of Manual test scenarios

Defect Report generation

Conversion of Manual to Automation regression test cases

Mid Iteration review

End of Iteration review
5. Wrapping

Small Releases

Regression Testing

Demos and reviews

Develop new stories based on the need

Process Improvements based on end of iteration review comments
25 | P a g e
6. Closure

Pilot Launch

Training

Production Launch

SLA Guarantee assurance

Review SOA strategy

Production Support
There are two storyboards available to track the work on a daily basis, and those
are listed below for reference;
1. Story Cardboard: This is a traditional way of collecting all the stories in a
board in the form of stick notes to track daily XP activities. As this manual
activity involves more effort and time, it is better to switch to an online form.
2. Online Storyboard: Online tool Storyboard can be used to store the
stories. Several teams can use it for different purposes.
Crystal Methodologies:
Crystal Methodology is based on three concepts;
1. Chartering: Various activities involved in this phase are creating a
development
team,
performing
a
preliminary
feasibility
analysis,
developing an initial plan and fine-tuning the development methodology
2. Cyclic delivery: The main development phase consists of two or more
delivery cycles, during which the
 Team updates and refines the release plan
 Implements a subset of the requirements through one or more program
test integrate iterations
 Integrated product is delivered to real users
 Review of the project plan and adopted development methodology
3. Wrap Up: The activities performed in this phase are deployment into the
user environment, post- deployment reviews and reflections are performed.
Dynamic Software Development Method (DSDM)
DSDM
is
a Rapid
Application
Development (RAD)
approach
to
software
development and provides an agile project delivery framework. The important
aspect of DSDM is that the users are required to be involved actively, and the
teams are given the power to make decisions.
26 | P a g e
Frequent delivery of product becomes the active focus with DSDM.
The techniques used in DSDM are;
1. Time Boxing
2. MoSCoW Rules
3. Prototyping
The DSDM project consists of 7 phases
1. Pre-project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
6. Implementation
7. Post-project
Feature Driven Development (FDD)
This method is focused around “designing & building” features. Unlike other
Agile methods in software engineering, FDD describes very specific and short
phases of work that has to be accomplished separately per feature. It includes
domain walkthrough, design inspection, promote to build, code inspection and
design.
FDD develops product keeping following things in the target
1. Domain object Modeling
2. Development by feature
3. Component/ Class Ownership
4. Feature Teams
5. Inspections
6. Configuration Management
7. Regular Builds
8. Visibility of progress and results
Lean Software Development
Lean software development method is based on the principle “Just in time
production”. It aims at increasing speed of software development and decreasing
cost.
27 | P a g e
Lean development can be summarized in seven steps.
1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole
Kanban
Kanban originally emerged from Japanese word that means, a card containing
all the information needed to be done on the product at each stage along its path
to completion. This framework or method is quite adopted in software testing
method especially in Agile concepts.
Scrum Vs Kanban
S/N
Scrum
Kanban
1
In scrum technique, test must be
broken down so that they can be
completed within one sprint
No particular item size is prescribed
2
Prescribes a prioritized product
backlog
Prioritization is optional
3
Scrum team commits to a
particular amount of work for the
iteration
Commitment is optional
4
Burn down chart is prescribed
No particular item size is prescribed
5
Between each sprint, a scrum
board is reset
A Kanban board is persistent. It
limits the number of items in
workflow state
6
It cannot add items to ongoing
iteration
It can add items whenever capacity
is available
7
WIP limited indirectly
WIP limited directly
8
Time boxed iterations prescribed
Timeboxed iterations optional
28 | P a g e
What is Agile Testing?
Agile Testing is a testing practice that follows the rules and principles of agile
software development. Unlike the Waterfall method, Agile Testing can begin at
the start of the project with continuous integration between development and
testing. Agile Testing methodology is not sequential (in the sense it’s executed
only after coding phase) but continuous.
Agile Testing Life Cycle: is completed in five different phases, as we can see
in the following image;
Here are the Agile process testing steps:
Phase1: Impact Assessment: In this initial phase, we gather inputs from
stakeholders and users. This phase is also called the feedback phase, as it
assists the test engineers in setting the objectives for the next life cycle.
Phase 2: Agile Testing Planning: It is the second phase of the Agile testing life
cycle, where all stakeholders come together to plan the schedule of the testing
process and deliverables.
Phase 3: Release Readiness: At this stage, we review the features that have been
developed/ Implemented are ready to go live or not. In this stage, it is also
decided which one needs to go back to the previous development phase.
Phase 4: Daily Scrums: This stage includes every standup morning meeting to
catch up on the status of testing and set the goal for the entire day.
Phase 5: Test Agility Review: The last phase of the Agile life cycle is the Agility
Review Meeting. It involves weekly meetings with stakeholders to regularly
evaluate and assess progress against goals.
29 | P a g e
Agile Test Plan
Agile test plan includes types of testing done in that iteration like test data
requirements, infrastructure, test environments, and test results. Unlike the
waterfall model, in an agile model, a test plan is written and updated for every
release.
Typical test plans in agile includes:

Testing Scope

New functionalities which are being tested

Level or Types of testing based on the features complexity

Load and Performance Testing

Infrastructure Consideration

Mitigation or Risks Plan

Resourcing

Deliverables and Milestones
Agile Testing Strategies
Agile testing life cycle spans through four stages
Iteration 0
During the first stage or iteration 0, you perform initial setup tasks. It includes
identifying people for testing, installing testing tools, scheduling resources
(usability testing lab), etc.
30 | P a g e
The following steps are set to achieve in Iteration 0

Establishing a business case for the project

Establish the boundary conditions and the project scope

Outline the key requirements and use cases that will drive design trade-offs

Outline one or more candidate architectures

Identifying the risk

Cost estimation and prepare a preliminary project
Construction Iterations
The second phase of agile testing methodology is Construction Iterations, the
majority of the testing occurs during this phase. This phase is observed as a set
of iterations to build an increment of the solution. In order to do that, within
each iteration, the team implements a hybrid of practices from XP, Scrum, Agile
modeling, and agile data and so on.
In construction iteration, the agile team follows the prioritized requirement
practice: With each iteration, they take the most essential requirements
remaining from the work item stack and implement them.
Construction
iteration
is
classified
into
two,
confirmatory
testing
and
investigative testing. Confirmatory testing concentrates on verifying that the
system fulfills the intent of the stakeholders as described to the team to date,
and is performed by the team. While the investigative testing detects the problem
that confirmatory team has skipped or ignored. In Investigative testing, tester
determines the potential problems in the form of defect stories. Investigative
testing deals with common issues like integration testing, load/stress testing,
and
security
testing.
aspects developer
Again
for,
testing and agile
confirmatory
acceptance
testing
testing.
there
Both
of
are
two
them are
automated to enable continuous regression testing throughout the lifecycle.
Confirmatory testing is the agile equivalent of testing to the specification.
Agile acceptance testing is a combination of traditional functional testing and
traditional acceptance testing as the development team, and stakeholders are
doing it together. While developer testing is a mix of traditional unit testing and
traditional service integration testing. Developer testing verifies both the
application code and the database schema.
31 | P a g e
Release End Game Or Transition Phase
The goal of “Release, End Game” is to deploy your system successfully into
production. The activities include in this phase are training of end users,
support people and operational people. Also, it includes marketing of the
product release, back-up & restoration, finalization of system and user
documentation.
The final agile methodology testing stage includes full system testing and
acceptance testing. In accordance to finish your final testing stage without any
obstacles, you should have to test the product more rigorously while it is in
construction iterations. During the end game, testers will be working on its
defect stories.
Production
After the release stage, the product will move to the production stage.
The Agile Testing Quadrants
The agile testing quadrants separate the whole process in four Quadrants and
help to understand how agile testing is performed.
32 | P a g e
Agile Quadrant I
The internal code quality is the main focus in this quadrant, and it consists of
test cases which are technology driven and are implemented to support the
team, it includes

Unit Tests

Component Tests
Agile Quadrant II
It contains test cases that are business driven and are implemented to support
the team. This Quadrant focuses on the requirements.
The kind of test performed in this phase is

Testing of examples of possible scenarios and workflows

Testing of User experience such as prototypes

Pair testing
Agile Quadrant III
This quadrant provides feedback to quadrants one and two. The test cases can
be used as the basis to perform automation testing. In this quadrant, many
rounds of iteration reviews are carried out which builds confidence in the
product. The kind of testing done in this quadrant is

Usability Testing

Exploratory Testing

Pair testing with customers

Collaborative testing

User acceptance testing
Agile Quadrant IV
This quadrant concentrates on the non-functional requirements such as
performance, security, stability, etc. With the help of this quadrant, the
application is made to deliver the non-functional qualities and expected value.

Non-functional tests such as stress and performance testing

Security testing with respect to authentication and hacking

Infrastructure testing

Data migration testing

Scalability testing

Load testing
33 | P a g e
QA challenges with agile software development

Chances of error are more in agile, as documentation is given less priority,
eventually puts more pressure on QA team

New features are introduced quickly, which reduces the available time for
test teams to identify whether the latest features are according to the
requirement and does it truly address the business suits

Testers are often required to play a semi-developer roled

Test execution cycles are highly compressed

Very less time to prepare test plan

For regression testing, they will have minimal timing

Change in their role from being a gate-keeper of quality to being a partner
in Quality

Requirement changes and updates are inherent in an agile method,
becoming the biggest challenge for QA
Risk of Automation in Agile Process

Automated UI provides a high level of confidence, but they are slow to
execute, fragile to maintain and expensive to build. Automation may not
significantly improve test productivity unless the testers know how to test

Unreliable tests are a major concern in automated testing. Fixing failing
tests and resolving issues related to brittle tests should be a top priority in
order to avoid false positives

If the automated test are initiated manually rather than through CI
(Continuous Integration) then there is a risk that they are not regularly
running and therefore may cause failing of tests

Automated tests are not a replacement for an exploratory manual testing.
To obtain the expected quality of the product, a mixture of testing types
and levels is required

Many commercially available automation tools provide simple features like
automating the capture and replay of manual test cases. Such tool
encourages testing through the UI and leads to an inherently brittle and
difficult to maintain tests. Also, storing test cases outside the version
control system creates unnecessary complexity
34 | P a g e

In order to save time, much times the automation test plan is poorly
planned or unplanned which results in the test fail

A test set up and tear down procedures are usually missed out during test
automation, while Performing manual testing, a test set up and tear down
procedures sounds seamless

Productivity metrics such as a number of test cases created or executed
per day can be terribly misleading, and could lead to making a large
investment in running useless tests

Members of the agile automation team must be effective consultants:
approachable, cooperative, and resourceful, or this system will quickly fail

Automation may propose and deliver testing solutions that require too
much ongoing maintenance relative to the value provided

Automated testing may lack the expertise to conceive and deliver effective
solutions

Automated testing may be so successful that they run out of important
problems to solve, and thus turn to unimportant problems.
Conclusion
Agile methodology in software testing involves testing as early as possible in
the software development lifecycle. It demands high customer involvement and
testing code as soon as it becomes available. The code should be stable enough
to take it to system testing. Extensive regression testing can be done to make
sure that the bugs are fixed and tested. Mainly, Communication between the
teams makes agile model testing success.
Scrum Testing Methodology
Scrum in Software Testing
Scrum Testing is a testing done in scrum methodology to verify the software
application
requirements
are
met.
It
involves
checking
non-functional
parameters like security, usability, performance etc. There is no active role of
tester in the process so it is usually performed by developers with Unit Test.
Sometimes dedicated test teams are needed depending on nature & complexity
of project.
35 | P a g e
1. Roles in Scrum
There are three chief roles in Scrum Testing
1. Product Owner
2. Scrum Master and
3. The Development Team.
Product Owner
Scrum Master
The Team
He/She defines features of
the product.
He/She manages the
team and look after the
team’s productivity
The team is usually
about 5-9 members
Product Owner decides the
release date and
corresponding features
He/She maintains the
block list and removes
barriers in the
development
It includes developers,
designer and sometimes
testers, etc.
They prioritize the features
according to the market
value and profitability of
the product
He/She coordinates
with all roles and
functions
The team organizes and
schedule their work on
their own
He/She is responsible for
the profitability of the
product
He/She shields team
from external
interferences
Has right to do
everything within the
boundaries of the
project to meet the
sprint goal
He/She can accept or
reject work item result
Invites to the daily
scrum, sprint review
and planning meetings
Actively participate in
daily ceremonies
36 | P a g e
2. Scrum Artifacts
A scrum process includes;

User stories: They are a short explanation of functionalities of the system
under test. Example for Insurance Provider is – “Premium can be paid using
the online system.”

Product Backlog: It is a collection of user stories captured for a scrum
product. The product owner prepares and maintains the product backlog. It
is prioritized by the product owner, and anyone can add to it with approval
from the product owner.

Release Backlog: A release is a time frame in which the number of iterations
is completed. The product owner co-ordinates with the scrum master to
decide which stories should be targeted for a release. Stories in the release
backlog are targeted to be completed in a release.

Sprints: It is a set period of time to complete the user stories, decided by the
product owner and developer team, usually 2-4 weeks of time.

Sprint Backlog: It’s a set of user stories to be completed in a sprint. During
sprint backlog, work is never assigned, and the team signs up for work on
their own. It is owned and managed by the team while the estimated work
remaining is updated daily. It is the list of task that has to be performed in
Sprint

Block List: It is a list of blocks and unmade decisions owned by scrum
master and updated daily
37 | P a g e

Burndown chart: Burn-down chart represents overall progress of the work in
progress and work completed throughout the process. It represents in a
graph format the stories and features not completed
3. Ceremonies (Processes) in Scrum

Sprint Planning: A sprint begins with the team importing stories from the
release backlog into the sprint backlog; it is hosted by scrum master. The
Testers estimate effort to test the various stories in the Sprint Backlog.

Daily Scrum: It is hosted by scrum master, it last about 15 minutes.
During Daily Scrum, the members will discuss the work completed the
previous day, the planned work for the next day and issues faced during a
sprint. During daily stand-up meeting team progress is tracked.

Sprint Review/ Retrospective: It is also hosted by scrum master, it last
about 2-4 hours and discuss what the team has accomplished in the last
sprint and what lessons were learned.
Role of Tester in Scrum
There is no active role of Tester in the Scrum Process. Usually, testing is carried
out by a developer with Unit Test. While product owner is also frequently
involved in the testing process during each sprint. Some Scrum projects do have
dedicated test teams depending on the nature & complexity of the project.
Following note will answer-Testing Activities in Scrum
Testers do following activities during the various stages of Scrum-Sprint
Planning

In sprint planning, a tester should pick a user-story from the product
backlog that should be tested.

As a tester, he/she should decide how many hours (Effort Estimation) it
should take to finish testing for each of selected user stories.

As a tester, he/she must know what sprint goals are.

As a tester, contribute to the prioritizing process
38 | P a g e
Sprint
1.
Support developers in unit testing
2.
Test user-story when completed. Test execution is performed in a lab
where both tester and developer work hand in hand. Defect are logged
in Defect Management tool which are tracked on a daily basis. Defects can
be conferred and analyzed during the scrum meeting. Defects are retested
as soon as it is resolved and deployed for testing
3.
As a tester, he/she attends all daily standup meeting to speak up
4.
As a tester, he/ she can bring any backlog item that cannot be completed
in the current sprint and put to the next sprint
5.
Tester is responsible for developing automation scripts. He schedules
automation testing with Continuous Integration (CI) system. Automation
receives the importance due to short delivery timelines. Test Automation
can be accomplished by utilizing various open source or paid tools
available in the market. This proves effective in ensuring that everything
that needs to be tested was covered. Sufficient Test coverage can be
achieved with a close communication with the team.
6.
Review CI automation results and send Reports to the stakeholders
7.
Executing non-functional testing for approved user stories
8.
Coordinate with customer and product owner to define acceptance criteria
for Acceptance Tests
9.
At the end of the sprint, the tester also does acceptance testing(UAT) in
some case and confirms testing completeness for the current sprint
Sprint Retrospective
1.
As a tester, he will figure out what went wrong and what went right in the
current sprint
2.
As a tester, he identifies lesson learned and best practices
Test Reporting
Scrum
Test
metrics
reporting
provides
transparency
and
visibility
to
stakeholders about the project. The metrics that are reported allow a team to
analyze their progress and plan their future strategy to improve the product.
39 | P a g e
There are two metrics that are frequently used to report;
Burn down chart: Each day, Scrum Master records the estimated remaining
work for the sprint. This is nothing but the Burn Down Chart. It is updated
daily. A burn down chart gives a quick overview of the project progress, this
chart contains information like the total amount of work in the project that must
be completed, amount of work completed during each sprint and so on.
Velocity history graph: The velocity history graph predicts the velocity of the
team reached in each sprint. It is a bar graph and represents how teams output
has changed over time. The additional metrics that may be useful are schedule
burn, budget burn, theme percent complete, stories completed – stories
remaining and so on.
Agile Test Automation Framework
Agile Automation Testing in software development is an approach of using test
automation in agile methodologies. The purpose of agile automation testing is to
make the software development process more effective and efficient while
maintaining the quality and time as well as resource consumption. Thus, the
implementation of such a process requires a lot of coordination and
collaboration between teams.
Automation in Waterfall vs. Automation in Agile
In the realm of the traditional process of software testing life cycle, Automation
Testing is normally feasible when the application is stable, steady and the
requirement is involving with a real considerable amount of time and in most
cases involving a set of very skillful automation expert resources as well as a
40 | P a g e
considerable amount of set-up costs. The basic purpose of Automation Testing is
to reduce costs over a long time and to ensure no new defects have been
introduced as a result of existing test cases. Automation testing by the very
nature of the technology is not exploratory in nature since the main role of
Automation Testing is saving time and reducing costs. Automation Testing is not
meant to come up with new and innovative defects. Automation Testing aims at
mostly confirmation of the already existing.
How to automate in Agile Methodology
Now by its very definition agile methodology talks about doing away with
laborious and tedious documentation so that new and innovative ideas could be
implemented and people could interact freely with each other so that more of
these innovative and explorative ideas could be implemented.
Thus we could see a contradiction between the basic fundamental philosophies
of agile methodologies and Automation Testing.
Fundamental Points for Agile Test Automation
So we need to consider certain fundamental points here when it comes to
evaluating the use of agile methodologies with respect to the Automation Testing
methods and techniques. Thus we need to consider some fundamental points
like time taken for design and coding, validation of the designed scripts with the
existing test data and the adoption of the same for testing (whether the tests are
of functional or regression purposes) So the real fact of all these events is that in
order to perform all these facts, we need to ensure that a considerable amount of
time is required for these tasks and in an agile environment where an average
sprint takes an average 1-2 weeks to complete and thus it is obviously too
difficult to contemplate affording so much time for automating scripts in such a
way. Another significant factor remains here that the type of changes in
41 | P a g e
requirements which come into picture when the agile methodology is at play.
The agile methodology by its own very definition is a sort of technique which is
very helpful for responding to quick customer induced change requirements and
which thus lends itself well to frequent changes during the overall development
of the application. In contrast, automation testing is very useful when it comes
to the more stable and less frequent types of requirements. Thus by definition
automation testing does not lend itself well to various types of frequent changes
in requirements which comes alongside the adoption of any agile methodologies.
Agile Automation Tools
The selection of relevant automation tool is also a potentially very important
factor when it comes to the adoption of automation testing within the scope of
an overall agile methodology. Licensed automation tools, for example, impose
strict security access criterion to different types and levels of users when it
comes accessing various important resources belonging to that particular testing
automation framework.
In contrast agile methodology emphasizes upon mostly open collaboration and
open-ended interaction between team members and thus restrictive policies
which directly affects how the users would have a negative impact on the overall
cohesion within the team and thus may be leading into results which are neither
very helpful nor very conducive to the overall success of the project.
Therefore the primary importance of the process should be to ensure that in
order to obtain the quality delivery of automation test scripts within a stipulated
time as afforded by agile methodology; we need to choose our prospective test
cases which would be automated in a more nuanced way such that these
automated test scripts lend themselves well for future re-use as well as ensuring
that they can be prepared within the proper duration of the allotted time (as
required during the agile methodology process).
After consideration of all the above factors we thus can realize that even while
adopting agile methodologies, we need to bring into picture the types of tests like
for example regression tests (since even during agile testing there is a
considerable amount of testing work which is required to put into the job of agile
methodologies for ensuring better quality of the overall product).
42 | P a g e