Scribd
Upload
48 views49 pages

Top Presentation

Creating better quality software using Agile Acceptance Testing and Fitnesse The document discusses how an organization improved software quality and testability over 12 months by implementing Fitnesse acceptance testing within an Agile development process. Testers were integrated into development teams and responsible for writing Fitnesse tests. This led to automated testing taking just one hour and developers embracing testing. Key factors for success included a realistic timeline, treating test automation as a project, and influence over system design for testability.

Uploaded by

moviesnmusic
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
48 views49 pages

Top Presentation

Creating better quality software using Agile Acceptance Testing and Fitnesse The document discusses how an organization improved software quality and testability over 12 months by implementing Fitnesse acceptance testing within an Agile development process. Testers were integrated into development teams and responsible for writing Fitnesse tests. This led to automated testing taking just one hour and developers embracing testing. Key factors for success included a realistic timeline, treating test automation as a project, and influence over system design for testability.

Uploaded by

moviesnmusic
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 49

Bridging the Gap

Creating better quality software using Agile Acceptance Testing and Fitnesse
Clare McLennan clare.mclennan gmail.com

http!""cra#y$it$ad%entures.blogspot.com http!""twitter.com"claremclennan

Contents
& & & & & & The Challenge 'hat means Testability( Fitnesse ) to *)+ in * months ,ur -ystem Test Toolbo. -uccess Factors

The Challenge

The Challenge
& /n the beginning0 time to market was e%erything & As our customer base grew it became important that the system always worked & Big culture change & **.**+ uptime target & 1eleases wee2ly & -ystem was hard to test

'hat means testability(

Testability
& Any wor2ing system is testable & Aim for Easy to Test & 3ow much
4 -etup 4 5nowledge

is needed to test one aspect of the system( & -ee podcast0 Test 6ri%en 6e%elopment is 6esign

-ymptoms of Low Testability


& Frustrating and slow to test anything & Testers needing continuous help from de%elopers & 6e%elopers may belie%e testers are stupid & 6e%elopers a%oid system testing and stop after unit testing succeeds & 7oor understanding of the -ystem de%elops & Can8t easily introduce new people to the pro9ect

Automated Testing System Test System Knowledge Debugging Methods Predictability Status Tools

Installer

System Test

System Knowledge Debugging Methods

Predictability Status Tools

Auto Test

Installer

3ow 'e /mpro%ed Testability


& Created an installer so e%eryone runs the system in the same way & Created a means to query the system for when processing is finished & Added business time to the system so we instantly test functionality that ta2es long periods of time :.ample! Con%ersion trac2ing wor2s o%er a period of ;) days.

Fitnesse

Fitnesse in a <ut -hell


& & & & & Means of capturing requirements as tests Tests turn green if passed0 red if failed 1equirements stay up to date Customer or testers write the tests 7rogrammers write fi.ture code to ma2e the tests run

1unning a -uite of Tests

The Technical -ide


& & & & & & Fitnesse is a wi2i 1ecommend to store tests with the code =se -L/M >has replaced F/T? @a%a0 CAA0 1uby0 7ython and more Test fail when testers write them Testers can reuse fi.tures to create more tests

-ample Fi.ture

-ample Fi.ture

-ample Fi.ture

-ample Fi.ture Code

-cript Fi.ture

Buery Fi.ture

Test ,rganisation
& & & & & Tests organised into heirachy of suites -et=p and Tear6own run before each test Test 3istory of success"failures Tests can ha%e e.planatory te.t Fi.ture toolbo. documentation

3ow To 'rite Good Tests


& =se user language0 not programmer mumbo$9umbo & Ma2e each test specific & 'rite cases not scripts $ you should only specify things rele%ant for this e.ample & Generally0 if you can8t do it manually you won8t be able to automate it. & -ee http!""www.concordion.org"Technique.html

:%olution of ,ur Tests >C?

Test uses magic numbers from database 4 canDt see what this test is about

:%olution of ,ur Tests >E?

All this setup...

:%olution of ,ur Tests >;?


...replaced by this

This is a system current implementation detail 4 not a requirement

:%olution of ,ur Tests >F?

3ang on0 these 9ust set up data and donDt test anythingG Ah better.. 'e still arenDt finished..

) to *)+ in CE months

Creating Buality 7rocesses 7reprocesses


& First Fitnesse tests were written to pro%e it was possible & First testers 9oined the pro9ect But... & 'riting automated tests didnDt catch on

Creating Buality 7rocesses -tage C


& BA group was formed to
4 1ecruite and train testers 4 'rite and program the Fitnesse automated tests 4 Test new functionality

But... & BA group struggled to 2eep up with de%elopment effort

Creating Buality 7rocesses -tage E


& BA group continued to write tests. & BA group responsible for running tests & <ew Fi.ture requests were handed o%er to de%elopment team at start of sprint But... & BA group still needed needed system programmers 2nowledge to 2eep tests wor2ing & 3ard to specify upfront all fi.tures required & 7rogrammers hated writing fi.tures

Creating Buality 7rocesses -tage ;


& Testers 9oined in de%elopment teams. & Testers responsibility to write tests & 6e% teams responsibility to get tests running & 6e% team gi%en a test bo. to run tests on & 'ee2ly BA meeting for testers to share changes and ideas

Creating Buality 7rocesses -tage ;

3ighly successfulGG
After initial teething in sprint >; wee2s? e%eryone was positi%e about the change

'hat 3appened 6uring -tage ;(


& 6BA sped up tests & 'e reduced the number of G=/ functionality tests required because of good unit test co%erage & Many manual testing issues were resol%ed & Finally testing and de%elopment occurred at the same pace & 7rogrammers embraced writing tests as part of their 9ob to maintain quality

Change in Testers 1ole


& More about ensuring good specifications to pre%ent bugs & More testing time spent on e.ploratory testing & Better relationships with programmers & Less dull wor2 & More influence on how the system is written to ma2e testing easier

,ur -ystem Test Toolbo.

,ur -ystem Test Toolbo.


& & & & As2 =ser fi.ture Business time -taged 6eployment -eparate Functionality0 Gui Functionality0 Gui Layout0 Load0 Full -ystem0 -anity and Full system tests & Close communication between testers and programmers to find optimal test strategies

As2 =ser

As2 =ser
& Mi. and match human and automated processes & Allows tests to be written and run before all automation is ironed out
4 :.ample! Gui testing will e%entually be automated with -elenium

& =ser created ob9ects can be referred to in Fitnesse tests & -imple idea but really practicalG

Business Time
& Changes the current time in the system & Allows testing of scenarios that ta2e a long time & ,nly in testing mode & Low ris20 as if forgotten system still wor2s correctly in production en%ironment

-taged 6eployment
& Thin2 Beta testing & Test throughly0 then do a partial release to
4 ,nly some customers0 or 4 For a small proportion of the daily impressions0 or 4 1un old and new system side by side

& Gi%es a more accurate test

Types of testing
Unit 4 7rogrammers tests. 7inpoint bugs quic2ly. unctionality 4 7ure0 automatic testing of the whole system. All processes triggered !ui unctionality 4 Test functionality of Gui page at a time. All other ob9ects required are generated as for functionality testing

Types of Testing
!ui "ayout 4 7ure gui test of layout0 updating. "oad 4 =se real database0 or e.tra large database ull System 4 Main functionality0with processes on timers0 as in production Sanity #heck 4 Final chec2 performed before a each release

-uccess Factors

,utcomes
& Automated testing of the system ta2es one hour0 plus some quic2 manual tests & 7rogrammers attitude has changed from e.pecting outsiders to %alidate the system0 to sharing responsibility for this tas2 & -ystem more easy to test0 deploy0 monitor and manage & A self$running BA process which is continually impro%ed by de%elopment teams

-uccess Factors
& 1ealistic time frame >CE months? & Treated building automated testing system as a pro9ect of it8s own & /nfluence o%er design of system to be tested & -tarted with high 1,/0 hard to manual test0 functionality & Get tests wor2ing0 then perfect & Gently challenged company culture

Future /mpro%ements(
& Automate G=/ functionality tests with -elenium & -tart sprints with a -pecification 'or2shop & /mpro%e Load tests $ run them on a cloud & Mo%e system 2nowledge from Fitnesse0 bac2 into the system & Ma2e tests more user orientated

To learn more read $ridging the #ommunications !a% by Go92o Ad#ic

1eferences
itnesse http!""www.fitnesse.org $ridging the #ommunications !a% by Go92o Ad#ic Test Dri&en De&elo%ment is Design - The "ast 'ord on TDD0 3ansel Minutes 7odcast starring -cott Bellware and -cott 3anselman (ints and Ti%s Hfor writing acceptance testsI by 6a%id 7eterson http!""www.concordion.org"Technique.html

You might also like