Slow Down to Speed Up - Leveraging Quality to Enable Productivity and Speed with

1

Slow Down to Speed Up – Leveraging Quality to Enable Productivity

and Speed

Fran O’Hara – Inspire Quality [email protected]

www.inspireqs.ie

© 2014 Inspire Quality Services

2

Agenda

• Quality and Speed/Productivity

• Lessons learnt/challenges


3

Resources Schedule

Scope/Requirements

Plan Driven

FIXED

ESTIMATED

Resources Schedule

Scope/Requirements

Value Driven

QualityQuality

Flipping the Iron Triangle

?

4

Quality <-> Speed

(short term)Quick and Dirty is Faster

Bad Quality slows you down (long term)

Going faster gives better quality (short & long term)

5

Economics of Product DevelopmentCycle Time

How Long it Takes to get Through the Value Stream

• Economies of Speed/Cost of Delay• Fast Feedback & Learning (Empirical)• Waste/Cost Reduction & Agility

Unit/Post-Dev CostCost of Deploying, Configuring,

Supporting, Using each ‘instance’• Ease of Use, Robustness• Cost of Configuration/Administration• Browser/Platform/OS Support

Development ExpenseDevelopment Project Costs

• Cost of Engineering Team• Dev Tools: SCM, CI, AutoTest• Team Management & Facilities• Shared Services (HR, Finance,etc.)

Product ValueProfit from a Software Product; Savings

from Internal IT Project• Sales Revenue (Volume * Price)• Cost Savings• Strategic Value

Adapted from Don Reinertsen, 2009

6

go fast have quality we must To

Faster is better…

7

Technical DebtSymptoms of technical debt• Bugs found in production• Incomprehensible, un-maintainable code• Insufficient or un-maintainable automated tests• Lack of CI• Poor internal quality• Etc.


8

Quality & Test

• Quality is not equal to test. Quality is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.

• Testing must be an unavoidable aspect of development, and the marriage of development and testing is where quality is achieved.

from ‘How google tests software’, James Whittaker et. al.


9

Lessons Learnt / Challenges

Test Automation

Line Management

Definition of Done

Test Competency

Requirements(e.g. Story size,

Non-Fn)

Test Strategy & Risk

Techniques (e.g. exploratory),

Planning for Quality, Documentation, …..

10

Basic Testing within a Sprint

Automated Acceptance/Story

based Tests

Automated Unit Tests

Manual Exploratory

Tests

Represent Executable requirements

Represent Executable Design specifications

Provides Supplementary

feedback

Test Strategy &

Risk


11

Agile Testing Quadrants – Risk!


Test Strategy & Risk

12

Definition of ‘Done’

• An agreement between PO and the Team– Evolving over time to increase quality & ‘doneness’

• Used to guide the team in estimating and doing• Used by the PO to increase predictability and

accept Done PBIs• ‘Done’ may apply to a PBI and to an Increment• A single DoD may apply across an organisation, or

a product– Multiple teams on a product share the DoD

Definition of Done


13

DoD example

Story level• Unit tests passed, • unit tests achieving 80%

decision coverage,• Integration tests passed• acceptance tests passed with

traceability to story acceptance criteria,

• code and unit tests reviewed,

• static analysis has no important warnings,

• coding standard compliant, • published to Dev server

Sprint level• Reviewed and accepted by

PO, • E-2-E functional and feature

tests passed• all regression tests passing, • exploratory testing

completed, • performance profiling

complete, • bugs committed in sprint

resolved, • deployment/release docs

updated and reviewed, • user manual updated

Release level• Released to Stage server, • Deployment tests passed, • Deployment/release docs

delivered, • large scale integration

performance/stress testing passed

Definition of Done


14

The Automation Pyramid

Unit/Component layerDeveloper Tests

e.g. JUnit

API/Service layerAcceptance Tests

e.g. Fitnesse, Cucumber

GUI layere.g. Selenium

Manual Tests e.g. exploratory

Automate at feature/workflow level

Automate at story level

Automate at design level

Based on Mike Cohn

Test Automation

15

Development Team(Analysts, Progmrs., Testers, Architect, DBA, UI/UX, etc)

You only need a Hero in a Crisis – so

No Heroes!

Deep

Broad

Programming Testers Testing Programmers

Architect

Team Lead

Developer1

Developer2

QA Lead

Tester1

Tester2

BA Lead

BA1

BA2

Create each increment of ‘Done’ Product

No Specialised Sub-Teams

Test Competency

?

16

Is testing fully integrated?

Code Code Code & Bug Fix

Test

Sprint 1 Sprint 2

Code

Test

Sprint 1 Sprint 2

Code & Bug Fix Code

Test

Code & Bug Fix

Code & Bug Fix

Test

Sprint 1 Sprint 2

Code & Bug Fix

Test

A

B

C

Requirements(e.g. Story

size, Non-Fn)

17

Examples of how to evolve quality/test practices…

• See Google’s ‘Test Certified’ levels• Paddy Power’s review of teams practices – using scale of 0-5 for items such as

– Code Reviews, – Pair Programming, – Code Analysis, – Unit Tests, – Continuous Integration, – Automated Acceptance Tests, – Data Generation, – Performance Analysis, – TDD, etc.

(from Graham Abel, Softtest Test Automation Conference 2013)

• Communities of Practice, Tribes, Mentors, etc.


18

Fran O’HaraInspireQS

[email protected]

Thank You!


mailto:[email protected]

Slow Down to Speed Up - Leveraging Quality to Enable Productivity and Speed with

Technology

quality test8 quality

leveraging quality

quality speedquick

quality isachieved

agenda quality

quality services2

quality doneness

quality services7