AGILE SOFTWARE AND DEVELOPMENT TESTING

UNIT – 1
OVERVIEW OF SOFTWARE ENGINEERING:
• Software is more than just a program code. A program is an executable code, which
serves some computational purpose. Software is considered to be collection of
executable programming code, associated libraries and documentations. Software,
when made for a specific requirement is called software product.
• Engineering on the other hand, is all about developing products, using well-defined,
scientific principles and methods.
• Software engineering is an engineering branch associated with development of
software product using well-defined scientific principles, methods and procedures.
The outcome of software engineering is an efficient and reliable software product.
SOFTWARE PROCESS AND ITS MODEL:

A software process model is an abstraction of the software development process. The models
specify the stages and order of a process. So, think of this as a representation of the order of
activities of the process and the sequence in which they are performed.

A model will define the following:

 The tasks to be performed

 The input and output of each task
 The pre and post conditions for each task
 The flow and sequence of each task

There are many kinds of process models for meeting different requirements. We refer to these
as SDLC models (Software Development Life Cycle models). The most popular and
important SDLC models are as follows:

 Waterfall model
 V model
 Incremental model
 RAD model
 Agile model
 Iterative model
 Prototype model
 Spiral model

Types of software process models

As we mentioned before, there are multiple kinds of software process models that each meet
different requirements. Below, we will look at the top seven types of software process models
that you should know
Waterfall Model

The waterfall model is a sequential, plan driven-process where you must plan and schedule
all your activities before starting the project. Each activity in the waterfall model is
represented as a separate phase arranged in linear order.

It has the following phases:

 Requirements
 Design
 Implementation
 Testing
 Deployment
 Maintenance

Each of these phases produces one or more documents that need to be approved before the
next phase begins. However, in practice, these phases are very likely to overlap and may feed
information to one another.

The software process isn’t linear, so the documents produced may need to be modified to
reflect changes.

The waterfall model is easy to understand and follow. It doesn’t require a lot of customer
involvement after the specification is done. Since it’s inflexible, it can’t adapt to changes.
There is no way to see or try the software until the last phase.

The waterfall model has a rigid structure, so it should be used in cases where the
requirements are understood completely and unlikely to radically change.
V Model

The V model (Verification and Validation model) is an extension of the waterfall model. All
the requirements are gathered at the start and cannot be changed. You have a corresponding
testing activity for each stage. For every phase in the development cycle, there is
an associated testing phase.

The corresponding testing phase of the development phase is planned in parallel, as you can
see above.

The V model is highly disciplined, easy to understand, and makes project management easier.
But it isn’t good for complex projects or projects that have unclear or changing requirements.
This makes the V model a good choice for software where downtimes and failures are
unacceptable.

Incremental Model

The incremental model divides the system’s functionality into small increments that are
delivered one after the other in quick succession. The most important functionality is
implemented in the initial increments.

The subsequent increments expand on the previous ones until everything has been updated
and implemented.

Incremental development is based on developing an initial implementation, exposing it to

user feedback, and evolving it through new versions. The process’ activities are interwoven
by feedback.

Each iteration passes through the requirements, design, coding, and testing stages.

The incremental model lets stakeholders and developers see results with the first increment. If
the stakeholders don’t like anything, everyone finds out a lot sooner. It is efficient as the
developers only focus on what is important and bugs are fixed as they arise, but you need
a clear and complete definition of the whole system before you start.

The incremental model is great for projects that have loosely-coupled parts and projects with
complete and clear requirements.

Iterative Model

The iterative development model develops a system through building small portions of all
the features. This helps to meet initial scope quickly and release it for feedback.

In the iterative model, you start off by implementing a small set of the software requirements.
These are then enhanced iteratively in the evolving versions until the system is completed.
This process model starts with part of the software, which is then implemented and reviewed
to identify further requirements.

Like the incremental model, the iterative model allows you to see the results at the early
stages of development. This makes it easy to identify and fix any functional or design flaws.
It also makes it easier to manage risk and change requirements.

The deadline and budget may change throughout the development process, especially for
large complex projects. The iterative model is a good choice for large software that can
be easily broken down into modules.
RAD Model

The Rapid Application Development (RAD model) is based on iterative development and
prototyping with little planning involved. You develop functional modules in parallel for
faster product delivery. It involves the following phases:

1. Business modeling
2. Data modeling
3. Process modeling
4. Application generation
5. Testing and turnover

The RAD concept focuses on gathering requirements using focus groups and workshops,
reusing software components, and informal communication.

The RAD model accommodates changing requirements, reduces development time, and
increases the reusability of components. But it can be complex to manage. Therefore, the
RAD model is great for systems that need to be produced in a short time and have known
requirements.
Spiral Model

The spiral model is a risk driven iterative software process model. The spiral model delivers
projects in loops. Unlike other process models, its steps aren’t activities but phases for
addressing whatever problem has the greatest risk of causing a failure.

It was designed to include the best features from the waterfall and introduces risk-assessment.

You have the following phases for each cycle:

1. Address the highest-risk problem and determine the objective and alternate solutions
2. Evaluate the alternatives and identify the risks involved and possible solutions
3. Develop a solution and verify if it’s acceptable
4. Plan for the next cycle
You develop the concept in the first few cycles, and then it evolves into an implementation.
Though this model is great for managing uncertainty, it can be difficult to have stable
documentation. The spiral model can be used for projects with unclear needs or projects still
in research and development.

1. Objectives determination and identify alternative solutions: Requirements are

gathered from the customers and the objectives are identified, elaborated, and analyzed
at the start of every phase. Then alternative solutions possible for the phase are
proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant, all the possible solutions are
evaluated to select the best possible solution. Then the risks associated with that
solution are identified and the risks are resolved using the best possible strategy. At the
end of this quadrant, the Prototype is built for the best possible solution.
3. Develop next version of the Product: During the third quadrant, the identified features
are developed and verified through testing. At the end of the third quadrant, the next
version of the software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate
the so far developed version of the software. In the end, planning for the next phase is
started.

Advantages of Spiral Model:

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

Disadvantages of Spiral Model:

Below are some main disadvantages of the spiral model.
1. Complex: The Spiral Model is much more complex than other SDLC models.
2. Expensive: Spiral Model is not suitable for small projects as it is expensive.
3. Too much dependability on Risk Analysis: The successful completion of the project
is very much dependent on Risk Analysis. Without very highly experienced experts, it
is going to be a failure to develop a project using this model.

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

Agile model

The agile process model encourages continuous iterations of development and testing. Each
incremental part is developed over an iteration, and each iteration is designed to be small and
manageable so it can be completed within a few weeks.

Each iteration focuses on implementing a small set of features completely. It involves

customers in the development process and minimizes documentation by using informal
communication.

Agile development considers the following:

 Requirements are assumed to change

 The system evolves over a series of short iterations
 Customers are involved during each iteration
 Documentation is done only when needed

Though agile provides a very realistic approach to software development, it isn’t great for
complex projects. It can also present challenges during transfers as there is very little
documentation. Agile is great for projects with changing requirements.

Some commonly used agile methodologies include:

 Scrum: One of the most popular agile models, Scrum consists of iterations called
sprints. Each sprint is between 2 to 4 weeks long and is preceded by planning. You
cannot make changes after the sprint activities have been defined.
  Extreme Programming (XP): With Extreme Programming, an iteration can last
between 1 to 2 weeks. XP uses pair programming, continuous integration, test-driven
development and test automation, small releases, and simple software design.
 Kanban: Kanban focuses on visualizations, and if any iterations are used they are
kept very short. You use the Kanban Board that has a clear representation of all
project activities and their numbers, responsible people, and progress.

SOFTWARE PRODUCT:
a software product is software that has been developed and maintained for the benefit of a
user base and often to satisfy a need in the market.
Most of us interact with different types of software products each day. Examples of a
software product can include products that help its users hold online video conferences and
meetings (think Zoom) or a platform that helps businesses manage employee expenses.
COMPONENTS:
Product design: Product design is the visual aesthetic and interactive interface in which
users can engage with the product.
Functionality and features: Functionality is how users interact with the software product
when they use it.
Content: Content refers to the data and information present in a software product.
SOFTWARE PROJECT PLANNING:
• A Software Project is the complete methodology of programming advancement from
requirement gathering to testing and support, completed by the execution procedures,
in a specified period to achieve intended software product.

PROJECT SCHEDULING AND TRACKING:

Project schedule simply means a mechanism that is used to communicate and know about
that tasks are needed and has to be done or performed and which organizational resources
will be given or allocated to these tasks and in what time duration or time frame work is
needed to be performed. Effective project scheduling leads to success of project, reduced
cost, and increased customer satisfaction. Scheduling in project management means to list out
activities, deliverables, and milestones within a project that are delivered. It contains more
notes than your average weekly planner notes. The most common and important form of
project schedule is Gantt chart.
Process :
The manager needs to estimate time and resources of project while scheduling project. All
activities in project must be arranged in a coherent sequence that means activities should be
arranged in a logical and well-organized manner for easy to understand. Initial estimates of
project can be made optimistically which means estimates can be made when all favorable
things will happen and no threats or problems take place.

Advantages of Project Scheduling :

There are several advantages provided by project schedule in our project management:
It simply ensures that everyone remains on same page as far as tasks get completed,
dependencies, and deadlines.
It helps in identifying issues early and concerns such as lack or unavailability of resources.
It also helps to identify relationships and to monitor process.
It provides effective budget management and risk mitigation

Tracking Project Schedules

Periodic project status meetings with each team member reporting progress and problems
Evaluation of results of all work product reviews
Comparing actual milestone completion dates to scheduled dates
Comparing actual project task start-dates to scheduled start-dates
Informal meeting with practitioners to have them asses subjectively progress to date and
future problems
Use earned value analysis to assess progress quantitatively
Tracking Increment Progress for Object Oriented Projects
 Technical milestone: OO analysis complete
 All hierarchy classes defined and reviewed
 Class attributes and operations are defined and reviewed
 Class relationships defined and reviewed
 Behavioral model defined and reviewed
 Reusable classed identified
Technical milestone: OO design complete
 Subsystems defined and reviewed
 Classes allocated to subsystems and reviewed
 Task allocation has been established and reviewed
 Responsibilities and collaborations have been identified
 Attributes and operations have been designed and reviewed
 Communication model has been created and reviewed
Technical milestone: OO programming complete
 Each new design model class has been implemented
 Classes extracted from the reuse library have been implemented
 Prototype or increment has been built
Technical milestone: OO testing complete
 The correctness and completeness of the OOA and OOD models has been reviewed
 Class-responsibility-collaboration network has been developed and reviewed
 Test cases are designed and class-level tests have been conducted for each class
 Test cases are designed, cluster testing is completed, and classes have been integrated
 System level tests are complete

Project-task scheduling is a significant project planning activity. It comprises deciding which

functions would be taken up when.
To schedule the project plan, a software project manager wants to do the following:
1. Identify all the functions required to complete the project.
2. Break down large functions into small activities.
3. Determine the dependency among various activities.
4. Establish the most likely size for the time duration required to complete the activities.
5. Allocate resources to activities.
6. Plan the beginning and ending dates for different activities.
7. Determine the critical path. A critical way is the group of activities that decide the
duration of the project.
8. The first method in scheduling a software plan involves identifying all the functions
required to complete the project. A good judgment of the intricacies of the project and
the development process helps the supervisor to identify the critical role of the project
effectively. Next, the large functions are broken down into a valid set of small
activities which would be assigned to various engineers.

The work breakdown structure formalism supports the manager to breakdown the
function systematically after the project manager has broken down the purpose and
constructs the work breakdown structure; he has to find the dependency among the
activities. Dependency among the various activities determines the order in which the
various events would be carried out.

If an activity A necessary the results of another activity B, then activity A must be

scheduled after activity B. In general, the function dependencies describe a partial
ordering among functions, i.e., each service may precede a subset of other functions,
but some functions might not have any precedence ordering describe between them
(called concurrent function). The dependency among the activities is defined in the
pattern of an activity network.

9. Once the activity network representation has been processed out, resources are
allocated to every activity. Resource allocation is usually done using a Gantt chart.
After resource allocation is completed, a PERT chart representation is developed. The
PERT chart representation is useful for program monitoring and control. For task
 scheduling, the project plan needs to decompose the project functions into a set of
activities. The time frame when every activity is to be performed is to be determined.
The end of every action is called a milestone. The project manager tracks the function
of a project by audit the timely completion of the milestones. If he examines that the
milestones start getting delayed, then he has to handle the activities carefully so that
the complete deadline can still be met.

SOFTWARE METRICS:

Software metric is a measure of software characteristics which are measurable or countable.

Software metrics are valuable for many reasons, including measuring software performance,
planning work items, measuring productivity, and many other uses.

Within the software development process, many metrics are that are all connected. Software
metrics are similar to the four functions of management: Planning, Organization, Control, or
Improvement.

Classification of Software Metrics

Software metrics can be classified into two types as follows:

1. Product Metrics: These are the measures of various characteristics of the software
product. The two important software characteristics are:

1. Size and complexity of software.

2. Quality and reliability of software.

These metrics can be computed for different stages of SDLC.

2. Process Metrics: These are the measures of various characteristics of the software
development process. For example, the efficiency of fault detection.

They are used to measure the characteristics of methods, techniques, and tools that are used
for developing software.
Types of Metrics

Internal metrics: Internal metrics are the metrics used for measuring properties that are
viewed to be of greater importance to a software developer. For example, Lines of Code
(LOC) measure.

External metrics: External metrics are the metrics used for measuring properties that are
viewed to be of greater importance to the user, e.g., portability, reliability, functionality,
usability, etc.

Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource
metrics. For example, cost per FP where FP stands for Function Point Metric.

Project metrics: Project metrics are the metrics used by the project manager to check the
project's progress. Data from the past projects are used to collect various metrics, like time
and cost; these estimates are used as a base of new software. Note that as the project
proceeds, the project manager will check its progress from time-to-time and will compare the
effort, cost, and time with the original effort, cost and time. Also understand that these
metrics are used to decrease the development costs, time efforts and risks. The project quality
can also be improved. As quality improves, the number of errors and time, as well as cost
required, is also reduced.
Advantage of Software Metrics

 Comparative study of various design methodology of software systems.

 For analysis, comparison, and critical study of different programming language

concerning their characteristics

 In comparing and evaluating the capabilities and productivity of people involved in

software development.
 In the preparation of software quality specifications.
 In the verification of compliance of software systems requirements and specifications.
 In making inference about the effort to be put in the design and development of the
software systems.
 In getting an idea about the complexity of the code.

Disadvantage of Software Metrics

 The application of software metrics is not always easy, and in some cases, it is
difficult and costly.

 The verification and justification of software metrics are based on historical/empirical

data whose validity is difficult to verify.

 These are useful for managing software products but not for evaluating the
performance of the technical staff.

 The definition and derivation of Software metrics are usually based on assuming
which are not standardized and may depend upon tools available and working
environment.

 Most of the predictive models rely on estimates of certain variables which are often
not known precisely.

SYSTEM ENGINEERING:
• Systems engineering, technique of using knowledge from various branches of
engineering and science to introduce technological innovations into the planning and
development stages of a system.
• Systems engineering is not so much a branch of engineering as it is a technique for
applying knowledge from other branches of engineering and disciplines of science in
effective combination to solve a multifaceted engineering problem. It is related
to operations research but differs from it in that it is more a planning and design
function, frequently involving technical innovation.
BUSINESS PROCESS ENGINEERING:
• Business process re-engineering is the process of redesigning a business process to
enhance product output, improve quality, improve speed or reduce costs. Business
process re-engineering involves eliminating unnecessary and inefficient aspects of the
workflow or aspects that don't add any value.
• Another aspect of the re-engineering process is combining similar tasks to reduce the
number of steps employees must take to complete a procedure. Switching from a
paper-based data system to an electronic storage option is an example of business
process improvement, as this eliminates an inefficiency and makes the work easier for
employees.

PRODUCT ENGINEERING:
• Product Engineering is the process of innovating, designing, developing, testing and
deploying a software product. The advent of Web 2.0 technologies and utility based
software delivery through Software as a Service (SaaS) has led to the process of
gradual transformation of client enabling engineering services from traditional
software engineering to product engineering. Product engineering takes care of the
entire product life cycle from the innovation phase, starting from the idea being
conceived to the deployment and user acceptance testing phase.
 • Let us now understand, what are the various phases of product engineering? The
various phases of product engineering are:
• Product Ideation
• Product Architecture
• Product Design
• Product Testing
• Product Migration and Porting
• Technical Support
• Sustaining Engineering
• Professional Services

REQUIREMENT ENGINEERING:
• Requirements engineering (RE) refers to the process of defining, documenting, and
maintaining requirements in the engineering design process.
• Requirement engineering provides the appropriate mechanism to understand what the
customer desires, analyzing the need, and assessing feasibility, negotiating a
reasonable solution, specifying the solution clearly, validating the specifications and
managing the requirements as they are transformed into a working system.
• Thus, requirement engineering is the disciplined application of proven principles,
methods, tools, and notation to describe a proposed system's intended behavior and its
associated constraints.
SOFTWARE ANALYSIS AND PRINCIPLES:
Software requirements engineering is a process of discovery, refinement, modeling, and
specification. The system requirements and role allocated to software—initially established
by the system engineer—are refined in detail. Models of the required data, information and
control flow, and operational behavior are created. Alternative solutions are analyzed and a
complete analysis model is created. Donald Reifer describes the software requirement
engineering process in the following way:

Requirements engineering is the systematic use of proven principles, techniques, languages,

and tools for the cost effective analysis, documentation, and on-going evolution of user needs
and the specification of the external behavior of a system to satisfy those user needs. Notice
that like all engineering disciplines, requirements engineering is not conducted in a sporadic,
random or otherwise haphazard fashion, but instead is the systematic use of proven
approaches.

Both the software engineer and customer take an active role in software requirements
engineering—a set of activities that is often referred to as analysis. The customer attempts to
reformulate a sometimes nebulous system-level description of data, function, and behavior
into concrete detail. The developer acts as interrogator, consultant, problem solver, and
negotiator.
SOFTWARE ARCHITECTURE:

The architecture of a system describes its major components, their relationships (structures),
and how they interact with each other. Software architecture and design includes several
contributory factors such as Business strategy, quality attributes, human dynamics, design,
and IT environment.

We can segregate Software Architecture and Design into two distinct phases: Software
Architecture and Software Design. In Architecture, nonfunctional decisions are cast and
separated by the functional requirements. In Design, functional requirements are
accomplished.
Architecture serves as a blueprint for a system. It provides an abstraction to manage the
system complexity and establish a communication and coordination mechanism among
components.
 It defines a structured solution to meet all the technical and operational
requirements, while optimizing the common quality attributes like performance
and security.
 Further, it involves a set of significant decisions about the organization related
to software development and each of these decisions can have a considerable
impact on quality, maintainability, performance, and the overall success of the
final product. These decisions comprise of –

o Selection of structural elements and their interfaces by which the

system is composed.
o Behavior as specified in collaborations among those elements.
o Composition of these structural and behavioral elements into
large subsystem.
o Architectural decisions align with business objectives.
o Architectural styles guide the organization.
Goals of Architecture

The primary goal of the architecture is to identify requirements that affect the structure of the
application. A well-laid architecture reduces the business risks associated with building a
technical solution and builds a bridge between business and technical requirements.
Some of the other goals are as follows −
 Expose the structure of the system, but hide its implementation details.
 Realize all the use-cases and scenarios.
 Try to address the requirements of various stakeholders.
 Handle both functional and quality requirements.
 Reduce the goal of ownership and improve the organization’s market position.
 Improve quality and functionality offered by the system.
 Improve external confidence in either the organization or system.

Limitations

Software architecture is still an emerging discipline within software engineering. It has the
following limitations −
 Lack of tools and standardized ways to represent architecture.
 Lack of analysis methods to predict whether architecture will result in an
implementation that meets the requirements.
 Lack of awareness of the importance of architectural design to software
development.
 Lack of understanding of the role of software architect and poor
communication among stakeholders.
 Lack of understanding of the design process, design experience and evaluation
of design.

DESIGN CONCEPTS AND PRINCIPLES:

Software design provides a design plan that describes the elements of a system, how they fit,
and work together to fulfil the requirement of the system. The objectives of having a design
plan are as follows −
 To negotiate system requirements, and to set expectations with customers,
marketing, and management personnel.
 Act as a blueprint during the development process.
 Guide the implementation tasks, including detailed design, coding, integration,
and testing.
It comes before the detailed design, coding, integration, and testing and after the domain
analysis, requirements analysis, and risk analysis.
USER INTERFACE DESIGN:
• The visual part of a computer application or operating system through which a client
interacts with a computer or software. It determines how commands are given to the
computer or the program and how data is displayed on the screen.
Types of User Interface
• There are two main types of User Interface:
• Text-Based User Interface or Command Line Interface
• Graphical User Interface (GUI)
• Text-Based User Interface: This method relies primarily on the keyboard. A typical
example of this is UNIX.
Advantages
• Many and easier to customizations options.
• Typically capable of more important tasks.
Disadvantages
• Relies heavily on recall rather than recognition.
• Navigation is often more difficult.

UI Design Principles
Structure: Design should organize the user interface purposefully, in the meaningful and
usual based on precise, consistent models that are apparent and recognizable to users, putting
related things together and separating unrelated things, differentiating dissimilar things and
making similar things resemble one another. The structure principle is concerned with overall
user interface architecture.

Simplicity: The design should make the simple, common task easy, communicating clearly
and directly in the user's language, and providing good shortcuts that are meaningfully related
to longer procedures.

Visibility: The design should make all required options and materials for a given function
visible without distracting the user with extraneous or redundant data.

Feedback: The design should keep users informed of actions or interpretation, changes of
state or condition, and bugs or exceptions that are relevant and of interest to the user through
clear, concise, and unambiguous language familiar to users.

Tolerance: The design should be flexible and tolerant, decreasing the cost of errors and
misuse by allowing undoing and redoing while also preventing bugs wherever possible by
tolerating varied inputs and sequences and by interpreting all reasonable actions.
 UNIT – 2
SOFTWARE TESTING:
Introduction to Software Testing
• Software Testing is a method to check whether the actual software product matches
expected requirements and to ensure that software product is Defect free. It involves
execution of software/system components using manual or automated tools to
evaluate one or more properties of interest. The purpose of software testing is to
identify errors, gaps or missing requirements in contrast to actual requirements.
• Some prefer saying Software testing definition as a White Box and Black Box
Testing. In simple terms, Software Testing means the Verification of Application
Under Test (AUT). This Software Testing course introduces testing software to the
audience and justifies the importance of software testing.
• Software testing is a procedure of implementing software or the application to identify
the defects or bugs. For testing an application or software, we need to follow some
principles to make our product defects free, and that also helps the test engineers to
test the software with their effort and time. Here, in this section, we are going to learn
about the seven essential principles of software testing.
•
TESTING PRINCIPLES
7 Principles of Software Testing
1. Testing shows presence of defects
2. Exhaustive testing is not possible
3. Early testing
4. Defect clustering
5. Pesticide paradox
6. Testing is context dependent
7. Absence of errors fallacy
1) Exhaustive testing is not possible
• Yes! Exhaustive testing is not possible. Instead, we need the optimal amount of
testing based on the risk assessment of the application.
2) Defect Clustering
• Defect Clustering which states that a small number of modules contain most of the
defects detected. This is the application of the Pareto Principle to software testing:
approximately 80% of the problems are found in 20% of the modules.
• By experience, you can identify such risky modules. But this approach has its own
problems
 • If the same tests are repeated over and over again, eventually the same test cases will
no longer find new bugs.
3) Pesticide Paradox
• Repetitive use of the same pesticide mix to eradicate insects during farming will over
time lead to the insects developing resistance to the pesticide Thereby ineffective of
pesticides on insects. The same applies to software testing. If the same set of
repetitive tests are conducted, the method will be useless for discovering new defects.
• To overcome this, the test cases need to be regularly reviewed & revised, adding new
& different test cases to help find more defects.
4) Testing shows a presence of defects
• Hence, testing principle states that – Testing talks about the presence of defects and
don’t talk about the absence of defects. i.e. Software Testing reduces the probability
of undiscovered defects remaining in the software but even if no defects are found, it
is not a proof of correctness.
• But what if, you work extra hard, taking all precautions & make your software
product 99% bug-free. And the software does not meet the needs & requirements of
the clients.
• This leads us to our next principle, which states that- Absence of Error
5) Absence of Error – fallacy
• It is possible that software which is 99% bug-free is still unusable. This can be the
case if the system is tested thoroughly for the wrong requirement. Software testing is
not mere finding defects, but also to check that software addresses the business needs.
The absence of Error is a Fallacy i.e. Finding and fixing defects does not help if the
system build is unusable and does not fulfill the user’s needs & requirements.
6) Early Testing
• Early Testing – Testing should start as early as possible in the Software Development
Life Cycle. So that any defects in the requirements or design phase are captured in
early stages. It is much cheaper to fix a Defect in the early stages of testing.
7) Testing is context dependent
• Testing is context dependent which basically means that the way you test an e-
commerce site will be different from the way you test a commercial off the shelf
application. All the developed software’s are not identical. You might use a different
approach, methodologies, techniques, and types of testing depending upon the
application type. For instance testing, any POS system at a retail store will be
different than testing an ATM machine.
NEEDS FOR TESTING:
1. To gain customer confidence
2. To check software adaptability
3. To identify errors
4. To avoid extra costs
5. To accelerate software development
6. To avoid risks
7. To optimise business

1.To Gain Customer Confidence:

Software testing makes sure that the software is user-friendly. That makes it capable of being
used by the customers it is intended for. Those who specialise in software application testing
are familiar with the needs of customers, and unless a software can satisfy a customer’s
needs, it would be a practically useless investment.

Different kinds of software have different kinds of customers. For instance, a Human
Resources department in a company that needs to track its employees and their performance
would have an entirely different software package from a hospital administrator trying to
evaluate which hospital departments need more resources.

That’s why just like software developers, software testers also tend to specialise in certain
kinds of software designs. That’s what makes software testing all the more resourceful in
gaining customer confidence. It’s a process that’s case-sensitive, and takes care to make
customers happy.

2. To Check Software Adaptability

Given that there are many devices, operating systems, and browsers available today, it is
necessary for software to be compatible with all platforms in order to offer users a smooth
user experience.If the functionality of software is affected by the change of devices, it can
count towards a negative user experience.
Testing eliminates such errors in the performance while adding to the compatibility and
adaptability of the software.Of course, one can design software that’s exclusively limited for
use on a desktop, but given that so much of networking and work is now also conducted on
smartphones, how useful would that software really be? Likewise, fewer customers will
choose a software that only efficiently operates on an operating system such as that of the
Apple Mac.It goes without saying that only the most adaptable software can really translate
into success in the market.

3. To Identify Errors

While it seems intuitive, it’s important to remember that software testing is what helps rid
products of errors before the product goes into the hands of a client.Regardless of how
competent software developers and engineers may be, the possibility of glitches and bugs is
always present in untested software. Testing will lead to better functioning of the product as
hidden errors will be exposed and fixed.

Even a single bug can be damaging for the reputation of a software developing house. It can
take a long time to regain customer confidence, so it’s much better and ultimately more
convenient to ensure testing is being achieved.The various types of software testing involved
in the process ensure that the end result is software that will be valued by clientele.

4. To Avoid Extra Costs

Tied to the problem of errors is the issue of the costs of reimbursing clients who have
experienced glitchy software.
These additional expenses can amount to a significant amount of damages, as not only has the
client been dissatisfied with the product for which they have paid, but a client’s time that they
could have invested elsewhere was also rendered worthless.

That’s why it’s a misconception to believe software testing costs a lot of stress, and that
testers themselves “break” software. Testers do feed large amounts of data to software
applications, but that’s what is necessary in software testing: if a software cannot support
large data-loads, what purpose does it achieve for businesses or individual customers?

If anything, software testing is the more cost-effective approach of handling software

applications. Testing alleviates the need for a constant cycle of upgrades and fixes, as
software testers identify bugs and errors before any such problems can arise.

5. To Accelerate Software Development

Some companies also neglect software testing as they have spent too much time on the
software development process, and need to quickly deliver the product to the client. While
this may be a problem with time-management in how a software development team is
considering its work delegations, it’s also an issue of conceptualising software testing.

Software testing and software development if run in parallel, can accelerate the software
development process and make it more efficient.

Staging the design process in a way that makes it certain that both software testing and
software development are happening simultaneously takes care to avoid such pit-falls in
software development.
6. To Avoid Risks

The worst thing about bugs and glitches is that it indicates a software is not secure. Especially
when it comes to software that is meant for organisations, errors or loopholes can lead to
vulnerability.

This can lead to huge losses of information to competitor businesses, and can also lead to a
lot of communication errors within an organisation.Thus, besides just being about a software
developer’s reputation or the annoyance of encouraging bugs in an application’s usability,
bugs can also lead to privacy leaks and data gaps that can cost more than either of those
things.

7. To Optimise Business

Testing allows the end-product to achieve a higher quality standard before being made live.It
also adds to the company’s brand image as well as its profitability through reduced support
costs.

Essentially, every software developer’s goal is customer retention, and every customer’s goal
is finding a service that’s reliable and worth their money. Providing effective software thus,
allows a business to become entrenched in a software provider’s reputation.
TESTING STRATEGIES:

A test strategy is an outline that describes the testing approach of the software
development cycle. The purpose of a test strategy is to provide a rational deduction from
organizational, high-level objectives to actual test activities to meet those objectives from a
quality assurance perspective.

Software Testing is a type of investigation to find out if there is any default or error present
in the software so that the errors can be reduced or removed to increase the quality of the
software and to check whether it fulfils the specifies requirements or not.

• Unit Testing: This software testing basic approach is followed by the programmer to
test the unit of the program. It helps developers to know whether the individual unit of
the code is working properly or not.
• Integration testing: It focuses on the construction and design of the software. You
need to see that the integrated units are working without errors or not.
• System testing: In this method, your software is compiled as a whole and then tested
as a whole. This testing strategy checks the functionality, security, portability,
amongst others.
SOFTWARE TESTING TECHNIQUE:
• Software testing techniques are the ways employed to test the application under test
against the functional or non-functional requirements gathered from business. Each
testing technique helps to find a specific type of defect.
• For example, Techniques which may find structural defects might not be able to find
the defects against the end-to-end business flow. Hence, multiple testing techniques
are applied in a testing project to conclude it with acceptable quality.
Principles Of Testing
• Below are the principles of software testing:
1. All the tests should meet the customer requirements.
2. To make our software testing should be performed by a third party
3. Exhaustive testing is not possible. As we need the optimal amount of testing based on
the risk assessment of the application.
4. All the test to be conducted should be planned before implementing it
5. It follows the Pareto rule(80/20 rule) which states that 80% of errors come from 20%
of program components.
6. Start testing with small parts and extend it to large parts.

Types Of Software Testing Techniques

• There are two main categories of software testing techniques:
1. Static Testing Techniques are testing techniques which are used to find defects in
Application under test without executing the code. Static Testing is done to avoid
errors at an early stage of the development cycle and thus reducing the cost of fixing
them.
2. Dynamic Testing Techniques are testing techniques that are used to test the dynamic
behavior of the application under test, that is by the execution of the code base. The
main purpose of dynamic testing is to test the application with dynamic inputs- some
of which may be allowed as per requirement (Positive testing) and some are not
allowed (Negative Testing).
Static Testing Techniques

As explained earlier, Static Testing techniques are testing techniques that do not require the
execution of a code base. Static Testing Techniques are divided into two major categories:
1. Reviews: They can range from purely informal peer reviews between two
developers/testers on the artifacts (code/test cases/test data) to totally
formal Inspections which are led by moderators who can be internal/external to
the organization.

1. Peer Reviews: Informal reviews are generally conducted without any

formal setup. It is between peers. For Example- Two
developers/Testers review each other’s artifacts like code/test cases.
2. Walkthroughs: Walkthrough is a category where the author of work
(code or test case or document under review) walks through what
he/she has done and the logic behind it to the stakeholders to achieve
a common understanding or for the intent of feedback.
3. Technical review: It is a review meeting that focuses solely on the
technical aspects of the document under review to achieve a
consensus. It has less or no focus on the identification of defects
based on reference documentation. Technical experts like
architects/chief designers are required for doing the review. It can
vary from Informal to fully formal.
4. Inspection: Inspection is the most formal category of reviews.
Before the inspection, The document under review is thoroughly
prepared before going for an inspection. Defects that are identified in
the Inspection meeting are logged in the defect management tool and
followed up until closure. The discussion on defects is avoided and a
separate discussion phase is used for discussions, which makes
Inspections a very effective form of reviews.
 2. Static Analysis: Static Analysis is an examination of requirement/code or
design with the aim of identifying defects that may or may not cause failures.
For Example- Reviewing the code for the following standards. Not following a
standard is a defect that may or may not cause a failure. There are many tools for
Static Analysis that are mainly used by developers before or during Component
or Integration Testing. Even Compiler is a Static Analysis tool as it points out
incorrect usage of syntax, and it does not execute the code per se. There are
several aspects to the code structure – Namely Data flow, Control flow, and
Data Structure.

1. Data Flow: It means how the data trail is followed in a given

program – How data gets accessed and modified as per the
instructions in the program. By Data flow analysis, You can identify
defects like a variable definition that never got used.
2. Control flow: It is the structure of how program instructions get
executed i.e conditions, iterations, or loops. Control flow analysis
helps to identify defects such as Dead code i.e a code that never gets
used under any condition.
3. Data Structure: It refers to the organization of data irrespective of
code. The complexity of data structures adds to the complexity of
code. Thus, it provides information on how to test the control flow
and data flow in a given code.

Dynamic Testing Techniques

Dynamic techniques are subdivided into three categories:

1. Structure-based Testing:

These are also called White box techniques Structure-based testing techniques are focused
on how the code structure works and test accordingly. To understand Structure-based
techniques, We first need to understand the concept of code coverage.

Code Coverage is normally done in Component and Integration Testing. It establishes what
code is covered by structural testing techniques out of the total code written. One drawback
of code coverage is that- it does not talk about code that has not been written at all (Missed
requirement), There are tools in the market that can help measure code coverage.

There are multiple ways to test code coverage:

a. Statement coverage: Number of Statements of code exercised/Total number of
statements. For Example, If a code segment has 10 lines and the test designed by you
covers only 5 of them then we can say that statement coverage given by the test is 50%.

b. Decision coverage: Number of decision outcomes exercised/Total number of Decisions.

For Example, If a code segment has 4 decisions (If conditions) and your test executes just
1, then decision coverage is 25%
c. Conditional/Multiple condition coverage: It has the aim to identify that each outcome
of every logical condition in a program has been exercised.

2. Experience-Based Techniques:

These are techniques of executing testing activities with the help of experience gained over
the years. Domain skill and background are major contributors to this type of testing. These
techniques are used majorly for UAT/business user testing. These work on top of structured
techniques like Specification-based and Structure-based, and it complements them. Here
are the types of experience-based techniques:

a. Error guessing: It is used by a tester who has either very good experience in testing or
with the application under test and hence they may know where a system might have a
weakness. It cannot be an effective technique when used stand-alone but is really helpful
when used along with structured techniques.

b. Exploratory testing: It is hands-on testing where the aim is to have maximum execution
coverage with minimal planning. The test design and execution are carried out in parallel
without documenting the test design steps. The key aspect of this type of testing is the
tester’s learning about the strengths and weaknesses of an application under test. Similar to
error guessing, it is used along with other formal techniques to be useful.

3. Specification-based Techniques:

This includes both functional and non-functional techniques (i.e. quality characteristics). It
basically means creating and executing tests based on functional or non-functional
specifications from the business. Its focus is on identifying defects corresponding to given
specifications. Here are the types of specification-based techniques:
1. Equivalence partitioning: It is generally used together and can be applied to any level
of testing. The idea is to partition the input range of data into valid and non-valid sections
such that one partition is considered “equivalent”. Once we have the partitions identified, it
only requires us to test with any value in a given partition assuming that all values in the
partition will behave the same. For example, if the input field takes the value between 1-
999, then values between 1-999 will yield similar results, and we need NOT test with each
value to call the testing complete.

2. Boundary Value Analysis (BVA): This analysis tests the boundaries of the range- both
valid and invalid. In the example above, 0,1,999, and 1000 are boundaries that can be
tested. The reasoning behind this kind of testing is that more often than not, boundaries are
not handled gracefully in the code.

3. Decision Tables: These are a good way to test the combination of inputs. It is also called
a Cause-Effect table. In layman’s language, One can structure the conditions applicable for
the application segment under test as a table and identify the outcomes against each one of
them to reach an effective test.

1. It should be taken into consideration that there are not too many combinations,
so that table becomes too big to be effective.
 2. Take an example of a Credit Card that is issued if both credit score and salary
limit are met. This can be illustrated in below decision table:

Decision Table

4. Use case-based Testing: This technique helps us to identify test cases that execute the
system as a whole- like an actual transaction by transaction. Use cases are a sequence of
steps that describe the interaction between the Actor and the system. They are always
defined in the language of the Actor, not the system. This testing is most effective in
identifying the integration defects. Use case also defines any preconditions and
postconditions of the process flow. ATM machine example can be tested via use case:

Use case-based Testing

5. State Transition Testing: It is used where an application under test or a part of it can be
treated as FSM or finite state machine. Continuing the simplified ATM example above, We
can say that ATM flow has finite states and hence can be tested with the State transition
technique. There are 4 basic things to consider –
1. States a system can achieve
2. Events that cause the change of state
3. The transition from one state to other
4. Outcomes of change of state

A state event pair table can be created to derive test conditions – both positive and
negative.
 State Transition

PSYCHOLOGY OF TESTING:
In software testing, psychology plays an extremely important role. It is one of those factors
that stay behind the scene, but has a great impact on the end result. Categorized into three
sections, the psychology of testing enables smooth testing as well as makes the process hassle-
free. It is mainly dependent on the mindset of the developers and testers, as well as the quality
of communication between them. Moreover, the psychology of testing improves mutual
understanding among team members and helps them work towards a common goal.

The three sections of the psychology of testing are:

 The mindset of Developers and Testers.

 Communication in a Constructive Manner.
 Test Independence.

The mindset of Developers and Testers

The software development life cycle is a combination of various activities, which are
performed by different individuals using their expertise and knowledge. It is not an unknown
fact that to accomplish the success, development of software, people with different skills and
mindset are required.

Developers synthesize code. They build up things, putting pieces together and figuring out fun
and unique ways of combining those distinct little bits to do wonderful and amazing things.
But Testers are all about analysis. Once it has all been put together, the tester likes to take it
apart again, piece by piece, this time looking for those little corners, edges, and absurdities that
hide in those weird and strange interactions that come from those new and amazing ways of
putting pieces together.
Testing and Reviewing the applications are different from analyzing and developing it. While
testing or reviewing a product, testers mainly look for defects or failures in the product. If we
are building or developing applications, we have to work positively to solve the problems
during the development process and to make the product according to the user specification.

Communication in a Constructive Manner

Testers and test managers need to have good interpersonal skills to be able to communicate
effectively about the defects, failures, test results, test progress and risks and to build positive
relationships among colleagues.

Communication, if done in a polite and respectful manner can help build a strong and reliable
relationship between the team members and help them avoid any misunderstanding.

• The comparison of the mindset of the tester and the developer.

• The balance between self-testing and independent testing.
• There should be clear and courteous communication and feedback on defects between
tester and developer.
Self-testing and Independent testing

• Comparison of the mindsets of a tester and a programmer does not mean that a tester
cannot be a programmer, or that a programmer cannot be the tester, although they
often are separate roles. In fact, programmers are the testers. They always test the
component which they built.

WHITE BOX TESTING:

White Box Testing is a testing technique in which software’s internal structure, design, and
coding are tested to verify input-output flow and improve design, usability, and security. In
white box testing, code is visible to testers, so it is also called Clear box testing, Open box
testing, Transparent box testing, Code-based testing, and Glass box testing.
It is one of two parts of the Box Testing approach to software testing. Its counterpart,
Blackbox testing, involves testing from an external or end-user perspective. On the other
hand, White box testing in software engineering is based on the inner workings of an
application and revolves around internal testing.
White box testing techniques analyze the internal structures the used data structures,
internal design, code structure and the working of the software rather than just the
functionality as in black box testing. It is also called glass box testing or clear box testing or
structural testing.
Working process of white box testing:
• Input: Requirements, Functional specifications, design documents, source code.
• Processing: Performing risk analysis for guiding through the entire process.
 • Proper test planning: Designing test cases so as to cover entire code. Execute
rinse-repeat until error-free software is reached. Also, the results are communicated.
• Output: Preparing final report of the entire testing process.

Types of White Box Testing

• White box testing encompasses several testing types used to evaluate the usability of
an application, block of code or specific software package. There are listed below —
• Unit Testing: It is often the first type of testing done on an application. Unit
Testing is performed on each unit or block of code as it is developed. Unit Testing is
essentially done by the programmer. As a software developer, you develop a few lines
of code, a single function or an object and test it to make sure it works before
continuing Unit Testing helps identify a majority of bugs, early in the software
development lifecycle. Bugs identified in this stage are cheaper and easy to fix.
• Testing for Memory Leaks: Memory leaks are leading causes of slower running
applications. A QA specialist who is experienced at detecting memory leaks is
essential in cases where you have a slow running software application.
• Apart from the above, a few testing types are part of both black box and white box
testing. They are listed below
• White Box Penetration Testing: In this testing, the tester/developer has full
information of the application’s source code, detailed network information, IP
addresses involved and all server information the application runs on. The aim is to
attack the code from several angles to expose security threats.
• White Box Mutation Testing: Mutation testing is often used to discover the best
coding techniques to use for expanding a software solution.

White Box Testing Techniques

A major White box testing technique is Code Coverage analysis. Code Coverage analysis
eliminates gaps in a Test Case suite. It identifies areas of a program that are not exercised by
a set of test cases. Once gaps are identified, you create test cases to verify untested parts of
the code, thereby increasing the quality of the software product.
Following are important White Box Testing Techniques:

 Statement Coverage
 Decision Coverage
 Branch Coverage
 Condition Coverage
 Multiple Condition Coverage
 Finite State Machine Coverage
 Path Coverage
 Control flow testing
 Data flow testing

Statement coverage: In this technique, the aim is to traverse all statement at least once.
Hence, each line of code is tested. In case of a flowchart, every node must be traversed at
least once. Since all lines of code are covered, helps in pointing out faulty code.

This technique requires every possible statement in the code to be tested at least once during
the testing process of software engineering.

Branch Coverage: In this technique, test cases are designed so that each branch from all
decision points are traversed at least once. In a flowchart, all edges must be traversed at
least once.
Branch Coverage – This technique checks every possible path (if-else and other conditional
loops) of a software application.

Condition Coverage: In this technique, all individual conditions must be covered as shown
in the following example:
1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’

Multiple Condition Coverage: In this technique, all the possible combinations of the
possible outcomes of conditions are tested at least once. Let’s consider the following
example:
1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’

Basis Path Testing: In this technique, control flow graphs are made from code or flowchart
and then Cyclomatic complexity is calculated which defines the number of independent
paths so that the minimal number of test cases can be designed for each independent path.
Steps:
1. Make the corresponding control flow graph
2. Calculate the cyclomatic complexity
3. Find the independent paths
4. Design test cases corresponding to each independent path

 Loop Testing: Loops are widely used and these are fundamental to many algorithms
hence, their testing is very important. Errors often occur at the beginnings and ends of
loops.

1. Simple loops: For simple loops of size n, test cases are designed that:
 Skip the loop entirely
 Only one pass through the loop
 2 passes
 m passes, where m < n
 n-1 ans n+1 passes
2. Nested loops: For nested loops, all the loops are set to their minimum count and we
start from the innermost loop. Simple loop tests are conducted for the innermost
loop and this is worked outwards till all the loops have been tested.
3. Concatenated loops: Independent loops, one after another. Simple loop tests are
applied for each.

If they’re not independent, treat them like nesting.

There are automated tools available to perform Code coverage analysis. Below are a few
coverage analysis techniques a box tester can use:

Apart from above, there are numerous coverage types such as Condition Coverage, Multiple
Condition Coverage, Path Coverage, Function Coverage etc. Each technique has its own
merits and attempts to test (cover) all parts of software code. Using Statement and Branch
coverage you generally attain 80-90% code coverage which is sufficient.

White Box Testing Tools

Below is a list of top white box testing tools.

 EclEmma
 NUnit
 PyUnit
 HTMLUnit
 CppUnit

Advantages of White Box Testing

 Code optimization by finding hidden errors.

 White box tests cases can be easily automated.
 Testing is more thorough as all code paths are usually covered.
  Testing can start early in SDLC even if GUI is not available.
 White box testing is very thorough as the entire code and structures are tested.
 It results in the optimization of code removing error and helps in removing extra
lines of code.
 It can start at an earlier stage as it doesn’t require any interface as in case of black
box testing.
 Easy to automate.

Disadvantages of WhiteBox Testing

 White box testing can be quite complex and expensive.

 Developers who usually execute white box test cases detest it. The white box testing
by developers is not detailed and can lead to production errors.
 White box testing requires professional resources with a detailed understanding of
programming and implementation.
 White-box testing is time-consuming, bigger programming applications take the time
to test fully.
 Redesign of code and rewriting code needs test cases to be written again.
 Testers are required to have in-depth knowledge of the code and programming
language as opposed to black box testing.
 Missing functionalities cannot be detected as the code that exists is tested.
 Very complex and at times not realistic.

BLACK BOX TESTING:

• Black Box Testing is a software testing method in which the functionalities of

software applications are tested without having knowledge of internal code structure,
implementation details and internal paths.

• Black Box Testing mainly focuses on input and output of software applications and it
is entirely based on software requirements and specifications. It is also known as
Behavioral Testing.

Black box testing can be done in the following ways:

 Understand the application under the test’s requirement specifications. A precise and
accurate SRS document should be present. (A Software Requirements Specification (SRS)
document outlines what the software will do and how it should perform.)
 To test the software, evaluate the set of valid inputs and test scenarios.
 Prepare the test cases to cover as many inputs as possible.
 Run the test cases in the system to generate output validated against the expected outcome
to determine whether the test passes or fails. The failed steps are noted and forwarded to
the development team for correction.Based on the defects that have been fixed, the tester
retests the defects to determine whether or not they are recurring.

1. Syntax-Driven Testing – This type of testing is applied to systems that can be

syntactically represented by some language. For example- compilers, language that can be
represented by a context-free grammar. In this, the test cases are generated so that each
grammar rule is used at least once.

2. Equivalence partitioning – It is often seen that many types of inputs work similarly so
instead of giving all of them separately we can group them and test only one input of each
group. The idea is to partition the input domain of the system into several equivalence
classes such that each member of the class works similarly, i.e., if a test case in one class
results in some error, other members of the class would also result in the same error.
The technique involves two steps:
1. Identification of equivalence class – Partition any input domain into a minimum of
two sets: valid values and invalid values. For example, if the valid range is 0 to 100
then select one valid input like 49 and one invalid like 104.

2. Generating test cases – (i) To each valid and invalid class of input assign a unique
identification number. (ii) Write a test case covering all valid and invalid test cases
considering that no two invalid inputs mask each other. To calculate the square root of a
number, the equivalence classes will be: (a) Valid inputs:

 The whole number which is a perfect square- output will be an integer.

 The whole number which is not a perfect square- output will be a decimal number.

 Positive decimals

 Negative numbers(integer or decimal).

 Characters other than numbers like “a”,”!”,”;”, etc.

3. Boundary value analysis – Boundaries are very good places for errors to occur. Hence
if test cases are designed for boundary values of the input domain then the efficiency of
testing improves and the probability of finding errors also increases. For example – If the
valid range is 10 to 100 then test for 10,100 also apart from valid and invalid inputs.
4. Cause effect Graphing – This technique establishes a relationship between logical input
called causes with corresponding actions called the effect. The causes and effects are
represented using Boolean graphs. The following steps are followed:
1. Identify inputs (causes) and outputs (effect).

2. Develop a cause-effect graph.

3. Transform the graph into a decision table.

4. Convert decision table rules to test cases.

5.Requirement-based testing – It includes validating the requirements given in the SRS of

a software system.
6. Compatibility testing – The test case result not only depends on the product but is also
on the infrastructure for delivering functionality. When the infrastructure parameters are
changed it is still expected to work properly. Some parameters that generally affect the
compatibility of software are:
1. Processor (Pentium 3, Pentium 4) and several processors.
2. Architecture and characteristics of machine (32-bit or 64-bit).
3. Back-end components such as database servers.
4. Operating System (Windows, Linux, etc).

Black Box Testing Type

The following are the several categories of black box testing:

1. Functional Testing

2. Regression Testing

3. Nonfunctional Testing (NFT)

Functional Testing: It determines the system’s software functional requirements. This

black box testing type is related to the functional requirements of a system; it is done by
software testers.
Regression Testing: It ensures that the newly added code is compatible with the existing
code. In other words, a new software update has no impact on the functionality of the
software. This is carried out after a system maintenance operation and upgrades. Regression
Testing is done after code fixes, upgrades or any other system maintenance to check the new
code has not affected the existing code.

Nonfunctional Testing: Nonfunctional testing is also known as NFT. This testing is not
functional testing of software. It focuses on the software’s performance, usability, and
scalability. This type of black box testing is not related to testing of specific functionality, but
non-functional requirements such as performance, scalability, usability.

Tools used for Black Box Testing:

Tools used for Black box testing largely depends on the type of black box testing you are
doing.

 For Functional/ Regression Tests you can use – QTP, Selenium

 For Non-Functional Tests, you can use – LoadRunner, Jmeter
Black Box Testing Techniques
Following are the prominent Test Strategy amongst the many used in Black box Testing

 Equivalence Class Testing: It is used to minimize the number of possible test cases
to an optimum level while maintains reasonable test coverage.
 Boundary Value Testing: Boundary value testing is focused on the values at
boundaries. This technique determines whether a certain range of values are
acceptable by the system or not. It is very useful in reducing the number of test cases.

It is most suitable for the systems where an input is within certain ranges.

 Decision Table Testing: A decision table puts causes and their effects in a matrix.
There is a unique combination in each column.

Black Box Testing and Software Development Life Cycle (SDLC)

Black box testing has its own life cycle called Software Testing Life Cycle (STLC) and it is
relative to every stage of Software Development Life Cycle of Software Engineering.

 Requirement – This is the initial stage of SDLC and in this stage, a requirement is
gathered. Software testers also take part in this stage.
 Test Planning & Analysis – Testing Types applicable to the project are determined.
A Test Plan is created which determines possible project risks and their mitigation.
 Design – In this stage Test cases/scripts are created on the basis of software
requirement documents
 Test Execution– In this stage Test Cases prepared are executed. Bugs if any are fixed
and re-tested.
Comparison of Black Box and White Box Testing:
Black Box Testing White Box Testing
White Box Testing (Unit Testing) validates
The main focus of black box testing is on
internal structure and working of your
the validation of your functional requirements.
software code

To conduct White Box Testing, knowledge of

underlying programming language is
Black box testing gives abstraction from code
essential. Current day software systems use a
and focuses on testing effort on the software
variety of programming languages and
system behavior.
technologies and its not possible to know all
of them.

Black box testing facilitates testing White box testing does not facilitate testing
communication amongst modules communication amongst modules

Advantages of Black Box Testing:

 The tester does not need to have more functional knowledge or programming skills to
implement the Black Box Testing.
 It is efficient for implementing the tests in the larger system.
 Tests are executed from the user’s or client’s point of view.
 Test cases are easily reproducible.
 It is used in finding the ambiguity and contradictions in the functional specifications.

GREY BOX TESTING:

Grey Box Testing or Gray box testing is a software testing technique to test a software
product or application with partial knowledge of internal structure of the application. The
purpose of grey box testing is to search and identify the defects due to improper code
structure or improper use of applications.
In this process, context-specific errors that are related to web systems are commonly
identified. It increases the testing coverage by concentrating on all of the layers of any
complex system.

Gray Box Testing is a software testing method, which is a combination of both White Box
Testing and Black Box Testing method.

 In White Box testing internal structure (code) is known

 In Black Box testing internal structure (code) is unknown
 In Grey Box Testing internal structure (code) is partially known

In Software Engineering, Gray Box Testing gives the ability to test both sides of an
application, presentation layer as well as the code part. It is primarily useful in Integration
Testing and Penetration Testing.

Example of Gray Box Testing: While testing websites feature like links or orphan links, if
tester encounters any problem with these links, then he can make the changes straightaway in
HTML code and can check in real time.

Gray Box Testing Strategy

To perform Gray box testing, it is not necessary that the tester has the access to the source
code. A test is designed based on the knowledge of algorithm, architectures, internal states, or
other high -level descriptions of the program behavior.

To perform Gray box Testing-

  It applies a straightforward technique of black box testing
 It is based on requirement test case generation, as such, it presets all the conditions
before the program is tested by assertion method.

Techniques used for Grey box Testing are-

 Matrix Testing: This testing technique involves defining all the variables that exist in
their programs.
 Regression Testing: To check whether the change in the previous version has
regressed other aspects of the program in the new version. It will be done by testing
strategies like retest all, retest risky use cases, retest within a firewall.
 Orthogonal Array Testing or OAT: It provides maximum code coverage with
minimum test cases.
 Pattern Testing: This testing is performed on the historical data of the previous
system defects. Unlike black box testing, gray box testing digs within the code and
determines why the failure happened
Usually, Grey box methodology uses automated software testing tools to conduct the testing.
Stubs and module drivers are created to relieve tester to manually generate the code.

Steps to perform Grey box Testing are:

 Step 1: Identify inputs

 Step 2: Identify the outputs
 Step 3: Identify the major paths
 Step 4: Identify Subfunctions
 Step 5: Develop inputs for Subfunctions
 Step 6: Develop outputs for Subfunctions
 Step 7: Execute test case for Subfunctions
 Step 8: Verify the correct result for Subfunctions
 Step 9: Repeat steps 4 & 8 for other Subfunctions
 Step 10: Repeat steps 7 & 8 for other Subfunctions

The test cases for grey box testing may include, GUI related, Security related, Database
related, Browser related, Operational system related, etc.

Gray Box Testing Challenges

 When a component under test encounter a failure of some kind may lead to abortion
of the ongoing operation
 When test executes in full but the content of the result is incorrect.

ROUBUSTNESS TESTING:
 • Robustness testing is a type of testing that is performed to assess the ability of a
system or component to function correctly when it is subjected to invalid or
unexpected inputs, or when it is operating outside of its specified operating
conditions. It is typically used to test for the presence of memory leaks or other types
of errors that can cause a system to crash. Robustness testing is also sometimes
referred to as reliability testing, stress testing, or endurance testing.

• The purpose of robustness testing is to identify the parts of the system that are most
vulnerable to failure and to determine how the system can be made more resistant to
failure.
• Robustness testing is typically conducted by subjecting the system to a variety of
stressful conditions, such as high temperatures, high humidity, high pressure, and high
levels of vibration.
• Robustness testing is typically conducted during the later stages of software testing
after the software has been shown to work correctly under normal conditions.
• A common example of robustness testing is testing how a system responds to
unexpected input values.
• For example, if a system is designed to accept numerical input values between 1 and
10, a robustness test would involve trying to input values outside of this range, such
as 0, 11, or -5, to see how the system responds.
• Another example of robustness testing would be testing how a system responds to
unexpected environmental conditions, such as excessive heat, cold, or humidity.
TYPES:
• Regression testing: Regression testing is a type of testing that is used to find bugs in
software that have already been fixed. This is done by running the software with
different inputs and comparing the output to the expected output. This type of testing
is used to verify that a software program continues to function properly after it has
been modified or updated. This type of testing is typically performed after a new
 version of the software has been released, or after a change has been made to the
code.
• Functional testing: Functional testing is a type of testing that is used to verify that a
system or software performs as expected. Load testing is a type of testing that is used
to verify that a system or software can handle a heavy load or traffic. This type of
testing is typically performed by running the software through a series of tests that
exercise the various functions of the software.
• Load testing: Load testing is a type of testing that is used to find bugs in software by
running it with different inputs and checking if the output is as expected. It is used to
verify that a software program is able to handle the load that is expected to be placed
on it. This type of testing is typically done by running the software through a series of
tests that simulate the load that the software will experience in production.
• Stress testing: Stress testing involves subjecting a system to intense or extreme
conditions in order to see how well it holds up. This can help to identify potential
issues that may only arise under high levels of stress or strain.
• Negative testing: Negative testing involves deliberately providing invalid or incorrect
inputs to a system in order to see how it responds. This can help to uncover errors in
input validation or handling that could lead to security vulnerabilities or data loss.
• Fuzz testing: A fuzz test (also known as a fuzzing test) is a software testing
technique, usually automated or semi-automated, that involves providing invalid,
unexpected, or random data to the inputs of a computer program. The program is then
monitored for exceptions such as crashes, failing built-in code assertions, or potential
memory leaks. Fuzz testing is effective in finding coding errors and security
vulnerabilities. This involves feeding random or invalid data into a system and seeing
how it responds. This can help to find potential vulnerabilities in the system.
• Use case testing: Use case testing involves testing the system with realistic scenarios
to see how it responds. This can help to identify potential usability issues.
• Security testing: Security Testing involves testing the system for security
vulnerabilities. This can help to identify potential security risks.
• Black-box testing: Black-box testing is a method of software testing that examines
the functionality of a software program without knowing the internal code structure.
The tester is only aware of what the software is supposed to do but not how it does it.
Black-box testing can be used to test the functionality of a software program, the
usability of a user interface, and the compliance of a program with external standards.
• Mutation testing: Mutation testing is a type of software testing that involves
modifying a program’s source code or its inputs and then testing to see if the program
still behaves as expected. The goal of mutation testing is to find faults in a program’s
code or inputs that can cause the program to produce incorrect results.
• Fault injection testing: Fault injection testing is a method of testing software by
Introducing faults into the software program to see if the program can detect and
 handle the faults. Fault injection can be used to test the robustness of a program’s
error-handling capabilities.
VERIFICATION AND VALIDATION TESTING:
Verification testing
• Verification testing includes different activities such as business requirements, system
requirements, design review, and code walkthrough while developing a product.
• It is also known as static testing, where we are ensuring that "we are developing the
right product or not". And it also checks that the developed application fulfilling all
the requirements given by the client.

Validation testing
• Validation testing is testing where tester performed functional and non-functional
testing. Here functional testing includes Unit Testing
• (UT), Integration Testing
• (IT) and System Testing (ST), and non-functional testing includes User acceptance
testing (UAT)
Validation testing is also known as dynamic testing, where we are ensuring that "we have
developed the product right." And it also checks that the software meets the business
needs of the client.
SYNTAX TESTING:
• Syntax Testing, a black box testing technique, involves testing the System inputs and
it is usually automated because syntax testing produces a large number of tests.
Internal and external inputs have to conform the below formats:
• Format of the input data from users.
• File formats.
• Database schemas.
Syntax Testing - Steps:
• Identify the target language or format.
• Define the syntax of the language.
• Validate and Debug the syntax.
Syntax Testing - Limitations:
• Sometimes it is easy to forget the normal cases.
• Syntax testing needs driver program to be built that automatically sequences through a
set of test cases usually stored as data.
UNIT TESTING:
• Unit Testing is a type of software testing where individual units or components of a
software are tested. The purpose is to validate that each unit of the software code
performs as expected. Unit Testing is done during the development (coding phase) of
an application by the developers. Unit Tests isolate a section of code and verify its
 correctness. A unit may be an individual function, method, procedure, module, or
object.
• In SDLC, STLC, V Model, Unit testing is first level of testing done before integration
testing. Unit testing is a WhiteBox testing technique that is usually performed by the
developer. Though, in a practical world due to time crunch or reluctance of
developers to tests, QA engineers also do unit testing.

INTEGRATION TESTING:
• Integration testing is the second level of the software testing process comes after unit
testing. In this testing, units or individual components of the software are tested in a
group. The focus of the integration testing level is to expose defects at the time of
interaction between integrated components or units.

SYSTEM TESTING:
• System Testing is a level of testing that validates the complete and fully integrated
software product. The purpose of a system test is to evaluate the end-to-end system
 specifications. Usually, the software is only one element of a larger computer-based
system. Ultimately, the software is interfaced with other software/hardware systems.
System Testing is defined as a series of different tests whose sole purpose is to
exercise the full computer-based system.

LEVELS OF TESTING:
• Testing levels are the procedure for finding the missing areas and avoiding
overlapping and repetition between the development life cycle stages. We have
already seen the various phases such as Requirement collection, designing, coding
testing, deployment, and maintenance of SDLC (Software Development Life
Cycle)
• Different Levels of Testing
• The levels of software testing involve the different methodologies, which can be used
while we are performing the software testing.
1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing
Level1: Unit Testing
• Unit testing is the first level of software testing, which is used to test if software
modules are satisfying the given requirement or not.
• The first level of testing involves analyzing each unit or an individual
component of the software application.
• Unit testing is also the first level of functional testing.
• The primary purpose of executing unit testing is to validate unit components with
their performance.
Level2: Integration Testing
• The second level of software testing is the integration testing. The integration testing
process comes after unit testing.
• It is mainly used to test the data flow from one module or component to other
modules.
• In integration testing, the test engineer tests the units or separate components or
modules of the software in a group.
• The primary purpose of executing the integration testing is to identify the defects at
the interaction between integrated components or units.
Level3: System Testing
• The third level of software testing is system testing, which is used to test the
software's functional and non-functional requirements.
• It is end-to-end testing where the testing environment is parallel to the production
environment. In the third level of software testing, we will test the application as a
whole system.
• To check the end-to-end flow of an application or the software as a user is known
as System testing.
 • In system testing, we will go through all the necessary modules of an application and
test if the end features or the end business works fine, and test the product as a
complete system.
Level4: Acceptance Testing
• The last and fourth level of software testing is acceptance testing, which is used to
evaluate whether a specification or the requirements are met as per its delivery.
• The software has passed through three testing levels (Unit Testing, Integration
Testing, System Testing). Some minor errors can still be identified when the end-
user uses the system in the actual scenario.
• In simple words, we can say that Acceptance testing is the squeezing of all the
testing processes that are previously done.
• The acceptance testing is also known as User acceptance testing (UAT) and is done
by the customer before accepting the final product.
• Usually, UAT is done by the domain expert (customer) for their satisfaction and
checks whether the application is working according to given business scenarios and
real-time scenarios.
 UNIT –III

INTRODUCTION TO AGILE PROCESS

CONCEPTS OF AGILE PROCESS

Agile software development refers to software development methodologies centered around

the idea of iterative development, where requirements and solutions evolve through
collaboration between self-organizing cross-functional teams.

The ultimate value in Agile development is that it enables teams to deliver value faster, with
greater quality and predictability, and greater aptitude to respond to change.

SCRUM :

CONCEPTS:

The Scrum approach is a general agile method but its focus is on managing iterative
development rather than specific agile practices. There are three phases in Scrum:

1. The initial phase is an outline planning phase where you establish the general
objectives for the project and design the software architecture.
2. This is followed by a series of sprint cycles, where each cycle develops an
increment of the system.
3. The project closure phase wraps up the project, completes required documentation
such as system help frames and user manuals and assesses the lessons learned
from the project.

Sprints are fixed length, normally 2-4 weeks. They correspond to the development of a
release of the system in XP. The starting point for planning is the product backlog, which is
the list of work to be done on the project. The selection phase involves all of the project team
who work with the customer (product owner) to select the features and functionality to be
developed during the sprint. Once these are agreed, the team organize themselves to develop
the software. During this stage the team is relatively isolated from the product owner and the
organization, with all communications channelled through the ScrumMaster. The role of the
ScrumMaster is to protect the development team from external distractions. At the end of the
sprint the work done is reviewed and presented to stakeholders (including the product
owner). Velocity is calculated during the sprint review; it provides an estimate of how much
product backlog the team can cover in a single sprint. Understanding the team's velocity helps
them estimate what can be covered in a sprint and provides a basis for measuring and
improving performance. The next sprint cycle then begins.

The ScrumMaster is a facilitator who arranges short daily meetings (daily scrums), tracks the
backlog of work to be done, records decisions, measures progress against the backlog and
communicates with the product owner and management outside of the team. The whole team
attends daily scrums where all team members share information, describe their progress since
the last meeting, problems that have arisen and what is planned for the following day.
Advantages of scrum include:

 The product is broken down into a set of manageable and understandable

chunks.
 Unstable requirements do not hold up progress.
 The whole team have visibility of everything and consequently team
communication is improved.
 Customers see on-time delivery of increments and gain feedback on how the
product works.
 Trust between customers and developers is established and a positive culture is
created in which everyone expects the project to succeed.

Scrum is an agile development methodology used in the development of Software based on

an iterative and incremental processes. Scrum is adaptable, fast, flexible and effective agile
framework that is designed to deliver value to the customer throughout the development of
the project. The primary objective of Scrum is to satisfy the customer’s need through an
environment of transparency in communication, collective responsibility and continuous
progress. The development starts from a general idea of what needs to be built, elaborating a
list of characteristics ordered by priority (product backlog) that the owner of the product
wants to obtain.

Scrum Methodology & Process

Scrum is precisely an evolution of Agile Management. Scrum methodology is based on a set

of very defined practices and roles that must be involved during the software development
process. It is a flexible methodology that rewards the application of the 12 agile principles in
a context agreed by all the team members of the product.

Scrum is executed in temporary blocks that are short and periodic, called Sprints, which
usually range from 2 to 4 weeks, which is the term for feedback and reflection. Each Sprint is
an entity in itself, that is, it provides a complete result, a variation of the final product that
must be able to be delivered to the client with the least possible effort when requested.

The process has as a starting point, a list of objectives/ requirements that make up the project
plan. It is the client of the project that prioritizes these objectives considering a balance of the
value and the cost thereof, that is how the iterations and consequent deliveries are
determined.

On the one hand the market demands quality, fast delivery at lower costs, for which a
company must be very agile and flexible in the development of products, to achieve short
development cycles that can meet the demand of customers without undermining the quality
of the result. It is a very easy methodology to implement and very popular for the quick
results it gets.

Scrum methodology is used mainly for software development, but other sectors are also
taking advantage of its benefits by implementing this methodology in their organizational
models such as sales, marketing, & HR teams etc.

Different Roles in Scrum

In Scrum, the team focuses on building quality software. The owner of a Scrum project
focuses on defining what are the characteristics that the product must have to build (what to
build, what not and in what order) and to overcome any obstacle that could hinder the task of
the development team.

The Scrum team consists of the following roles:

Scrum master: The person who leads the team guiding them to comply with the rules and
processes of the methodology. Scrum master manages the reduction of impediments of the
project and works with the Product Owner to maximize the ROI. The Scrum Master is in
charge of keeping Scrum up to date, providing coaching, mentoring and training to the teams
in case it needs it.

Product owner (PO): Is the representative of the stakeholders and customers who use the
software. They focus on the business part and is responsible for the ROI of the project. They
Translate the vision of the project to the team, validate the benefits in stories to be
incorporated into the Product Backlog and prioritize them on a regular basis.

Team: A group of professionals with the necessary technical knowledge who develop the
project jointly carrying out the stories they commit to at the start of each sprint.

Benefits of Scrum Methodology

Scrum has many advantages over other agile development methodologies. It is currently the
most used and trusted framework of reference in the software industry. Below are some of the
known benefits of Scrum:

Easily Scalable: Scrum processes are iterative and are handled within specific work periods,
which makes it easier for the team to focus on definite functionalities for each period. This
not only has the benefit of achieving better deliverables in line with the needs of the user, but
also gives the ability to the teams to scale the modules in terms of functionality, design, scope
and characteristics in an orderly, transparent and simple manner.
Compliance of expectations: The client establishes their expectations indicating the value
that each requirement/ history of the project brings, the team estimates them and with this
information the Product Owner establishes its priority. On a regular basis, in the sprint
demos, the Product Owner verifies that the requirements have been met and transmits
feedback to the team.

Flexible to changes: Quick reaction to changes in requirements generated by customer needs

or market developments. The methodology is designed to adapt to the changing requirements
that complex projects entail.

Time to Market reduction: The client can start using the most important functionalities of
the project before the product is completely ready.

Higher software quality: The working method and the need to obtain a functional version
after each iteration, helps to obtain a higher quality software.

Timely Prediction: Using this methodology, we know the average speed of the team by
sprint (story points), with which, consequently, it is possible to estimate when a certain
functionality that is still in the backlog will be available.

Reduction of risks: The fact of carrying out the most valuable functionalities in the first
place and of knowing the speed with which the team advances in the project, allows to clear
risks effectively in advance.

Planning in Scrum

The Sprint Planning Meeting is held at the beginning of each Sprint. All the members of the
Team participate in the meeting, i.e., the Product Owner, Scrum Master and all the
Development Team. The entire Scrum team must understand and define what objective
should be obtained in that Sprint (Sprint Goal). From this point the development team must
design a work plan to achieve the objective. This planning should allow you to see if the
sprint goal involves a workload according to the duration stipulated for the Sprints (which is
2 to 4 weeks).

The client shows the result to be achieved in that Sprint and the requirements of the
deliverable product. Here you have to carry out a discussion in which the development team
evaluates what elements of the list can be delivered.

Both the Scrum Master and the Product Owner must collaborate to clarify any aspect of the
requirements. Finally, the development team must explain how they will organize the team’s
work to achieve the Sprint goal.

Extreme programming (XP)

Extreme programming (XP) is one of the most important software development

frameworks of Agile models. It is used to improve software quality and responsiveness to
customer requirements.

The extreme programming model recommends taking the best practices that have worked
well in the past in program development projects to extreme levels. Good practices need to
be practiced in extreme programming.
Extreme Programming (XP) is an agile software development framework that aims to produce
higher quality software, and higher quality of life for the development team. XP is the most
specific of the agile frameworks regarding appropriate engineering practices for software
development.

Perhaps the best-known and a very influential agile method, Extreme Programming (XP)
takes an 'extreme' approach to iterative development:

 New versions may be built several times per day;

 Increments are delivered to customers every 2 weeks;
 All tests must be run for every build and the build is only accepted if tests run
successfully.
This is how XP supports agile principles:

 Incremental development is supported through small, frequent system releases.

 Customer involvement means full-time customer engagement with the team.
 People not process through pair programming, collective ownership, and a
process that avoids long working hours.
 Change supported through regular system releases.
 Maintaining simplicity through constant refactoring of code.

Model and suggested to maximize their use are given below:

 Code Review: Code review detects and corrects errors efficiently. It suggests pair
programming as coding and reviewing of written code carried out by a pair of
programmers who switch their works between them every hour.

 Testing: Testing code helps to remove errors and improves its reliability. XP suggests
test-driven development (TDD) to continually write and execute test cases. In the TDD
approach test cases are written even before any code is written.

 Incremental development: Incremental development is very good because customer

feedback is gained and based on this development team comes up with new increments
every few days after each iteration.

 Simplicity: Simplicity makes it easier to develop good quality code as well as to test
and debug it.

 Design: Good quality design is important to develop good quality software. So,
everybody should design daily.

 Integration testing: It helps to identify bugs at the interfaces of different

functionalities. Extreme programming suggests that the developers should achieve
continuous integration by building and performing integration testing several times a
day.

Basic principles of Extreme programming: XP is based on the frequent iteration through

which the developers implement User Stories. User stories are simple and informal
statements of the customer about the functionalities needed.
A User Story is a conventional description by the user of a feature of the required system. It
does not mention finer details such as the different scenarios that can occur. Based on User
stories, the project team proposes Metaphors.

Metaphors are a common vision of how the system would work. The development team
may decide to build a Spike for some features. A Spike is a very simple program that is
constructed to explore the suitability of a solution being proposed.

It can be considered similar to a prototype. Some of the basic activities that are followed
during software development by using the XP model are given below:

 Coding: The concept of coding which is used in the XP model is slightly different from
traditional coding. Here, the coding activity includes drawing diagrams (modeling) that
will be transformed into code, scripting a web-based system, and choosing among
several alternative solutions.

 Testing: XP model gives high importance to testing and considers it to be the primary
factor to develop fault-free software.

 Listening: The developers need to carefully listen to the customers if they have to
develop good quality software. Sometimes programmers may not have the depth
knowledge of the system to be developed. So, the programmers should understand
properly the functionality of the system and they have to listen to the customers.

 Designing: Without a proper design, a system implementation becomes too complex

and very difficult to understand the solution, thus making maintenance expensive. A
good design results elimination of complex dependencies within a system. So, effective
use of suitable design is emphasized.

 Feedback: One of the most important aspects of the XP model is to gain feedback to
understand the exact customer needs. Frequent contact with the customer makes the
development effective.

 Simplicity: The main principle of the XP model is to develop a simple system that will
work efficiently in the present time, rather than trying to build something that would
take time and may never be used. It focuses on some specific features that are
immediately needed, rather than engaging time and effort on speculations of future
requirements.

KEY PRACTICES OF XP INCLUDE:

User stories for specification
In XP, a customer or user is part of the XP team and is responsible for making decisions on
requirements. User requirements are expressed as user stories or scenarios..

Refactoring
Conventional wisdom in software engineering is to design for change. It is worth spending
time and effort anticipating changes as this reduces costs later in the life cycle.

Test-first development
Testing is central to XP and XP has developed an approach where the program is tested after
every change has been made.

Test-driven development: writing tests before code clarifies the requirements to be

implemented. Tests are written as programs rather than data so that they can be executed
automatically.

Customer involvement: The role of the customer in the testing process is to help develop
acceptance tests for the stories that are to be implemented in the next release of the system.
The customer who is part of the team writes tests as development proceeds.

Pair programming
Pair programming involves programmers working in pairs, developing code together. This
helps develop common ownership of code and spreads knowledge across the team. It serves
as an informal review process as each line of code is looked at by more than one person.

Applications of Extreme Programming (XP): Some of the projects that are suitable to
develop using the XP model are given below:

 Small projects: XP model is very useful in small projects consisting of small teams as
the face-to-face meeting is easier to achieve.

 Projects involving new technology or Research projects: This type of project face
changing requirements rapidly and technical problems. So XP model is used to
complete this type of project.

UNIFIED PROCESS MODEL:

Unified process (UP) is an architecture centric, use case driven, iterative and incremental
development process. UP is also referred to as the unified software development process.
The Unified Process is an attempt to draw on the best features and characteristics of
traditional software process models, but characterize them in a way that implements many of
the best principles of agile software development.

Agile Unified Process (AUP) is a simplified version of the Rational Unified Process
(RUP) developed by Scott Ambler. It describes a simple, easy to understand approach to
developing business application software using agile techniques and concepts yet still
remaining true to the RUP.

Phases of the Unified Process

This process divides the development process into five phases:

• • Inception

• • Elaboration

• • Conception

• • Transition

• • Production

The inception phase of the UP encompasses both customer communication and planning
activities. By collaborating with stakeholders, business requirements for the software are
identified; a rough architecture for the system is proposed; and a plan for the iterative,
incremental nature of the ensuing project is developed.
The elaboration phase encompasses the communication and modeling activities of the generic
process model.

Elaboration refines and expands the preliminary use cases that were developed as part of the
inception phase and expands the architectural representation to include five different views of
the software the use case model, the requirements model, the design model, the
implementation model, and the deployment model.

Elaboration creates an “executable architectural baseline” that represents a “first cut”

executable system.

The construction phase of the UP is identical to the construction activity defined for the
generic software process. Using the architectural model as input, the construction phase
develops or acquires the software components that will make each use case operational for
end users.

To accomplish this, requirements and design models that were started during the elaboration
phase are completed to reflect the final version of the software increment. All necessary and
required features and functions for the software increment (the release) are then implemented
in source code.

The transition phase of the UP encompasses the latter stages of the generic construction
activity and the first part of the generic deployment (delivery and feedback) activity.

Software is given to end users for beta testing and user feedback reports both defects and
necessary changes. At the conclusion of the transition phase, the software increment becomes
a usable software release.

The production phase of the UP coincides with the deployment activity of the generic
process. During this phase, the ongoing use of the software is monitored, support for the
operating environment (infrastructure) is provided, and defect reports and requests for
changes are submitted and evaluated.

It is likely that at the same time the construction, transition, and production phases are being
conducted, work may have already begun on the next software increment. This means that the
five UP phases do not occur in a sequence, but rather with staggered concurrency.

EARNED VALUE (EV)

Earned value (EV) measurement and techniques, as methods for project management
monitoring, reporting, forecasting, and controlling have been developed and adopted over the
past few decades in software product development as well as traditional engineering projects.
The methods, relying largely on baselined task-driven plans with fixed and well-defined
scope, assume linear progression on task execution and completion that pave the way to the
devising of schedule and cost performance indices that can be used for forecasting and
making decisions on project controls.
 UNIT – IV
AGILE TECHNOLOGY AND METHODOLOGY

CONCEPTS OF AGILE MANAGEMENT

AGILE PRINCIPLES

What are the Agile Principles?

There are 12 agile principles outlined in The Agile Manifesto in addition to the 4 agile
values. These 12 principles for agile software development help establish the tenets of the
agile mindset. They are not a set of rules for practicing agile, but a handful of principles to
help instill agile thinking.

The 12 agile principles and describe how they may be practiced.

Agile Principle 1

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

The best ways to ensure you make customers happy while continuously delivering valuable
software are to ship early, iterate frequently, and listen to your market continually.

Unlike traditional approaches to product development, which have notoriously long

development cycles, agile principles encourage minimizing the time between ideation and
launch. The idea is to get a working product in the hands of customers as soon as possible.

Doing this successfully means product managers are able to quickly get a minimum viable
product (MVP) out and into the world and use it to get feedback from real customers. This
feedback is then fed back into the product development process and used to inform future
releases.

How it looks in practice:

 Product teams use minimum viable products and rapid experimentation to test
hypothesis and validate ideas.
 Frequent releases help fuel a continuous feedback cycle between customer and
product.
 Shipped and done is not the same thing. Instead of releasing a “finished” product,
iterations continue to make incremental improvements to product based on customer
and market feedback.

Agile Principle 2

“Welcome changing requirements, even late in development. Agile processes harness change
for the customer’s competitive advantage.”

In the world around us, change is the only constant. Agile principles and values support
responding to these changes rather than moving forward in spite of them. Previous
approaches to product development were often change adverse; detailed, well-documented
plans were made before development began and were set in stone regardless of new findings.
Agile principles support observing changing markets, customer needs, and competitive
threats and changing course when necessary.

How it looks in practice:

 Product teams are guided by high-level strategic goals and perhaps

even themes below those goals. The product department’s success is measured against
progress toward those strategic goals rather than by delivery of a predefined feature
set.
 Product constantly has its ear to the ground monitoring the market, customer
feedback, and other factors which could influence product direction. When actionable
insight is uncovered, plans are adjusted to better serve customer and business needs.
 Product strategy and tactical plans are reviewed, adjusted, and shared on a regular
cadence to reflect changes and new findings. As such, product needs to manage the
expectations of executive stakeholders appropriately and ensure they understand
the why behind changes.
Agile Principle 3
“Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.”

Agile philosophy favors breaking a product’s development into smaller components and
“shipping” those components frequently. Using an agile approach, therefore — and building
in more frequent mini-releases of your product— can speed the product’s overall
development.

This agile approach, with short-term development cycles of smaller portions of the product,
results in less time spent drafting and poring over the large amounts of documentation that
characterizes Waterfall product development.

More importantly, this frequent-release approach creates more opportunities for you and your
teams to validate your product ideas and strategies from the qualified constituencies who see
each new release.

How it looks in practice:

 Agile development cycles, often called “sprints” or “iterations” break down product
initiatives into smaller chunks that can be completed in a set timeframe. Often this
timeframe is between 2 and 4 weeks which truly is a sprint if you consider the
marathon-like development cycles waterfall teams often follow.
 Another popular alternative to agile sprints is continuous deployment. This method of
shipping software frequently works less in terms of predetermined time boxes and
more in terms of simply deciding what to do and doing it.
Agile Principle 4
“Business people and developers must work together daily throughout the project.”
Communication is a critical component of any project or team’s success, and agile principles
essentially mandate that it’s a daily event. It takes a village to raise a child they say, and that
applies to product as well.
A successful product requires insight from the business and technical sides of an organization
which can only happen if these two teams work together consistently. Regular
communication between business people and developers helps improve alignment across the
organization by building trust and transparency.

How it looks in practice:

 Cross-functional agile product development teams include product people. This

means that product is represented on the development team and bridges the gap
between technical and business aspects of the product.
 Daily update meetings, or standups, are one technique many agile shops use to put
this principle in practice and keep everyone connected.

Agile Principle 5

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

A key part of the agile philosophy is empowering individuals and teams through trust and
autonomy.

The agile team needs to be carefully built to include the right people and skill sets to get the
job done, and responsibilities need to be clearly defined before the beginning of a project.
Once the work has begun, however, there’s no place in agile for micromanagement or hand
holding.

How it looks in practice:

 Product must clearly ensure engineering understands strategy and requirements before
development starts. This means not only sharing user stories with the cross-functional
team but also the bigger picture outlined in the product roadmap.
 Product is not responsible for explaining “how” something should be built. They need
to share what and why, but it’s the delivery team’s job to determine the how.
Furthermore, during sprints product does not micromanage outcome, instead they
make themselves available to answer questions and provide support as needed.

Agile Principle 6

“The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.”

With so many distributed or remote development teams these days, this principle gets a bit of
critique. But at the root of it, effective communication with developers means getting these
conversations out of Slack and email and favoring more human interaction (even if done by
video conference calls). The overall objective behind this principle is to encourage product
people and developers to truly communicate in real time about the product, requirements, and
the high-level strategy driving those things.
How it looks in practice:
 Daily standup meetings
 Collaborative backlog grooming sessions
 Sprint planning meetings
 Frequent demos
 Pair-programming

Agile Principle 7

“Working software is the primary measure of progress.”

Proponents of the agile philosophy are quick to remind us that we’re in the business of
building software, and that’s where our time should be spent. Perfect, detailed documentation
is secondary to working software. This mentality pushes to get products to the market quickly
rather than let documentation or an “it’s not done until it’s perfect” mentality become a
bottleneck. The ultimate measure for success is a working product that customers love.

How it looks in practice:

 Designing and releasing “Minimum Viable Features” rather than fully-developed
feature sets means thinking first and foremost about the smallest things we can ship to
start getting customer feedback and validate as we continue to build software.
 A fail fast mentality means moving forward even in times of uncertainty and testing
ideas rapidly.
 Ship software often: a useful product now is better than a perfect one later.

Agile Principle 8

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

Keeping up with a demanding, rapid release schedule can be taxing on a team. Especially if
expectations are set too high. Agile principles encourage us to be mindful of this and set
realistic, clear expectations. The idea is to keep morale high and improve work-life balance to
prevent burnout and turnover among members of cross functional teams.

How it looks in practice:

 Before every sprint, careful consideration of the amount of work that can be
committed to is made. Development teams don’t over promise on what they can and
cannot deliver. Effort estimations are a common practice in setting output
expectations for development teams.
 Everyone agrees on what will get done during a sprint. Once a sprint has begun, no
additional tasks are to be added except in rare cases.
 Product managers should act as gatekeepers to reduce the noise from other
stakeholders and to avoid squeezing in additional unplanned work during an ongoing
sprint.
 Product people should do their part in promoting a sense of psychological safety
across the cross-functional team that encourages open communication and freely
flowing feedback.

Agile Principle 9
“Continuous attention to technical excellence and good design enhances agility.”

While the agile philosophy encourages shorter cycles and frequent releases, it also puts
emphasis on the importance of keeping things neat and tidy so they don’t cause problems in
the future. Product managers often forget about this aspect of development because they
mostly don’t spend their days wading through their products’ codebases, but it is still of the
utmost importance to them.

How it looks in practice:

 The team needs to be cognizant of technical debt and the technical debt implications
of any new features or initiatives added to the backlog. Developers and product need
to work together to understand if and when technical debt is acceptable.
 On a regular basis, product will need to allocate development resources to refactoring
efforts. Refactoring cannot be an afterthought, it needs to be an ongoing
consideration.

Agile Principle 10

“Simplicity—the art of maximizing the amount of work not done—is essential.”

You’ve probably heard of the 80/20 rule—the concept that you can usually get 80% of your
intended results with just 20% of the work. Agile principles encourage thinking this way;
doing the things that can have the most impact. In a product management context this means
having a laser sharp focus on organizational objectives and making some
cutthroat prioritization decisions. Agile principles discourage building merely for the sake of
building by emphasizing the importance of being strategic and building with purpose.

How it looks in practice:

 Product managers need to make very focused product decisions and closely align
product strategy with organizational goals while being extremely picky about what
user stories and features actually make the cut. Using prioritization techniques to
prioritize initiatives by effort and predicted impact is one way product teams can
apply this agile principle to product development.
 The short sprints that agile is characterized by present many opportunities for rapid
testing and experimentation which can help reduce uncertainty around whether
initiatives will truly have the predicted impact. Using experiments to validate ideas
before building them up to spec is a great way to weed out bad ideas and identify
good ones.

Agile Principle 11

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

In traditional software development methodologies, you’ll often see pyramid shaped teams
where management makes key decisions for contributors. Agile principles suggest the use of
self-organizing teams which work with a more “flat” management style where decisions are
made as a group rather than by a singular manager or management team. The concept ties
into agile’s value of teams and interactions over processes and tools, and the intent behind the
concept is to empower teams to work together as they need to.
How it looks in practice:
 Self-organizing teams are autonomous groups within the organization who take
control and responsibility over their respective projects and have ownership of those
areas. Different organizations practice this principle differently. Spotify, for example
uses “product squads” to practice this.

Agile Principle 12

“At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.”
If you’re truly living by agile principles, there is no place for “we can’t change because
we’ve always done it this way.” Just like we’re always learning new things about our
customers and markets, we’re also learning from the processes we’re using to learn those
things. Agile is not about following a strictly-defined process for every sprint and release, it’s
about continuous improvement. And that continuous improvement must also extend to
processes and teams.

How it looks in practice:

 Experimentation and testing is not limited to the product only. Agile teams are
encouraged to experiment with their processes. You may think you’re already doing
something well only to experiment with a revised version of the process and discover
an even more effective method. Experimenting with your process and team is just as
important as experimenting with the software you’re building.
 Regular retrospectives are opportunities for the team to discuss what went well, what
didn’t go so well, and where the process can be tweaked to improve things in the
future. They’re an excellent place for product managers and product owners to learn if
they are communicating effectively with developers and giving them the support they
need before, during, and after sprints.
 Another consideration to make regarding this agile principle is that in order to
practice it effectively you need to create a culture of trust and transparency that
encourages openness and frequent sharing of feedback.

AGILE SOFTWARE MODEL

The meaning of Agile is swift or versatile."Agile process model" refers to a software

development approach based on iterative development. Agile methods break tasks into
smaller iterations, or parts do not directly involve long term planning. The project scope and
requirements are laid down at the beginning of the development process. Plans regarding the
number of iterations, the duration and the scope of each iteration are clearly defined in
advance.

Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks. The division of the entire project into smaller parts
helps to minimize the project risk and to reduce the overall project delivery time
requirements. Each iteration involves a team working through a full software development
life cycle including planning, requirements analysis, design, coding, and testing before a
working product is demonstrated to the client.
Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

1. Requirements gathering: In this phase, you must define the requirements. You should
explain business opportunities and plan the time and effort needed to build the project. Based
on this information, you can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project, work with stakeholders
to define requirements. You can use the user flow diagram or the high-level UML diagram to
show the work of new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a working
product. The product will undergo various stages of improvement, so it includes simple,
minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's performance
and looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's work environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.

Agile Testing Methods:

o Scrum
o Crystal
o Dynamic Software Development Method(DSDM)
o Feature Driven Development(FDD)
o Lean Software Development
o eXtremeProgramming(XP)

Scrum

SCRUM is an agile development process focused primarily on ways to manage tasks in team-
based development conditions.

There are three roles in it, and their responsibilities are:

o Scrum Master: The scrum can set up the master team, arrange the meeting and
remove obstacles for the process
o Product owner: The product owner makes the product backlog, prioritizes the delay
and is responsible for the distribution of functionality on each repetition.
o Scrum Team: The team manages its work and organizes the work to complete the
sprint or cycle.

eXtremeProgramming(XP)

This type of methodology is used when customers are constantly changing demands or
requirements, or when they are not sure about the system's performance.
Crystal:

There are three concepts of this method-

1. Chartering: Multi activities are involved in this phase such as making a development
team, performing feasibility analysis, developing plans, etc.
2. Cyclic delivery: under this, two more cycles consist, these are:
A.Team updates the release plan.
B.Integrated product delivers to the users.
3. Wrap up: According to the user environment, this phase performs deployment, post-
deployment.
Dynamic Software Development Method(DSDM):

DSDM is a rapid application development strategy for software development and gives an
agile project distribution structure. The essential features of DSDM are that users must be
actively connected, and teams have been given the right to make decisions. The techniques
used in DSDM are:
1. Time Boxing
2. MoSCoW Rules
3. Prototyping

The DSDM project contains seven stages:

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 focuses on "Designing and Building" features. In contrast to other smart
methods, FDD describes the small steps of the work that should be obtained separately per
function.
Lean Software Development:
Lean software development methodology follows the principle "just in time production." The
lean method indicates the increasing speed of software development and reducing costs. Lean
development can be summarized in seven phases.

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

When to use the Agile Model?

o When frequent changes are required.
o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
 o When project size is small.

Advantage(Pros) of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.

Disadvantages(Cons) of Agile Model:

1. Due to the shortage of formal documents, it creates confusion and crucial decisions
taken throughout various phases can be misinterpreted at any time by different team
members.
2. Due to the lack of proper documentation, once the project completes and the
developers allotted to another project, maintenance of the finished project can become
a difficulty.

CLASSIFICATION OF METHOD

There are various types of agile methodology available in the market to suit every
project’s wants. Although there are different agile methodologies, everything is based on
the main principles in the agile manifesto.

Therefore, every framework or behavior that adapts these principles is named Agile, and,
notwithstanding the different types of agile methodologies a team implements, the agile
methodology benefits can be copiously apprehended only with the collaboration of all the
involved parties.

The below agile methodologies list comprises of famous types of agile methodology that
one can opt from:

1) Kanban

Originating from the Japanese language, the translation of the word ‘Kanban’ is “visual
board or signboard” and is connected to the concept of “just in time”! Initially, the
Kanban concept was introduced as a lean manufacturing system and slowly drove its way
to agile software development teams. This method uses visual methods for developing
and managing projects.

Projects through Kanban are overseen with the help of the Kanban Board, which is
divided into columns to depict the process flow of the software development. This helps
in increasing visibility teams as the teams can see the progress through every stage of
development and prepare for the upcoming tasks to deliver the product “just in time”!
This method requires thorough interaction and transparency to enable the team members
to be equipped with the right stage of the development at any time and have a cohesive
flow of work at all times.

2) Scrum

One of the most popular agile methodology examples is the agile scrum development
methodology, which is depicted by various cycles of development. Similar to Kanban,
Scrum breaks down the development phases into stages or cycles called ‘sprints’. The
development time for each sprint is maximized and dedicated, thereby managing only one
sprint at a time.

Scrum and agile methodologies focus on continuous deliverables, and thus this method
lets designers adjust priorities to ensure that any incomplete or overdue sprints get more
attention.

Scrum Team has exclusive project roles such as a scrum master and a product owner with
constant communications on the daily scrum where the activities are harmonized to
devise the best way to implement the sprint.

3) Extreme Programming (XP)

Extreme Programming (XP) is a methodology that emphasizes teamwork,

communication, and feedback.

It focuses on constant development and customer satisfaction. Similar to scrum, this

method also uses sprints or short development cycles. This is developed by a team to
create a productive and highly efficient environment.

Extreme Programming technique is very supportive in a situation of constant and varying

demands from the customers. It motivates the developers to accept changes in the
customer’s demands, even if they pop-up in an advanced phase of the development
process.

In Extreme Programming, the project is tested from the initial stages by collecting
feedback that progresses the output of the system. This also presents a spot check to
implement easily any customer requirements.
4) Crystal

Introduced by Mr. Alistair Cockburn, one of the monumental persons in formulating the
Agile manifesto for software development, Crystal is a group of smaller agile
development methodologies comprising of Crystal Yellow, Crystal Clear, Crystal Red,
Crystal Orange, and more.

Each has its peculiar and exclusive framework that is characterized by factors such as
system criticality, team size, and project priorities. Depending on the nature of the project
or system criticality such as Comfort (C), Essential Money (E), Discretionary Money (D),
and Life (L), the kind of crystal agile methodology is chosen.
 Similar to other methodologies of Agile, Crystal also addresses prompt delivery of
software, regularity, less administration with high involvement of users, and customer
satisfaction. The Crystal family advocates that each system or project is inimitable and
necessitates the solicitation of diverse practices, processes, and policies to achieve the
best results, earning the name of the most lightweight methods of agile methodology.

5) Dynamic Systems Development Method (DSDM)

To address the need for a standard industry charter for the swift delivery of software, the
Dynamic Systems Development Method (DSDM) was developed.

DSDM gives a comprehensive structure that is defined and modified to create a plan,
execute, manage, and scale the procedure of software development. Based on a business-
driven approach and eight principles, the DSDM believes that modifications to the project
are always expected, and quality with timely delivery must never be negotiated.

AGILE PROJECT MANAGEMENT:

Agile project management is an interactive approach to manage software development. The

agile project management focuses on continuous releases and covers customer feedback with
every iteration. Traditionally the agile project management is classified into two
frameworks: scrum and kanban. The scrum framework
focused fixed-length project iterations, whereas kanban fram focused on continuous releases.
After competition of project first iteration (or steps) project management activity immediately
moves on to the next.
History of Agile Project Management
Agile project management is rapidly rising in the 21st century. It is used for software
development projects and other IT initiatives.
However, from the mid-20th century, the concept of continuous development has taken
various forms. For example, there was James Martin's Rapid Iterative Production
Prototyping (RIPP), an approach that served as the premise for the 1991 book Rapid
Application Development (RAD).
The agile project management framework which has emerged in most recent years is known
as Scrum. This methodology features works on the development team to create a product
backlog. It also creates a prioritized list of the features, functionalities, and fixes required to
deliver a successful software system. The scrum team offers the pieces of a task in rapid
increments.
How Agile Project Management works
The agile project management calls for teams to regularly evaluate cost and time as they
move through their work. They use velocity, burnup and burndown charts to measure their
work, rather than Gantt charts and project milestones to track progress.
The agile team practices to continuous development and continuous integration using
technology that automates steps to speed up the release and use of products.
The presence and participation of the project manager are not required in agile project
management.
The role of the project manager is to distribute task among team members. However, the
project manager is not obsolete in agile project management, and many organizations use
them in a large, more complex project. The organization mostly places them in the project
coordinator role.
Agile Project Management demands that team members know how to work in this new agile
methodology. The team member must be able to coordinate with each other, as well as with
users.
Agile project management is an iterative approach to managing software development projects that
focuses on continuous releases and incorporating customer feedback with every iteration.
The Agile project management (APM) framework is an iterative and cohesive method of effective
project management during the entire lifecycle of the project. It successfully integrates the
traditional aspects of project management with modern requirements within the scope of the
project.
Benefits of Agile Project Management
Here are some of the benefits of Agile project management and why organizations adopt it for
managing their projects:

Improved customer satisfaction:The agile process includes the customers in the loop and changes
are made adhering to their feedback. Doing so provides value to the customer. The product backlog
needs to be updated to respond to the changes quickly. Demonstrating the working features and
functionalities to the customer at every sprint will make them come back to you more often.

Improved performance visibility:Every team member can know about the progress of the project at
any stage. Conducting daily scrum meetings, progress charts, and sprint reviews will help to check
the performance.

Improved team morale:The members of the Agile project team are self-managing and self-
organized. Scrum master removes any sort of hindrances to the team from external interferences.
On the other hand, cross-functional nature allows the team to learn skills and rise in their career.

Improved project predictability:Improved project visibility leads to easy mitigation plans and risk
predictability. Agile provides various ways to predict risks and strategies for efficient project
completion. Task boards, scrum meetings, and burndown charts help to predict the project’s
performance.

Reduced Risk:None of the Agile projects fail with having a working product from the initial sprint.
Providing regular feedback, regular communication with the development team, product release,
sprint review, and retrospective meeting ensures that the end user can look at the new features and
ask for changes required. This process leads to reduced risks in the process.

Improved product quality:Agile is an iterative process, and the team keeps themselves updated with
the latest skills and continuous improvement. Testing is an integral part of the execution phase;
thus, overall product quality is greater. Client can get involved in the development process and can
demand for changes based on their requirement.

Added relevant metrics:Agile process emphasizes producing desired results and optimizing
performance. A few of the metrics used in Agile are cycle time and lead time used for estimating cost
and time, it helps to keep track of the team’s performance more accurately, identify the issues and
take necessary decisions to overcome the hindrances.

Now that you are aware of Agile Project management’s benefits, let’s understand who are all the
people involved in the process.

Components of Agile Project Management

Here are a few components of Agile Project Management:

User Stories:User story encompasses information about the entire project, which would help the
team raise a reasonable estimate to attain desired project goals. The user story is mainly written
from the user’s perspective.

Sprints: Sprints are nothing but short iterations, which usually take 1-3 weeks to accomplish the
meeting’s determined task. The tasks should be equally segregated amongst the team members to
complete the task during each sprint successfully. Sprints should be continuously repeated until all
the essential features of the product are ready. On completion of the sprint, you can review what is
working and what not in your product and make necessary adjustments accordingly before moving
on to the next.

Agile board:The main purpose of using the Agile board is to track the progress of the project. Some
of the examples for Agile board include sticky notes, project management software, or just a Kanban
board.

Product backlog:The sprint planning process involves the stories in the backlog to be moved to the
sprint before the completion of each iteration. Thus, handling product backlog is essential for project
managers.

Stand-up meeting:Stand-up meeting or daily scrum meeting is a way to know that every team
member stays on track. The meeting is usually held for about 10-15 minutes and to the point.

The five phases of the Agile project management

1.Envision:This is the first phase of the APM Framework and corresponds with the Initiation phase of
PMBOK. In this phase, a product is conceptualized and all the project stakeholders are identified. The
possible objectives of the project and the identification of the customer’s needs are also a part of
this phase.

2. Speculate:This is similar to the planning phase of the PMBOK’s version. It deals with creating a
features list of the final product and how the team would work to achieve it.

The speculation phase normally revolves around two key activities:

‘Breaking down’ the project into a series of high-level milestones and deciding the expected project
timeline.Coming up with the initial understanding of the critical tasks of the project. Priority to a
certain class of tasks is given over others in this phase and the team members decide on the way to
maintain the quality of the final project deliverable.

3. Explore:This phase is parallel to the project execution phase and team members explore the
various alternatives to fulfill all the requirements of the project while staying within the given
constraints. The main focus is on creating value and maintaining the quality of the final deliverable.

Similar to almost all Agile methodologies, teams work by focusing on a single milestone and iterate
until perfection is achieved. This phase works parallelly with the Adapt phase because teams may
have to change their plan and execution-style if a customer demands it or if the feedback is not as
expected.

4. Adapt:This is perhaps the most distinguishing phase of this framework. The ability to adapt to
different circumstances allows the team to be prepared for anything that gets thrown towards them.

By constantly taking feedback from customers and ensuring that each aspect of the project is up to
the end user’s requirements, teams can significantly increase their efficiency and effectiveness.

5. Close:This is the final phase. Teams ensure that the project gets completed in an orderly manner
without any hitch. The final deliverable is checked against the updated requirements of the
customers and teams ponder over their mistakes in order to avoid them in the future.

AGILE ETHICS:
Two of the most popular agile approaches, Extreme Programming (XP) and Scrum, advocate
specific values.
(Again, this is not to say that other software development approaches do not have values—
just that XP and Scrum explicitly spell them out.)
Ken Schwaber identified the following five Scrum values in his book Agile Software
Development with Scrum: commitment, focus, openness, respect, and courage.
Kent Beck identified these five XP values in his book Extreme Programming Explained:
communication, simplicity, feedback, courage, and respect.
While many trainers focus on the practices to get new agile teams up and running, it is the
values that will keep the team truly agile long after
the trainers and coaches leave.
Commitment: It's not enough to be assigned to a team and agree to try this new agile thing,
and it's not enough simply to be dedicated.
One must also be committed to doing whatever is necessary to meet the goals outlined and to
take the authority to do so to heart.
It means "to carry into action deliberately" (Merriam-Webster) or, as Yoda says, "Do, or do
not. There is no try."

Focus: Don't get sidetracked. Remember what you committed to do, and focus your energies
on fulfilling that promise.
Distractions are not limited to the obvious things like email and unrelated meetings. They
may also be things like creating
Documentation because "we've always done it that way" instead of creating documentation
because it truly provides the customer with something of value.

Openness: Openness is about keeping the project status highly visible to everyone all the
time. Anyone who is interested should be able to look at a wall, a wiki page, or a dashboard
in an agile project management tool and see how many features have been completed, what's
currently being worked on, and the goals of the iteration and release.
Communication: People on the team must talk to each other. This gets harder to do the more
geographically Separated the team is, but with tools like Skype, teams can talk to one another
easily and cheaply. The point is that team members must not rely on email and
documentation alone. Verbal communication is required to clarify ideas, solve complex
problems, answer questions quickly, and help team members coordinate work efforts.

Simplicity: Beck says the XP coach should ask the team, "What is the simplest thing that
could possibly work?" Then they should do that thing.
Because agile approaches develop code in increments each iteration, the thought is that it is
better to develop something simple that may have to be expanded later if needed, rather than
spend a large amount of time now developing a solution that's more complicated and may, in
fact, not be necessary.

Feedback: As stated earlier, our number one obligation is to provide value to the customer.
In order to do that, we must obtain frequent feedback from the customer or customer
representative in order to make sure that the product we are building is meeting their
expectations. And if it is not, we have the information we need now in order to make
corrections. Beck extends this meaning of feedback to include feedback from the system
itself in the form of unit, functional, and performance tests run frequently in each iteration.
Courage: In order to accept the authority and accountability for the delivery of the product,
the team members all need courage. From the courage to make decisions to the courage to
say no, this is a foundational value that gives rise to all the others.

Respect: Each team member must begin by agreeing that everyone deserves to be treated
with respect. Many teams clarify this with working agreements that outline ways in which
they choose to work together. And, as a result of working together to adhere to all the other
values outlined here, team members grow to respect one another beyond their shared
humanity to the ways each valued colleague contributes to the whole.

AGILE IN DESIGN,TESTING,DOCUMENTATION

AGILE in DESIGN

Design plays a vital role in any software development process. The agile team also focuses on
"what to do about design" because of the following four factors:
o Many crucial factors focus on loyal designs during the planning process. Design
forces towards waterfall culture throughout product implementation.
o Designers also interact with a cross team for a limited time.
o Designers don't always have an easy way to report feedback to the engineering team.
o The presentation and logic layers are not still transparent. They are not separated
clearly in the code base, making style changes difficult.

The product design process and customer interview

The agile is divided into several methodologies and processes. These methodologies and
processes keep the iterative and free-flowing nature of the technique at their core. The agile
design and development methodology used especially in engineering development, and this
process called Scrum.
Customer interviews can be an informative part of the project design phase. We will have
several of those "light bulb" movements during interviews. It encourages the people who are
interviewing with other members of the team (engineering, marketing, design, etc.)
There are several resources that are available on which we conduct an interview- the
logistics, methods, and techniques.
The customer interview pyramid:
Atlassian is a simple framework that helps in building the customer interview pyramid. This
pyramid looks like as
Communication Observation: At the bottom of the pyramid, we will get the very minimum.
We should all come back from an interview and be able to list observations as we don't need
any experience to regulate what you've seen.
Interpret problems: Above the Communication Observation, it is an interpret problem. It is
explaining the user's behavior and grouping them with an over-arching problem statement.
Connecting opportunities: This is the peak of the pyramid where the most value comes in
combining the problem with potential opportunities or related patterns. This helps influence a
roadmap and make decisions about what to tackle next.

AGILE TESTING

The Software Testing process contains several testing procedures and techniques that
simplify the testing process and increase its efficiency.

In this tutorial, we are going to understand the following topic related to specified testing
known as Agile Testing, which helps us to enhance our knowledge of Agile Testing:

o Introduction to Agile Testing

o Principle of Agile Testing
o How is Agile Methodology used in Testing?
o Agile Testing Strategies
o Agile Testing Quadrants
o Agile Testing Life Cycle
 o What are the different challenges we faced during the agile Testing?
o Advantages of Agile Testing
o Disadvantages of Agile Testing

Introduction to Agile Testing

Here, we are discussing another essential software testing technique, which is known as Agile
Testing.

Agile testing follows the standards of agile software development.

Agile testing is an iterative and incremental method, and the necessities, which develop
during the cooperation between the customer and self-establish team

In agile testing, the word "Agile" primarily signifies something that can be performed quickly
and immediately, but also in the area of software development.

The core-functional agile team implements it in order to test the software product and its
several modules. The implementation of agile testing makes sure to deliver a high quality
product as bugs or defects get deleted in the initial stage of the project itself.

Unlike the Waterfall model, Agile Testing can create at the beginning of the project with
endless incorporation between development and testing. It is not a sequential but the
continuous process.

The agile testing process is a smart way of testing complicated software, which accepts more
effective results as compared to the traditional testing procedures.

In the modern days of software testing, agile testing has gained a lot of acceptance and
significance. The execution of agile testing will help us identify the initial error and
elimination, giving better results in less development time and costs.

Principles of Agile Testing

Agile Testing includes various different principles that help us to increase the productivity of
our software.

1. Constant response
2. Less documentation
3. Continuous Testing
4. Customer Satisfaction
5. Easy and clean code
6. Involvement of the entire team
7. Test-Driven
8. Quick feedback

For our better understanding, let's see them one by one in detail:

1. Constant Response

The implementation of Agile testing delivers a response or feedback on an ongoing basis.

Therefore, our product can meet the business needs.
In other words, we can say that the Product and business requirements are understood
throughout the constant response.

2. Less Documentation
The execution of agile testing requires less documentation as the Agile teams or all the test
engineers use a reusable specification or a checklist. And the tea
m emphases the test rather than the secondary information.

3. Continuous Testing
The agile test engineers execute the testing endlessly as this is the only technique to make
sure that the constant improvement of the product.

4. Customer Satisfaction
In any project delivery, customer satisfaction is important as the customers are exposed to
their product throughout the development process.
As the development phase progresses, the customer can easily modify and update
requirements. And the tests can also be changed as per the updated requirements.

5. Easy and clean code

When the bugs or defects occurred by the agile team or the testing team are fixed in a similar
iteration, which leads us to get the easy and clean code.

6. Involvement of the entire team

As we know that, the testing team is the only team who is responsible for a testing process in
the Software Development Life Cycle. But on the other hand, in agile testing, the business
analysts (BA) and the developers can also test the application or the software.

7. Test-Driven
While doing the agile testing, we need to execute the testing process during the
implementation that helps us to decrease the development time. However, the testing is
implemented after implementation or when the software is developed in the traditional
process.

8. Quick response
In each iteration of agile testing, the business team is involved. Therefore, we can get
continuous feedback that helps us to reduces the time of feedback response on development
work.

How is Agile Methodology used in Testing?

Agile Testing is a fast and informal testing process. In simple terms, we can say that it is
specified as an advanced and dynamic type of Testing that is performed regularly
throughout every iteration of the SDLC (Software Development Life Cycle) by the agile
test engineers.

If we deliver the software quickly with the best of the attributes, and the customer satisfaction
is the primary concern at some stage in the agile testing process.

Agile Testing Methodologies

When we are executing the agile testing, the team takes help from several agile
methodologies, which support them in accomplishing the precise results.
Some of the effective agile testing methodologies are as follows:
o Test-Driven Development (TDD)
o Behavior Driven Development (BDD)
 o Exploratory Testing
o Acceptance Test-Driven Development (ATDD)
o Extreme Programming (XP)
o Session-Based Testing
o Dynamic Software Development Method (DSDM)
o Crystal Methodologies

Test-Driven Development (TDD)

The test-driven development method begins with the test itself. As the name proposes, the
TDD varies upon the repetition of the development cycle.

We already knew that the first step in of development cycle is to create a unit test case. And
in the next step, we will be designing the code that fits the test case in order to execute the
test cases.

Hence, the whole code is designed until the unit test passes. Generally, the test-driven
development is executed by using the automated testing tools and implement on units and
components of the code.

Behavior-Driven Development (BDD)

The following method in agile testing is behavior-driven development. The BDD enhances
the communication between the project stakeholders to facilitate the members adequately and
understood all the components before the development process begins.

It is constructed on the same rules as TDD and ATDD. Therefore, the code is developed as
per the test case designed in this testing methodology too.

The primary purpose of this development is to emphasize the identification of business needs
and outputs. And the development should be consistent to a business output.

In behavior-driven development, we need to follow the below steps:

1. Describe the behavior.

2. Generating the test case.
3. Writing code as per the test case is specified.
 4. Continuing the process until the code passes the test case.

Exploratory Testing

In Software testing, exploratory testing is one particular type where the test engineers have
the fundamental freedom to explore the code and create the most effective software.

In simple words, we can say that if we don't have the requirement, then we do one round of
exploratory testing.

Exploratory testing is a very significant part of the agile test as it helps discover the unknown
risks from the software that a simple testing approach could not have noticed.

To explore each aspect of the software functionality, the test engineer creates various test
cases, executes different tests, and records the process to learn it and understand its particular
flow.

While performing the exploratory testing, we need to follow the below steps:

o Exploring the application in all possible ways

o Understanding the flow of the application

o Preparing a test document
o Testing the application

Acceptance Test-Driven Development (ATDD)

Another methodology of agile testing is Acceptance Test-Driven Development

(ATDD). The ATDD approach emphasizes the customer's requirements by involving the
team members with different viewpoints.

The team's members of development, testing, and the customers come together in order to
develop the acceptance test from the customer's perspective.
In Acceptance Test Driven Development, the code is acquired along with the developed
acceptance test case.

It is a very customer-centered methodology; the primary objective of using the ATDD

methodology is to develop a program based on the user's view.
Extreme Programming (XP)

The next significant agile methodology is Extreme Programming which is denoted

as XP. When there is a continuous modification in the user requirements, we will go for the
extreme programming methodology.

Just like other agile testing methodologies, Extreme Programming is also a customer-
centric methodology.
The XP will help us deliver a quality product, which meets the customer's requirements that
are made clear throughout the process of development and testing.

Session-Based Testing

In the row of various agile testing methodologies, the next methodology is Session-based
testing. It is mainly is created on the values of exploratory testing.

Though session-based testing contains some structure and on the other hand, exploratory
testing is performed unexpectedly without any planning. It is used to help us identify the
hidden bugs and defects in the particular software.

The session-based testing structure is prepared by executing the tests in continuous sessions
where test engineers must report the tests, which took place throughout the process.

Dynamic Software Development Method (DSDM)

Another effective method of agile testing is Dynamic Software Development Method. It is

a Rapid Application Development (RAD) approach that offers a delivery framework to
agile projects.

In other words, we can say that the Dynamic Systems Development technique (DSDM) is a
correlate degree agile code development approach, which gives a framework for developing
and maintaining systems.

The Dynamic Software Development Method can be used by users, development, and
testing teams.

Crystal Methodologies

The subsequent agile testing is crystal methodologies. This methodology mainly emphasizes
recording, cyclic delivery, and wrap-up, which is to make sure during the various analyses.

Agile Testing Quadrants

It has different quadrants to easily understand agile testing, which divides the whole testing
process into four parts.

In addition to the four quadrants, the left two specify the test engineer that code to write, and
the right two quadrants help them understand the code improved with the support of response
to the left quadrants.

These agile testing quadrants may be understood as a traditional process or strategies to

perform the end-to-end agile testing of a software application in four different stages, as we
can see in the following image:
Let us discuss them one by one to understand the process of agile testing:
1. Quadrant 1 (Automated)
2. Quadrant 2 (Automated and manual)
3. Quadrant 3 (Manual)
4. Quadrant 4 (Tools)

Quadrant 1 (Automated)

In the first quadrant of Agile testing, we will see mainly emphasis on the quality of the code.
We can say internal code quality, which contains the test cases and test components that is
executed by the test engineers.
And these test cases are technology-driven and used for automation testing in order to
enhance the code and support the testing team to perform their tasks.

All through the first quadrant of agile testing, we can execute the following testing:
o Unit Testing
o Component Testing

Quadrant 2 (Automated and manual)

In the second quadrant of Agile testing, we will see mainly emphasis on the customer
requirements given to the team before and throughout the testing procedures, which expands
the business results of the newly created software.
The test case involved in this second quadrant is business-driven, usually manual and
automated functional tests, prototypes, and examples of test scenarios performed by the
testing team.

In quadrant 2, we can execute the following tests:

o Testing scenarios which may occur and workflow
o Implementing the pair testing
o Testing the user story and experiences like prototypes.

Quadrant 3 (Manual)

The third quadrant of agile testing primarily emphasizes the response for the previous two
phases (Quadrant 1 and Quadrant 2).
The execution of agile testing involves many iterations. And in this quadrant, these reviews
and responses of the particular iterations are sustained that helps to strengthen the code.
To test the user experience and determine business results allows the testing team to learn as
the test develops.
The team, business owners, and even customers realistically use the product. In the third
quadrant, the test cases have been designed to implement automation testing, which helps us
develop certainty in the particular product.

In quadrant 3, below types of testing can be executed:

o Usability testing
o Collaborative testing
o Exploratory testing
o User acceptance testing
o Pair testing with customers

Quadrant 4 (Tools)

The last and fourth Quadrant of agile testing primarily emphasizes the product's non-
functional requirements, including compatibility, performance, security, and constancy.
In other words, we can say that the fourth Quadrant ensures that the code fulfils all the non-
functional requirements.
Like other Quadrants, various types of testing are performed in quadrant 4 to deliver the non-
functional qualities and the expected value.
o Non-functional testing such as Stress testing, performance testing, and load
testing, etc.
o Scalability testing
o Security Testing
o Data Migration Testing
o Infrastructure testing
Agile Test Plan

As compared to the waterfall model, the agile test plan is created and updated for every
release. Furthermore, the agile test plan contains those types of testing executed in a specific
iteration, such as test environments, test data requirements, test results, and infrastructure.
The agile test plans emphasize the following:
o Testing Scope: The testing scope specifies the sprint goals, test scope, and test
coverage in which the test will be implemented.
o Performance and Load Testing: Here, it specifies the different testing methods and
procedures.
o Types of testing or levels as per the feature's complexity: It defines those types of
testing or levels of testing which are going to be used. And also specifies the data and
configurations for the test and the environment in which the test will be executed.
o Mitigation or Risks Plan: It defines the backup plan prepared to overcome the risks
or issues. And it also identifies the challenges which might face at the time of testing
of the application in the current release.
o Deliverables and Milestones: It sets the deliverables and milestones of the tests as
per the customer's perspective.
o Infrastructure Consideration: It governs the infrastructure which is required to
perform the tests.
o Resourcing: It lists out the test tasks and the occurrence of tests, which defines how
many times the tests will be executed.
o Establish the New functionalities which are being tested.

Agile Testing Strategies

Agile testing has four different approaches, which help us to enhance our product quality.
1. Iteration 0
2. Construction iteration
3. Release End Game or Transition Phase
4. Production
Let us discuss them one by one in detail:
1. Iteration 0

The first strategy or approach of agile testing is iteration 0. In this, we execute the
preliminary setup tasks such as finding people for testing, establishing testing tools,
preparing resources or usability testing lab, etc.
In Iteration 0, the below steps are accomplished:
o Verifying a business case for the project and boundary situations, and the project
scope.
o Summarise the important requirements and use cases that will determine the strategic
trade-offs.
o Plan the initial project and cost valuation
o Detecting the risk.
o Outline one or more candidate designs

2. Construction Iteration

The next strategy of agile testing is Construction Iteration. During this approach, the
majority of the testing is performed.
The construction iteration is performed as a set of iterations in order to create an increment of
the solution.
In simple words, we can say that the agile team follows the listed requirement within each
iteration where they can acquire the most significant business needs or requirements left
behind from the work item stack and then execute them.
The construction iteration process divided into the following two types of testing:
o Confirmatory Testing
o Investigative Testing
 1. Confirmatory Testing
To ensure that the product meets all the stakeholders' requirements, we will execute the
confirmatory testing.
Confirmatory testing can be further separated into another two types of testing, which are as
follows:
o Agile Acceptance Testing
o Developer Testing
Agile Acceptance Testing: It is a combination of functional testing and acceptance testing.
The agile acceptance testing can be executed by the development team and stakeholders
together.
Developer Testing: It is a combination of unit testing and integration testing. And it
validates both the application code as well as the database schema.
Note: We can automate both (agile acceptance testing and developer testing) to ensures
that continuous regression testing has occurred.
2. Investigative Testing
In order to test deep and identify all the issues, which are overlooked in confirmatory
testing, we will execute the investigative testing.

3. Release End Game or Transition Phase

The third approach of agile testing is release. The objective of this specific approach is to
implement our system effectively in production.
The test engineer will be working on its defect stories in the end game. In the release end
game or transition stage, we have the following activities:
o Support Individuals
o Training of end-users
o Operational People
Similarly, it involves some additional activities as well:
o Back-up and Restoration
o Marketing of the product release
o User documentation
o Completion of system
The last agile methodology testing stage encompasses whole system testing and acceptance
testing. To complete our final testing phase without having any difficulties, we should have to
test the product more thoroughly in construction iterations.

4. Production

The product will move on to the production stage as soon as the release stage is completed.
What are the different challenges we faced during the agile testing?
Generally, while performing agile testing, a testing team may face some challenges. Let see
those challenges all together for our better understanding:
o Last-minute modification
o Tools selection
o Lack of documentation
 o Repeated modifications in the code
o Limited test coverage

o Last-minute Modification
The most faced challenges during the agile testing are last-minute modifications by the client,
which gives significantly less time to the testing team to design the test plan, which may
affect the product quality. And sometimes, the test engineer is often required to play a semi-
developer role.
o Tools Selection
The selection of tools during agile testing is essential because if we select the wrong tool, it
will waste our time as well as money.
As we already knew, the Test execution cycles are highly reduced, and for the regression
testing, we will have minimal timing.
o Lack of Documentation
Another frequently faced challenge while executing agile testing is the lack of
documentation. The probabilities of error are more agile as documentation is given less
importance and ultimately puts more burden on the testing team.
o Repeated Modifications in the code
In an agile method, requirement modification and updation are fundamental, making it the
major challenge for the Quality assurance team.
o Limited Test Coverage
In agile testing, new features are initiated quickly, decreasing the available time for the
testing teams to find whether the latest features are as per the requirement and address the
business suits.
After seeing all the frequent challenges, the question arises how do we overcome them?
Therefore, in the below topic, we are going to discuss that:
How do we overcome Agile testing challenges?
Agile Testing life cycle

Just like other types of testing has their life cycle process, Agile Testing life cycle completed
into five different phases, as we can see in the following image:

Let understand all the phases in detail:

Phase1: Impact Assessment

The first phase of the Agile testing life cycle is Impact assessment. Here, we collect the
inputs and responses from users and stakeholders to execute the impact assessment phase.
This phase is also known as the feedback phase, which supports the test engineers to set the
purpose for the next life cycle.

Phase2: Agile Testing Planning

The second phase of the Agile testing life cycle is agile testing planning. In this phase, the
developers, test engineers, stakeholders, customers, and end-users team up to plan the testing
process schedules, regular meetings, and deliverables.

Phase3: Release Readiness

The next phase of the Agile testing life cycle is release readiness, where test engineers have
to review the features which have been created entirely and test if they are ready to go live or
not and which ones need to go back to the previous development phase.
Phase4: Daily Scrums

Daily scrums are the next phase of the Agile testing life cycle, which involves the daily
morning meetings to check on testing and determine the objectives for the day.
And, in order to help the test engineers to understand the status of testing, the goals and
targets of the day are set daily.

Phase5: Test Agility Review

The last and final phase of the Agile life cycle is the test agility review. The test agility
phase encompasses the weekly meetings with the stakeholders to evaluate and assess the
progress against goals.
In other words, we can say that the agility reviews are implemented regularly in the
development process to analyze the progress of the development.
Advantages of Agile Testing
For the past few years, Agile software testing has been a significant part of the IT field. Here,
we are discussing some essential benefits of Agile testing:
o Agile testing gives way to get regular feedback and reviews directly from the end-
user, which helps us enhance the software product's quality and attribute.
o The implementation of agile testing will save lots of time and money, making the
estimation of cost more transparent.
o Through daily meetings, we can determine better issues.
o Agile testing reduces documentation, or we can say it requires less documentation to
execute the agile testing.
o The most significant advantage of implementing Agile software testing is reducing
errors and enhancing software productivity.
o As we understood from the above discussion, the workload is divided into small parts
in agile software development and restricts the developer from going off the track.
And in the results, we will get more minor inconsistencies and higher efficiency.

Disadvantage of Agile Testing

Agile testing is a creative method to test the software application, but still, we have some
disadvantages of using Agile Testing:
o The most significant disadvantage of agile testing is that if two or more members
leave a job, it will lead to project failure.
o Determination is needed while performing any testing to test the application or the
software and becomes inconsistent for the testing team.
o It makes it difficult for us to predict expected results because there are no or fewer
documentation results into explicit conditions and requirements.
o Sometimes, it leads us to introduce new bugs in the system because the bug fixes,
modifications, and releases repeatedly happen in agile testing.
Agile testing is becoming very famous among significant software development
organizations as it a very customer-centric one that ensures a high-quality product.
AGILE DOCUMENTATION

Agile documentation is an approach to create concise documents that serve the situation at
hand. In traditional software development projects, there is comprehensive documentation
which is perceived as a risk reduction strategy. The documentation should be as efficient as
possible in a way it achieves relevant goals in agile software development projects.
 Work with executable specifications
 Document as late as possible
 Simply documentation
 Avoid overlapping documents
 Purpose oriented documents
 Ensure good communication
 UNIT – 5
AGILE KNOWLEDGE MANAGEMENT AND QUALITY ASSURANCE
AGILE KNOWLEDGE MANAGEMENT
Developing and integrating a meaningful KM strategy and sustainable knowledge transfer
capability faces many challenges, even in the most innovative and forward looking
organizations.
The complexity and operational tempo of today’s business environment requires a new, more
agile approach to transforming the behavior of knowledge workers and enabling higher levels
of individual and organization performance through knowledge and collaboration.
Agile in the Knowledge Managment (KM) context means rapid implementation and results,
being adaptive to culture, context, and the business environment, and focused on changing
knowledge sharing mindsets and behaviors.
In our Agile approach to KM, business strategy and operational requirements continuously
and iteratively inform and evolve KM efforts to deploy knowledge capabilities faster with
meaningful results.
Whether developing and then implanting new concepts, strategies, and implementing
practices, or focusing on existing KM strategies to renew or revitalize them, improved
performance and an appreciation of KM is integrated as part of the way work gets done.
Agility in sharing and transferring knowledge emerges as an iterative outcome of the
application of proven KM practices in and as part of the work environment.
In the KM Agile approach to assessment, design and development of a flexible KM strategy
is accomplished in the background while proven KM techniques are applied to existing
business challenges through short, quick win pilot projects. The results and key learnings
from the KM pilots are then quickly and iteratively combined with proven KM practices to
produce a “fit for purpose” KM strategy and roadmap to guide ongoing implementation.
KM Agile Approach Explained
 People and practices over high-level processes and tools;
 Performing and learning over strategy in a vacuum;
 Collaboration over traditional consulting; and
 Responding and adapting to change over following a perfect plan.

Principles to Inculcate Agility in Your Knowledge Management Processes

1. Embrace the Change

Your knowledge management requirements will evolve with time. Agile KM means your
processes are designed and braced by innovative tech that supports the constant changes. The
strategy should be responsive and adaptive rather than following a perfect plan laid out in the
rule book. Hence, knowledge managers should be abreast of the latest apps and tools that
support this principle. They can start by exploring on-demand webinars related to it.
2. (Re)focus on Results

Laying out rules and best practices won’t do you much good if you’re unable to quantify your
KM efforts. An ideal knowledge management solution should offer a way to measure KCS,
for instance, reports that reveal the number of articles created over time and how effective
they are. To add on, it should list top contributing agents so that knowledge managers can
appreciate or reward them to promote agile KM values.

3. Prioritize Simple and Holistic Solutions

Tech-enabled knowledge management should streamline processes and offer a one-shop stop
to employees for KM. Rather than investing in a solution that reinvents your entire
knowledge infrastructure, go for the one that improves knowledge linkage and creation
through existing organizational workflows. The solution should be simple to use, scalable,
and streamlined for your processes.

4. Improve Continuously

Nothing is perfect: there’s always scope for improvement. That’s why organizations need to
identify and fill knowledge content gaps. Knowledge management solutions should offer an
easy way to identify issues causing tickets so that necessary self-service content is prepared
to help end-users.

5. Align Technical Processes With Business Goals

Knowledge management practices can’t be thrust upon technical staff or support engineers.
The management and knowledge engineers need to work together to identify actual business
needs and accordingly decide on a knowledge management solution that fulfills them.

AGILE SOFTWARE QUALITY ASSURANCE

Agile software development evolved as a practice to establish an approach that fosters flexibility,
speed, and collaborative effort. With Agile, solutions evolve with an inclusive approach and with
cross-functional team efforts. New age organizations with changing needs are realizing its benefits for
faster application development cycles and quicker turnaround during demanding situations. However,
shorter and faster development cycles are generally questioned for quality, and that’s where Quality
Assurance (QA) comes in.

While quality brings in validation, it cannot impair the software development process and its pace.
Nevertheless, QA becomes an integral component of the equation, especially, to bring validation and
ensure stability for the application. It helps to build an application that is robust, reliable, and
accessible even during any unforeseen circumstances. Hence, testing cannot run in phases, as it has to
be planned as a process.

According to Gartner, “Agile adoption has traditionally been driven primarily from the bottom up,
and enterprise-class agile development is a natural evolution of project-level agile to support the needs
of large-scale software management … Top-down strategic adoption of agile is now growing, driven
by digital business initiatives that demand the quick delivery of solutions to new types of problem.”

With Agile development, both testers and developers have to work together and the roles could be
interchangeable. Hence, it is important that the requirements are frozen and the team is well informed.
Testing will come into play right from the time when the user stories get written. Both the
development and testing team needs to have a clear understanding of the expected scope of work.
Transparency is the ground rule of Agile development.

Agile way of development is much more experimental and exploratory in nature. The roles can
interchange and even the scope of the project can evolve over a period of time. The testing team needs
to sync in effectively within the development cycle to deliver the application with tested codes. The
role of QA in agile can involve both testing and development. The idea is that developers and testers
must actively engage to deliver the code and complete the project as per the client’s brief.

QA helps to proactively address issues and potential bugs within an application during the
development cycles. It can also help address functionality, performance, or security issues. This will
not only ensure stability of the application, but also bring down the testing efforts once the application
lands in the hands of the users. In this way developers are able to move ahead without dealing
relentlessly with pending issues or rework.

QA must fit into every development approach to make the process reliable and validate every step. At
the same time, it cannot obstruct the speed at which the development process is running. So, what
does a relevant and best-fitting QA plan look like?

 Keep QA result-oriented

Agile development works with shorter goals and with smaller targets. This implies that QA needs to
fit into the Agile equation that is much faster and dynamic in nature. A result-oriented approach can
make all the possible difference for teams to deliver results that drive faster towards the end objective.
Testers and developers do work together, but delivering the specific results makes them work more
cohesively.

 Maintain transparency in objectives

Agile or any new software development approach works effectively when transparency is maintained.
Whether it is with clarity of goals, or clarity through the process; it is important to keep things in the
bright light while working in an Agile environment. This will help teams to collaborate well and
deliver within time constraints.

 Make Testing an ongoing activity

Testing cannot be saved up till the end of the cycle. It is important to integrate it within the
development cycle. It must happen throughout the sprint, where the QA workload gets distributed and
enables teams to identify issues during the cycle, rather than at the end. When testing and
development is integrated it enables both the teams to resolve issues at speed and by ensuring better
quality.

 Arrange for demonstrations from developers

The value of in-person demonstrations and meeting is incredible. Hence, whenever an opportunity
comes by, it is good to organize face-to-face demonstrations for various application features from the
development team. This will result in further involvement from the QA team and help clarify issues in
person. Moreover, in person interactions will reduce the feedback loop between development and
QA, resulting in more collaboration and faster turnaround.

Business enterprises across the world are experiencing a common trend of increased client
expectations, technology upgrades and unpredictability in their business environment. The magnitude
of these changes and accompanying uncertainty is compelling most of the enterprises to adopt/follow
“Agile” – a flexible and progressive software development process/model.

INTRODUCTION TO AGILE INFORMATION SYSTEMS:

Even the simplest use of technology can dramatically improve your business' productivity
and efficiency. Arguably, the greatest benefit of information systems is their ability to give
users the information they need to carry out tasks efficiently.

Importance of information systems

IT systems can produce:

 custom data to help with a specific task or decision-making

 custom format (eg list, chart, etc) which can be tailored to the user's need

 real-time data, particularly useful where fast action is needed (eg mechanical fault)

 archived data, particularly useful for reports, analysis and business planning
Other advantages of information systems

Technology systems can also benefit a business by enabling:

 operational efficiencies
 cost reductions
 supply of information to decision-makers
 better customer service
 continuous availability of the systems
 growth in communication capabilities and methods

To maximise the benefits of your IT system, you have to fully utilise all its features and
functions. For example, you can:

 Use instant messaging, emails, voice and video calls, and even chatbot technology to
improve communication with customers and suppliers. This could save you time,
money and effort, allowing you to react quickly to new work.
 Integrate various IT systems to reduce administrative costs. For example, you can link
your online e-commerce shop front with stock control and accounting systems to
streamline your processes. See how to integrate your back-office systems.
 Use labelling products with unique numbers and scannable barcodes to boost your
efficiency, and improve your stock control and supply chain management.
 Use different solutions, such as customer relationship management systems
or mobile technology, to improve levels of customer service. These may help you
record, organise and plan contact with customers, access customer details on the go
and view customer interactions.

AGILE DEVELOPMENT:

Agile is a type of software development methodology that anticipates the need for flexibility
and applies a level of pragmatism to the delivery of the finished product. Agile software
development requires a cultural shift in many companies because it focuses on the clean
delivery of individual pieces or parts of the software and not on the entire application.

Benefits of Agile include its ability to help teams in an evolving landscape while maintaining
a focus on the efficient delivery of business value. The collaborative culture facilitated by
Agile also improves efficiency throughout the organization as teams work together and
understand their specific roles in the process. Finally, companies using Agile software
development can feel confident that they are releasing a high-quality product because testing
is performed throughout development. This provides the opportunity to make changes as
needed and alert teams to any potential issues.

Agile has largely replaced waterfall as the most popular development methodology in most
companies, but is itself at risk of being eclipsed or consumed by the growing popularity
of DevOps.

The four values of Agile

In 2001, 17 software development professionals gathered to discuss concepts around the idea
of lightweight software development and ended up creating the Agile Manifesto. The
Manifesto outlines the four core values of Agile, and although there has been debate about
whether the Manifesto has outlived its usefulness, it remains at the core of the Agile
movement.

The four core values outlined in the Agile Manifesto are as follows:

Individual interactions are more important than processes and tools. People drive the
development process and respond to business needs. They are the most important part of
development and should be valued above processes and tools. If the processes or tools drive
development, then the team will be less likely to respond and adapt to change and, therefore,
less likely to meet customer needs.

A focus on working software rather than thorough documentation. Before Agile, a large
amount of time was spent documenting the product throughout development for delivery. The
list of documented requirements was lengthy and would cause long delays in the
development process. While Agile does not eliminate the use of documentation, it streamlines
it in a way that provides the developer with only the information that is needed to do the work
-- such as user stories. The Agile Manifesto continues to place value on the process of
documentation, but it places higher value on working software.

Collaboration instead of contract negotiations. Agile focuses on collaboration between the

customer and project manager, rather than negotiations between the two, to work out the
details of delivery. Collaborating with the customer means that they are included throughout
the entire development process, not just at the beginning and end, thus making it easier for
teams to meet the needs of their customers. For example, in Agile, the customer can be
included at different intervals for demos of the product. However, the customer could also be
present and interact with the teams daily, attend all meetings and ensure the product meets
their desires.

A focus on responding to change. Traditional software development used to avoid change

because it was considered an undesired expense. Agile eliminates this idea. The
short iterations in the Agile cycle allow changes to easily be made, helping the team modify
the process to best fit their needs rather than the other way around. Overall, Agile software
development believes change is always a way to improve the project and provide additional
value.

The 12 principles of Agile

The Agile Manifesto also outlined 12 core principles for the development process. They are
as follows:

1. Satisfy customers through early and continuous delivery of valuable work.

2. Break big work down into smaller tasks that can be completed quickly.

3. Recognize that the best work emerges from self-organized teams.

4. Provide motivated individuals with the environment and support they need and
trust them to get the job done.

5. Create processes that promote sustainable efforts.

6. Maintain a constant pace for completed work.

7. Welcome changing requirements, even late in a project.

8. Assemble the project team and business owners on a daily basis throughout the
project.

9. Have the team reflect at regular intervals on how to become more effective, then
tune and adjust behavior accordingly.

10. Measure progress by the amount of completed work.

11. Continually seek excellence.

12. Harness change for a competitive advantage.

The Agile software development cycle

The Agile software development cycle can be broken down into the following six steps:

 Concept

 Inception

 Iteration/Construction

 Release

 Production

 Retirement

The first step, concept, involves the identification of business opportunities in each potential
project as well as an estimation of the time and work that will be required to complete the
project. This information can then be used to prioritize projects and discern which ones are
worth pursuing based on technical and economic feasibility.

During the second step, inception, team members are identified, funding is established and
the initial requirements are discussed with the customer. A timeline should also be created
that outlines the various responsibilities of teams and clearly defines when work is expected
to be completed for each sprint. A sprint is a set period of time during which specific work
has to be completed and made ready for review.

A
visualization of the Agile software development cycle

The third step, iteration/construction, is when teams start creating working software based on
requirements and continuous feedback. The Agile software development cycle relies on
iterations -- or single development cycles -- that build upon each other and lead into the next
step of the overall development process until the project is completed. Each iteration typically
lasts between two to four weeks, with a set completion date. The goal is to have a working
product to launch at the end of each iteration.

Multiple iterations occur throughout the development cycle and they each possess their
own workflow. A typical iteration flow consists of the following:

 defining requirements based on the product backlog, sprint backlog and customer
and stakeholder feedback;

 developing software based on the set requirements;

 conducting QA testing, internal and external training and documentation;

 delivering and integrating the working product into production; and

 gathering customer and stakeholder feedback on the iteration in order to define

new requirements for the next sprint.

The fourth step, release, involves final QA testing, resolution of any remaining defects,
finalization of the system and user documentation and, at the end, release of the final iteration
into production.

After the release, the fifth step, production, focuses on the ongoing support necessary to
maintain the software. The development teams must keep the software running smoothly
while also teaching users exactly how to use it. The production phase continues until the
support has ended or the product is planned for retirement.

The final step, retirement, incorporates all end-of-life activities, such as notifying customers
and final migration. The system release must be removed from production. This is usually
done when a system needs to be replaced by a new release or if the system becomes outdated,
unnecessary or starts to go against the business model.

Throughout the Agile cycle, different features can be added to the product backlog, but the
entire process should consist of repeating each step over and over until every item in the
backlog has been satisfied. This makes the Agile cycle more of a loop than a linear process.
At any time, an enterprise can have multiple projects occurring simultaneously with iterations
that are logged on different product lines and a variety of internal and external customers
providing different business needs.

KNOWLEDGE MANAGEMENT IN SOFTWARE ENGINEERING:

 Banks’ reliance on large, legacy technology estates and application portfolios, plus inconsistent
knowledge capture
 Staff churn and the consequent loss of knowledge
 Complex integration across a multitude of in-house systems, third-party products and hybrid
solutions
 Unreliable capture of the incremental knowledge gained through testing, user acceptance,
production, warranty and maintenance
1: Knowledge capture needs to be prioritized and extensible

Gone are the days when software development began at inception for every product or
application. Today, many products are extensions of previous products, or they’re built in
partnership with third-party products, or leverage off-the-shelf coding solutions and so on.

A prime requirement is to establish a robust knowledge transition process to make sure that
teams have access to this historical knowledge before they attempt the future building of a
product.

This knowledge transition process needs to ensure that:

Knowledge capture is prioritized. Not all historical knowledge needs to be captured at the
time of transition and can be prioritized as follows:

 Visible book of work for a 6-month period

 Analysis of most frequent areas of software change over the last 6 months
 Analysis of most frequent areas of support in the last 6 months if already in production

Knowledge capture is extensible to augment the knowledge base in the future as required.
This can be achieved by:

 Building a clear inventory of knowledge sources as metadata (documents, Wiki pages,

development management tools like JIRA, source-code libraries, application logs, support
ticketing systems, etc.)
 Mapping knowledge sources to relevant functional and technical modules of the product

2: Known knowns make up only half of the required knowledge

The other half is probably locked in the minds of previous team members or implemented
systems on the ground.

Knowledge falls into one of three types:

1. Explicit: Visible and clearly available in known sources

2. Implicit: Knowledge gained from practical application of explicit know-how
3. Tacit: Knowledge that is understood, assumed or accumulated over time

Capturing implicit knowledge:

 Practical assessment: Study of implemented systems. For instance, code reverse-engineering

tools can be used to develop documentation from implemented code
 Shadow incumbent experts: Observe or work alongside to gain insights
Capturing tacit knowledge:

 Analyze historical chat transcripts, emails, application logs, development and support ticket
history and so on, based on relevance and reflecting real-time behaviors exhibited in history. You
can use Natural Language Processing solutions to analyze unstructured knowledge sources and
derive meaningful insights.

3: Knowledge management needs quantification

Team knowledge levels are the most proactive indicators for expected quality of software and
product. So, you need to develop an objective view of team knowledge, and a solid plan to
aid its gradual improvement. “Knowledge index (KI)” is the primary metric.

Measuring the KI:

 Proficiency-based KI: The most objective approach is the Dreyfus model’s five levels of
proficiency (novice to expert)
 Objective KI: Certifications, internal assessments, deliverable reviews, etc.
 Team or squad KI: Granular level measurement — specific to teams
 Organizational baselines: For common areas of knowledge e.g., specific domains or
technologies
 Target versus actual: Baseline current KI, establish target KI and have an objective plan to
bridge the gap between actual and target levels
Other objective metrics, such as software quality, efficiency and productivity, can provide a
retrospective view of knowledge also. An ongoing corelation analysis between these metrics
will produce the most accurate quantitative knowledge levels of the teams.

4: Knowledge is revised continuously

Knowledge management is a continuous journey. Fresh knowledge might not be captured in

full due to time and cost pressures — you need to capture this knowledge before it becomes
history.

Minimize the cycle by:

 Incentivizing fresh knowledge capture:
 Convert collaboration tools like Confluence and Miro into knowledge repositories
 Deploy knowledge automation tools such as code reverse-engineering to generate
documentation from code.
  Simplifying incremental knowledge capture: A lot of knowledge is gained post-development of
code and testing onwards. Use defect management and ticket management tools to record fresh
knowledge whenever gained
5: Knowledge extends beyond people

Although knowledge means people and people mean knowledge, we still need to decouple
the two.
Key person dependencies can cause stress which impacts work-life balance and affects team
morale. You must download this knowledge to an offline repository and make it available for
upskilling.

Offline knowledge repositories:

 Recorded sessions: Incentivize experts to make their knowledge available as offline recorded
audio and video presentations
 Automated knowledge repositories: Use code reverse-engineering tools and natural language
processing solutions on implemented code
 Collaboration tools: Like Confluence and Miro
Organize these offline knowledge repositories into a structured, on-demand library with a
“course curriculum”. The team can assimilate this knowledge at their own pace, charting a
career path for themselves based on their expanded knowledge.

ISSUES AND CHALLENGES OF AGILE METHODOLOGY:

1. Changing Requirements

It can sometimes happen that management changes requirements or drops stories during a
sprint, even though this is not encouraged in an agile/Scrum framework. This means that
work already half-done needs to be discarded or modified, which changes the scope of testing
unexpectedly.

How to master:

Testers should be able to react and modify their processes according to changing conditions,
because in agile projects, change is common. When requirements change, testers should share
as much information as they can about what tests they have conducted, and which areas of
the application have not been tested yet. This can help the team understand how to make the
required changes to the sprint without hurting the quality of the release.

2. Not Enough Information

Product owners, who are responsible for developing user stories, may have an idea about a
new feature but may not be aware of the specifics. This means they can’t write a good set of
acceptance criteria. If there is missing information about requirements, testers can’t build
comprehensive test cases.

How to master:

Testers do not need in-depth requirements to begin testing, they can begin by coming up with
high level scenarios that test the idea of the story, confirming them with the product owner.
Testing can be done without the complete details about a feature. You can create high level
test scenarios, even when particulars change.

3. Continuous Testing

Testing is not restricted to one part of the development process, rather it’s an ongoing
activity that starts before the development phase. This creates a major challenge because
testers are expected to start building tests for features before coding has even started, or while
coding is taking place.

How to master:

To make life easier for testers, user stories in the backlog should be expanded during sprint
planning. Testers, developers and product owners should jointly define the details of each
story and then write effective acceptance criteria.

The team should ensure that each story has sufficient acceptance criteria and that the context
of the story is universally understood before work on development begins. This makes it
possible to start creating tests early on, which can be implemented when the code for the
feature is complete.

4. Technical Skills

Testers who work in an agile environment need to be technically savvy, helping developers
with API testing, integration testing, and scripting UI automation checks with Selenium or
similar frameworks. Testers with an exploratory or manual testing background entering the
world of agile will encounter a steep learning curve.

How to master:

Testers can and should learn programming or scripting languages such as Javascript and
Ruby. Testers who are familiar with programming but lack practical experience can ask for
help from developers. Testers can also learn automated testing tools like Selenium tool and
JMeter.

For specialized testing areas, such as performance, security, or compliance testing, teams
should have dedicated testers with the relevant professional background, or leverage
consultants with deep experience in these areas.

5. Frequent Regression Cycles

Developers frequently and continuously add features to the product. This can cause
regressions in previous features. Testers use regression tests to identify this problem and
overcome it, but manual regression testing is impractical in a fast-paced agile environment.

Another challenge is that modern web applications behave differently when viewed on
different devices or browsers. This creates a complex matrix of compatibility testing
scenarios, which need to be tested to ensure that the application functions correctly for all
users.

How to master:

Agile testers rely on automation. They use unit testing to ensure recent changes have not
broken the code, and tools like Selenium and JMeter to verify there is no regression in basic
functionality. Testers can use Docker or Selenium Grid to manage and run their automated
test, in parallel on various browsers and machines.

6. Lack of Communication

If communication between developers, testers and the product owners is lacking, agile testing
will simply not work.

How to master:

Direct communication within the team should be strongly encouraged. Developers, testers
and product owners should talk face-to-face on a regular basis to ensure everyone is on the
same page. Scrum ceremonies such as stand-up meetings, sprint planning, and retrospectives
are instrumental in creating a common understanding of the sprint scope and goals.

7. No Quality Measurement

Agile teams today have no single measurement of quality, which they can use to optimize and
plan testing efforts.

There are numerous metrics like unit test code coverage, lines of code (LOC) and code
complexity, but none of them provides a clear picture as to “where we stand” with quality at
each point in a sprint or release – which areas of the product are working well, which are less
stable and at higher risk of quality issues.Most agile teams are flying blind, responding to
production failures or bugs, but unable to proactively focus on product areas which have the
biggest quality issues.

AGILE PRODUCT DEVELOPMENT:

The Agile product development is based on iterations – standard time frames during which

Agile teams deliver certain value. They usually last from 1 to 4 weeks.
The very first iteration aims to deliver a product with basic functionality, and the rest of the

features will be added during next iterations. The structure of each iteration can be

represented as follows.

The iterative development process consists of the following phases.

 Defining requirements.

These requirements are based on the feedback of customers and business owners.
 Product development.

The team works on delivering a certain part of the future software (a feature, functionality,

etc.) in accordance with previously defined requirements.

 Testing.

This phase involves the testing of the delivered piece of software by QA engineers, creating

corresponding documentation, and fixing bugs before releasing this deliverable to customers.
 Delivery.

Finally, the developed piece of software can be deployed by users, and corresponding

technical support is provided.

 Feedback.
Gathering users’ feedback is important in Agile software development: it will become the

basis for requirements for the next iteration and make it possible to deliver the most user-

centric product.

These iterations will be repeated again and again until all the requirements are met and the

final product can be delivered to customers.

AGILE METRICS:

Agile metrics help agile development teams and their management measure the development
process, gauging productivity, work quality, predictability, and health of the team and
products being developed. A key focus of agile metrics is on value delivered to customers –
instead of measuring “what” or “how much” we are doing, we measure how it impacted a
customer.

Types of Agile Metrics

There are three important families of agile metrics:

 Lean metrics – Focus on ensuring a flow of value from the organization to its
customers and eliminating wasteful activities. Common metrics include lead time and
cycle time.
 Kanban metrics – Focus on workflow, organizing and prioritizing work and getting
it done. A common metric is a cumulative flow.
 Scrum metrics – Focus on the predictable delivery of working software to customers.
Common metrics include the burndown chart and team velocity.

The Importance of Agile Testing Metrics

Agile methodologies place a special emphasis on quality because the end goal is delivering
working software to users – buggy or unusable software is not working software. Quality is
also manifested in internal aspects that are not directly visible to customers, such as code
quality, maintainability and technical debt.

Agile Metrics

For agile software development, one of the most important metrics is delivered business
value. These progress measures, while observation-based, do not violate the team spirit.

Agile Metrics: Progress Monitoring of Agile Contractors, which was co-authored by myself,
Suzanne Miller, Mary Ann Lapham, Eileen Wrubel, and Timothy A. Chick--details three key
views of agile team metrics that are typical of most implementations of agile methods:
Velocity.

Simply stated, velocity is the volume of work accomplished in a specified period of time, by
a given team. Typically, this is measured as story points accomplished per sprint.

Sprint Burn-Down Chart. As detailed in our technical note, this graphical technique
provides a means for displaying progress for the development team during a sprint. As items
in the backlog of work are completed, the chart displays the rate and amount of progress. This
chart is typically provided for viewing on a team's common wall, or electronic dashboard.

Release Burn-Up Chart. A complementary graphical technique for the sprint burn-down,
the release burn-up chart is also commonly used. Many cling to the convention that sprints
burn down and releases burn up--though there is no mathematical principle that governs this
choice. Our research involved interviewing professionals who manage agile contracts who
gave us insight from professionals in the field who have successfully worked with agile
suppliers in DoD acquisitions.

Based on our interviews with personnel who manage agile contracts, our technical note
identified seven successful ways to monitor progress that help programs account for the
regulatory requirements that are common in the DoD:

Software Size is typically represented in story points when agile methods are used. This
approach is supported by the decomposition of functionality from a user's perspective--into
user stories.
 • Agile metrics provide insight into productivity through the different stages of a

software development lifecycle. This helps to assess the quality of a product and track

team performance.

• Metrics are a touchy subject.

Sprint burndown

• Scrum teams organize development into time-boxed sprints. At the outset of the

sprint, the team forecasts how much work they can complete during a sprint. A sprint

burndown report then tracks the completion of work throughout the sprint.

GANTT CHART

A Gantt chart is a project management tool that illustrates work completed over a period

of time in relation to the time planned for the work. It typically includes two sections: the

left side outlines a list of tasks, while the right side has a timeline with schedule bars that

visualize work.

Epic and release burndown

• Epic and release (or version) burndown charts track the progress of development over

a larger body of work than the sprint burndown, and guide development for both

scrum and kanban teams. Since a sprint (for scrum teams) may contain work from

several epics and versions, it's important to track both the progress of individual
sprints as well as epics and versions.

AGILE QUALITY ASSURANCE:

The agile QA process begins at the inception of the software development life cycle.
From the initial design meeting, through the development phase, to final testing and
hardening of the application. This process is repeated in two-week sprints until the
project is released.

1. DEFINE AN AGILE QA PROCESS

Most companies have made the shift from the traditional waterfall development
methodology to an agile process. Agile testing introduces QA into the project as early
as possible to foresee issues, write and execute test cases, and uncover any gaps in
requirements. With the project divided into iterative stages, QA engineers are able to
add focus to the development process and provide rapid, continuous feedback.
Sprints benefit the client by delivering working software earlier rather than later,
anticipating change, providing better estimates in less time, and allowing for course
corrections instead of completely derailing the project. The QA team can incorporate
lessons learned from previous projects to improve the process for future projects.

2. RISK ANALYSIS

An important aspect of any QA process is risk analysis. Risk analysis is defined as the
process of identifying and assessing potential risks and their impact. The process helps
organizations avoid and mitigate risks.
It’s highly unlikely for an application to be 100% bug free, but a dedicated QA team
should attempt to remove or prevent the most problematic bugs. Understanding all the
possible outcomes of a project allows your team to establish preventive measures that
reduce the probability of occurrence.

3. TEST EARLY AND TEST OFTEN

The agile model aims to incorporate QA at each stage of the project’s lifecycle to
identify issues as early as possible. Within each sprint, QA engineers test and retest
the product with each new feature added. This allows them to validate that the new
features were implemented as expected and to catch any problems that may have been
introduced. Testing early and often leads to the conservation of time and budget.

4. WHITE-BOX VS. BLACK-BOX

Black-box testing assumes no knowledge of how a system does what it does. It only
has an understanding of what it should do from the user’s perspective. White-box
testing enables the QA engineer to develop a deeper understanding of the system’s
internals. Armed with this knowledge, the QA engineer can begin testing much earlier.
In an agile QA process, the test engineers need this extra level of system
understanding to validate features as soon as they are developed.
White-box testing allows QA teams to anticipate potential error conditions and
develop better test scenarios. Knowing how the system works ensures they have tested
all possible input scenarios. It can also help identify potential security problems.
Perhaps most important: white-box testing encourages close collaboration between
development and QA.

5. AUTOMATE WHEN FEASIBLE

Automation can help maximize the effectiveness of your QA staff. Since regression
testing can consume a large percentage of the QA team’s time, automation provides a
way to ensure previous deliverables continue to work while QA engineers focus on
testing newly delivered features.

Being able to reliably reproduce tests will free up resources for exploratory testing.
Automation will give your development team the confidence to make changes to the
system with the knowledge that any issues will be identified quickly, and can be fixed
before delivery to the QA team.
All that being said, it is important to be cautious of over-automating. Your team
should prioritize test cases and then determine which of them should be automated.
Situations in which the data might change or where a scenario isn’t consistently
reproducible may not actually benefit from automation because the results can cause
false failures.

Implementing automation costs more up front, but saves money in the long run by
increasing efficiency between development and QA teams.

6. KNOW YOUR AUDIENCE

Understanding the target audience will improve the QA process. Tailoring the
development and QA process around your users needs will enable your team to build
value-driving applications. When you are familiar with who will be using the actual
end-product, you can better prioritize the QA process to save time and money.

7. TEAMWORK MAKES THE DREAM WORK

Behind each high-quality product, there is a team of professionals that work

incessantly to maintain the high standard of quality upheld by the organization.
Although each team working on the project must take responsibility for ensuring
quality, the primary responsibility for quality rests with the QA team. The QA team
understands what the client needs the system to do and can prove the client’s
satisfaction with the system. Using the Agile QA process, engineers are the super-
sleuths who root out problems and help the team to deliver high-quality products and
ensure client confidence, company credibility and successful product delivery.

AGILE GLOBAL SOFTWARE DEVELOPMENT:

Agile Software Development Over the last decade, introduction of agile software
development has brought considerable changes to software engineering field.

Nowadays many organizations and software developers are using agile methods to deliver the
efficient and high-quality product in the shortest time.

The various types of agile methodologies being used by these organizations are extreme
programming (XP), scrum, lean software development, feature-driven development (FDD),
DSDM and crystal methodologies.

Global Software Development

The increasingly complex and competitive market situation has resulted in Global
Software Engineering (GSE). Global Software Engineering (GSE) is becoming popular in
today’s industry due to the globalization of many organizations. Global Software
Engineering(GSE) can be defined as “Software development with teams situated at
different geographic locations, from different national and organizational cultures, and
different time zones”.
 Such kind of development is known as Distributed Software Development(DSD),
Global Software Development (GSD), Global Software Engineering and Dispersed
Software Development.

Software organizations are shifting towards global software engineering to get GSD
benefits such as reduced software development costs by delegating work to countries
with low labour cost, transfer of knowledge and resources, access to talented
workforce, better-quality software, rapid innovation and increased productivity .

Agile Software Development methods focuses on agile manifesto given by four values:

 Individuals and interactions over Processes and tools  Working software over
Comprehensive documentation.
 Customer collaboration over Contract negotiation
 The first value refers that role of humans and team interactions should be
considered more valuable than defined processes and development tools.
 The second value implies that main objective of software team should be to deliver
the working software at frequent intervals rather than large.

Roles in agile methodology

An agile software development process always starts by defining the users for a particular
product and documenting a vision statement for the scope of problems, opportunities, and
values to be addressed. The product owner captures this vision and works with a
multidisciplinary team (or teams) to deliver on it. Several roles are involved in an agile
development process.

Users:An agile process always begins with the user or customer in mind. Today, we often
define user personas to illustrate different workflow roles or types of customer needs and
behaviors.

Product owner:The product owner is tasked to be the voice of the customer, including any
internal stakeholders. This person distills insights, ideas, and feedback to create a product
vision.

Whatever the vision, the product owner is responsible for defining it and then working with
the development team to make it real.

Software development team

Teams should be multidisciplinary and include a diverse group with the skills and
backgrounds to get the job done. In addition to developers, agile development teams should
include quality assurance automation engineers, data engineers, user experience (UX)
designers, and other roles depending on the type of software project.

Agile focuses teams on delivering working software, so they must complete end-to-end
functioning applications, integrations, and other deliverables that impact users—not just the
technical components. Team members must align on what they are building, who is doing
what, and how th software will be developed.
 Agile teams often have other roles assigned, including the following:

 Tech or team leads partner with the product owner on architecture, non-functional
acceptance criteria, sequencing, dependencies, and other technology and security
considerations
 Scrum masters often coach new teams on agile processes, responsibilities, and tools.

Business analysts partner with the product owner. Business analysts are especially helpful
when software development teams are developing micro services and other technical
products, and where the business analyst has more software development knowledge than the
product owner.
• Global Software Development (GSD) continues to grow substantially and it is fast
becoming the norm and fundamentally different from local Software Engineering
development. Withal, agile software development (ASD) has become an appealing
choice for companies attempting to improve their performance although its methods
were originally designed for small and individual teams.
• The current literature does not provide a cohesive picture of how the agile practices
are taken into account in the distributed nature of software development: how to do it,
who, and what works in practice. This study aims to highlight how ASD practices are
applied in the context of GSD in order to develop a set of techniques that can be
relevant in both research and practice.
• To answer the research question, "how are agile practices adopted in agile global
software development teams?" We conducted a systematic literature review of the
ASD and GSD literature.
• A synthesis of solutions found in seventy-six studies provided 48 distinct practices
that organizations can implement, including "collaboration among teams", "agile
architecture", "coaching", "system demo" and "test automation". These implementable
practices go some way towards providing solutions to manage GSD teams, and thus to
embrace agility.