Testing in Agile - Antipatterns and Remedies

TESTING IN AGILE:
ANTI-PATTERNS AND
REMEDIES
@kksure
KK Sure
krishnakumarsure@gmail.com
Confidential | Copyright © Agile Testing Alliance Global Gathering

what is ‘agile’ ?

what is an ‘anti-pattern’ ?
“ is a common response to a recurring problem
that is usually ineffective and risks being highly
counterproductive.”
-- Wikipedia

agile manifesto
• Individuals and interactions over processes
and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a plan

guiding principles
Technical
excellence
Customer
Satisfaction
Welcome
Changing
Requirements
Collaboration Trust
Delivering
software
frequently
Business
Involvement
Working
software is the
measure of
progress
Sustainable
development
Simplicity
Self organized
teams
Course
correction

some stories…

story 1

“it works on
my machine”

reasons
different roles
work in silos
effects
further
increases the
divide between
the various
roles
remedies
QA and Dev.
collaboration (e.g.
tech huddles)
we adopt only the
easy parts of
agile (sprints and
planning-meetings
etc.)
delays in making
changes/fixes
share the
responsibility of a
quality software
delivery
lack of shared
responsibility

principles we violate
Delivering
software
frequently
Collaboration
Self organized
teams

story 2

“I found 80 defects
this week”

reasons
number driven
reports
effects
possibility on
missing out
important
defects
remedies
working software
as the measure
of the success of
the team
measuring the
success of QAs
by the number of
defects they find
more defects and
hence defect
triages
use empirical
ways of
measurement
more low priority
and duplicate
defects

Working
software is the
measure of
progress

story 3

“lets choose
from this list of
defects”

reasons
not enough
involvement from
business
effects
last minute
panic
remedies
work on definition
of ‘Done’
Done isn’t Done
production
defects have regular
business
involvement
poor quality
delivered have automated
tests as safety
net

Business
Involvement
Course
correction
Customer
Satisfaction

story 4

“buckle up for the
2 months release
testing cycle”

reasons
a history of
regression
defects
throughout the
development
cycle
effects
dependency on
regression test
team
remedies
invest in an
effective and
efficient
automated
regression suite
continuous
delivery is not
possible
release testing
should only be risk
management
no regression
suite in place or
not enough
coverage

Delivering
software
frequently
Technical
Excellence

story 5

“why didn’t you
find that bug?”

reasons
we believe
‘Quality is a QA
responsibility’
effects
displays lack of
trust
remedies
Quality should be
a shared
responsibility
isolated QA or
testing teams

Customer
Satisfaction
Trust

story 6

Manual Testers Automation Testers

reasons
considering test
automation as a
separate project
effects
duplication of
efforts by these
two teams
remedies
consider test
automation an
integral part of
your software
development
team
considering test
automation as
specialization
changes cannot
be made with
confidences
test suite
maintenance
becomes difficult
make test
automation a
shared
responsibility

Collaboration
Self organizing
teams

story 7

“let’s automate
everything”

reasons
not enough
analysis on ROI
effects
automated test
suites brings
along with the
maintenance
costs
remedies
evaluate the ROI
before investing
into getting a full
coverage
separate test
automation teams
consider test
automation
pyramid before
adding up tests

Collaboration Simplicity Trust

story 8

“the build is red, why
don’t you comment out
that test”

reasons
test automation
knowledge is not
shared
effects
low confidence
in test suite
remedies
follow TDD,
ATDD, BDD
techniques
lack of discipline
test coverage
drops over a
period of time
collaborate on the
test automation
effort
release pressure
(deadlines)

Technical Collaboration
excellence

Key Takeaways
• It’s easy to get the simpler parts of agile (viz. the
rituals) but our primary focus should be on the core
principles
• Business involvement is very important in an agile
context
• Working software is the measure of success of an
agile team and not numbers
• Software quality is a shared responsibility
• Test automation is not a specialization and is an
integral part of the software development teams
• Being agile needs more discipline than non-agile
projects

thank you
@kksure
krishnakumarsure@gmail.com

Testing in Agile - Antipatterns and Remedies

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (15)

Similar to Testing in Agile - Antipatterns and Remedies

Similar to Testing in Agile - Antipatterns and Remedies (20)

Recently uploaded

Recently uploaded (20)

Testing in Agile - Antipatterns and Remedies