testing in agile - antipatterns and remedies

Confidential | Copyright © Agile Testing Alliance Global Gathering

TESTING IN AGILE:

ANTI-PATTERNS AND

REMEDIES

@kksure

[email protected]

KK Sure


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.

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

CollaborationSelf 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

InvolvementCourse

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 suitecontinuous

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



CollaborationSelf 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



TrustCollaboration Simplicity


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)



CollaborationTechnical

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

[email protected]

testing in agile - antipatterns and remedies

Technology

easy parts of agile

toolsworking software

business effects

number of defects

important defects remedies

production defects

silos effects

various roles remedies