Agile Software and Development Testing
Agile Software and Development Testing
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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:
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.
1. Product Metrics: These are the measures of various characteristics of the software
product. The two important software characteristics are:
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
The application of software metrics is not always easy, and in some cases, it is
difficult and costly.
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:
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 –
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.
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
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.
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.
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?
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.
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.
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.
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:
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 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.
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.
• 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.
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.
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.
EclEmma
NUnit
PyUnit
HTMLUnit
CppUnit
• 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.
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.
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 not a perfect square- output will be a decimal number.
Positive decimals
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. Regression Testing
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.
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.
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
Black box testing facilitates testing White box testing does not facilitate testing
communication amongst modules communication amongst modules
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 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.
The test cases for grey box testing may include, GUI related, Security related, Database
related, Browser related, Operational system related, etc.
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
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:
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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 (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.
• • 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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
Agile Principle 10
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.
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.
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.
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:
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.
Scrum
SCRUM is an agile development process focused primarily on ways to manage tasks in team-
based development conditions.
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:
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
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
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.
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.
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.
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.
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.
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.
‘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 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:
Here, we are discussing another essential software testing technique, which is known as Agile
Testing.
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.
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
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.
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.
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.
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
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.
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.
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:
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.
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.
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.
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.
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 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.
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 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.
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:
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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
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.
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.
The Agile Manifesto also outlined 12 core principles for the development process. They are
as follows:
2. Break big work down into smaller tasks that can be completed quickly.
4. Provide motivated individuals with the environment and support they need and
trust them to get the job done.
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.
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;
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.
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.
Knowledge capture is prioritized. Not all historical knowledge needs to be captured at the
time of transition and can be prioritized as follows:
Knowledge capture is extensible to augment the knowledge base in the future as required.
This can be achieved by:
The other half is probably locked in the minds of previous team members or implemented
systems on the ground.
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.
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.
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.
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.
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.
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.
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.
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.
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,
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
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
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.
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.
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.
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 (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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.