agilerecord_03

8/7/2019 agilerecord_03

1/70

The Magazine for Agile Developers and Agile Testers

July 2010

issue 3www.agilerecord.com freedigitalversion madeinGermany


2/702 www.agilerecord.com

online trainingesh & gm (Fud)

ISTQB

Certied Tester Foundation LevelISTQB Certied Tester

Advanced Level Test Manager

Our company saves up to

60%of training costs by online training.

The obtained knowledge and the savings ensure

the competitiveness of our company.

www.te-trainings-shop.com


3/703www.agilerecord.com

Dearreaders,

weareveryhappywiththeresponseofthemarket.Weareontherighttrackforsuc-

cesswiththeAgileRecord.

Thankyoutoallofyouwhosupportandspreadthelinkstoyourinterestedcontacts.

Weneedthecommunitytosucceed.Weneedyounotonlytoreadthemagazine,but

alsotowritearticlestoinform,toshareknowledgeorjusttogiveyouropinion.

Wehaveseenandstillseethatthereisalottolearnandtoshare.Agileisgetting

moreandmorepopularandthenewmembersofthecommunityarehappyabout

thetransfermediumAgileRecord.

InourconferenceTesting&FinanceinBadHomburg,Germany,NitinBhargava,

HeadofQualityServicesatBarclays,heldakeynoteandtoldthataround25%ofthe

projectsrunbyBarclaysarealreadydonebyagilemethods.

Amazing!Hepointedoutthattheyguredoutthatitisnotthateasytorunthese

projectsusingoutsourcedforcesandthatswhytheystartedtorunitbylocalteams.

Idontknowifthismeansthattestoutsourcingisonthewayout,maybenot,butfor

sureinthewayoftransforming.Ithinkthatoutsourcingwillhappenasacomplete

service.Imeandevelopmentandtestingforagileprojectsinonego.Ifyouhave

experiencewiththat,pleasesendmeanarticleonit.

Ialsospokewithoneofthebiggestsoftwareandsystemservicecompaniesfor

banks.TheytoldmethattheyjustrunsmallprojectsinAgile.Assoonasoneproject

hastoomuchinterfaces/interferencesfromotherprojectsexpectingresultsandso

on,itisforthemimpossibletocontroltheinterchangegatestodeterminatedates.I

dontknowifanyofyouhavesomeexperiencewiththat,butwearehappyaboutany

articlediscussingexperienceswiththosekindofprojects.

WearefacingtheAgileTestingDaysinBerlin.Wearehappytoseethatmanyofyou

areusingtheearlybird.Pleasebeawarethatthereareonly20placesforeachtuto-

rial.Firstcomerstserved!Theconferencehotelhasonlyacapacityof170rooms.If

youwanttobethereandnotinanotherhotelnexttoit,thenbooktheresoon.

TheOzAgileDaysinSydneyareorganizedtogetherwithPlanitLtd.Thecallfor

papersisoverandwewillpresentthePrograminafewdays.Pleaseinformyour

contactsdownunder.Australia,weareonthewaytoyou!

TheBelgiumTestingDaysaregoingtobequiteAgileandweareintheplanning.

SavethedatesFeb1416,2011.

Lastbutnotleast,Iwanttothankalltheauthorsforthegreatarticlesandthesup-

portingcompaniesfortheirads.Thanks!

Lookingforwardtohearingfromyou.

Enjoyreading

JosDaz

P.S.DontbesadwhenSpainwinstheWorldCup!!

Editorial



Contents

Editorial3

KeepitsimpleSevenrulesofthumbforeffectivesoftwaredevelopment6

by Remi-Armand Collaris & Eef Dekker

ProblemSolvingThroughPairProgramming10

by Paul Pagel

WhatReallyHappened12

by Catherine Powell

AgileTestingBetweenTheoryandPractice14

by Sara Medhat

Value-DrivenDevelopmentPrinciplesandValuesAgilityistheTool,NottheMas-

ter18

by Tom Gilb

ThingsIveLearnedtheHardWay26

by Alex Rosiu

TheArtofThrow-AwayTestAutomation28

by George Wilson

TestAutomationinAgileEnvironments31

by Mallika Singh

TheVisionaryStoryTeller37

by Geert Bossuyt

TheAgileBible40

by Simon Romans

TaskBoardsandCautionSigns!!49

by Sowmya Karunakaran

SCRUM&Testing:Assessingtherisks52

by Erik van Veenendaal

SkillsforSCRUMAgileTeams55

by Prasad Prabhakaran

DangersLurkinginTasksandBreakdowns58

by Alexander Tarnowski

SignicanceofToolsinAgileSoftwareDevelopment61

by Chaitanya Sudha Nakka

TheAbileneParadoxandTeamCollaboration66

by Badri N Srinivasan

Masthead69

IndexOfAdvertisers69


5/70

Es gibt nur einen Weg zum Glck.



Introduction

Animportantquestionwithrespecttoimplementingasoftware

developmentmethodishowto concretizethemethodintheor-

ganizationandtheprojectwhichitshouldserve.Thisstepiseas-

ilyforgotteninintroducingandapplyinganewmethod,anditis

easytoslipintothehabitofregardingafullandcleanapplica-

tionofamethodasagoalinitself.Manydevelopmentmethods

(DSDM,Scrum,XP)presupposethisconcretizationstepwithout

makingitexplicit.IntheRationalUniedProcess(RUP),thisstep

isexplicitinitsrstkeyprinciple:AdapttheProcess.Itisbynomeansaneasystep,sinceknowledgeofandexperiencewiththe

methodisneeded.

Whichrulescouldyouuseinperformingthisstep?Howdoyou

gettoaclearandconcretedevelopmentprocessthatoptimally

supportsyourproject?Whichtoolsdoyouapplyandwhowilluse

them?Belowwehavelistedafewsituations,inwhichthisstep

shouldhavebeentakenmoreconsciously:

1. Anenterpriseboughtanexpensivetoolbutdidnotanticipate

thelargeamountsoftimeitcoststoimplementitandkeepit

up-to-date.Thisresultsinthetoolremainingunused.

2. Reviewformsaredeveloped,butittakessomuchtimetoll

theminthateveryoneavoidsreviewing.

3. RUPdenes128workproducts.Itisdecidedthatallneedto

becreated.Thisresultsintheprojectcomingtoacomplete

standstill.

4. Theprojectneedsto benishedquickly,so alargedevelop-

mentteamisrolledout,butthedemandingorganizationcan-

notsupplysufcientinputtotheteam.

5. Thechangeproceduretakes3monthsat least.Thisleadsto

alargepartofthechangesnotbeingrelevantanymorebythe

timetheyarenallyimplemented.6. Peopleresponsibleforrequirementsarenotavailableduring

system implementation,and therefore thesystemdoes not

complywiththecustomersneeds.

7. Alotoftimewasinvestedinkeepinganup-to-datetraceability

betweenrequirementsandcode,butestimationofchanges

doesnotappeartobeanyquicker.

Inthisarticle,weprovidesevenrulesofthumbwhichhelpyou

tomakethedevelopmentmethodofyourchoicemoreeffective.

Theserules weredeveloped during ourexperiences in various

enterprises,inwhichwe helpedto implementmoderndevelop-

mentmethods.Followingtheseruleswillhelptoavoidthesitua-

tionsdescribedabove.

Seven Rules of Thumb

Allrulespresentedherefollowthesameprinciple:balancecost

andrevenues.Ameasure(document,procedure,applicationor

atool)iseffectiveifityieldsthecorrecteffect,i.e.anoptimalbal-

anceofcostsandrevenues.Costsandrevenuesnotonlyapplyto

theperiodofsoftwaredevelopment,buttothecompletelifecycle

oftheapplicationandtothecontextwithinwhichtheapplication

isdevelopedandused.Animportantquestioninthisrespectis

whattheexpectedlifetimeoftheapplicationisandhowmany

changesareexpected.

Weoftenseepeoplebeingsoenthusiasticabouttheexpected

revenues that they lose sight of the costs. Or the other way

around:becauseofthecosts,asmartsolutionisnotchosen,

althoughinthelongruntherevenueswouldhaveoutweighedthe

costs.Costsorrevenuesinthemselvesarenotthecriterionfora

gooddecision,butthebalanceofbothis.

Rule 1: Keep the level of ceremony as low as possible

Thelevelofceremonycanbedenedastheamountofadditions

tothedevelopmentprocessforthesakeofcontrollingthepro-cessanditsresultingworkproducts.Ahigherlevelofceremony

implies moreformal recording,reviewand approvaland often

moreworkproducts,proceduredescriptionsandmoredetailed

meansofcontrol.

Keep it simple Sevenrules of thumb for effectivesoftware development

by Remi-Armand Collaris & Eef Dekker

AlexanderMaier-Fotolia.com



Everyorganizationknowsitsownceremonies.Usuallythebig-

gerthe organization, themore formal it is.Some examplesof

lowerandhigherlevelsofceremonyarelistedinthetablebelow:

Lower level of ceremony Higher level of ceremony

InformationisavailableinaWIKI,

everyonecanlookthere.

Itisexplicitlyrecordedwhomust

beinformed,andinwhatway.

Theworkproductsthemselvesmirrorwhatisagreedupon.

Minutesofeverymeetingaremadeandformallyapproved.

Informalexchangeofinformation Informationisusuallyexchanged

inwriting.

Qualityisacknowledgedandas-

suredbytheteam.

ThereisaQualityAssurance

department.

Changescanbeprocessedeasily. Thereisacommitteewhichmust

approvechanges.

Reviewsareheldinformally. Allreviewresultsarerecorded.

Standardsandguidelinesare

implicit.

Thereareextensivelistsofstan-

dardsandguidelines.

Manyorganizationsareunawareofthecostsaswellasthereve-

nuesoftheirlevelofceremony.Manypeopleseeformalreviews,

anextensiveapprovalprocedureand detailedplanswithGantt

chartsassimplyindispensable.Wehavefoundthataskingfor

explicitestimatesofcostsandrevenueshelpspeopletobecome

awareoftheamountofoverheadbroughtaboutbythelevelof

ceremony.

Rule 2: Keep the team as small as possible

Adevelopmentteamofexactly1experiencedpersonwhouniesallrolesinhimselfismostefcientinavoidinghandovers.Howev-

er,notonlytheavailabilityofonepersonwithallknowledgeand

skillsneededprohibitsthisoption,butalsodevelopmentspeed

(timetomarket),vulnerability(whathappensifthissingleperson

getssick)andsafeguardingofknowledge.

Adjustthenumberofteammemberstothelevelofinputthede-

mandorganizationcansupplyonacontinuousbasis.Itdoesnot

makemuchsensetoinstallateamof3ana-

lystsand8developersifthemaximuminput

thekeyuserscansupplyisonlysufcientfor

1analystand2developers.

Moreover,abiggerteamdoesnothaveapro-

portionallybiggerproductivity,duetoalarger

overheadinplanning,handoversanddepen-

dencies.Itmaywellbethecasethatawell-

functioningteamof3developers,anarchitect,ananalystanda

testeraremoreproductivethanthesameteambutnowenlarged

with3moredevelopers,ananalystandatestertomeetthetime-

to-market.Ifsuchascalingoperationtakesplacetowardtheend

oftheprojecttomeetthedeadline,theneteffectwillbenega-

tive.Manypeopleforgettotakeintoaccountthelearningcurveofnewteammembersandtheextraoverhead.1

Rule 3: Make as few work products as possible

Ifyoumakealistofworkproducts,thequestionsyouneedto

askyourselfare:

Whowillmissthisworkproduct?

Whatwillgowrongifwedontmakeit?

Thisapproachwillclarifythepurposeoftheworkproduct.Will

thisworkproductonlybeneededfordevelopment,orwillitalso

playaroleinfuturesystemadministration?Byknowingwhowill

needtheworkproduct,youcaninvolvethispersoninproducing

it,validatingitscontentsandbalancingproductioneffortwiththe

expectedrevenues.

Theamountofworkproductsforsoftwaredevelopmentdepends

onthecircumstancesoftheproject,asdotheirspecicformand

comprehensiveness.Ifasketchonawhiteboardsufces,itisnot

necessarytoproduceacomprehensivedocument.

Someworkproductswillbepartofthenalproduct,forinstance

because they are needed for system administration or future

maintenance and support. If the only thing you deliver isthe

application,andthedemandorganizationcanuseandadmin-

istrateit,thatisnefortheshortterm.Thisisevenmorelikelyif

anAgilewayofdevelopmentisappliedandallcodeisaccompa-

niedbyunittestsandcodedocumentationandkeptassimple

aspossiblebyrefactoring.However,mostapplicationsmustbe

maintainedlong afterthe originaldevelopers aregone. Inthis

caseitmightbebettertohavesomedocumentationinplace,like

usecasespecications,asoftwarearchitecturedocumentand

systemadministrationdocument.

Rule 4: Apply the simplest possible approval procedure on as

few work products as possible

Not all workproducts need tobe approvedin aformalway. A

similarquestionasaboveapplieshere:

Whatgoeswrongifaworkproductisnotformallyapproved?

Ifthe answer isnothing,it isclear

thatformalapprovalisnotneeded.Of-

tentheworkproductsthatdenethe

scopeoftheprojectarecandidatesfor

formalapproval.Alsousecasespeci-

cationscouldbeapprovedinorderto

haveacommonpointofreferencefor

acceptingthesolution.

Formal approvaltakes time and energy. Onthe otherhand, it

deliversclarity,baselinesandreferencepoints.Ifthereisaclear

mandateofonepersonapprovingaworkproduct,thiswillsim-

plifythe process tremendously.For example, a subject matter

expertwhohasmandatecandecideveryquicklyifausecase

specicationiscorrect.Hecandotheformalacceptanceaswell.Itdoesnotaddmuchvaluetohaveapersonhigherintheman-

agementhierarchyaccepttheusecasespecication.

Often a few separate,specialized tools better meet

the requirements than a

complete integrated toolset.



Rule 5: Take the simplest toolset that meets your needs

Itisoftenunderestimatedhowwellrequirementsandmanage-

mentcanbedoneusingonlyabigwhiteboard,brownpaperand

post-its, a word processor, spreadsheet, simple modeling tool

andWIKI.Addmoreonlyifthereisaveryclearneedorbottle-

neck.Besurethatasolutionisalreadyproveninpracticeand

thatyouhaveagoodpictureofhowitwillhelpyoubeforechoos-

ing it. Donot only formulate requirementsfora tool,but look

atthecostsaswell.Toolsneedtobeinstalled,conguredand

maintained.Thetimeandexpertiseneededtodothisisoften

underestimated.

Formulate tool requirements with concrete improvements in

mind,whichcanbeexpressedintermsofrevenue.Ifyoubalance

costs(purchase, conguration, maintenance, keeping informa-

tionup-to-date)againstrevenues(savingsintime),thisbalance

mayeasilyturnoutnegative.

Ifyouhaveasetofprioritizedtoolrequirements,lookatthesim-

plest toolsthatmeet them. Often a few separate, specialized

toolsbettermeetthe requirementsthana completeintegrated

toolset.Integratedtoolsetsareinherentlycomplexandmaylack

thefeaturesofspecializedtools.

Rule 6: Maintain (explicit) traceability as little as possible

Traceability maymean twothings:there isa connectionmade

betweendecisionsintime,orbetweenworkproductsbelonging

togetherinonebaseline.Theconnectionmaybemadeexplicitly

(inatoolorspreadsheet)orimplicitlybyfollowingdesignrulesornamingconventions. Traceabilityisoften desiredbecauseit

mayhelpwith:

Keepingbusinessrequirements,high-

level and detailed software require-

ments, test cases and implemented

functionalityinline;

Impactestimation,especiallywhenthe

originaldevelopersarenolongeravail-

able;

Tracing why certain decisions were

made,bywhom,andwhen.

Explicit traceability from high-level to

detailsoftwarerequirementsandimple-

mented functionality maybe useful, for

examplein situationsin which changed

lawsorgovernmentrulesmayleadtoad-

aptationsin the application. If theright

traceabilityisinplace,thismayhelpin

estimatingtheimpactofthesechanges.

Keepinmind,however,thattraceability

canneverserveasasubstituteforintel-

ligent,humaninspection.

Traceabilitymaybeusedtoensurethat

allhigh-levelrequirementsaremet.While

detailingrequirements,yougainmoreinsight.High-levelrequire-

ments formulated (much) earlier might no longer be relevant.

Hence, we need human inspection here as well. Maintaining

traceabilitybetweenchangingrequirementsistime-consuming,

evenwhentoolsareused.Asolutionusingjusthumaninspection

mightbecheaper.

Traceabilitycanbekeptimplicitinmanycases,whichisacheap

approach.Forexample,namingconventionsandobject-oriented

development may help. Ifsomething iscalled dossier bythe

business, then itisa good ideato givetheobject inthecode

whichrepresentsthedossierthenamedossieraswell.Things

youcandoinrealitywithadossierwillthenbeassociatedwith

thedossierinthecode.Themoreperspicuousanapplicationis

built,thebettertheimplicittraceabilityis.

Theworstscenarioisthatinwhichexplicittraceabilityisinstalled

butnotkeptup-to-date.Outdatedinformationrendersthetrace-

abilityunreliableandhenceuseless.Inthiscasetheinvestment

intraceability has a negative result, since the effort that has

beenputindoesnotpayatall.Considerexplicittraceabilityonly

when its maintenance is guaranteed throughout the applica-

tionslifecycle.

Rule 7: Choose the most effective form of communication

Thequickerandbetteryourintentionsareunderstood,themore

effectiveyourcommunicationis.Thebestwaytoreachthisis

tohavea liveconversationandbeenabledtovisualizeyourin-

tentions.Theworstwayistosenda textdocumentwithoutany

explanationorpossibilitytoraisequestionsaboutit.Inthegurebelow,variouscommunicationchannelsandtheireffectiveness

areshown.

Figure 1: Eectiveness of communication channels



Donottrustblindlyinthisgure.Keepinmindhowacommuni-

cationchannelisused.Inordertoconveyanintention,apiece

ofpaperonitsownisnotveryeffective.Ifwehaveaface-to-face

conversation, a paperdocumentcould, however, be helpful to

supporttheconversationandcapturetheresultforfuturerefer-

ence.Itthenfunctionsasa meanstosupporttherealcom-

munication.

Conclusion

Wehavepresentedseventestedrulesofthumb,whichcanbe

usedtotailoranysoftwaredevelopmentmethod.Theyhelpyou

toimplementaneffectivedevelopmentprocessortoimprovean

existingprocess:

1. Keepthelevelofceremonyaslowaspossible

2. Keeptheteamassmallaspossible

3. Makeasfewworkproductsaspossible

4. Apply the simplest possibleapprovalprocedure on as few workproductsaspossible

5. Takethesimplesttoolsetthatmeetsyourneeds

6. Maintain(explicit)traceabilityaslittleaspossible

7. Choosethemosteffectiveformofcommunication

Eachoftheserulessupportsbalancingofcostsandrevenues.

Especiallyrevenuesthatwillshowuponlyinthelongrunmight

behardtoquantify,butmightbeveryworthwhileinvestigating.

Makingexpectedrevenuesexplicitgivesyouatoolformeasuring

theeffectivenessofthemeasurestaken.Theresultsofsucha

measurementareinturnindispensableforfurtheroptimizationofyourdevelopmentprocess.

Remi-Armand Collaris

Remi-Armand Collaris is

a consultant at Ordina,

based in The Netherlands.

He has worked for a num-

ber of nancial, insurance

and semi-government in-

stitutions. In recent years,

his focus shifted from

project management to

coaching organizations in

adopting Agile using RUP and Scrum. An important part

of his work at Ordina is contributing to the companys

Agile RUP development case and giving presentations

and workshops on RUP, Agile and project management.

With co-author Eef Dekker, he wrote the Dutch book

RUP op Maat:Een praktischehandleiding voorIT-pro-jecten, (translated as RUPTailored:APracticalGuideto

ITProjects), second revised edition published in 2008

(see www.rupopmaat.nl). They are now working on a

new book: ScrumUP, Agile Software Development with

Scrum and RUP (see www.scrumup.eu).

Eef Dekker

is a consultant at Ordina,

based in The Netherlands.

He mainly coaches orga-

nizations in implementing

RUP in an agile way. Fur-

thermore he gives presen-

tations and workshops on

RUP, Use Case Modeling

and software estimation

with Use Case Points. With

co-author Remi-Armand Collaris, he wrote the Dutch

book RUP op Maat, Een praktische handleiding voor

IT-projecten, (translated as RUP Tailored, A Practical

GuidetoITProjects), second revised edition published

in 2008 (see www.rupopmaat.nl). They are now working

on a new book: ScrumUP, Agile Software Development

with Scrum and RUP (see www.scrumup.eu).

> About the authors

[1] See Frederick P. Brooks Jr., The Mythical Man-Month. Essays on

Software Engineering, Anniversary Edition 1995. The insights that Brooks

formulated in 1975 are still valid.


10/7010 www.agi lerecord.com

I cant seem to gure out what is wrong with this

function. Jim, can you help me out?

Of course.

Okay, so rst you get rid of the element through the form

post. Then, you look up the model from the database and

ask it to update itself. That, in turn, tells it EUREKA!

Thats it! Thanks, Jim, for the help.

Sure, but I didnt even do anything.

Doesthisone-sidedconversationsoundfamiliar?Formanythe

simple process of explaining a problem to a coworker allows

themtoarriveattheanswerindependently.(Then,ifyoureany-

thinglikeme,yourunbacktoyourcomputerinordertogetthe

solutionintocodeasquicklyaspossible!)Meanwhile,bystanders

likeJimarelefttowonderwhytheywerecreditedwiththesolu-

tionwhentheirfeedback--orlackthereof--didntactuallysolve

theproblem.Infact,inmanyinstancesitisntthefeedbackthat

allowsustoovercomeourhurdles;itistheveryactofcommuni-

cationthattriggersthesolution.

Theideathatverbalcommunicationcanpositivelyaffecttheso-

lutionsanddesignsofasystemisprettypowerful,because,lets

faceit,creatingsoftwareisnoeasytask.Itisdifculttoconsis-

tentlydesignsimplesolutionsforcomplicatedproblems.Still,the

provenpositiveeffectsthatcommunicationhasonbothdesign

and problem-solving makes me wonder why more developers

arentactivelyseekingoutopportunitiestoworktogether.Thereisevidencethatshowsthatpairprogramming--similartowhatis

beingdonecurrentlybymembersof theeXtremeprogramming

community -- is more productive than individual programmers

workingalone.Iwouldliketoproposethatpairprogrammingis

productive thanks in part tothe factthat the verbal reection

loopisinconstantmotion.

Sowhatispairprogramming?Pairprogrammingisatechniquein

whichtwodeveloperssitatasinglecomputerandcollaborateon

thesameproblem.Usuallyonepersonisdriving,withcontrolof

mouseandkeyboard,althoughthedriverisfrequentlychanged.

During theprocess,communication between thetwo program-

mersisconstant,astheyexplaintooneanotherthenatureof

whattheyaredoinginrealtime,astheytypeit.Thisset-upal-lows the passive member ofthe duoan opportunity toreect

upontheteamsworkandoffersuggestionsoralternativestothe

design.Tobeinthezonewhenpairprogrammingrequiresthat

thetwoprogrammerscontinuallyverbalizetheirideasinaway

thatallowstheirpartnertofollowtheirthinkingandstayengaged

(Cogley1).

ThesimulatedconversationwithJimisademonstrationofwhat

isreferredtoastheRubberDuckySyndrome;ajokethatpor-

tendsthatyoumightaswellhavebeentalkingtoaninanimate

rubberduckinsteadofaperson.RubberDuckySyndrome,as

weallknow,isnottechnicallytrue:whentryingtosolveaprob-

lemyoucantsimplyexplainittoaninanimateobjectandexpect

asolutioneverytime.Nonetheless,everyonecanrelatetothe

needtotalkthroughcertainproblemsoutloud.Forthisreason,

thespiritoftheRubberDuckySyndromeisrelevant;sincethe

actofexplainingaproblemtoanotherpersoncreatesthemental

contextthatisnecessaryforsolvingtheproblem.

AccordingtoRobertM.KraussandSusanR.Fussell,authorsof

ModelsofInterpersonalCommunication,thereisevidencethat

creatinga message can affectthe way the creator perceives,

remembers,andthinksaboutthemessagescontents(99).Inotherwords,communicatingamessagewill,ineffect,alterit.Al-

thoughhisalterationcanhaveanegativeeffectwhenyouaretry-

ingtodosomethingspecic,likerecognizeafacialstructureor

Problem Solving ThroughPair Programming

by Paul Pagel

Cyhel-Fotolia.com



explainamemory,ithasaverypositiveeffectwhenyouwantto

solveaproblem.Thecommunicationlaysoutanexplanationof

theknownpartsoftheproblem.Then,bylinkingtogetherthese

knownpartsoftheproblem,asolutionfrequentlyappearsbyvir-

tueofverbalizingtheproblemitself.

InastudythatAnnekatrinWetzsteinandWinfriedHackerpub-

lishedin2004,theyaskedagroupofstudentstoputtogethera

complexgardengrill.Thecontrolgroupwasaskedtoassemble

thegrillandthenleftaloneuntiltheirdesignwascomplete.The

experimentalgroupwasaskedto,atsomepoint,stopwhatthey

weredoingandexplainanydifcultiestheywerehaving,along

withtheirproposedsolution.Theresultsofthestudyindicated

thatthe experimental groupthathadbeenasked tostop and

verbalizetheirplanhadamuchbetternaldesignthanthecon-

trol groupthatworkedstraightthrough.Evenwithoutproviding

anyfeedback,thestudydemonstratedthatcommunicationitself

altersthewaywethinkaboutproblems.Beingaskedforexpla-

nationsforresults,justicationsofdecisions,andevaluationof

proceduresandresultsrequirespeopletobringinformationinto

workingmemorywhichisnotnormallystoredthere(Wetzstein

andHacker146).Whenyouhavetointeractsociallywithan-

otherpersonaboutaproblem,youloadafullcontextintoyour

memory,whichprovidesyouwithmoreinformationandframing

for theproblem. Then,withthisclearmental snapshotof the

challengesathand,itismorelikelythatyouwillarriveatasolu-

tionthatyouhadnotpreviouslyconsidered.

The results aresimilarwithin the realm of computerprogram-

ming.Pairprogramminghasbeenshowntobemoreeffective

throughanumberofmetrics.TheWilliams(2000)studyshowedanimprovementin [programming]correctness of around15%,

aswellasa2040%decreaseintimeandanincreaseineffort

ofbetween1560%.Theoverallqualityofthecodeisincreased,

whichoverthelifeofasoftwareapplicationdrivesdownallnega-

tivemetrics.Imagineifyourapplicationhad15%fewermistakes

whichtookyou2040%lesstimetox.Thisqualitymakesthe

applicationstableandabletoadapttochanges.

Theimportanceofthisresearchisthatprogrammingisshown

todemonstrateconsistentbenetswhenemployingsomeform

of a communication loop.It is through explanation andverbal

reectionthatwesolveproblemsmosteffectively,inadditionto

creatingsolutionsthataresimpleandreadablefortherestof

theworld.

Bibliography

http://en.wikipedia.org/wiki/Pair_programming

Arisholm, Erik; Hans Gallis, Tore Dyb, Dag I.K. Sjberg (Febru-

ary 2007). Evaluating Pair Programming with Respect to System

Complexity and Programmer Expertise. IEEE Transactions on

Software Engineering 33 (2): 6586. doi:10.1109/TSE.2007.17.

http://simula.no/research/engineering/publications/Aris-

holm.2006.2/simula_pdf_le. Retrieved 2008-07-21.

Models of Interpersonal Communication (Robert M. Krauss and

Susan R. Fussell)

Jonathan Cogley: http://weblogs.asp.net/jcogley/archive/2007/

03/19/pair-programming-improves-your-communication-skills.

aspx

Paul Pagel

is co-founder and software

craftsman at 8th Light. He

has been working in the

software industry for over

5 very unique years. Paul

is among the rst formally

trained software crafts-men. He spent about 3

and a half years apprentic-

ing under the tutelage of

the renowned developers at Object Mentor.

Paul has been a driving force in the realm of Software

Craftsmanship. He was the primary organizer of the

Software Craftsmanship Summit in December 2008

and major contributor to the Manifesto for Software

Craftsmanship (manifesto.softwarecraftsmanship.org).

Not only is Paul a practicing craftsman, but he is also

an active mentor for software apprentices. Participating

in the software community is important to Paul.

> About the author



Graphsandnumberslookliketheycontainalotofinformation,

buttheycanbemisleading.Thisisthestorybehindthechart.

Thisisthenumberoffoundandxeddefectsduringaniteration,

andmoreimportantly,thisiswhatreallyhappened.

The Chart

Thischartshowsthenumberofdefectsfound(red)andthenum-

berofdefectsresolved(green)overathirty-dayperiodonasingle

project.Thisisthemiddleofa project,withnewfeaturesbeing

codedandcheckedin,ongoingtestsbeingconducted,andde-

fectsbeingidentied,xed,andveried.

What It Looks Like

Onthesurface,thischarttellsastory.Itsaysthatbugsareget-

tingfound,andbugsaregettingxedinaboutequalmeasure.

Thecodeischurning,whichisnormalforthemiddleofadevel-

opmentcycle,butisnttrendingtowardstability.Thenumberofbugsfoundslightlyexceedsthenumberofbugsbeingxed,so

thisisaprojecttokeepaneyeon.Thedevelopers(andtesters)

mayneedsomeintervention!

Butisthatreallytherightstory?

What Really Happened

Background

ThisprojectisasoftwaresolutionbeingdevelopedbyaBoston-

basedteam.ThesoftwareisalibrarythatrunsonseveralLinux

variantsandprovidesservicestoenterpriseOEMcustomers.The

teamreliesheavilyonautomationfortesting,andhasalarge

labthatrunsdevelopertests,unittests,buildvericationtests,nightly tests, andmulti-node scaling tests nearconstantly.De-

fectsareloggedbymachines(automaticallywithscripts)andby

humans.Anytestthatdoesnotcompletesuccessfullyisconsid-

eredafailure;teststhatdonotrunorthatarefaultyarelogged

asdefects,aswellastestfailures.Inaddition,supportengineers

logdefectsbasedoncustomerescalations.

Episode 1: Memorial Day

TheMemorialDayholidayoccurredonMay31,2010intheUnit-

edStates.Theofcewasclosed,andlittletonoworkwasdone.

Thedropinthenumberofdefectsidentiedandinthenumber

ofdefectsxedhasnothingtodowiththesoftware.Rather,its

becausenohumanswerendingorxingdefects.

Thatapparentincreasedstability?Thatwasreallyabarbecue

andateamignoringtheircomputersforalongweekend.

Episode 2: The Heat Wave

IntherstweekofJune2010,Bostonexperiencedaheatwave

andhighhumidity.Itsnotuncommon,butthishappenedearlier

inthesummerthannormal.Thebuildingwasunprepared,andtheairconditionerswerenotyetturnedonforsummerweather.

Thespikeindefectsisthelabgettingwarm.Severalmachines

simplygottoohotanddied.Whentheydied,theteststhathap-

What Really Happened

by Catherine Powell

MartinFischer-Fotolia.com

Figure 1



penedtobeusingthosemachinesfailedwithanerrorandauto-

maticallyloggedadefect.

Soaspikeinheatledtoaspikeindefectscreated.Thereisa

spikeinresolveddefectsjustafterwards,astheteamreplaced

thedeadmachinesandtrackedthetestfailurestothosema-

chines.

Episode 3: The File Server Update

Alltestmachinesinthelabuseacentralleserverforstoring

logsandothersharedinformation.OnMay24,theITteamde-

ployedanewleserver.Thiswouldhavebeennehadnotests

beenrunning,butonesetoftestswasstillgoing.Whenthecen-

tralleserverwentdown(forreplacement),itexposedabugin

thetestinfrastructure.Thetestinfrastructurepanicked,discard-

ingmachinesthatdidntworkandgrabbednewmachines,over

andover.Thisstoppedwhenthecentralleservercameback

up,bywhichtimethetestinfrastructurehadusedanddiscarded

24machines.

Onebuginthetestinfrastructure,andonetriggeringeventinthe

formofleserverdowntimecaused24defectstobelogged.The

xtook10minutestoimplement.

Episode 4: The New Operating System

Thisprojectis software running on various avorsof Linux. In

general,thevariousavorsofLinuxareroughlysimilar,butthey

areeachquirkyintheirownway.Inmid-June,theteamdecided

tostartsupportinganewtypeofLinux:RedHatEnterpriseLinux.AteammemberinstalledRedHatEnterpriseonafewmachines,

puttheminthelab,andconguredtheteststostartrunningon

those machines. That night, some ofthe testsfailed,and the

teamcameinthenextdaytondsomebugsspecictoRedHat

EnterpriseLinux.Somewerexed,andanotherspikeoccurred

thenextdayasfollow-onissuesshowedup.

Thisspikeindefectsloggedistheresultofanewfeatureofthe

softwaresupportforanewoperatingsystem.

Episode 5: The Vacation

Inmid-Mayoneofthedeveloperstookaweekofvacation.Witha

smallteamlikethis,thedevelopersvacationmeantthat20%of

theteamwasgoneforaweek.Thechartshowsanunusuallylow

numberofdefectsxed;thisisbecauseasignicantportionof

theteamsimplywasntaroundtoxthings.Thefollowingweek

whenthedeveloperreturnedfromvacationshowsajumpin

thenumberofdefectsxed.

Isthatindicativeofaproblem?No.Itsindicativeofavacation.

Conclusion

Thechartshownaboveimpliesastory.Atrstglanceitsastory

ofsomechurningcodeandsomedeveloperswhojustcantkeep

up.Thatstoryiswrong.Alookatwhatreallyhappenedpoints

totwothings: asmall team,andanunstabletest lab.A more

spikey chart is a consequence of a small team, where the

effects ofone teammemberbeinggonearehighlyvisible; on

largerteamstheeffectofanyonepersonisgenerallysmaller,

sochartsaresmoother.Forthemanagerlookingatthischart,

understandingthestorybehindthelinesofthechartpointsto

needingtospendmoreeffortonstabilizingthetestlabrather

thanonchangingadevelopmentteamsbehavior.

Catherine Powell

has been testing and man-

aging for about ten years.

She is a manager, a tester,

an author and a formal

mentor to testers and test

managers. Catherine has

worked with a broad range

of software, including an

enterprise storage system,a web-based healthcare

system, data synchronization applications on mobile

devices, and web apps of various avors.

With a focus on the human side of software develop-

ment, Catherine builds strong teams spanning testers,

developers, support, product management, and all the

people involved in turning an idea into reality. She em-

phasizes the generation of information and pragmatic

decision making using a myriad of approaches. With

thoughtful techniques that access the strengths of the

human team members combined with the needs of the

system and its users, Catherine guides both developers

and testers to be a valuable part of the decision making

required to create rock-solid software.

Catherine focuses primarily on the realities of ship-

ping software in small and mid-size companies. Spe-

cically, she highlights and works to explicate the on-

the-ground pragmatism necessary for an engineering

team to work effectively with both software and humans

from product denition through release, and in the eld.

> About the author



IfyouareworkingwithanAgileteamorevenaroundone,you

willbefamiliarwiththewordsiterativebuilds,regressiontesting,

automation,feedback,codeexcellence,unittesting,andother

terminologiesthatindicatetestingandquality.Whytestingand

quality? Because this is what differentiates one organization

fromanother,becausequalityisthereasonwhypeopleusecer-

tainproductsandandnotothers,becausequalitymeanssafety,

reliability, efciency and outstanding performance. Nowadays,

organizationsareverycompetitive.Themarketchangesrapidly,

andcustomers demands aresometimeschallenging,so if we

didnotdoourbesttocatchupthetechnologytrain,wewillbewaybehind.Howcanwedothis?Theanswerisbyraisingour

workqualitystandards,becausebelievemeitisallabout

quality.

Asqualityisabasicobjectiveinourwork,andbecauseweare

committed to delivering high-quality products, we will look at

somebasicdenitionsofAgileTesting.WhoaretheAgiletesters,

whatistheirroleinAgileteams,andwhydoweneedAgiletesters

inourteamsanyway?

What is Agile Testing?

AgileTestingissoftwaretestingbasedontheprinciplesofthe

AgileManifesto.Itdiffersfromthetraditionalsoftwaretestingin

theapproachofthetesterandinhowheseesthesoftwareap-

plication.ItisbasedmainlyonPersonasthatareusing/buying

thesystem,i.e.testingfromthecustomerperspective.AlsoAgile

testingisnotanactivitythatcomesattheendofthesoftware

development lifecycle,but it is an iterative activity thatcomes

withintheprojectiterationsthroughoutthewholelifecycleofthe

project.Itisatestearlyandtestoftenactivity.

Agiletestersshoulduseautomationtestingtoeliminatethere-petitivemanualtestingoftheacceptancetestsandtheregres-

siontestsuites.AutomatedtestingisessentialinAgiletestingbe-

causeoftherepetitivebuilds.Testersneedtoperformregression

testingaftereverybuildtomakesurethealreadyimplemented

featuresarestillworkingproperlyandthatthenewlyaddedfea-

tureshavenotintroducednewbugs.

InAgileteams,testersarenolongerintruders.Theyareteam

members,they worktogetherwiththerestof theteam tode-

liverthehighestqualitytosatisfytheircustomers.InsomeAgile

teamstherelationbetweentestersanddevelopersisnotthetra-

ditionalrelationwitheachofthemdefendingtheirsideasifina

battle.InAgileteams,thetestersandthedevelopershavethe

samevisionandthesamegoaltoreach.

Who are Agile Testers?

AnAgiletesterisnotjustaqualitycontrolperson,butisagood

tester withexcellent knowledge of the Agilepracticesand the

developmentlifecycle.Heistheteammemberwhohelpsguide

thewholedevelopmentteaminawaythatensurestheproduct

behavesasintended,andtheimplementedfeaturesareexactly

whatwasagreedwiththecustomerinthestoriesoftheiteration

ortherelease.

TheAgiletesterworkswiththecustomerandthestakeholdersto

understandeveryfeatureoftheprojecttofacilitatethecommu-

nicationbetweenteamandcustomerandtoensurethattheyare

allonthesamepageandspeakthesamelanguage.Forexam-

ple,theteamandthecustomerhaveagreedonthedenitionofa

Done-Donefeature/story,agreeingontheacceptancecriteriafor

eachstory(whichcanbeamajorconictissuebetweencustom-

erandteam);theythereforeneedtohavethesameunderstand-

ingofthedenitionoftheacceptancecriteria.Youhavetotake

intoconsiderationthateverycustomerhashisownpersonality

andhisownbusinessbackground.Soevenifthedevelopment

teamhaspredenedwhattheacceptancecriteriaare,theystillneedtobediscussedwiththecustomer.Thiswaytheywillknow

theircustomerbetterandknowexactlywhatisexpected.

Agile Testing BetweenTheory and Practiceby Sara Medhat

Kzenon-Fotolia.com



Do We Need Agile Testers in our Team?

SomeAgileteamswhichpracticeunittesting,testdrivendevel-

opmentoranyothertypeofcodetestingthinkthattheydonot

needanAgiletesterintheirteam.Theyseeitthisway:wecode,

wetestourcode,wegetfeedbackfromthecustomer,andwe

workonthatfeedback,whatisthevalueofatesterinourteam.

Letmeshowyouthevalueoftestersinanydevelopmentteam,

notonlyanAgileteam.Whatdistinguishesthetesterfromthe

restofthedevelopmentteamisthatwhenatesterteststheap-

plication,hekeepsinmindacoupleofthings:

First:Howwilltheuserdealwiththisapplication?Isitusable?

Doesitfunctioncorrectlyforeveryuseraction?Testersverifythe

applicationagainsttherequirements.OrinanAgileteamthey

verifytheapplicationagainstthestories,andhedoessousing

the predened acceptance criteria.This

typeoftestingiscalledpositivetesting.

Second: Testers think about ways to

break the application, testing the re-

sponseoftheapplicationafterincorrect

user inputs (e.g. wrong entry). How will

theapplicationbehave?Willitbreak?Willitrespondcorrectly?

Inthistypeoftestingthetestervalidatestherequirementsorthe

storiestoseewhatwasnotcoveredwhencoding.Thistypeof

testingiscallednegativetesting,andthisisexactlywhyweneed

testersinourdevelopmentteams,whethertheyareAgileornot.

Mostofthedevelopersdonotconsiderthesetypesofcases,the

breakingtypes.

Whendeveloperstesttheirwork,theytestthenormalcases,they

understandhowthefunctionworksandtheytestthatitworks

thewayitshould,butthenegativetestingofthefunctionisnot

whattheykeepinmindwhiletestingtheirwork.

Anotherreasonwhyweneedtestersinourdevelopmentteamis

thatweashumanbeingsarefallible,andwecannotdiscoverour

ownmistakes,soafresheyetoourworkwillenhanceourwork

quality.Soletsagreethat,whetherweareAgileornot,weneed

softwaretestersinourprojects.

Agile Testers in the Real World

Oneofthemainnaturalchallengeswefaceinourlivesisthatwe

liveinanimperfectworld.Thingswillnotalwaysworkthewaywe

wantitto.Sometimeswehavetochangeourplansandourgoals

tocopewithworldimperfection.Thesechangesmaybetrivialor

crucial,dependingonwhetherwehaveconsideredthemwhen

settingourgoals,orwhathappenedwasnotexpectedandwe

werehitintheface.Inallcases,wekeepaskingthesameques-

tion;howcanwehandleandeliminatetherisksthatmayaffect

ourobjectivetoachievethebestquality?

Bythebook,theAgiletestersroleinanAgileteamisclear,even

ifhemayplaymorethanoneroleintheteam.Weknowthatthe

Agiletesterattendstheiterationplanning,releaseplanning,ac-

ceptancecriteriawriting,feedbackmeetingswithclients,demo

meetingwithclients,functionalitytestingforeachstoryduring

theiteration, performs acceptancetests perstory,and regres-

siontestingaftereachbuild.TheAgiletesterveriesandvali-

dateseverystorydeliveredtothecustomerandmakessurethat

theDone-Donecriteriaaremet.

Intherealworld,theAgiletestersrolemayvaryfromthisspe-

cicdenedrole.Becauseweliveinanimperfectworld,wecan

expectcomplicationsalongtheway.Throughoutanyprojectthe

developmentteammayfacesomeobstaclesthatmaycause

unintentionallydiversionsfromtheirclearlydenedway.

Complicationsmaybefromtheteamsideorfromthecustomer

side,ormaybeboth.Itcouldbetheperformanceofoneteam

memberthataffectstherestoftheteam,itcouldbeamisunder-

standingoftheprojectscopeand/orre-

quirementsthatcauseaconictbetween

team members or between team and

customer,itcouldbeamisunderstanding

ofAgileimplementationorabsenceofan

Agilecoachtoguidetheteam,itcouldbe

latedeliverythatcausestrustissuesbe-

tweentheteamandtheclient,itcouldbescopecreeporthatthe

clientkeepschanginghismindwithnewrequirementswhichaf-

fecttheprojecttime,theteameffort,itcouldliterallybeanything

thataffectstheteamsproductivityorthequalityofthedelivered

project. During iteration planning, release planning, or project

planning,theteammaytakeintoconsiderationsomeoftherisks

thattheyarealreadyawareof,risksthatmayaffecttheirproject,butsometimeswegetrisksthatwedidnotknowabout,risksthat

evolvewhiletheteamisworking.

Be Part of the Solution, Not the Problem

Applying riskassessmentin the chartering phase willelimi-

nateasmuchaspossibleanyfuturerisksthattheteamcould

faceduringdevelopment.AsanAgiletester,youshouldraisea

agwithanypotentialproblemsyoumayface,likeundened

scope,lotsoftestingactivity,theneedformoretestersinthe

team,and/oranuncleartestplan.Ifyouarenotsureofwhat

youaregoingtotest,thenyoushouldaskforhelp.

Behonest.ThisismeantnotonlyfortheAgiletester,butfor

thewholeteam.Behonestwithyourselfandyourteam.Ifyou

canthinkofanythingthatmaydisrupttheteamprogressinthe

future,youshouldbeclearandadmititfromthebeginning.

Ifyoudo not havetheskill.If theteam plansto use a new

technology,orwillapplysomenewpracticesthatyouarenot

familiarwith,youmaywellbeeagertolearnthese,butthis

maynotbeforthebenetoftheproject.Iftimeistight,orthe

workloadistoomuch,theywouldbebetteroffwithanalready

experiencedpersontohelpwiththedelivery.Sobehonestand

tellyourteamyourconcerns.Demanding customer. What if the team has a demanding

customerthatwantseverythingatthesametimeandatthe

sameprice.Thiskindofcustomerisdenitelyaheadachefor

Sometimes we have to change

our plans and our goals to cope

with world imperfection.



Sara Medhat

is a senior software test

engineer, ISTQB (Interna-

tional Software Testing and

Qualications Board) certi-

ed, and software testing

trainer with ve years of ex-

perience in the quality con-

trol and software testing

eld. For the last two years

she has been working with

agile teams as an agile tester and project coordinator.

She has published an article about Agile Adoption in

Agile Record issue No. 2. She is also a co-speaker at the

Agile2010 conference with Dr. Ahmed Sidky in a ses-sion about How an Agile Project can Fail; and what to

do about it.

> About the author

theteamandforthewholeorganization.Agileteamsinpar-

ticularknowthevalueofcustomersatisfactionandcontinuous

feedback,butwhosaidthatfeedbackisforfree,andwhosaid

managing thecustomermeans saying no to hisrequests. It

ishardtokeepyourcustomersatisedandatthesametime

keepyourprojectwithinbudget,butthatiswhatgoodteams

andgoodmanagersarefor.

Testers and Project Failures

Cantesterscauseaprojecttofail?Well,inagiledevelopment,as

weknow,qualityiseveryonesresponsibility,notonlythetesters.

Everyteammemberisresponsiblefordeliveringhispartwiththe

bestqualityhecan.Ofcourse,wecannotdenytheimportantrole

ofthetesterinthedeliveryorintheprojectquality.Thetester

istheonewhodecidesthateverythingisokayandthatwecan

delivertothecustomer,sopoortestingorapoortestplanwill

causethedeliveryofabuggyapplication,whichmayaffectthe

organizationsfuturebusiness.

The good understanding of the project requirements/stories,

goodknowledgeoftheAgileprocess,understandingthecustom-

erneeds,and,ofcourse,excellentunderstandingofthetesting

techniquesusedwithinyourprojectwillempowerthetesterto

decidewhethertheprojectmeetsthequalitystandardsagreed

withthecustomer,orwhetheritisadisasterandthecustomer

shouldknownothingaboutit.

Attheend,itisallaboutquality.WhetheryouareAgileornot,

whetheryouareatesterornot,youworkinateamandthequal-

ityisthewholeteamsresponsibility.Wemayfacesomeobsta-clesalongourway,butthisislife,itisallaboutchallenges.So

areyoureadytofaceyournextchallengeandtakeitasastep

towardsreachingyourgoals?

iS

tockphoto.com/mariusFM77

Wir suchen

Senior Consultants

IT Management & Quality Services

(m/w)

www.diazhilterscheid.de

Wachsen Sie mit uns!


17/70



Value-Driven DevelopmentPrinciples and Values Agilityis the Tool, Not the Master

by Tom Gilb

MikhailTolstoy-Fotolia.com

Introduction

TheAgileManifesto[2]hasitsheartintherightplace,Iamonly

worriedaboutitsmind.AnditsrstprincipleOur highest prior-

ity is to satisfy the customer through early and continuous deliv-

ery of valuable software,iscentraltotheideasinthisarticle.

ItisnotstrangethatIagree,sincemanyoftheAgilistas,forex-

ampleKentBeck,explicitlypointtomy1988bookasasourceof

someoftheirideas[4,5,6,7,8,9,12].

Myproblemwithagile isnot inits ideals, but inthe everydayteachingandpracticeswesee.Whatweseeisthesameproblem

thathasbeenafictingallsoftwareandITprojectslongbefore

agileappeared.Ourtechnocraticculturehasforgottenourstake-

holdersandtheirvalues.

Thepracticesarefartooprogrammercentric,andfartoolittle

stakeholdervaluecentric.Theresultisthatworkingsoftware

[2]isdeliveredtoacustomer[2].

However,necessaryvaluesarenotnecessarily,andalltoorarely,

deliveredtoall critical stakeholders.Codehasnovalueinitself.

Wecandeliverbug-freecode,thathaslittleornoneofthean-

ticipatedvalue.Wecandeliversoftwarefunctions,asdenedin

requirements,tothecustomerbuttotallyfailtodelivercritical

valuetomanycriticalstakeholders.

The Opera ticket system at the magnicent new Oslo Opera

Houseisasimpleexample.Intheolddays,aticketwasripped

off a stack andimmediately deliveredto the ticket buyer. The

newsystem,atopening,took1020minutesfortheticketsell-

erstonegotiatewhattodoandhowtodothingslikeseniorand

childdiscounts.Withfrequentaccesstosupervisors,whowere

notsureofwhatorhow.Nobugs,allthefunctions,butsome-thingwascatastrophicallywrong.Working software working

badly.ThankGod,theAgilistasdidnotdesigntheOperaHouse

itself!Thatwasdonebyrealrst-classarchitects![3]

Ifearthisarticlemaynotcorrectthenarrow-mindednessofthe

codercommunity,andmyprinciplesdoapplytoahigherlevelof

thinkingthancoding.Iamgoingtotrytoformulateamuchclear-

ersetofprinciples,amoreexplicitset;andinthesubsequentar-

ticle,IwillformulateclearervaluesthantheAgilistasmanaged

todo.Ihaveonedecidedadvantage:Iamnotsubjecttolowest

commondenominatorpolitics,astheywere;Icanexpressmy

ownopinionunopposed!Iherebygivethemspecicpermission

toupdatetheirwoolyanddangerousidealswiththesemorefo-

cussedideals.Andbecausetheywont(chiselledinstone,unag-

iledocumentationManifesto)Igivethereadertherighttospreadit,andupdate,andimproveit,astheylike.

Value Principles

Principle 1. Control projects by quantied critical-few results.

1 page in total!(Notstories,functions,features,usecases,ob-

jects,)

Mostofourso-calledfunctionalrequirementsarenotactuallyre-

quirements.Theyaredesignstomeetunarticulated,higher-level,

andcriticalrequirements[14].For examplethe requirementto

haveapasswordishidingtherealSecurityqualityrequirement

[13].Mostofthereallycriticalprojectobjectivesarealmostal-

waysburiedinoldmanagementslides,andformulatedinawooly

andun-testableway.Theyareneverusedinarchitecture,con-

tractingortesting.Thisisamajorcauseofprojectfailure[14].

Managementandprojectsponsorsareledtobelievetheproject

willdelivercertain improvements.In practice the agileculture

hasnomechanismforfollowingupanddeliveringexpectedval-

ues.Scrumwouldarguethatthatisthejoboftheproductowner.

However,eventopScrumgurusopenlyacknowledgethatthesit-

uationinpracticeisnowherenearwhatitshouldbe.Wesimply

donotteachandpracticethenecessarymechanisms.Softwarepeoplewerealwaysbadatthis,butagiledidnotdeliverclear

idealsonitsown.

Part1of2:

Gilbs Ten Key Agile Principles to deliver stakeholder

value, to avoid bureaucracy and to give creative freedom

(Part2,Values for Value,nextissue)


19/70



Principle 2. Make sure those results are business results, not

technical.Alignyourprojectwithyournancialsponsorsinter-

ests!

Peopledonotdodevelopmentprojectstogetfunction,features

andstories.Yettheseseemprimaryinthecurrentagilemethods.

Weneedfunctions,storiesandperhapsfeaturestomakesure

theapplicationwilldothefundamentalbusinessactivitiesthat

areexpected(e.g.issue an opera ticket, give a child discount).

Butthesefundamentalsarenevertheprimarydriversforthein-

vestmentina developmentproject.Asarule,the stakeholders

alreadyhavethosefunctionsinplace,incurrentsystems.Ifyou

lookattheprojectdocumentation,someonesoldmanagement

onbettersystemssomeimprovements.Faster,cheaper,more

reliableetc.

These are always improvements that are specically stated

somewhere,andtheyarealwaysquantiable,.Unfortunately,we

inagiledevelopmentavoidbeingspecicat this level.Weusead-

jectiveslikebetter,improved,enhancedandleaveitatthat.

Wehavelearnedlongagothatourcustomeristoouneducated

andtoostupid(commonsense shouldcompensateforlackof

education)tochallengeusonthesepoints.Andtheyhappilypay

usalotofmoneyforworsesystemsthantheyalreadyhave.

Weneed tomake itpart of our development culture tocare-

fullyanalyzebusinessrequirements(savemoney),tocarefully

analyzestakeholderneeds(reduceemployeetrainingcosts),to

carefullyanalyzeapplicationqualityrequirements(vastlybetter

usability).Weneedtoexpresstheserequirementsquantitatively.

Weneedtosystematicallyderivestakeholderrequirementsfromthe businessrequirements.We needto derive the application

qualityrequirementsfrom the stakeholder requirements. Then

weneedtodesignandarchitectthesystemstodeliverthequan-

tiedrequirementlevelsontime.Wearenowhereneartryingto

dothisincurrentconventionalagilemethods.Soweconsistently

failthebusiness,thestakeholders,andfailtodeliverthequality

levelsrequired[15].

Letme beclear here.You can dothisas the system evolves,

anditcanbeexpressedonasinglepageofquantiedtoplevel

requirements[examples14].Sodonttrytheupfrontbureau-

cracyargumentonme!

Principle 3. Give developers freedom, to nd out howto deliver

those results.

TheworstscenarioIcanimagineiswhenweallowrealcustom-

ers, users, and our own salespeople todictatefunctionsand

featurestothedevelopers,carefullydisguisedascustomerre-

quirements.Maybeconveyedbyourproductowners.

Ifyougoslightlybelowthesurfaceofthesefalserequirements

(means,notends),youwillimmediatelyndthattheyarenotreallyrequirements.Theyarereallybadamateurdesignforthe

realrequirementsimplied,butnotwelldened[17].Igave

oneexampleearlier(arealone,Ohio),whereapasswordwas

required,butsecurity(the realrequirement)wasnotatallde-

ned.

Wearesobadatthis,thatyoucansafelyassumethatalmost

all so-called requirements are not real requirements, theyare

bad designs.Allyouhavetodo toseethisis ask:WHY? Why

password? (Security, stupid!) Oh! Whereis the securityre-

quirement? Not there, or worse, stated in managementslides

asstate-of-the-artsecurityandthenlefttototalamateursto

designitin!

Imagine if Test Driven Development (TDD) actually tested the

qualitylevels,likethesecuritylevels,tostartwith?Farfromit;

andTDDisanotherdisappointmentintheagilekitbag.

Ianalyzerealrequirementsaboutonce aweek,internationally,

andndveryfewexceptionsi.e.situationswheretherealre-

quirements are dened, quantied, and then designed (engi-

neered,architected)towards.Agileculturehasnonotionofreal

engineeringatall.Softcrafting[4],sure.Butnotengineering

totallyalien.

Youcannotdesigncorrectlytowardsavaguerequirement(better

security).HowdoIknowifapasswordisagooddesign?Ifthe

securityrequirementsareclearandquantied(andIsimplify!)

likeLessthan1%chancethatexperthackerscanpenetratethe

systemwithin1hourofeffort,thenwecanhaveanintelligent

discussionaboutthe4-digitpincodethatsomethinkisanOK

password.

Ihaveoneclient(Conrmit,[16])whopointedlyrefusestoaccept

functionsandfeaturesrequirementsfromanycustomerorsales-

person.Theyfocusonafewcriticalproductqualities(likeusabil-

ity,intuitiveness)andlettheirdevelopersengineertechnicalso-

lutionstomeasurablymeetthequantiedqualityrequirements.

Thisgetstherightjob(design)donebytherightpeople(devel-

opers)towardstherightrequirements(higherleveloverallviews

ofthequalitiesofthe application).Theyevendotheirrefactor-

ingbyiteratingtowardsasetoflong-termqualityrequirements

regardingmaintainability,andtestability.Probablyjustacoinci-

dencethattheirleadershaverealengineeringdegrees?

Principle 4. Estimate the impacts of your designs, on your

quantied goals.

Itakequantiedimprovementrequirementsforgranted.Sodo

engineers.Agilistasdonotseemtohaveheardofthequantied

qualityconcept.This means theycannotdeal withspecic,or

high,qualitylevels.

Theconceptofdesignalsoseemsalien.Theonlymentionofde-

signorarchitectureintheAgileManifestois The best architec-tures, requirements, and designs emerge from self-organizing

teams.[2].Thereissomemeritinthisidea.But,theAgileview



Berlin, Germany

IT LawContract Law

GermanEnglishSpanishFrench

[email protected]

k a n z l e i h i l t e r s c h e i d

KatrinSchlke



onarchitectureanddesignismissingmostallessentialideasof

realengineeringandarchitecture[18].

Wehavetodesignandarchitectwithregardtomanystakehold-

ers,manyqualityandperformanceobjectives,manyconstraints,

manyconictingpriorities.Wehavetodoso inanongoingevo-

lutionary sea of changes with regard to all requirements, all

stakeholders,allpriorities,andallpotentialarchitectures.Simply

pointingtoself-organizingteamsisamethodfallingfarshortof

necessarybasicconceptsofhowtoarchitectandengineercom-

plex,large-scalecriticalsystems.Indeed,evenformuchsmaller

systemssuchasthe13-developerConrmitsystem[16].

Anyproposeddesignorarchitecturemust

becomparednumerically,withestimates,

thenmeasurements,ofhowwellitmeets

the multitudeof performance and qual-

ity requirements; and towhat degree it

eatsupresources,orthreatenstoviolate

constraints.IrecommendtheImpactEstimationtableasabasic

methodfordoingthisnumericcomparisonofmanydesignsto

manyrequirements[19,10,4].Ithasbeenproventobeconsis-

tentwithagileidealsandpractices,andhasbeengivenfarbet-

terreportedresultsthanothermethods[16].Ifothermethods

havebetterresults,theyareunabletoreportthemconvincingly,

sincetheydonotdealnumericallywiththevaluesandqualities

ofstakeholders.

Ifadesignerisunabletoestimatethemanyimpactsofasug-

gesteddesignonourrequirements,thenthedesignerisincom-

petent,andshouldnotbeemployed.Mostsoftwaredesignersarebythisdenitionincompetent.Theydontjustfailtoestimate,

theydonotevenunderstandtheirobligationtotry!

Principle 5. Select designs with the best value impacts for

their costs, do them rst.

Assumingwendtheassertionabove,thatweshouldestimate

and measure thepotential, and real, impacts of designs and

architecture on our requirements, to be common sense. Then

Iwouldliketoarguethatourbasicmethodofdecidingwhich

designstoadoptshouldbebasedonwhichoneshavethebest

value for money. Scrum, likeother methods, focuses narrowly

on estimatingeffort. This is not the same as also estimating

themultiplevaluescontributedtothetoptenprojectobjectives

(whichImpactEstimationdoesroutinely)[19].Itseemsstrange

tomethatagilemethodsunderstandthe secondaryconceptof

estimatingcosts,butneverdealwiththe primaryconceptofes-

timatingvaluetostakeholders,andtotheirrequirements.There

islittlepointinmanagingcost,ifyoucannotrstmanagevalue.

ThedeeperproblemhereisprobablynotAgilemethods,butis

atotalfailureofourbusinessschoolstoteachmanagersmuch

moreaboutnance,andnothingaboutqualityandvalues[20].

Ifmanagementwereawakeandbalanced,theywoulddemandfarmoreaccountabilitywithregardtovaluedeliveredbysoftware

developersandITprojects.Butthedevelopmentcommunityhas

longsincerealizedthatmanagementwasasleeponthejob,and

lazilytakenadvantageofit.

Principle 6. Decompose the workow into weekly (or 2% of

budget) time boxes.

Atonelevel,theAgilistasandIagreethatdividingupbigprojects

intosmallerchunks,ofaweekorso,ismuchbetterthanaWa-

terfall/BigBangapproach[21].

However, I wouldarguethatwe need todo more than chunk

byproductownerprioritizedrequirements.Weneedtochunk

thevalueowitselfnotjustbystory/function/usecases.This

valuechunkingissimilartotheprevious

principleofprioritizingthedesignsofbest

value/cost.Weneedtoselect,nextweek

(nextvaluedeliverysteptostakeholders)

thegreatestvaluewecanproduceinan

arbitrarilysmallstep(ourteam,workinga

week).InprinciplethisiswhattheScrum

Productownershouldbedoing.ButIdontthinktheyareeven

remotelyequippedtodothiswell.Theyjustdonothavethequan-

tiedvaluerequirements(above),andthequantieddesignesti-

mates(above)tomakeithappeninalogicalmanner.

OnedisputeIdonotseemtohavewithAgilistasisaboutwhether

youcaninfactdivideanyprojectintosmall(2%ofbudget)deliv-

erysteps.Indthatyoualwayscan,buttherearealotofpeople

outtherewhoare rmly,andfalsely,convincedit isimpossible

[21].Butmaybethedisputewillsurfacewhentheyareconfront-

edwiththeneedtochunkbyvalue,notbyfunction.

Principle 7. Change designs, based on quantied value and

cost experience of implementation.

If you get stepwise numeric feedback on the actual delivered

valueofadesign,comparedtoestimatedandperceivedvalue,

asisnormalatConrmit[16],thenyouwilloccasionallybedisap-

pointedwiththevalueachieved.Thiswillgiveyoutheopportunity

toreconsideryourdesign,oryourdesignimplementation,inor-

dertogetthevalueyouneed,irrespectiveofyourpreviouslack

ofunderstanding.Youmightevenlearnthatcodingaloneisnot

enoughtodelivervaluetostakeholders.

Ifearthatthisrealisticinsightpossibilityislargelylost;sincethe

agilemethodsneitherquantifythevaluerequired,nordothey

quantifythevalueexpectedfromasteporadesignatagiven

deliverystep.

Theresultisthatwegetstuckwithbaddesignsuntilitistoolate.

Tome,thatdoesnotseemveryagile.

Principle 8. Change requirements based on quantied value

and cost experience, new inputs.

Sometimes the quantied quality and value requirements are

overambitious.Itistooeasytodreamofperfection,andimpos-

sibletoactuallygetit.Itistooeasytodreamofgreatimprove-

Sometimes the quantied

quality and value requirements

are overambitious.



ment,withoutbeingawareofitstruecost,orstate-of-the-artlimi-

tations.Sometimeswehavetolearntherealityofwhatwecanor

shouldrequirebypracticalexperience.Thisisofcoursenormal

engineeringandscience.Tolearntechnicalandeconomicreali-

tiesstepbystep.

Theagilecommunity,however,has,aswehavepointedout,little

concept of quantifying any requirements. Consequently, they

cannotlearnwhatisrealistic.Theywilljustgetwhattheygetby

chanceorcustom.

If they actually quantied their key requirements, and if they

measuredtheincrementalnumericresults,thenifrequirements

wereeitheroverambitiousorunacceptablycostly,wewouldhave

a chance to reactquickly(agility!). Learning and agilechange

arethreatenedbythelackofquanticationandmeasurement

inthenormaldevelopmentprocess.Buttodaysagilecommunity

remainsunconcerned.

Principle 9. Involve the stakeholders, every week, in setting

quantied value goals.

Agilemethodsrefertousersandcustomers.Thetermsusedare

sponsors,developers,andusers,customers.In systemsengi-

neering(incose.org)thereisnodoubtthatthegenericconcept

isstakeholder.Somepartsofsoftwareengineeringhavebeen

adoptingastakeholderparadigm[22].Butagilemethodsdonot

mentiontheconcept.Inrealprojectsofmoderatesize,thereare

20to40interestingstakeholderrolesworthconsidering.Stake-

holders aresourcesof criticalrequirements.Microsoftdid not

worryenoughaboutastakeholdercalledtheEUacostlymis-take.Ineveryfailedprojectandwehavefartoomanyyouwill

ndastakeholderproblemattheroot.Stakeholdershavepriori-

ties,andtheirvariousrequirementshavedifferentpriorities.We

havetokeepsystematictrackofthese.Sorry,ifitrequiresmental

effort.Wecannotbelazyandthenfail.IdoubtifaScrumproduct

owneristrainedorequippedtodealwiththerichnessofstake-

holdersandtheirneedsInfact,thePOseemstobeadangerous

bottleneckinthisconcern.

However,itcanneverbeasimplematterofanalyzingallstake-

holders and theirneeds and the priorities of those needs up

front. The fact of actual value delivery on a continuous basis

will changeneeds and priorities.The external environmentof

stakeholders(politics,competitors,science,economics)willcon-

stantlychangetheirpriorities,andindeedevenchangethefact

ofwhothestakeholdersare.Soweneedtokeepsomekindof

lineopentotherealworld,onacontinuousbasis.Weneedtotry

tosensenewprioritizedrequirementsastheyemerge,infront

ofearlierwinners.Itisnotenoughtothinkofrequirementsas

simplefunctionsandusecases.Themostcriticalandpervasive

requirementsare overallsystemqualityrequirements,and itis

thenumericlevelsoftheilitiesthatarecriticaltoadjust,sothat

theyareinbalancewithallotherconsiderations.

Atrickybusinessindeed,butarewegoingtoreallybeagile?

Thenweneedtoberealisticandcurrentagilemethodsarenot

evenrecognizingthestakeholderconcept.Headinthesand,if

youaskme!

Principle 10. Involve the stakeholders, every week, in actually

usingvalue increments.

Finallythestakeholdersaretheoneswhoshouldgetvaluede-

liveredincrementally,ateveryincrementofdevelopment.

Ibelievethatthisshouldbetheaimofeachincrementandnot

deliveringworkingcodetocustomers.Thismeansyouneedto

recognizeexactlywhichstakeholdertypeisprojectedtoreceive

exactlywhichvalueimprovement,andplantohavethem,ora

usefulsubsetofthem,onhandtogettheincrement,andevalu-

ate the valuedelivered. Current agilemethods are not set up

todothis,andinfactdonotseemtocareatallaboutvalueor

stakeholders.

Infact,developerswouldhavetoconsiderthewholesystem,not

justthecode,inordertodeliverrealvalueandcodersfeelvery

uncomfortablewithanythingoutsidetheirnarrowdomain.

Isntitisamazingthattheyhavebeengivensomuchpowerby

managerstoscrewupsociety?

Here is an overview of my Agile Values, the subject of a more

detailed article in the next issue.

My 10 Agile Values? Tom Gilb 2004-10

Simplicity

1. Focusonrealstakeholdervalues

Communication

2. Communicatestakeholdervaluesquantitatively

3. Estimateexpectedresultsandcostsinweeklystepsandget

quantiedmeasurementfeedbackonyourestimatesthesame

week

4. Installrealquantiedimprovementsforrealstakeholdersweekly

5. Measurethecriticalaspectsintheimprovedsystemweekly

6. Analyzedeviationsfromvalueandcostestimates

Courage

7. Changeplanstoreectweeklyquantiedlearning

8. Immediatelyimplementthemostvaluedstakeholderneedsby

nextweek

Dont wait, dont study (analysis paralysis), dont make excuses.

Just do it!

9. Tellstakeholdersexactlywhatquantiedimprovementyouwill

delivernextweek

10. Useanydesign,strategy,method,processthatworkswellquan-

titativelyinordertogetyourresults

Be a systems engineer, not a just a programmer (a Softcrafter).

Do not be limited by your craft background, in serving yourpaymasters.


24/70


25/70



Dont Procrastinate

Itsalwayseasyto leavethingsforlater,butthe consequences

arealmostalwaysbad.Usually,thereisnologicalreasontodefer

anything,starting withsimplethingssuch as paying yourbills,

andendingwithdealingwithyourprojectsproblems.Theywont

justgetsolvedbythemselves;theyareonlygoingtogetworseas

timepasses.Whatismore,thereareforsuresomepeoplerely-

ingonyouandwaitingforyoutonish,inordertobeabletodo

theirjob.Youowethesepeopletogetyourjobdoneassoonand

aswellasyoucan.

Respect Your People

Theyve made it to this team thanks to their qualities and

strengths.Theyhavedevelopedintoexperiencedprofessionals,

ortheyarejusttakingtherststeps.Anyhow,theyaretheones

directlyhelpingyoudoyourjob,andrespectisoneofthekeyfac-

torsinanygoodrelationship.

Trust Them

Therearetwokindsofpeople.Theonesthinkingthattrustisto

beearned,andtheotherswhotrustpeoplefromthebeginning,

onlytoloseitiftheygetletdown.Ipersonallybelongtothelatter,

butIndworthmentioningthattrustingsomeonedoesntmean

beingnaive.Youstillhavedeadlinestomeet,youstillhaveto

makesureyourteamisproducingqualitywork,sothereisavery

thinlinebetweenbeingtrustingandbeingtooloose.

Dont Lose Control

Thereisanoldsaying:Trustisgood,controlisbetter.Youmaybe

shockedtondoutitbelongstonootherthanJosephStalin,butIconsiderthisonlyprovesthatevenvillainscanbeprettywise

fromtimetotime.Evenifyouareluckytohavecompetentpeople

inyourteam,youstillhavetondnon-intrusivewaysofkeeping

trackof yourschedulesandcommitments.Thinkingaboutthat

nelineagain

Dont Micromanage

Whilebeingconfrontedwithstressfulsituationsortightcommit-

ments,youcaneasilyturnintoacontrolfreak.Youmayfeelthe

needtoknoweveryaspect,everydetail,inordertobeableto

have everythingunder control. Humans, however, are notthatmulti-threaded,sotheyneedtosurroundthemselveswithtrust-

worthyandskilledpeoplewhotheycanrelyon,ratherthantrying

tosqueezeeverybitofinformationintotheir20%-usedbrain.

Listen and Make Sure They Listen to You

Youwanttobeconstantlyawareofyourpeoplesneedsandprob-

lems,whilemakingsuretheyknowyourexpectations.Youhave

everyreasonintheworldtobeattentivewhileinmeetingswith

yourfellowleadersandmanagers,butalsotobeabletoleave

relievedthattheyallknowyourteamsstatusoryourpersonal

pointsofview,whenthemeetingisover.Findingtherightwaysto

communicateisthereforecrucial,andyetsodifferentfromone

situationtoanother.

Never Wait

Leaders arent waiting, theyre acting. Being reactive, or even

worsepassive,isntpartofaleadersjobdescription.Agood

waytotellifyouarebeingproactiveenoughistoaskyourself

thisquestion:Usually,whenmymanagerasksmesomething,do

Iknowtheansweronthespot,ordoIhavetonditout?Ifyou

arealwaysbeingtoldwhattodo,youprobablyarentmuchofaleaderafterall.

Leah-AnneThompson-Fotolia.com

Things Ive Learned the Hard Way

by Alex Rosiu



Be What You Want Them to Be

Beingaleadermeansheavingpeoplefollowyou.Butiftheynd

youworthyinanyway,theywillalsoborrowfromyourwayofbe-

ing,moreorlessconsciously.Yourbehavioristhereforecrucially

determinativefortheirown,sounlessyoudontwanttobesur-

roundedbyjerks,makesureyourenotone.Unfortunately,nega-

tivebehaviorsareeasytoimitate,butthegoodnewsis,positive

thingsarealsoquitecatchy.

Alex Rosiu

is a Technical Project Man-

ager at BitDefender, a se-

curity software company.

As a computer science

graduate, he started his

career as a software de-

veloper, moving on to tech-

nical lead as soon as his

experience allowed me to.

As a Certied Scrum Master, he nds great interest in

mentoring and implementing the Agile practices in his

company. He is an active member of the Agile Alliance

and the Scrum Alliance, and he also enjoys sharing his

professional experiences on his personal blog:

http://alex.rosiu.eu.

> About the author



Introduction

Softwaretestautomationhasbeenavailableforoveraquarter

ofacentury,butthepracticestillhasmanyskeptics,andthe

biggestbarriertoadoptionremainsthelevelofmaintenancere-

quiredtosustainit.Achievingjusta moderatelevelof automa-

tioncoveragerequires considerable investment of budget and

resource.Withincreasingsoftwaredevelopmentcomplexityand

moreandmoreITdepartmentstakingonanagileapproach,tra-

ditionaltestautomationhasbecometoocumbersomeformost

tosustain.

But Why is Test Automation so Cumbersome?

Traditionaltest automationsystems originatedin a world that

movedat a much slower pace, wherewaterfall developments

weretheonlygameintownandno-oneattemptedtotacklefast

moving,mission-criticalapplications theyknewthatthetech-

nologysimplycouldntkeepup.

Theseproductsallgettheircapabilitiesfrompowerfulscripting

languages;somethingthatsoundsgoodinapresentation,but

hasbecomeahorrorintherealworld,requiringacultofhigh

priests,who are highly skilled and paid test automation engi-

neers,tocommunicatewiththecomplexandmysteriousdeity;

thetestautomationtool.

Worsestill,thescriptlibrarytookweeksandmonthstodevelop.

ThiswassomethingthatwasrationalizedasOK,becauseyou

couldwrite the scripts in parallel withcode development. The

truthwas somewhatdifferentas thescriptrequiredknowledge

of how the developers were naming thevisual components

somethingthatwasneitherconsistentnorpredictable.Because

ofthis,thecode-basedtoolsrevertedtoarecordmodetoes-tablishtheinitialscript,whichmadethemonlyusableoncethe

applicationwascomplete.Thiswasmorepractical,butnowthe

automationcodingeffortcouldntevencommenceuntilsections

ofthecodewerecompleteandstable.

Itgotworse.Mostofeachscriptthatneededtobecodedhad

nothingtodowithtestingtheapplication.Theengineershadto

overcomemanychallengesbeforetheycouldevengetthatfar

handlingunpredictableresponsetimes,retrievingdisplayeddata

needed for validation, and establishing checkpoints to signify

whentheapplicationhadcompletedalogicalstep.

Butthedeathknellwaswhathappenedwhentheapplicationtobe tested changed. Suddenly allthese laboriouslycreatedas-

setswereworthnothingandwouldnotexecuteuntiltheentire

processhadbeenrepeated.

Whathappenednextrangedfromthesanetothealmostcomi-

cal.Thesaneorganisationsdidwhatcamenaturallyandgaveup.

Otherswerenottobedefeatedandthrewevenmoreexpensive

resourcesattheproblem,somehidingthefailurebyoutsourc-

ingtheentiretestburdenoftentocompanieswhodidmostof

thetestingmanually.Allthisforaninitiativewhichwasmeantto

reducetheneedforresources,savetimeandimprovequality!

Toputthisinperspective,industryanalystsstatethatthehigh

watermarkinautomationsuccessiswhen20%ofanapplica-

tionhasbeenautomated.Thisisthehighwatermark,mindyou,

nottheaverage,20%isthepeakofwhatyoucanexpectafter

a nancial investment measured in hundredsof thousandsof

dollarsandaneffortinvestmentmeasuredinmanymanyears.

The Current Need for Speed

Thewayweworkhasalsochanged.Inthelastdecadetherate

ofbusiness changehasrisenbeyondanything wecould haveexpected. The availability of new technology and the strategic

advantagethatitcanpotentiallyprovidebusinesseshasfuelled

The Art of Throw-AwayTest Automation

by George Wilson

MichaelFlippo-Fotolia.com

Business agility requires disposable test assets



this, alongwith the needto adaptquicklyto changing market

requirements.Therecessionhasarguablyexasperatedthesitua-

tion.Asthefortunesofmarketschangeandmovewithafrighten-

inglysuddenpace,everybusinessndsitselfneedingtoachieve

more,withstaticorreducedbudgetsandresources.

AgiledevelopmentisexperiencingincreasingpopularityinITde-

partments,becausetodaysfast-pacedbusinessenvironmentre-

quiresanorganisationsdevelopmentprocesstobeexibleand

adaptabletochangingneeds.TheAgilemodelprovidesfrequent

delivery,increasedcustomerinvolvementandhelpstodealwith

theproblemofrisingcomplexityinsystems.However,withallthe

benetsofamoreuid,exibleprocess,comechallengesinhow

toassurethequalityandgovernanceoftheseever-changingap-

plications.

QA teams now have to accept that requirements can often

changeduringandaftereachiteration,dependingonthefeed-

backfromthecustomer.Thesechangesinrequirementsarecon-

sequentlyreectedinthecodeandtheteststhatQAteamshave

todevelop,whichinturncanleadtoalargeamountofrework

andscriptmaintenance.

Withdeliverycyclesgettingshorter,and withsecurityconcerns

andnewregulationstomanage,applicationsarebecomingmore

likelivingthings;beingsthatgrowandmature,morphingfrom

new-bornstatustoanalmostunrecognizablefullygrownadult

withalltheassociatedtrappingsanddocumentsthatadultstend

tocollectthroughouttheirlives.

How on earth is outdated and cumbersome test automationtechnologysupposedtocopewiththislevelofchangeandcom-

plexity?Itsimplycant.

Still Stuck in the 90s

IreadaninterestingcommentbyJamesA.Whittakerinhisblog

postStillStuckinthe90s.

Dontgetmewrong,softwaretestinghasbeenfullofinnova-

tion.WevemintedpatentsandPhDtheses.Webuilttoolsand

automatedthecrudoutofcertaintypesofinterfaces.Butthose

interfaceschangeandthatautomation,wendtoourdistress,

israrelyreusable.Howmuchrealinnovationhavewehadinthis

disciplinethathasactuallystoodthetestoftime?Iarguethat

wevethrownmostofitaway.Adisposabletwodecades.Itwas

too tied to the application, the domain, the technology. Each

projectwestartoutbasicallyanew,reinventingthetestingwheel

overandover.Eachyearsinnovationlooksmuchthesameas

the yearbefore.1990 quickly turns into2010and we remain

stuckinthesameoldrut.

HPinarefreshingburstofhonestynowstatethatunlessyouwill

runascriptaminimumofseventimes,therewillnotbeanypay-backfromautomation.Thatisoneheckofastatement.Anypart

ofanapplicationthatneedstobetestedatleastseventimes,

suggestsanalmoststaticapplication,notonethatisasubjectof

activedevelopmentefforts.Thissortofautomationisneforre-

gressiontests,butwillnotmakeanyimpactoncurrentQAbottle-

necks.Theneedisforasolutionthatisfaster,lighterandbetter

abletorespondtodynamicapplicationdevelopments.

Inshort,themodernbusinesswithallitsneedforspeedandagil-

ityjusthasnoplaceleftforthesetypesofsolutions,regardless

ofhowmuchorganizationshavealreadyinvestedinthem,and

regardlessofhowmuchresourceistiedupintryingtomaintain

them.Theneedforchangeisnow.

The Rate of Obsolescence Outpaces the Pace of Change. *

SosaysRayWang,industryanalystandtheauthorofthepopular

enterprisesoftwareblogASoftwareInsidersPointofView

Hesright.Technologychangestooquicklyforanyonecompany

tostayontopofit.Newsoftwareisreleasedsoregularlythatit

isalreadyoutofdatebythetimeitislaunchedconsiderthe

frequencyofSAPorevenMicrosoftupdates,keepingontopof

theseposearealheadachetomostITdepartments.Wevegot

toastatewheretraditionaltestingprocessesandtoolsaretoo

cumbersomeanddevelopmentispullingaway.Testingbecomes

thebottleneck.Wedontneedtestassetswhichhavecostcom-

paniesthousandsofdollarsandman-hourstodevelop.Whatthe

businessneedsnowistestassetsthatarequickandeasytode-

velop,thatcanbere-usedoradaptedeasily,orcanbediscarded

withoutasecondthought.

So Why Throw Such Perfection Away?

Nowitwouldbefoolishtodisposeoftheentireconceptpurely

basedonwhatcamebefore.Weneedtorecalibrateourexpecta-

tionsandremindourselvesofexcellentpotentialbenetsfrom

testautomation,ifonlythecapabilitiesweredeliveredinaform

usablebyall.

Theability of any automation technologyto adapt tochanges

intheunderlyingapplicationwillalwayshavesomelimitations.

Isitreasonabletoexpectthatatestscriptcreatedforalegacy

mainframeapplicationtostillbevalidonthe replacement.Net

WPFarchitecture?Canyouexpectthetestscriptscreatedforthe

English version ofyourweb site tobe applicable tothenewly

developedJapaneseversion?

Byfreeingautomationfromtheburdenofascriptbasedoncode,

wecanbegintoimagineasolutionthatcouldbeusedbysubject

matterexpertsandnotlimitedto frustrateddevelopers,asolu-

tionthatcouldadapttochangesintheapplicationundertest,

anintelligentsolutionthatinherentlyunderstoodtheapplication

undertest,removingtheneedtodeveloplogicinadditiontothe

validationitself.

Theexcitingthingisthatmodernautomationgoesasurprisingly

longwaytowardsaddressingtheseneeds.Butdonotletthatop-



timisticoutlookhidethecoreissueatsomepointtheapplication,

environmentorbusinesswillchangeinsuchafundamentalwaythat

theexistingtestassetshavelittleornovalue.

Ifthatlossrepresentsaninvestmentinintellectualproperty,resource

andtimeatalevelsolargethatthereisnoappetitetoredevelop

thoseassetsfortheversionoftheapplication,thenautomationwill

havefailed.Thuswearriveattheacidtestifitisdeemedeasier

toreturntoamanualtestapproach,thenautomationhasfailedand

deservestobethrownaway.

Summary

Testautomationhasfailedtodatesimplybecausewecouldnotaf-

fordtothrowitaway.Creatinganyformofautomationtakeseffort

andtime,whentheapplicationundertestchangesandtheautoma-

tionceasestoworkyouarefacedwithastarkchoiceeithermain-

tainitatadditionaleffortandtimeorabandonit.Ifyouabandonit,

youarealsowritingofftheeffortandtimeyouinvestedincreatingit,

thusbringingthewholeconceptintoquestion.

The reality isthatyouhaveto bein a positionto throwaway the

automationyouhavecreated,assoonerorlatertheapplicationwill

changeinsuchawaythatnoamountofautomatichealingcantack-

le.Sobydenition,thecreationoftheautomationmusthavebeen

sofastandpainlessandtheinvestmentminimal,thatyoucanafford,

bothnanciallyandemotionally,tothrowitaway.

Thinkaboutyourowntestassets?Canyouevenestimatethecostin

timeandeffortinbuildingthem?Howconstrictedareyoubythatin-

vestment?Canyouhandonheartclaimthatyoudontgrimaceeverytimeyouhavetothrowthemaway?

* From: http://www.altimetergroup.net/

George Wilson

is Operations Director re-

sponsible for sales, con-

sulting services & product

support delivery to Original

Softwares worldwide cli-

ent base.

Another founding member;

Georges strong software

quality and customer care

orientation is reinforced by extensive software product

and large-scale development project experience within

many areas of IT.

He has helped shaped the solutions Original of fer today

with practical experience from the eld, combining well

with Colins insight and innovation. An engineer by train-

ing, his background served him to great effect at Osprey

Computer Services (to 1995) where, as a main board

director, he drove development and marketing of new

applications into new markets for the company.

Later, as Business Group Manager at AIG Computer

Services, George rapidly broadened his platform experi-

ence, simultaneously managing IBM Midrange, NT and

PC development projects in a rigorous ISO9001 and

TickIT management environment, where Georges natu-ral quality evangelism served him well.

He has been a keen dinghy sailor, enthusiastic wind-

surfer but these days golf seems to take precedence.

> About the author



I. Introduction

Intodayscompetitiveworld,mostofthesoftwareorganizations

arechurningouttheprocessesthatcanreducethetimetomar-

ketwithcustomersatisfaction.WhetheritisScrum,XP,Crystalor

anyotherAgilemethodology,thebasiswillremainthecontinual

improvement. And this has tohappen with anunclear project

scopeandalotlessdocumentationinsmallinstallments,typi-

callyreferredtoasiterationsinAgile.Withthisthenaloutcome

shouldbedeliveryontimewithgoodROI(returnoninvestment)

forthebusiness.LiteratureavailableonAgiledenesitthisway:

Individualsandinteractionsoverprocessesandtools.

Workingsoftwareovercomprehensivedocumentation

Customercollaborationovercontractnegotiation

Respondingtochangeoverfollowingaplan

Beingproactiveratherthanreactive

WithallthesekeyfeaturesaboutAgile,thetestersgetmuchless

timefortesting.Thediscussionsbelowuncoversomeofthechal-

lengestotackle.

II. Role of Testing in Agile Environments

Requirementsin Agiletestingare specied as userstories. To

make up an effective agile methodology, acceptance criteria

shouldbeapartofuserstories.Acceptancetestscheckeach

iteration to verify that business values are present. This way

theystarttoalsoserveasadocumentationofcustomerrequire-

ments.CommonlyinAgilepractices,yellowstickynotesareused

fortheactiveuserstories,orangestickynotesfortestsinprog-

ress, and the red sticky notes are bugs reported during daily

stand-upmeetings.

ThechallengefortestinginAgileisthattheshortiterationsdo

notallowtestsystemstobeinplace.Inwaterfalloranyothertra-

ditionalmodel,thetestcasesarewrittenonthebasisofthere-

quirementdocument.Andthereisenoughtimetoputthethings

inplace,suchastestcasedesignandtestbedset-up.InAgile,

allthishastobedecidedonthego.Attheendofeachiteration

workingsoftwaremustbedeliveredtothestakeholder.Sothere

isaneedtohaveaverysmartapproachtotesting.

Toachievethis,nodoubtwelldoneunittestingisthefoundation

toanyAgilemethodology.Ifunittestingisnotdoneproperly,a

largedegreeofcodechangewillhappenduringthetestingphase

toxthebugswhichmakethesystemmorefragileandproneto

haveahighernumberofdefects.Sincethetesterismoredepen-dentontheinteractionwithstakeholdersandteammembers,

thetwoapproachesofrisk-basedtestingandexploratorytesting

playaverycrucialrole.Inarisk-basedapproach,thetestsare

performedaccordingtopriority,whichhelpstodetecttheimpor-

tantdefectsearlyinthetestexecution.Thisalsolaysthefounda-

tionforbuildingautomatedfunctionaltestscripts,whichcanbe

usedfurtherforregressiontesting.

III. Role of the Tester in Agile Environments

Anagilisttesterneedstobeproactiveratherthanreactive.There

needstobeachangeinthemindsetoftesterstoadopttheAgile

wayofworkingandthinking.

InanAgileenvironment,thetesterneedstothinkanalyticallyin

ordertonddifcultbugsearlierintheexecution.Therealchal-

lengeforthetesterliesinthefactthatrequirementskeepon

changing;theveryevidenceforthisisconstantbugreportsget-

tingrejected.In a traditional development environment thisis

considerednotapositivesignfortesters,whereasinAgilemeth-

odologiesthetesterisevaluatednotonthenumberofbugsbut

thequalityoftheproduct.

Thechange inattitudeis required for the whole team that is

working in an Agile way. Whereas testers need to be precise

andconsistent,theteamshouldalsotrytoimplementvariation

Test Automation inAgile Environments

by Mallika Singh

DIREKTHIER-Fotolia.com



throughdifferenttesttechniquesandmethodologies,especially

sincethereis noteststrategythatcould resolve theissue of

changingsystem.

TestersworkingonAgileprojectsshouldbeabletounderstand

therootcauseanalysisofproblems(e.g.asimilarbugthatoc-

cursinconsecutivereleases).Todothis,asoundknowledgeof

softwaredevelopmentwillhelp.Itisalsorequiredforthetester

tobeclosetothedevelopersanduserstoworktowardsthe-

nalreleaseofabug-freeandstableproductthatwillsatisfythe

customer.

IV. Test Automation in Agile Environments

Tokeepupwiththepaceofdevelopers,testautomationisre-

quiredinanyprojectfollowinganyoftheAgilemethodologies.

Automationin early stages ofan Agileprojectis atoughjob,

butasthesystemevolvesther

agilerecord_03

Documents