a whole team approach to quality - bitpipedocs.media.bitpipe.com/io_10x/io_106357/item... ·...

www.rallydev.com © 2012 Rally So4ware Development, Inc.

1

A Whole Team Approach to Quality

We’re All in This Together

www.rallydev.com

Why Agile?

•  37% Faster to Market (Rally Teams 50%)1

•  16% More ProducIve (Rally Teams 25%)1

•  ¼ the Expected Defect Rate1

© 2012 Rally So4ware Development, Inc.

2

1) QSMA and Cutter Consortium ROI study on Agile teams, 2008.

QSMA Benchmarked 26 Agile development projects, against a database of 7,500 primarily traditional development projects in 500 organizations.

Results – Agile teams using Rally were 50% faster to market and 25% more productive @ ¼ the expected defect rates.

www.rallydev.com

The En.re Agile Team is Accountable for Quality

Tradi.onal

•  Dev and QA Separate •  QA as the Quality Police,

Expected to “test in” quality

•  QA has the keys to producIon/veto card

Agile

•  QA integrated with Team

•  Team Accountability & Commitment to Quality

•  QA has a criIcal seat at the table throughout the process


3

www.rallydev.com

The En.re Agile Team is Accountable for Quality

Tradi.onal Agile


4

“Moving Sticks – Not My Job” “We’re All in This Together”

s.


5

The Essence of Agile is Itera.ve Development Agile projects build so4ware incrementally, typically using short iteraIons of

1-‐4 weeks, to keep development aligned with changing business needs

So, instead of a single pass, 6-‐18 month release that predicts all requirements up-‐front and squeezes tesIng during the end game…

Agile adapts to frequent feedback by delivering working, fully tested code every 1-‐4 week iteraIon

www.rallydev.com

The Agile Team has a shared goal of A High Quality Product that Drives Business Value


6

“As a buyer, I want to have my shipping information confirmed so I get a chance to correct any errors”

The team commits to delivering value in the form of potentially shippable

product every 1-4 weeks. User stories specify the value to be delivered.

For stories to be accepted, the implementation must be complete and fully tested


7

The Team Must Test to Deliver Value Teams agree to a “Definition of Done” that represents

potentially shippable code at the User Story, Iteration and Release Levels.

…with a Story •  all code is checked in •  all unit tests passing •  all acceptance tests running and passing •  help text written •  accepted by the Product Owner •  could be delivered to users

…with an iteration •  story criteria + •  product backup complete •  performance testing •  all defects closed or postponed •  80%+ test code coverage

…with a release •  iteration criteria+ •  stress testing •  performance tuning •  security pass validated •  disaster recovery plan tested

Sample Team “Done” List:

www.rallydev.com

Without Test, There is No Value Delivered

•  If it’s not tested, it’s not accepted •  If it’s not accepted, there’s no value delivered •  The enIre team commits and is accountable •  It’s impossible to “run out of Ime” for tesIng

•  If test tasks are not complete, the team stops and everyone tests. Programmers can’t “get ahead” of testers.


8

www.rallydev.com

The Role of the Tester


9

“The nature of the tester's role changes in iteraIve projects. We are no longer the high-‐profile vicIms, we are no longer the

lonely advocates of quality, we are merely (!) competent service providers, collaboraIng with a group that wants to

achieve high quality.”

-‐ Cem Kaner

www.rallydev.com

Tes.ng -‐ “Just Another” Role on the Team


10

•  Testers are co-‐located and fully integrated into the team

•  Help the business stakeholders define acceptance criteria and examples for user stories during iteraIon planning

•  EsImate test tasks as part of user story work breakdown

•  Automate acceptance tests •  Perform exploratory tesIng

•  Perform non-‐funcIonal tesIng (e.g., performance/security) or interface with specialty teams

•  Report to SQA, sharing learning within their skill center

www.rallydev.com

The Collabora.on Model Changes, Tester Skillsets Do Not


11

•  Acceptance Test •  Exploratory Test •  Context-‐Based Approaches •  Model Driven •  Risk Based TesIng •  Non-‐FuncIonal TesIng

•  Performance •  Security •  Threat Modeling

•  Etc…


12

Agile Team Roles…Different Skills – One Goal A High Quality Product that Drives Business Value

•  Developers embrace automated unit tesIng. Since no work is accepted without being tested, design for testability is encouraged.

•  The ScrumMaster facilitates the team. Blocks like poor testability and failing builds are made visible and the ScrumMaster makes sure the team addresses them.

•  The Product Owner drives the product from a business perspecIve. Feedback is provided every 1 to 4 weeks, so requirements mistakes are caught immediately.

www.rallydev.com

How do we fit Test within a 1-‐4 Week Itera.on?


13

Agile teams deliver fully tested , working code every 1-‐4 week iteraIon. New teams o4en wonder how tesIng can be squeezed into that Imeframe.

A Lead in For Our Next PresentaIon…

“How TesIng fits within an IteraIon”

…and yes Agile teams do it all the Ime.

www.rallydev.com

Summary and Next Steps

Summary •  Agile teams are jointly commiied and accountable to Quality

•  Testers are one role on a team delivering a quality product that drives business value

•  The results are in. Agile teams using Rally are 50% faster to market, 25% more producIve and have ¼ the expected defects of their peers

Next Steps


14

•  View the “How to Fit TesIng in the IteraIon” presentaIon in this series to see how tesIng fits in a 1-‐4 week Ime-‐box.

•  Explore the ImplemenIng Agile Teams, Agile Test & Engineering PracIces, and Rally JumpStart Service Offerings

•  Request a free 30-‐day Rally Enterprise EdiIon trial.

a whole team approach to quality - bitpipedocs.media.bitpipe.com/io_10x/io_106357/item... ·...

Documents