testing in agile: antipatterns and remedies (draft)
TRANSCRIPT
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
Customer
Satisfaction
Welcome
Changing
Requirements
Delivering
software
frequently
Business
Involvement
TrustCollaboration
Working
software is the
measure of
progress
Sustainable
development
Technical
excellenceSimplicity
Self organized
teamsCourse
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.
Collaborationwe 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
CollaborationSelf organized
teams
try this
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
principles we violate
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
principles we violate
Business
InvolvementCourse
correction
Customer
Satisfaction
try this
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 suitecontinuous
delivery is not
possible
release testing
should only be risk
management
no regression
suite in place or
not enough
coverage
principles we violate
Delivering
software
frequently
Technical
Excellence
try this
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
principles we violate
Customer
Satisfaction
Trust
try this
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
principles we violate
CollaborationSelf organizing
teams
try this
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
principles we violate
TrustCollaboration Simplicity
try this
Complexity
Quick Wins, High Value, Definitely
Automate
High value, But complex. Priority 2.
High Complexity, low value. Definite No.
Low value, low complexity. Automate,
maybe
Value
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
effortrelease pressure
(deadlines)
principles we violate
CollaborationTechnical
excellence
try this
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
