agilerecord_08

8/17/2019 agilerecord_08

1/57

The Magazine for Agile Developers and Agile Testers

October 2011

issue 8www.agilerecord.com free digital version made in Germany ISSN 2191-1320


2/57

Pragmatic, Soft Skills Focused, Industry Supported

Díaz & Hilterscheid GmbH / Kurfürstendamm 179 / 10707 Berlin / Germany Tel: +49 30 747628-0 / Fax: +49 30 747628-99

www.diazhilterscheid.de [email protected]

Book your training with Díaz & Hilterscheid!Open seminars:

CAT is no ordinary certification, but a professional jour-ney into the world of Agile. As with any voyage you haveto take the first step. You may have some experiencewith Agile from your current or previous employment oryou may be venturing out into the unknown. Either wayCAT has been specifically designed to partner and guideyou through all aspects of your tour.The focus of the course is to look at how you the tes-ter can make a valuable contribution to these activitieseven if they are not currently your core abilities. Thiscourse assumes that you already know how to be a tes-ter, understand the fundamental testing techniques andtesting practices, leading you to transition into an Agileteam.

The certification does not simply promote absorptionof the theory through academic mediums but encour-ages you to experiment, in the safe environment of theclassroom, through the extensive discussion forumsand daily practicals. Over 50% of the initial course isbased around practical application of the techniquesand methods that you learn, focused on building theskills you already have as a tester. This then preparesyou, on returning to your employer, to be Agile.The transition into a Professional Agile Tester teammember culminates with on the job assessments, dem-onstrated abilities in Agile expertise through such fo-rums as presentations at conferences or Special Interestgroups and interviews.Did this CATch your eye? If so, please contact us formore details!

October 24 - 28, 2012 in Cologne, Germany *November 07 - 11, 2011 in Mödling, Austria

November 07 - 11, 2011 in Stockholm, SwedenDecember 5 - 9, 2011 in Berlin, Germany

* (German tutor and German exam)

February 13 - 17 , 2012 in München, GermanyMarch 19 - 23, 2012 in Berlin, Germany April 23 - 27, 2012 in Berlin, Germany

June 11 - 15, 2012 in Cologne, Germany

http://www.diazhilterscheid.de/de/kurse.php?id=313&m=ar_08&a=Pre2http://www.diazhilterscheid.de/de/kurse.php?id=313&m=ar_08&a=Pre2


3/571www.agilerecord.com

Dear readers,

I don’t know how to express my impatience to start the Agile Testing Days.

We have worked so hard to get it done, that we want to see the result soon. We want to see thesatisfaction on the faces of attendees and speakers.

We are breaking all the expectations. Not only the number of tutorials, keynotes, talks, the openspace, test lab, coding dojos and testing dojos.

We have great numbers of attendees from all around the world. We developed great ideas tomarket the conference that were well received. We have planned an award that got the supportof many professionals giving their vote. We have planned a great evening event using the old

scenery from the lm “Prince Valiant”, where the Major of the City of Potsdam will hand over theaward to the elected professional. A lot of exciting things. Believe me, I’m already nervous! I wouldlike to welcome you in Potsdam. Enjoy the conference!

We have again great articles in this issue. Thanks to all authors. Thanks also to the supportersand advertising companies. Without your help we could not get it done.

We are planning some webinars that we will announce in a few days. Please don’t feel “spammed”,when we inform you about it. We think that these events are a great opportunity to share theknowledge.

Please also check our website from time to time.

We are planning a “revolution” together with our sister magazine “testing experience”. We thinkthat you – the professional involved in software engineering – should have the chance to get it.We will keep you posted and will announce soon what the next steps are.

I’m facing the holidays with my kids. I really don’t know where to go. Disneyland Paris, Barcelona,Lanzarote, Gran Canaria, “Bauernhof” or even Heiligendamm again. My son just wants to take atrain and to have an adventure – to just set off and then arrive somewhere and sleep in an hoteletc. For one day that could be nice, exciting and interesting, but for a whole week with no planningand two 8 and 6 years old kids on the back, that is a real challenge. I will tell you what we decided.

I hope you enjoy reading the magazine and best regards

José Díaz

Editorial


4/572 www.agilerecord.com

ontents

Editorial 1

Agile Testing in Real Life – September 3by Lisa Crispin

Agile ALM and collaborative development 9by Michael Hüttermann

Agile Methods & traditional Project Management 14by Jan Kopia

The Necessity of New Contract Models for Agile Project Management 16by Dr. David F. Rico, PMP, CSM

Speci cation by Example 20by Gojko Adzic

Agile Testing 29by Santosh Varma

Getting the software tester ready for the agile word 33by Katy Magalhães & Giuliana Miglioli

Done should mean value delivered to stakeholders 41by Tom and Kai Gilb

Mental gymnastics 44by Bert Wijgers

Distributed Agile: Steps to Improve Quality before Design 47by Raja Bavani

Simply Go Agile! 49by Mithun Kumar S R

Daily Scrum meetings: What it is and what not, and what can be improved! 51by Chetan Giridhar & Vishal Kanaujia

Masthead 54

Picture Credits 54

Index Of Advertisers 54



I tend to philosophize some in this column, but I remind myself,it is titled “Agile testing in real life”. So let’s look at some agiletesting in real life. Technical debt (a term coined by Ward Cun -ningham 1) is one fact of our real agile life. When we cut a fewcorners in order to deliver business value faster, we have to payback that “loan”. Here’s an example of how this works on a realteam, the one in which I work as a tester, at ePlan Services Inc.

Every six months, our development team gets a two-week sprintin which we do not deliver any user stories for the business. In-stead, we do activities that keep our technical debt to a manage-able level. We call these “Engineering Sprints”, but some peoplerefer to them as “Technical Debt Sprints”.

What? Don’t you refactor every day?

Yes, we continually refactor, and we maintain the discipline toalways do test-driven development at the unit and higher levels,automate 100% of our regression tests (or checks, as some pre-fer to call these), and budget time to implement new themes anduser stories the “right” way. Still, we’re here to help the businesssucceed, and sometimes there are compelling reasons to imple-ment a solution that is not ideal. In addition, we still have about85,000 lines of “old” code – code that is now supported by tests,but is in the bad old architecture. We also have some “old newcode” – some early code written in the new architecture, but writ -ten poorly. Technical debt sprints are an opportunity for changeswhich are too time-consuming or risky to undertake during a nor-mal two-week sprint.

What kinds of activities are done in a technical debt sprint?

As of this writing, we have such a sprint coming up in two weeks.

The developers took advantage of some free time last week tostart planning it. Here’s the list they came up with:

1 http://www.youtube.com/watch?v=pqeJFYwnkjE

Agile Testing in Real Life – September

Column

by Lisa Crispin



The speci c tasks won’t mean a lot to you, but notice the word“rewrite”, “clean up”, “upgrade” and “refactor” appear often.

The third item from the bottom of this list, “Census Upload File Fixfor Canoo”, is a task to rewrite some old upload code that doesn’twork when we drive the le upload from a Canoo WebTest script.We take a whole-team approach to quality, and everyone on theteam is keen to maintain good regression test coverage. So thatmakes us testers on the team happy. But this is a list of codingand system administration tasks.

So, what will you testers do during this technical debt sprint?

Every item on that list involves testing. We have excellent cover -age from automated regression tests at the unit, API and GUIlevel, but some of these items require additional manual ex-ploratory testing. Take “Establishment Step Handling”. That willinvolve rewriting a navigation bar for a UI wizard that has a dozensteps. The regression tests don’t cover every possible path a usercould take up and down that navigation, and it’s a high-visibility

part of our website that must work awlessly.

The third item from the top is “Upgrade Windward”. We use Wind -ward to generate many PDF documents on our site. Many of theseare legal documents, and have to be just right. We have CanooWebTest scripts to spot check each document, but there’s a highrisk of problems such as misalignment or font issues that wouldbe dif cult to catch with an automated script. Based on previousupgrades, we know that we need human eyes on all these docu-ments after upgrading to the latest version of Windward.

The next item, “Auto-commit=false”, will also require some care -ful exploratory testing. One of the programmers recently discov-ered that some transactions in our system auto commit beforethe transaction is complete, which is dangerous, especiallywhere our “old” and “new” code interface.

There’s no way we’ll get to every item on this list in two weeks(though I sure hope that “Census Upload File Fix for Canoo” getsdone), but clearly, we testers will spend a lot of our time testingchanges made for these tasks. Anyone on the team can do thistesting, and the programmers often take on testing tasks, but wetesters will want to be involved in the high-risk updates.

That sounds like business as usual for testers. What’s differ-

ent?

We testers get to have fun too. We’ll upgrade our test tools – Ca -noo WebTest, FitNesse and Watir – to the latest versions. Testcode gets crufty just like production code. We refactor as we go,but the Engineering Sprint is a chance to take on some big re -designs that might take a few days to complete. We’ll ask theprogrammers for help in nding ways to extract duplication andmake the test code easier to maintain.

We’ve got some automated regression test build jobs that aretaking too long to run, so we’ll split those into multiple jobs. We’llneed help from the DBA to create new test schemas for that pur-pose, and test from a system administrator to create more build

slaves. We’ll also work with our DBA to do some test data groom-ing that we require every year or two.

In past technical debt sprints, we testers have used the time tolearn how to set up and use the same IDE as the programmers,upgraded our test servers, put our FitNesse tests under the sameversion control as the production code, and found a way to main-tain FitNesse tests more ef ciently by editing them via the IDE.These two weeks are an ideal time for big chunks of learning andexperimenting. It’s a chance to practice our craft. We can try outnew ideas, and throw them away if they don’t work – at the veryleast, we learned something new.

Sounds nice, but our business managers would never let us

do this.

Technical debt has a real cost – you can quantify 2 it in dollars,or Euros, or your currency of choice. Business managers, espe -cially the nance folks, understand when something is costingthe business real money. When they do, they’re eager to give the

team time to pay back this debt.

There are lots of different ways to managing technical debt. Ihope this example of one way we keep it in check will help youplan what you’ll do to reduce technical debt and improve quality.

2 http://www.cutter.com/offers/technicaldebt.html

Lisa Crispin

is the co-author, with Janet

Gregory, of Agile Testing: A

Practical Guide for Testers

and Agile Teams (Addison-

Wesley, 2009), co-author

with Tip House of Extreme

Testing (Addison-Wesley,

2002) and a contributor to

Beautiful Testing (O’Reilly,

2009). She has workedas a tester on agile teams for the past ten years, and

enjoys sharing her experiences via writing, presenting,

teaching and participating in agile testing communi-

ties around the world. Lisa was named one of the 13

Women of In uence in testing by Software Test & Per -

formance magazine. For more about Lisa’s work, visit

www.lisacrispin.com. @lisacrispin on Twitter. gplus.to/

lisacrispin on Google+.

> About the author


7/57

November 14–17, 2011Potsdam (near Berlin), Germany

www.agiletestingdays.com

http://www.agiletestingdays.com/index.php?m=ar_08&a=5http://www.agiletestingdays.com/index.php?m=ar_08&a=5


8/57

November 14–17, 2011in Potsdam (near Berlin), Germany

The Agile Testing Days is an annual European conference for and byinternational professionals involved in the agile world. This year’s centraltheme is “Interactive Contribution” .

Please visit our website www.agiletestingdays.com f or the currentprogram.

Follow us on Twitter:www.twitter.com/AgileTD

Agile Testing Days 2011 –A Díaz & Hilterscheid Conference

Díaz & Hilterscheid Unternehmensberatung GmbHKurfürstendamm 17910707 BerlinGermany

Phone: +49 (0)30 74 76 28-0Fax: +49 (0)30 74 76 28-99

[email protected]

“Hooray! We’re Agile Testers! What’s Next? Advanced

Topics in Agile Testing”Lisa Crispin

“Making Geographically Distributed Projects Work”Johanna Rothman

“Transitioning to Agile Testing”

Janet Gregory

“Inuence Strategies for Practitioners & “Patternsfor Improved Customer Interaction“Linda Rising

“Dealing with Differences:From Conict to Complementary Action”Esther Derby

“Critical Thinking Skills for Testers”Michael Bolton

“Introduction to BDD”Elizabeth Keogh

“Agile Management: Leading Software Professionals”Jurgen Appelo

“Winning big with Specication by Example:Lessons learned from 50 successful projects”Gojko Adzic

“Acceptance Testing: From Brains to Paperand Paper to Computer”Lasse Koskela

Exhibitors & Supporters 2011

Tutorials – November 14, 2011

The Austrian Software Test Experts!

http://www.agiletestingdays.com/index.php?m=ar_08&a=6http://www.agiletestingdays.com/index.php?m=ar_08&a=6http://www.agiletestingdays.com/index.php?m=ar_08&a=6http://www.agiletestingdays.com/index.php?m=ar_08&a=6http://www.agiletestingdays.com/index.php?m=ar_08&a=6http://www.agiletestingdays.com/index.php?m=ar_08&a=6


9/57


10/57

Premium Sponsor Package:12,000.00 € (limited to 4)• 5 free admission tickets for exhibitor‘s

contacts, but not for its own employees• 20 admission tickets at a 25 % discount on

the regular price• Exhibitor’s company name/logo included

in the program• Exhibitor’s company name/logo included

in all exhibition/sponsoring documents• Exhibitor’s company name/logo listed on

the Agile Testing Days website includinga link to their own website and 200 wordsabout the company

• Advertisement banner from exhibitor’scompany during the keynotes

• Logo included on all relevant printed AgileTesting Days marketing materials (yer,posters, folder, etc.)

• Logo displayed on screen betweenpresentations

• Verbal recognition during conference(welcome remarks, closing remarks)

• 4 admission tickets for exhibitor’s boothstaff

• 1 presentation (55 minutes) – vendor track 1•

Exhibition oor space (6 m × 2 m or 3 m ×4 m = 12 m²)• 4 admission tickets for the evening events• Catering during the event

Gold Sponsor Package:6,000.00 € (limited to 6)• 2 free admission tickets for exhibitor‘s





the Agile Testing Days website includinga link to their own website and 100 wordsabout the company

• Logo included on all relevant Agile TestingDays printed marketing materials (yer,posters, folder, etc.)


• 1 presentation (25 minutes) – vendor track 1• Exhibition oor space (2 m × 3 m = 6 m²)• 4 admission tickets for the evening events• Catering during the event

Exhibition Package:3,000.00 € (limited to 8)• 2 free admission tickets for exhibitor‘s





the Agile Testing Days website including alink to their own website


• Exhibition oor space (2 m × 2 m = 4 m²)• 2 admission tickets for the evening events• Catering during the event

1 Please note: There are only 8 vendor tracks available. We pursuethe „rst-come, rst-served“ principle.

Become Exhibitor or Sponsor

Get an Optional Sponsoring Package

Award Package: 3,000.00 €

(limited to 1)• Sponsor‘s company name/logo engraved

on the award (Most Inuential AgileTesting Professional Person)

• Your companies name/logo on the awardwebsite

• Verbal recognition of the company duringthe award event

• Your banner ads in front of the stage• 2 admission tickets for the staff of the

company (only if you are not an exhibitor)• 2 admission tickets for the evening events

(only if you are not an exhibitor)• Catering during the event

Brochure Package I: 1,000.00 €2

(limited to 1)• Advertisement from your company on rst

page (not cover) in our program

Brochure Package II: 500.00 € 2

• One page advertisement in our program

Brochure Package III: 250.00 € 2

• Half page advertisement in our program

Brochure Package IV: 500.00 € 3

• Advertisement inlay/yer in our program

Conference Package I: 1,000.00 € 2

• Conference bags with logo of the company

Conference Package II: 500.00 € 3• Conference bag lled with your own

advertisement or giveaways (for example:pens, t-shirts, writing pads, yer)

Conference Package III: 1,500.00

€ 2 (limited to 1)• Your company logo on 500 coffee cups at

the conference breaks

All optional Sponsoring packagesincluding the following:• 5 admission tickets at a 25 % discount on

the regular price• Sponsor’s company name/logo listed on

the Agile Testing Days website including alink to their own website

• Sponsor’s company name/logo included inall exhibition/sponsoring documents

• Sponsor’s company name/logo included inthe program

2 You have to order this package until 6 weeks before theconference.3 Please note: You have to organize/produce your advertise-ments and giveaways by yourself.



Application Lifecycle Management (ALM) synthesizes technicaland functional elements to provide a comprehensive approachto common project activities and phases, addressing build, con-

guration, deployment, release, test, quality, integration, andrequirements management. With its interdisciplinary approach,Agile ALM integrates project roles, project phases and artifacttypes. Agile ALM enriches an ALM with agile values and strate -gies. An agile approach to ALM improves product quality, reducestime to market, and makes for happier developers. Agile ALM isone of the ways in which ALM helps to provide structure for agile.

In a nutshell, Agile ALM ■ Helps overcome process, technology, and functional barri -

ers (such as roles and organizational units).

■ Spans all artifact types as well as development phases andproject roles.

■ Uses and integrates lightweight tools, enabling the team tocollaborate ef ciently without any silos.

■ Makes the relationship of given or generated artifacts vis -ible, providing traceability and reproducibility.

■ De nes task-based activities that are aligned with require -ments. This means that the activities are linked to require-ments, and that all changes are traceable to their require-ments.

One essential aspect of agile ALM is collaborative development,which is what we’ll discuss next.

Collaborative development

Writing software collaboratively means that all stakeholders workon the solution, constructively, and they have shared goals. Theagile testing matrix (see gure 1, a skeletal based on Lisa Crisp -

in’s version of Brian Marick’s diagram) de nes test quadrants,which are integrated and aligned with the outside-in approach.According to C. Kessler and J. Sweitzer, the main drivers of out -side-in are:

■ Understanding your stakeholders and the business context

■ Mapping project expectations to outcomes more effectively

■ Building more consumable software, making systemseasier to deploy and use

■ Enhancing alignment with stakeholder goals continuously

Figure 1: Agile testing matrix with test quadrants that are aligned with theoutside-in and barrier-free approach to software development.

Acceptance tests determine whether a system satis es its speci -ed acceptance criteria. This helps the customer to decide wheth -

er to accept the software. This means that acceptance tests also

tell the programmers what the customer doesn’t want them todo. Executable speci cations allow you to use tools that read thespeci cations automatically (either after manually starting theprocess, or continuously as part of a continuous integration pro-

Agile ALM and collaborativedevelopmentby Michael Hüttermann



cess), process them against the system under test, and outputthe results in an objectively measurable, ef cient, and readableway. The domain expert speci es the tests in simple formats (forexample based on HTML or Excel), and the program writes theresults after running the tests against the system under test.Merging different mediums for documentation (single-sourcingproduct information) reduces the amount of traditional docu-mentation, because the speci cation is the system’s functionaldocumentation and therefore can be ef ciently validated againstthe current software state. This leads to a living documentationthat is always up-to-date. There are many different ways of how toimplement acceptance tests, and many different integrated toolchains can be used, for example chains based on Fit/FitNesse.Beside tools, you can also utilize platforms and languages to im -plement acceptance tests, which is what we’ll discuss next.

Barrier-free, with BDD flavored acceptance tests

Behavior-driven development (BDD) promotes a special approachto writing and applying acceptance tests that’s different from the

traditional test-driven development (TDD), although BDD alsopromotes writing tests rst. With BDD, tests are like (functional)speci cation stories, normally in a given/when/then format. Thisspeci cation-oriented technique also uses a natural language toensure cross-functional communication and to understand busi-ness concepts. BDD provides a ubiquitous language for analysisand emphasizes application behavior over testing. Scala andGroovy, both 1st class citizens on the Java virtual machine, offerinteresting features for setting up a polyglot ecosystem, leverag-ing existing platforms by providing solutions that involve specialpurpose languages. With Scala and Groovy, you can write tests,

which helps to overcome various barriers:■ Barriers between project phases and project activities (be-

cause coding and testing move together more closely)

■ Barriers between artifact types (because code andexecutable speci cations are written on the same uni edinfrastructure)

■ Barriers between project roles (because tests are writtencollaboratively, with mechanisms to use terms close to theproblem domain)

■ Barriers between tools (because the same tools are used

for programming and testing)

Overcoming common project barriers leads to what I call a barri-er-free approach. In the Java ecosystem, you can write BDD a -vored acceptance tests with Scala and the Scala specs2 library,or with Groovy and the Groovy easyb library.

Summary

Agile ALM spans many disciplines in software engineering. AgileALM helps to provide structure for agile and helps to approachALM in a determined, pragmatic way. One essential aspect of ag -ile ALM is collaborative development that can help to improve theprobability of success of your project.

Reference

Michael Hüttermann, Agile ALM , Manning, 2011

Carl Kessler and John Sweitzer, Outside-in Software Develop-ment , IBM Press, 2008

Lisa Crispin and Janet Gregory, Agile Testing , Addison Wesley,

2009

Brian Marick’s test matrix: http://www.exampler.com/old-blog/2003/08/21/

Michael Hüttermann

(Java Champion, SCJA,

SCJP, SCJD, SCWCD) isfreelance developer, archi-

tect, coach, author and tu-

tor for Java/JEE, ALM/SCM

and agile software devel-

opment. Further informa-

tion: http://huettermann.

net.

> About the author


13/57

© i S t o c k p h o t o

. c o m / S T I L L F X

May 16 - 17, 2012in London, UK

The Conference for Testing & Finance Professionals

www.testingnance.com

A D í a z

& H i l t e r s c h e

i d C o n

f e r e n c e

http://www.testingfinance.com/index.php?m=ar_08&a=11http://www.testingfinance.com/index.php?m=ar_08&a=11


14/57

May 16-17, 2012in London, UK

Testing & Finance Europe 2012 –A Díaz & Hilterscheid Conference

Díaz & Hilterscheid Unternehmensberatung GmbHKurfürstendamm 17910707 Berlin (Germany)Phone: +49 (0)30 74 76 28-0Fax: +49 (0)30 74 76 28-99www.diazhilterscheid.de

Follow us on Twitter: www.twitter.com/testingnance

The theme of next year’s conference is “Testing and Finance in AgileProjects, Social Media and Regulation”.

is this year’s theme of the eighth Testing & Finance conference takingplace in London for the rst time in May 2012.

These two days provide a unique chance for software testingprofessionals in nancial institutions to learn, to confer and mostimportantly, to meet and network with other practitioners. Some of thebest known professionals and experts in software testing and qualityassurance in nance from around Europe will share their knowledgeand experiences at the event.

For the last seven years this event has grown in stature to become themost recognized in the nancial sector. To further broaden its appeal,Díaz & Hilterscheid GmbH has decided to move the conference fromFrankfurt to London and to expand the scope of the program.

www.testingnance.com

As before, there will be talks about new developments and processesin the areas of software testing and reporting. There will be a highernumber of eld reports and case studies for recent projects in nancialinstitutions; there will also be leading-edge talks on testing in aregulatory environment, and sessions on risk, goal and prot-basedreporting. The 2012 event will be truly international and not to bemissed!

The conference is aimed at practitioners who are actively involvedin, for example, projects concerning Risk Management or ExternalReporting for banks. The conference will benet professionals anddecision makers who like to exchange ideas with peers and expertsregarding the latest developments in Bank Supervision for instance.The Testing & Finance conference will also suit those who are interested

in solving problems that concern the technical assurance, testing, andQuality Assurance of upcoming projects.

We encourage Business Stakeholders, Testers, Test Managers, Qualityand Test Assurance professionals to join us and take part.

Sponsors, Partners and Supporters

The Future of Finance

Gerrard ConsultingPO Box 347, MaidenheadBerkshire, SL6 2GUPhone: +44(0) 1628 639173Fax: +44(0) 1628 630398www.gerrardconsulting.com

Venue

London Marriott Hotel Grosvenor SquareGrosvenor SquareLondon, W1K 6JP United Kingdom

Phone: 44 20 74931232Fax: 44 20 74913201Website: www.Marriot-GrosvenorSquare.co.uk

http://www.diazhilterscheid.de/en/index.php?m=ar_08&a=12http://www.testingfinance.com/index.php?m=ar_08&a=12http://www.diazhilterscheid.de/en/index.php?m=ar_08&a=12http://www.testingfinance.com/index.php?m=ar_08&a=12


15/57

May 16-17, 2012in London, UK

Brochure Package I (limited to 1):750.00 £ (Early Bird 600.00 £)• Advertisement from your company on rst

page (not cover) in our Program

Brochure Package II:500.00 £ (Early Bird 400.00 £)

• One page advertisement in our program

Brochure Package III:200.00 £ (Early Bird 150.00 £)

• Half page advertisement in our program

Brochure Package IV:

750.00 £ (Early Bird 650.00 £) 3

• Advertisement inlay/yer in our program

Conference Package I (limited to 1):2,000.00 £ (Early Bird 1,600.00 £) 2• Conference bags with your company logo

(one color print)

Conference Package II:750.00 £ (Early Bird 600.00 £) 3• Your own advertisement or giveaways into

the Conference Bags -• (for example: pens, t-shirts, writing pads,

yer)

Conference Package III (limited to 1):2,000.00 £ (Early Bird 1,600.00 £) 2• Your company logo on 500 coffee cups at

the conference breaks (one color print)

All additional Sponsoring packagesincluding the following:• 5 admission tickets at a 25 % discount on the

regular price (not for its own employees)•

Sponsor’s company name/logo listed on theTesting & Finance website including a link totheir own website

• Inclusion of the sponsor‘s company name/logo in all exhibition/sponsoring documents

• Inclusion of the sponsor’s company name/logo in the program brochure

2 you have to order this package until 6 weeks before theconference starts

3 please note: you have to organize /produce your advertise-ments and giveaways by yourself and send to the venue one

week prior to the event.All mentioned Early Bird prices are valid until November 30thin 2011.

Platinum Package:8,000.00 £ (Early Bird 7,000.00 £)• 5 free admission tickets for exhibitor‘s


the regular price• Exhibitor’s company name/logo included in

the program• Exhibitor’s company name/logo included in

all exhibition/sponsoring documents• Exhibitor’s company name/logo listed on

the Testing & Finance website including alink to their own website and 200 wordsabout the company

• Logo included on all relevant printedTesting & Finance marketing materials (yer,posters, folder, etc.)

• Logo displayed on screen betweenpresentations

• Verbal recognition during conference(welcome remarks, closing remarks)

• 4 free admission tickets for exhibitor’s boothstaff

• 1 presentation (50 minutes) - vendor track 1• Exhibition oor space (12 m²)• 4 free admission tickets for the evening

events•

Catering during the event• Free access to the tracks• 2 tables and 4 chairs• 2 free parking slots

Gold Package:5,000.00 £ (Early Bird 4,500.00 £)• 2 free admission tickets for exhibitor‘s


the regular price• Exhibitor’s company name/logo included in



the Testing & Finance website including alink to their own website and 100 wordsabout the company

• Logo included on all relevant Testing &Finance printed marketing materials (yer,posters, folder, etc.)

• 2 free admission tickets for exhibitor’s boothstaff

• 1 presentation (25 minutes) - vendor track 1• Exhibition oor space (6 m²)• 2 free admission tickets for the evening

events• Catering during the event• Free access to the tracks• 1 table and 2 chairs• 1 free parking slot

Silver Package:3,000.00 £ (Early Bird 2,700.00 £) • Exhibitor’s company name/logo included in



the Testing & Finance website including alink to their own website

• Logo included on all relevant Testing &Finance printed marketing materials (yer,posters, folder, etc.)


• Exhibition oor space (6 m²)• 2 admission tickets for the evening events• Catering during the event• Free access to the tracks

1 please notice: there are only 8 Vendor Speaking Tracks avail-able, assigned on a „rst-come, rst-served“ principle

Become Exhibitor

Get an additional Sponsoring Package



Many companies throughout the world are implementing an agile

methodology to create products and manage projects. Severalyears ago these products and projects were managed by projectmanagers, an area of expertise which has existed for almost ftyyears.

According to recent studies 1 it seems that projects realized withagile methods like Scrum have a higher success rate than thosewith traditional methods. It seems only rational that there is achange toward agility, especially since companies are facing con-stant pressure for creating innovative products to meet the cus-tomer’s needs and for motivating and nding employees.

However, does this mean that traditional project management isno longer needed?

Looking at the basis of the Agile Manifesto of Software Develop -ment 2, the focus in agile projects is the human being, the interac-tion between human beings and the fact that projects/ productsand their requirements tend to change quickly over time. Certainaspects which usually exist in bigger organizations can, however,lower the success rate of the agile approach. This is where tradi-tional project management can help.

Why traditional project management is still important

Agile contracts are hard to write

In many situations companies work with external suppliers whichdeliver entire products or parts which need not only to be de-

ned regarding the requirements, but also legally regarding cost,time, quality, risk etc. It is still a challenge to write contracts withagile components, such as incomplete and constantly changingrequirements. In many cases the contracts need to be completein order to calculate an exact price for a contract for work. Anexact price for external expenditures is necessary in many busi-

ness areas in order to make investment decisions. This is alsoimportant within an organization.1 oose-Studie zum “Einuss klassischer und agiler Techniken auf denProjekterfolg”, 2009, http://www.oose.de/pm/pm-studie.html

2 http://www.agilemanifesto.org/

External and internal forces set the boundaries

Additionally many companies also have a set of standard pro-cesses for different things. These might be legal aspects or qual-ity management procedures, compliance regulations and so on.Usually these boundaries have a negative impact on the freework of an agile team, especially if it is set up quickly and withouttaking these circumstances into account.

Complex products or projects have a lot of dependent parts

Scalability is another topic which is widely discussed in the agile

community. Companies usually have many projects running atthe same time. Multi-project management or program manage -ment deals with dependencies between projects and productsand the planning process of exact time management. This is areal challenge in a fully agile environment, because traditionaldepartments like controlling etc. are not used to the iterative ap-proach.

Traditional project management tools and techniques can help tosolve some of the above mentioned problems because contractmanagement, complex dependencies between projects, risks,regulations etc. are topics, the traditional project manager is ex-perienced in.

How traditional and agile teams work together

There is an easy answer how to deal with both worlds: The bestapproach for complex organizations is to use the best of bothmethods.

Radical changes are rarely good. Therefore every change towardagility needs be slow, especially in complex organizations, andtake into account the circumstances of that organization. Thepositive aspects of agile methods need to be integrated into the

company’s processes (ideally into the entire company includingIT-systems). Since agile methods and the agile way of thinkingcan be very different from the organizational culture, this integra -tion doesn’t need to be in all areas of the business. Sometimesthe agile mindset only works for a small innovative team. Over

Agile Methods & traditional ProjectManagementby Jan Kopia



time other people or departments might adopt the methods ornd out that in a particular situation the agile way does not work.

This evolutional approach seems to have worked for bigger com-panies 3 in the past.3 For instance Amazon.com, Inc.

M a n a g e m e n t

Project Managersas facilitator

A team using agile methods

A team using traditionalmethods

An external team (agile ortraditional)

Fig. 1: Using traditional methods and Scrum at the same time

An organization with a product development methodology as ingure 1 is not a fully agile company, but can be highly successful

by using methods which t to its circumstances, environment andculture.In this example the project managers work as facilitatorsand take care of the dependencies between the agile teams (es-pecially by working with the product owner), external teams andtraditional project teams. They coordinate the schedule (as wellas other areas as management of resources, suppliers, admin-istrative tasks and so on), and report the status to the manage-ment. The project managers assist the agile teams so that theyare able to concentrate on their work.

Agile teams can work independently on their parts or the entireproduct within their sprints (and closely together with the cus-tomer), but they need to agree to a certain level of traditionalprocesses like reporting etc. where the project manager assiststhem.

Conclusion

In complex organizations agile methods can help to developproducts more successful. But this doesn’t mean to replace ex-

isting project management. Because of the project managers’level of expertise they are able to assist agile teams with theirtools and techniques, especially when there are many project/product parts, teams, and internal/external dependencies. Agileteams can work ef ciently on their stories, focusing on customer

needs, short sprints, quick innovations, quality, and team inter-action, while the traditional project manager (familiar with all as-pects of agility) focuses on the key performance indicators of theentire product/program etc., the controlling, and the reporting.

Jan Kopiaworks as project manager

at ImmobilienScout24,

where he manages pro-

jects which consist of in-

ternal Scrum teams as

well as external develop-

ment teams. He has an

MBA degree and is project

management professional

(PMP) and certi ed Scrum

Master. ImmobilienScout24 uses Scrum very success-

fully: within two years productivity was more than dou-

bled, the number of bugs was halved and so was the

uctuation in the team.

> About the author

Subproject 1

Subproject 2

Project 1

Project 1

Project 2

Project 1

Subproject 1

Subproject 2

Subproject 1

Subproject 2

Subproject 3

Subproject 4

Subproject 1

Subproject 2

Project 1

Project 2

Project 1

Product 1

Product 2

Product 3

Product 4

Product 5

Product 6

Service-Line 1

Service-Line 2

Service-Line 3



Does the use of agile project management require new contractmodels in order to be successful? Can agile project manage -ment be used with traditional xed price contracts? Does agileproject management require a new type of contract? And, if so,what sorts of contracts are required? Furthermore, wouldn’t anew type of contract discourage the use of agile project manage-ment?

Agile project management is a new paradigm for managing highrisk, time sensitive, research and development oriented new

product and service development projects. It’s a lightweight, ex -ible, collaborative, adaptable, and highly disciplined project man-agement model for building high quality hardware and softwaretechnology intensive products and services.

Agile project management is designed to lead and empowerteams to deliver business value over meeting constraints byadapting to change over following plans. This is accomplishedwith a light structure of product visioning, adaptive planning, iter-ative development, and thorough product testing. It is also basedon a strong foundation of customer collaboration and teamwork.

The traditional model of project management attempts to mini-mize risk through exhaustive scope de nition, planning, docu -mentation, and process controls. Completing a project within a5% or 10% level of scope, time, and cost under or overrun isconsidered success. Detailed work breakdown structures andearned value management are used as the basis for correctiveaction.

Traditional project management is based on the notion that allcustomer requirements can be de ned as explicit knowledge,captured in detailed plans, and delivered with precise accuracy.

Therefore, a variety of contract vehicles have emerged over thelast century to realize the vision of scope driven project manage -ment paradigms that provide a legal advantage to the customers.

Old Contracts Description

Agreement Basic statement of terms and conditions (as a pre-lude to a detailed contract)

Fixed Contract ascribing cost liability to supplier (regard -less of scope change)

Reimburse-ment

Contract allowing minor cost growth to suppliers(award fees, in ation, etc.)

Inde nite Contract specifying minimum performance (prod -ucts, services, etc.)

Incentive Contract establishing pro t sharing conditions (tominimize cost vs. scope)

Others Contract for services with speci ed execution costs(salary and wage caps)

Traditional contracts have many issues. Separate suppliers areused for scoping vs. development. Buyers and suppliers do notcollaborate in critical early phases. Buyers select suppliers basedon arbitrary proposals. Terms and conditions are ambitious. Ef -fort estimates are overly optimistic. Suppliers underbid in orderto win contracts. Buyers shop by lowest price rather than bestvalue.

Traditional contracts result in what is known as “the winner’scurse” . The symptoms include large increases in scope, time,and cost. Others include reduced quality, customer satisfaction,and delivery order quantities. The statistics haven’t changedmuch in fty years (i.e., 67% of IT projects are challenged andfailing, resulting in $1 trillion in lost global revenues each year).

Innovation researchers have discovered that 70% of new productor service needs exist as tacit knowledge among customers, andcan only be elicited verbally. As a result, innovation projects oftenexhibit extremely large changes in scope over time. Therefore,

success is de ned as satisfying a customer’s emergent needsrather than unrealistic scope, time, and cost objectives.

The Necessity of New Contract Modelsfor Agile Project Managementby Dr. David F. Rico, PMP, CSM


19/57

Knowledge Transfer – The Trainer Excellence Guild

Website:http://www.diazhilterscheid.de/en/knowledge_transfer.php

Just a few seats left:Rapid Software Testingby Michael Bolton

Date Place Price

Dec 13 – 15, 2011 Oslo (Norway) € 1,475 + VAT

Risk-Based Testingby Hans Schaefer Date Place PriceDec 14, 2011 Helsinki (Finland) € 650 + VAT

http://www.diazhilterscheid.de/en/knowledge_transfer.php?m=ar_08&a=17http://www.diazhilterscheid.de/en/knowledge_transfer.php?m=ar_08&a=17http://www.diazhilterscheid.de/en/knowledge_transfer.php?m=ar_08&a=17



Agile project management is a con uence of two major 20th cen -tury paradigms: (1) rational model and (2) human behavior. It isalso attributed to chaos or complex adaptive systems theory, ex -ible manufacturing, and incremental or participative planning. Itis based on the idea that innovation results from tacit knowledgethat emerges through informal human communication.

Agile project management embraces the essence of traditionalproject management with exible yet disciplined processes. How -ever, it is based on a process of “learning by doing” to graduallydiscover a project’s scope while simultaneously delivering thebiggest bang for the buck. Thus, exible new contract modelshave emerged to achieve total customer satisfaction using thisparadigm.

New Contracts Description

Dynamic Value Contracts specifying initial scope and needs (withiterative enhancements)

Performance Contracts establishing performance objectives (butnot solutions)

Optional Scope Contracts specifying boundaries for time, cost, andquality (but not scope)

Target Cost Contracts specifying minimum and maximum costs(based on initial scope)

Collaborative Contracts specifying initial scope (with xed no. ofreleases and iterations)

Lean Contracts based on respect, value, system think -ing, ow, pull, and perfection

These new contract models have many similarities. Buyers and

suppliers collaborate throughout the process. Customer needsanalysis is performed that often results in a strategy, roadmap,goals, objectives, and capabilities. Cost goals are establishedalong with near term time horizons. Finally, the use of agile vs.traditional project management principles and practices is ex-pected.

The results of utilizing new contract models for agile projectmanagement are impressive. Agile contracts result in an aver-age of 60% improvements in productivity, quality, and customersatisfaction according to major surveys. An analysis of 71 stud-ies revealed an average of 73% improvements in cost, schedule,productivity, quality, and customer satisfaction.

Agile project contracts are up to 20 times less expensive thantraditional ones, which translates into a 1,600% increase in ben-e ts in terms of return on investment, net present value, andreal options. Furthermore, major studies reveal that well runagile contracts experience 1% overruns as opposed to 60% fortraditional contracts, which is attributed to better customer col-laboration.

The use of agile project management emerged with the popular-

ity of Extreme Programming and Scrum in the early 21st century.By the middle of the rst decade, up to 70% of small to mediumsized worldwide projects used agile project management. How -ever, both its proponents as well as detractors still have many

questions concerning the use of agile project management:

■ Has agile project management crossed the chasm (i.e.,what is its adoption rate)?

■ Why doesn’t the government use agile project manage-ment (especially the U.S. DoD)?

■ Can agile project management be used in highly regulated

industries (i.e., FAA, FDA, etc.)?

The answers to these questions may be surprising and unexpect-ed to some people. Agile project management has crossed thechasm in many regards. As mentioned earlier, 60% to 70% ofsmall to medium sized IT projects have been using agile projectmanagement since 2002. This includes Fortune 500 rms alongwith most industry sectors in North America, Europe, and the FarEast.

Government agencies have also been using agile project man-agement for the past decade. U.S. DoD agencies have been us -

ing evolutionary contracting models on large projects. Recentdata shows that nearly 70% of small to medium sized U.S. DoDprojects currently use agile project management. The U.S. DoDis revising its contract models for agile project management use.

Highly regulated industries such as the Federal Aviation Adminis -tration and Food and Drug Administration have also been usingagile project management for the last decade. It includes a rigor-ous life cycle wide regimen of verifying and validating productsand services against requirements. This is often done in a highlyautomated fashion called “continuous integration”.

Another frequently asked question is, “how can we convince ourcustomers to use agile project management?” Ironically, custom -ers often ask suppliers to use agile project management in orderto achieve their business goals at the least cost in today’s re-source constrained economy. Public and private sector leadershave heard of its bene ts, even if practitioners have not.

The list of organizations that have adopted agile project manage -ment is a veritable who’s who. This includes Fortune 500 rms,large military rms, and U.S. DoD agencies themselves. The lastbastion of traditional contracts seems to be large public sectorprojects. However, even these are beginning to transition to usingagile project management in increasing numbers everyday.

Agile project management is well suited to help realize post in -dustrial information age projects, which involve elements of am-biguity, risk, and lofty objectives. On the other hand, traditionalcontracts that assume requirements can be established withoutbuyer and supplier collaboration and then realized with rigid pro -

ject management models are not well suited for today’s needs.

Copyright © 2011 gantthead.com. Reproduced by permission of

gantthead.com



Dr. David Rico

has led large projects for

over 27 years. He spe-

cializes in IT investment

analysis, IT portfolio man-

agement, and IT-enabledchange. He teaches at

multiple universities, has

published numerous books

and papers, and is a fre-

quent PMI, APLN, INCOSE,

SPIN, and conference speaker. Please visit his website

for contact information (http://davidfrico.com).

> About the author

CERTiFYING PEOPLEwww.isqi.org

»Everything should be made as

easy as possible, but not easier.«Albert Einstein »Thanks Albert, this is just what we did.«[email protected]

With more than 10 years of experience in professional cer- tication, iSQI issues 10000 examinations a year. Custom-ers in over 60 countries all over the world rely on iSQI’s

state of the art ISO-17024-certied exam processes andunmatched services. iSQI is here to support you in yourcertication examination efforts.



How to Begin Changing the Process

Starting a process change is never easy, especially if you’re tryingto fundamentally change how team members collaborate. To getover the initial resistance and build a case for further changes,most teams started by implementing a practice that improvedproduct quality or saved time over the short term. All of thesestarting points will produce bene ts in the short term and lead tofurther improvements.

Implement Speci cation by Example as part of a

wider process change

When: On green eld projects

Four teams I interviewed implemented the core ide-as of Speci cation by Example when moving to anagile software development process. There was noneed to ght resistance to process changes or obtain manage -ment support.

Implementing Scrum, XP, or any other agile process is a shocktherapy anyway, so if you can, you might as well try to implementSpeci cation by Example at the same time.

Teams that were able to do this reported fewer problems andimplemented the process more quickly than teams that startedfrom a dysfunctional Scrum environment. This is most likely be-cause all four of these teams had signi cant support as partof their agile migration (three had consultants on site, and thefourth had a team member with prior exposure to Speci cationby Example).

Focus on improving quality

Instead of focusing on a particular target process,the team at uSwitch decided to focus on improvingproduct quality. They asked all members to presentsuggestions for improvement and used these as in-spiration. They ended up implementing most of theprocess patterns of Speci cation by Example withlittle resistance.

From a management perspective, this is a particularly good ap-proach if individuals on the team are likely to resist a process

change. People might be against Scrum, agile, Speci cation byExample, Kanban, or anything else that’s process related. Anopen initiative to improve quality is less likely to cause com-plaints. David Anderson advocates focusing on quality in Kan -

Speci cation by Exampleby Gojko Adzic

Starting a process change is never easy, especially if you’re trying to fundamentally change howteam members collaborate. In this article from chapter 4 of Speci cation by Example (http://www.manning.com/adzic/), author Gojko Adzic goes over the most common starting points to get overthe initial resistance and build a case for further changes.

You may also be interested in…



ban 1 as the rst step of his recipe for success.

Start by identifying the biggest obstacle to delivering

high-quality software; then solve it.

If developers and testers aren’t working closely together andhave a difference of opinion about whether something is of ac-ceptable quality, it might be useful to visualize activities relatedto releasing a product. At LMAX, an electronic trading exchange,Jodie Parker made all the release activities visible by creating arelease candidate board, which showed a high-level view of thethree teams’ progress. It featured the status of all the planneddeliverables, the main focus of the release, a set of tasks thatwould have to be done before a release, and critical issues thatwould have to be addressed before a release. All the teams couldsee this information and then come up with suggestions for im-proving delivery ow.

Start with functional test automation

When: Applying to an existing project

The majority of teams I interviewed adopted Speci cation by Ex -ample by starting with functional test automation and then grad-ually moving from testing af ter development to using executablespeci cations to guide development. That seems to be the pathof least resistance for projects that already have a lot of code andthat require testers to run their veri cations manually.

Several teams sought to solve the problem of bottlenecks at

the testing phase, a result of testers having to constantly catchup with development. With short delivery cycles (weeks or evendays), extensive manual testing is impossible. Testing then pilesup at the end of one iteration and spills over into the next, dis-rupting ow. Functional test automation removes the bottleneckand engages testers with developers, motivating them to partici-pate in the process change. Markus Gärtner says:

For a tester who comes from “testing is the bottleneck”

and continuous ghting against development changes, it

was very, very, very appealing to provide valuable feed-

back even before a bug was xed with automated tests.

This is a motivating vision to work toward.

If you don’t already have functional test automation,

know that this is a low-hanging fruit—an easy way to start

the journey to Speci cation by Example that provides im -

mediate bene ts.

Automating functional tests works well as a rst phase of adop -tion of Speci cation by Example, for several reasons:

■ It brings immediate bene t. With automated tests, thelength of the testing phase is signi cantly reduced, as isthe number of issues escaping to production.

1 David Anderson, Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010).

■ Effective test automation requires a collaboration ofdevelopers and testers and starts to break down the dividebetween these two groups.

■ Legacy products rarely have a design that supports easytesting. Starting with functional test automation forcesthe team to address this and make the architecture moretestable, as well as sort out any issues around test reli-ability and test environments. This prepares the ground forautomating executable speci cations later.

■ When most testing is manual and the team works in shortcycles, testers are often a bottleneck in the process. Thismakes it virtually impossible for them to engage in anythingelse. Test automation gives them time to participate inspeci cation workshops and start looking at other activi -ties, such as exploratory testing.

■ Initial test automation enables the team to run more tests,and run them more frequently, than manual testing. Thisoften ushes out bugs and inconsistencies, and the sud -

den increase in visibility helps business stakeholders seethe value of test automation.

■ Writing and initially automating functional tests oftenrequires involvement of business users, who have todecide whether an inconsistency is a bug or the way thesystem should work. This leads to collaboration amongtesters, developers, and business users. It also requiresthe team to nd ways to automate tests so business userscan understand them, preparing the way for executablespeci cations.

■ Faster feedback helps developers see the value of testautomation.

■ Automating functional tests helps team members under-stand the tools required to automate executable speci ca -tions.

Isn’t this just shifting work?

A common objection to freeing up testers by getting pro-grammers to collaborate on test automation is that pro-grammers will have more work and this will slow downdelivery of functionality. In fact, a trend in the industryis for teams to have more programmers than testers, somoving work from testers to developers is not necessarilybad—it might remove a bottleneck in your process.

Implementing functional test automation will get the team towork closer and prepare the system for the use of executablespeci cations later. To get the most out of this approach, auto -mate functional tests using a tool for executable speci cationsand design them well. Automating tests using traditional testerrecord-and-replay tools won’t give you the bene ts you need.


24/57

ISTQB® Certied Tester Foundation Level (English & German)ISTQB® Certied Tester Advanced Level - Test Manager (English)ISTQB® Certied Tester Advanced Level - Test Analyst (English)ISTQB® Certied Tester Advanced Level - Technical Test Analyst (English)ISEB Intermediate Certicate in Software Testing (English)

©SockphooYu_Acu

Our c om pa ny s a v e s up to

6 0 % of t ra in in g c os t s by on lin e t ra in ing .

T he ob t a ine d knowle dg e a n d th e s a v ing s e n s u re t he c om pe t it iv e ne s s o f o u r c om pa ny .

www.t e -t ra in ing s -s hop .c om

Online Training



Start by automating high-risk parts of the system

Working to cover all of a legacy system with automatedtests is a futile effort. If you use functional test auto-mation as a step to Speci cation by Example, developenough tests to show the value of test automation andget used to the tools. After that, start implementing ex-ecutable speci cations for changes as they come andbuild up test coverage gradually.

To get the most out of initial functional test automation,focus on automating the parts of the system that arerisky; these are the areas where problems can cost youa lot of money. Preventing issues there will demonstrateimmediate value. Good functional test coverage will giveyour team more con dence. The bene ts from automat -ing parts with less risk are probably not as noteworthy.

(See http://gojko.net/2011/02/08/test-automation-strategy-for-legacy-systems)

Introduce a tool for executable speci cations

When: Testers own test automation

On projects that already have functional test automation fullyowned by testers, a key challenge is to break the imaginary wallbetween testers and developers. There’s no need to prove thevalue of test automation or to ush out issues around test en -vironments, but the mindset of the team has to become morecollaborative.

This problem is mostly cultural (more on that soon), but some-times it’s also nancial. With an expensive test automationframework such as QTP, licensed per seat, developers and busi -ness analysts are intentionally kept far from the tests. Once theattitude toward collaboration changes, a team can work togetheron speci cations and automate the validation without changingthem.

Several teams got pushed in this direction when they had a prob-lem that couldn’t be appropriately tested with their existing auto-mation toolkit. They used this situation as a good excuse to startusing one of the automation tools for executable speci cations.

Teams discovered that using an automation tool for ex-

ecutable speci cations got developers more engaged

in test automation and provided business users with a

greater understanding of the tests.

Developers then became more engaged in test automation andbegan running tests on their machines; they were able to see thevalue of quick feedback from functional tests. Business userscould understand automated tests using a tool for executable

speci cations and participate in specifying related acceptancecriteria. After that, changing the process to design executablespeci cations and tests up front was relatively simple.

When working with a large insurance provider, Rob Park’s teamused a proof of insurance PDF as an excuse to introduce a toolfor automating executable speci cations and move functionaltesting to an earlier stage in the development cycle. Park says:

QTP wasn’t able to test it — it could verify that the window

would pop up without an error message, but that’s it. I

wanted to be able to have the developers run tests in the

rst place on their machines, which was one of the limita -

tions of QTP [due to cost per seat]. I went with JBehave.

We kind of threw it all in all at once, and it really just

took off in a week. We can now let these acceptance tests

themselves drive the design of the underlying controller.

At Weyerhaeuser, Pierre Veragen and the team worked with acustom test automation tool that recorded tests through the userinterface. The cost of maintenance was high. After a change thatbroke many tests, he was able to justify moving to FitNesse af-ter estimating that rewriting existing tests in the new tool would

take less time than rerecording all the broken tests. Moving toFitNesse allowed the team to work more closely with engineerson executable speci cations and sparked the move to Speci ca -tion by Example.

Use test-driven development as a stepping stone

When: Developers have a good understanding of TDD

Another common strategy for adopting Speci cation by Exampleis to grow the process from (unit) test-driven development, espe-

cially when working on a green eld project.

Test-driven development practices are much better documentedand understood in the community than Speci cation by Exam -ple. If a team already has good TDD practices in place, there’sprobably no need to demonstrate the value of automated tests orchange the design to make their sof tware more testable. Execut -able speci cations can be seen as an extension of test-drivendevelopment to business rules. (The term acceptance test-drivendevelopment is a popular synonym for Speci cation by Example.)

At ePlan Services, Lisa Crispin used this approach when theywere rst implementing Speci cation by Example:

I couldn’t get people interested in acceptance tests. On

Mike Cohn’s suggestion, I just picked a story, went to the

developer working on a story, and asked, “Could we pair

up writing a test on this story?” Developers would see

how easy it is. In the next sprint I picked a different story

and a different person. We right away found a bug, where

he didn’t really understand the requirement. So the de-

velopers immediately saw the value.

When a team has a good understanding of TDD, making the casefor executable speci cations is easy: Explain them as tests forbusiness functionality.



Summary

The most common starting points to get over the initial resist-ance and build a case for further changes are:

■ If there’s already a process change going on, use it toimplement key ideas of Speci cation by Example.

■ Use the ideas of Speci cation by Example as inspiration forimproving product quality.

■ Implement functional test automation for teams that don’thave automated functional tests.

■ Introduce automated executable speci cations for teamsthat have test automation separate from development.

■ Use test-driven development (TDD) as a stepping-stone forteams that practice it.

For source code, sample chapters, the Online Author Forum,and other resources, go to http://www.manning.com/adzic/

Here are some other titles you might be interested in:

Becoming Agile

…in an imperfect worldGreg Smith and Ahmed Sidky

AspectJ in Action, Second Edition

Enterprise AOP with Spring Applications

Ramnivas Laddad

C++ Concurrency in Action

Practical Multithreading Anthony Williams

Gojko Adzic

is a frequent speaker at

leading software develop-

ment and testing confer-

ences and runs the UK ag-

ile testing user group. Overthe last twelve years, he

has worked as a developer,

architect, technical direc-

tor and consultant on pro-

jects delivering nancial

and energy trading, mobile positioning, e-commerce

and online gaming.

Gojko runs Neuri Ltd, a UK based strategic consultancy

that helps ambitious teams from web startups to large

nancial institutions improve software delivery.

To get in touch, write to [email protected] or visithttp://gojko.net.

For more information on Gojko‘s latest book, see http://

speci cationbyexample.com

> About the author

Advertise at

www.agilerecord.com

http://www.agilerecord.com/index.php?m=ar_08&a=24http://www.agilerecord.com/index.php?m=ar_08&a=24


27/57

March 12–14, 2012Brussels, Belgium

www.belgiumtestingdays.com

http://www.belgiumtestingdays.com/index.php?m=ar_08&a=25http://www.belgiumtestingdays.com/index.php?m=ar_08&a=25


28/57

Conference (Day 1) – March 13, 2012

Time Galaxy 1 Galaxy 2 Galaxy 3 Workshops -Atrium Sponsor Tracks

08:00-09:00 Registration

09:00-09:15 Conference Opening

09:15-10:05 KeynoteGoranka Bjedov:

“The Future of Quality”

10:10-11:00 Kris Laes:“When performance

testing meets Businesspeople”

Maarten Van Eyken:“‚QA‘-gile: black-box on a

white-board”

Johan Jonasson :“Don‘t Mislead YourStakeholders (Even If

They Ask You To)”

Dorothy Graham &Mark Fewster:

“Test Automation Clinic“- Part 1 -

Sponsor Presenter

11:00-11:25 Coffee Break

11:30-12:20 Michel Kalis:“Perfomance Testing Case

Studies”

Henrik Andersson:“Hi, are you stuck in an

agile project?”

Susan Windsor:“How to deliver valuefrom Test Assurance”

Dorothy Graham &Mark Fewster:

“Test Automation Clinic”- Part 2 -

Sponsor Presenter

12:20-13:50 Lunch

13:50-14:40 Sajjad Malang &Catherine Decrocq:“ATDD with Robot

framework done right”

Elalami Lafkih:“Testing SerendipityTesting: The Art ofIncreasing Defect

Detection Likelihood”

Niels Malotaux:“Quality Comes Not

From Testing”

Dawn Haynes:“The Search for

Software Robustness”- Part 1 -

Sponsor Presenter

14:50-15:40 Wim Demey:“Knock-knock-knockin‘

on infrastructure‘s doors”

Matthew G. Sullivan:“Would You Enjoy

Reading Your Own TestReports?”

Jean-Paul Varwijk:“Regulations – Where

Quality Assurance meetsTesting”

Dawn Haynes:“The Search for

Software Robustness”- Part 2 -

Sponsor Presenter


16:20-17:10 KeynoteJohanna Rothman:

“QA or Test? Does it Matter? You Bet it Does!”

17:15-18:10 Lightning TalksSpeakers: Lisa Crispin, Scott Barber, Dawn Haynes, Dorothy Graham, Susan Windsor, Lee Copeland

18:10-18:20/18:30-19:20

Cocktail / Improvisation act

19:20- 22:30 Dinner & Chill Out

Tutorials – March 12, 2012

“Assessments and how to perform them”Johanna Rothman09:00-17:30

“Making Test Automation Work in Agile Projects”Lisa Crispin09:00-17:30

“Test Estimation, Monitoring and Control“Lloyd Roden

09:00-17:30

“Mobile Testing”Karen N. Johnson09:00-17:30

“Essential Software Requirements”Lee Copeland09:00-17:30

All tutorials include lunch and coffee breaks.


29/57

Conference (Day 2) – March 14, 2012

Time Galaxy 1 Galaxy 2 Galaxy 3 Workshops -Atrium Sponsor Tracks

08:00-09:00 Registration

09:00-09:05 Conference Infos

09:05-09:55 KeynoteKaren N. Johnson:

“Why it matters what I‘m called: Quality Analyst or Software Tester”

10:05-10:55 Scott Barber:“Applying EducationalAssessment to Testing”

Gilles Mantel:“Test automation: thereturn on investment

myth”

Dries Baert:“Offshore tester: Friend

or Foe?”

Eveliina Vuolli& Kirsi Korhonen:“Solving practicalproblems with the

quality assurance in thelarge scale”

- Part 1 -

Sponsor Presenter

10:55-11.25 Coffee Break

11:30-12:20 Peter Morgan:“Planning your careerto stay testing into the

sunset ...”

Michael Palotas& Dominik Dary:

“Test Automation – 10(sometimes painful)Lessons Learned”

George Wilkinson:“Creating balance as a

tester in modern times”

Eveliina Vuolli& Kirsi Korhonen:“Solving practicalproblems with the

quality assurance in thelarge scale”

- Part 2 -

Sponsor Presenter

12:20-13:50 Lunch

13:50-14:40 Raja Bavani:“Distributed Agile: TheNeed for QA Mindset in

Agile Testing Teams”

Graham Thomas:

“Test ProcessImprovement –

Answering the BIGquestions!”

Stefaan Luckermans:

“Janssen of Janssens,Thomson or Thompson,Dupont ou Dupond?”

Goranka Bjedov:

“Advanced Hands-onPerformance Testing”

- Part 1 -

Sponsor Presenter

14:50-15:40 Björn Vanhove:“Think out of the box with

ADQA”

Rik Marselis:“Governance: Controllingquality like a lmdirector”

Adrian Rapan& Tony Bruce:

“A Tale Of Two Cities”

Goranka Bjedov:“Advanced Hands-onPerformance Testing”

- Part 2 -

Sponsor Presenter


16:10-17:00 Alfonso Nocelli:“Open Source or not

open Source that is theQuestion”

Sigge Birgisson:“Moving the project

forward - perform testingand avoid the QA”

Zeger van Hese:“Artfull Testing”

17:05-17:55 KeynoteLloyd Roden:

“Dispelling Testing’s Top Ten Myths and Illusions”

18:00-18:10 Closing Session

Note that the program is subject to change. Please visit our website for the current program.


30/57

Díaz & Hilterscheid Unternehmensberatung GmbH

Kurfürstendamm 17910707 Berlin (Germany)Phone: +49 (0)30 74 76 28-0Fax: +49 (0)30 74 76 28-99www.diazhilterscheid.de

AQIS bvba

Uilstraat 763300 Sint-Margriete-Houtem (Belgium)Phone: +32 16 777420Fax: +32 16 771851www.aqis.eu

March 12-14, 2012in Brussels, Belgium

QA versus Testing! Antagonism or Symbiosis?

is next year’s theme of theBelgium Testing Days taking place from March12–14, 2012 in the Sheraton Brussels Airport Hotel in Brussels, Belgium.The Belgium Testing Days is an annual European conference for and by bothnational and international professionals involved in the world of SoftwareTesting.Learn from experts and many others who are passionate about Testing during3 days of talks, learning and discussion and use networking opportunitieswith your peers and industry experts.

Belgium Testing Days 2012 –A Díaz & Hilterscheid ConferenceEndorsed by AQIS

[email protected]

Follow us on Twitter:www.twitter.com/BelgiumTD

Register Now! Catch the Early Bird discount and save 15% of the regular price!

Exhibitors & Supporters 2012

If you’d like to be an exhibitor at Belgium Testing Days 2012, please ll in the form which you can nd in our exhibitor brochure and fax it to+49 (0)30 74 76 28-99 or e-mail it [email protected] .

Download our exhibitor brochure at www.belgiumtestingdays.com

Want to exhibit?

Impressions and quotes from 2011

“It was a realinformative and productive conference.“

“Good atmosphere and facilities andwell planned and organized .““I’d like to have thisyearly .““It gave me a lot ofnew inspiration .“

Exhibition

Knowledge Transfer Networking

Entertainment

http://www.diazhilterscheid.de/en/index.php?m=ar_08&a=28http://www.diazhilterscheid.de/en/index.php?m=ar_08&a=28http://www.belgiumtestingdays.com/index.php?m=ar_08&a=28http://www.belgiumtestingdays.com/index.php?m=ar_08&a=28http://www.belgiumtestingdays.com/index.php?m=ar_08&a=28http://www.diazhilterscheid.de/en/index.php?m=ar_08&a=28http://www.belgiumtestingdays.com/index.php?m=ar_08&a=28http://www.belgiumtestingdays.com/index.php?m=ar_08&a=28



Definition

The principal indicators of a growing business are a widening cus-tomer base and rising return on investment (ROI). Various param -eters steer these indicators in a positive direction, chie y cost,time and quality. Balancing these parameters is of paramountsigni cance for business growth. Companies need to deliver, costeffectively, the right product, in the right way, to meet customerrequirements with assured quality. They must do this rst timeevery time to ensure that they can bring new products and ser-vices to market ahead of their competition. Companies also need

to extensively consider market dynamics including technologicaldevelopments, changing customer preferences, evolving globalstandards and regulations. These market developments add fur-ther complexity and force companies to enhance the frequencyof their product updates and accelerate delivery schedules.

In software product development, an Agile methodology is onestrategy adopted when addressing the challenges of market dy-namics. As customer satisfaction and ROI are linked to productquality and cost of quality, QA and testing services have a criticalbearing on the success of any agile project.

In simple terms, agile software development refers to a groupof software development methodologies or procedures based oniterative development, meaning that the requirements and so-lutions are generated through collaboration and union betweenvarious cross-functional teams. This type of development is avery disciplined project management process. This encouragesfrequently the interaction and teamwork, inspection and adap-tation, which ensures rapid delivery of high-quality software tomeet the customer’s requirements.

Agile methods break activities/tasks into small increments with

minimal planning, and do not directly involve long-term planning.Iterations are short time frames that typically last from one tofour weeks. Each iteration involves a team working through a fullsoftware development cycle including planning, requirements

analysis, design, coding, unit testing and acceptance testingwhen a working product is demonstrated to stakeholders. Thishelps minimize overall risk, and lets the project adapt to changesquickly. Stakeholders produce documentation as required. An it-eration may not add enough functionality to warrant a marketrelease, but the goal is to have an available release at the endof each iteration. Multiple iterations may be required to releasea product or new features. The primary measure of progress isWORKING SOFTWARE .

The most important component of agile methodology is teamcomposition . Team composition in an agile project is usuallycross-functional and self-organizing without consideration forany existing corporate hierarchy or the corporate roles of teammembers. Team members normally take responsibility for tasksthat deliver the functionality an iteration requires. They decideindividually how to meet an iteration’s requirements. Their mainobjective is to ensure that they deliver and test what is requiredfor the delivery of the iteration.

The main emphasis in agile methods lies on face-to-face com-munication over written documents when the team is all in thesame location. When a team works in different locations, theymaintain daily contact through videoconferencing, voice, e-mail,etc.

Each agile team will be represented by the Project Manager/cus -tomer representative. All the meetings will be held between thestakeholders and this customer representative. All the responsi-bilities lie with the customer representative. He makes the com -mitments to be made available for queries by the developers. Atthe end of each iteration, all the stakeholders and the customerrepresentative discuss what is done and the progress so far, and

what is to be done to achieve the deliverable, as well as any is-sues and solutions.

Various tools/techniques are used to help improve quality and

Agile Testingby Santosh Varma



enhance project agility: Continuous integration, automated or xU -nit test, pair programming, test driven development, design pat-terns, domain-driven design and code refactoring.

By using an agile methodology better software is developed andothers are helped to develop it. The main values which are addedare:

■ Individuals and interactions over processes and tools

■ Working software over comprehensive documentation

■ Customer collaboration over contract negotiation

■ Responding to change over following a plan

To compare agile methods with other methods, we can say thatagile methods fall under adaptive methods . Adaptive methodsfocus on adapting quickly to changing realities. When the needsof a project change, an adaptive team changes as well. An adap-tive team will have dif culty describing exactly what will happen

in the future. The further away a date is, the more vague anadaptive method will be about what will happen on that date.An adaptive team can report exactly what tasks are being donenext week. When asked about a release six months from now, anadaptive team may only be able to report the mission statementfor the release, or a statement of expected value vs. cost. Onthe contrary, predictive methods focus on planning the futurein detail. A predictive team can report exactly what features andtasks are planned for the entire length of the development pro-cess. Predictive teams have dif culty changing direction. Agilemethods have much in common with RAD (Rapid Application De-

velopment) techniques.

When comparing agile methods with the waterfall model, it be-comes clear that agile development has little in common withthe waterfall model. The waterfall model is the most structuredof the methods, stepping through requirements capture, analy-sis, design, coding, and testing in a strict, pre-planned sequence.Progress is generally measured in terms of deliverable artifacts:requirement speci cations, design documents, test plans, codereviews and the like.

The main problem with the waterfall model is the in exible divi -sion of a project into separate stages, so that commitments aremade early on, and it is dif cult to react to changes in require -ments. Iterations are expensive. This means that the waterfallmodel is likely to be unsuitable if requirements are not well un-derstood or are likely to change in the course of the project.

Agile methods, in contrast, produce completely developed andtested features (but a very small subset of the whole) every fewweeks. The emphasis is on obtaining the smallest workablepiece of functionality to deliver business value early, and con-tinually improving it and adding further functionality throughout

the life of the project. If a project being delivered under the wa-terfall method is cancelled at any point up to the end, there isnothing to show for it beyond a huge resources bill. With the agilemethod, projects that are cancelled at any point will still leave the

customer with some worthwhile code that has likely already beenput into live operation.

We can say that agile uses the TDD (Test Driven Development)model. The main points to be considered from the testing per-spective and software development life cycle are :

Project Initiation Phase

For an Agile project to succeed, effective planning and manage-ment are required. As part of the project team the Test Manageris responsible for establishing the quality processes, identifyingtest resources and delivering the test strategy. The test strategywill include details of the agile development process being used.It will also include details of test phases not directly related tothe agile development, such as operational acceptance or per-formance testing.

Development Phase

True Agile development uses a “Test Driven Development” (TDD)

approach. Testers, developers, business analysts and projectstakeholders all contribute to kick-off meetings where the “userstories” are selected for the next sprint. Sprints are usually of

xed duration and selecting the right number of stories and esti -mating the time to deliver them is the key to success. The estima-tion process can often be inaccurate at the beginning of an agileproject, but improves as the team’s experience grows within thespeci c implementation they are working on.

Once the user stories are selected for the sprint, they are usedas the basis for a set of tests. The testers create test scenarios

which are presented to the business analysts and project stake-holders for their approval and signoff. These test scenarios arethen broken down into test cases that of fer adequate test cover-age for the given functionality. The developers then write codethat will pass the tests. In this approach the development andtesting take place continuously throughout the sprint – there isno separate testing phase. In the TDD approach the features aretested throughout the sprint and the results presented to thestakeholders for immediate feedback. The test scenarios de nedare not limited to functional testing but can include other types oftesting including performance and integration testing when theproduct is mature enough.

As functionality grows with each iteration, regression testingmust be performed to ensure that existing functionality has notbeen impacted by the introduction of new functionality in eachiteration cycle. Defect xes should also be followed by extensiveregression testing. The scale of the regression testing grows witheach sprint. To ensure that this remains a manageable task, thetest team should use test automation for the regression suiteand focus their manual testing effort towards locating new de-fects during the build phase.

Resource ManagementThe agile approach required a mixture of test skills – usually heldacross one team. Test resource will be required to de ne thescenarios and test cases, conduct manual testing alongside the



developers, write automated regression tests and execute theautomated regression packs. As the project progresses, special-ist skills will be required to cover further test areas that mightinclude integration and performance testing. The availability of apool of professional test resources offers the scope for effectiveresource management across the agile project life cycle. Thereshould be an appropriate mix of domain specialists who plan andgather requirements in addition to test engineers who will havemultiple skillsets and own the test execution.

Communication

The bene ts of independent testing will not be realized unlessgood communication exists between the testers, developers,business analysts and project stakeholders. The iterative modelof development and the frequency of releases mandate that allteams have a common understanding of the user requirements.The testing teams should be skilled in the use of change manage-ment tools. The communication model used by the testing teamitself must enable both regular and ad-hoc p

agilerecord_08

Documents