Download - Twice as much in half time - What's about the Quality?

agility accelerates ...

Twice as much in half 4me What‘s about the Quality?

Brown Bag SMA und Partner AG 6. Februar 2012


MISCHA RAMSEYER

Agile Coach & Consultant Cer4fied Scrum Professional Management 3.0 Trainer Member of the Lean, Agile & Scrum Group, SwissICT

So8ware Engineer Cer4fied Enterprise Architect Java Enterprise Edi4on (JEE) Performance Engineer

pragma4c solu4ons gmbh

mischa@pragma4c-‐solu4ons.ch

What is Quality?

? 08.02.12 About Quality, pragma4c solu4ons gmbh 3

ISO 9000 Definiton of Quality

“Quality is the degree to which a set of inherent characteristics fulfills

requirements.“

The standard defines requirement as need or expectation.

08.02.12 About Quality, pragma4c solu4ons gmbh 4

Philip B. Crosby‘s Defini4on of Quality

"Conformance to requirements“

The requirements may not fully represent customer expectations;

Crosby treats this as a separate problem.


Joseph Juran‘s Defini4on of Quality

"Fitness for use“

Fitness is defined by the customer


Peter Drucker defines Quality as

"Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay

for.“


American Society for Quality say‘s

A subjective term for which each person has his or her own definition. In technical usage, quality can have two meanings:

a. The characteristics of a product or service that bear on its ability to satisfy stated or implied needs;

b. A product or service free of deficiencies.“


W. Edwards Deming says

Concentrating on "the efficient production of the quality that the market expects,“

and he linked quality and management:

"Costs go down and productivity goes up as improvement of quality is accomplished

by better management of design, engineering, testing and

by improvement of processes.“


Defini4ons of Quality

Quality Fulfill the requirements

Fitness for use

Build what the customer is willing to pay

for No Bugs

Improve thru Management, Tes4ng &

Procesesses


Idea

What is Quality about?


Idea

Idea Idea Product

Development

Do the Right Thing! Do the Thing Right!

Effec4veness Efficiency

What is more important?



DO THE RIGHT THING


The „Cost of Complexity“ is huge!


It‘s all about segng priori4es!


Do the Right Thing!


•  Deliver Business Value •  in the right order •  as early as possible •  con4nuously

•  Collect Customer Feedback as early as possible

•  Embrace Change •  Release when it‘s good enough

Good enough is enough to Release!


Business Value

Time

Feature

Good Enough

Release 1.0

Faster Time to Market and Lower Cost

means earlier ROI

80% Business Value

20% Time

Release 1.x

Built-‐in Change Management


Business Value

Time

New Feature identified during development

Good Enough

Release 1.0

Release 1.x

exchange

Idea

3 4mes as Effec4ve


Idea

Idea Idea Product

Development


Effec4veness Efficiency 3x


DO THE THING RIGHT


Do the Thing Right!

Where Defects Originate What it costs to fix them

The Economics of Testing

The Relative Cost of Fixing Defects One of the most well known facts about software defects is that the longer they go undetected, the more expensive they are to fix. Although research differs on the exact ratios, the general rule is 1:10:100. That is, if a defect costs one unit (hour, dollar, etc.) to fix in requirements and design, it costs 10 units to fix in testing (system/acceptance) and over 100 times to fix in production. Sometimes the cost to fix a defect in production costs much more than 100 times the cost of fixing it in the requirements phase. This cost of defects doesnFt even take into account the impact cost of defects. These costs could be attributed to lost revenue, reimbursements, fraud, lost customers, bad public relations, and litigation. In the case of safety critical systems, how can one put a cost value on a human life?

The Relative Cost of FixingDefects

0102030405060708090100

Req's Design Code Test Prod

The Relative Cost of FixingDefects

0102030405060708090100

Req's Design Code Test Prod

STBC - 3


The Economics of Testing

The Economics of Testing There is a definite economic impact of software testing. One economic impact is from the cost of defects. This is a very real and very tangible cost. Another economic impact is from the way we perform testing. It is possible to have very good motivations and testing goals while testing in a very inefficient way. In this section, we will examine the economic impact of defects and ways to economize testing.

Where Defects Originate To understand the dynamics and costs of defects, we need to know some things about them. One of the most commonly understood facts about defects is that most defects originate in the requirements definition phase of a project. The next runner-up is the design phase. Some problems in getting accurate, clear, and testable requirements are: � Many people do not have a solid requirements gathering process � Few people have been trained in or understand the dynamics of requirements � Projects, people, and the world around us change very quickly � The English language is ambiguous and even what we consider clear language can be

interpreted differently by different people. The figures in this pie chart were taken from a James Martin study and the numbers track very closely to measurements of typical software projects.

Where Defects OriginateCode7%

Other10%

Req's56%

Design27%

Where Defects OriginateCode7%

Other10%

Req's56%

Design27%

This

doc

um

ent

may

not

be

repr

odu

ced.

STBC - 1

James Mar4n Study

1:10:100

How would you handle the problem?


From Specifica4on to Discussion


As an

employee I want

to log my working /me so that

I always keep track of my daily working /me

User Story Template

Speak the same language

•  An „Ubiquitous Language“ is needed to bridge the communica4on gap

•  Use Domain Modeling to describe the Business Domain


Timetracking Domain Model

Introducing Acceptance Criterias Priority As a [role] I can [goal] so that [reason] EsImaIon

10 Employee log my working 4me I always keep track of my daily working 4me

2


Narrow down the scope of the Story using Acceptance Criterias •  At least a „How-‐to-‐demo-‐Workflow“ •  Add them to the Product Backlog

Example 1.  Fill in star4ng-‐, lunch & end 4me in natural hours & minutes 2.  Decimal working hours will be displayed & saved 3.  Displayed working hours must be present in the DB

Introducing Specifica4on by Example


Business Rules •  Given work 4me is > 9h

Then break = 1 hour •  Given work 4me is > 7h

Then break = 30 min •  Given work 4me is > 5.5h

Then break = 15 min

Morn In

Lunch out

Lunch In

Eve Out

Time

9:00 12:00 13:00 17:05 7.08

8:00 12:00 13:00 17:00 8.00

8:00 -‐ -‐ 17:01 8.02

7:30 12:00 13:00 17:00 8.50

... ... ... ... ...

Priority As a [role] I can [goal] so that [reason] EsImaIon

10 Employee log my working 4me I always keep track of my daily working 4me

2

Build Executable Documenta4on


Scenario: Log 4me Given my 4me of <arrival> And the 4me I go for <lunch-‐out> And the 4me I return from <lunch-‐in> And the 4me I leave in the <evening> When I entered my 4me Then the <total> decimal 4me is calculated Examples: | arrival | lunch-out | lunch-in | evening | total!| 09:00 | 12:00 | 13:00 | 17:05 | 7.08!| 08:00 | 12:00 | 13:00 | 18:00 | 9.00!| 08:00 | - | - | 17:01 | 8.02!| 07:30 | 12:00 | 13:00 | 17:00 | 8.50!!!

In terms of the ubiquituous language

Specifiying Behaviour


Given Put the system in a known state

When Describe the key user ac4on

Then Observes the output

And / But Shortcut for mul4ple Given, When, Then‘s

Soda Machine Behaviour Feature: Thirst Quentsching As a thirsty guy I want to pull a sop drink from the machine to quench my thirst Scenario: Successful Buy Given a filled compartment When I select the desired drink And I provide the right amount of money Then the drink falls down in the tray Scenario: Empty Compartment Given an empty compartment When I select the drink Then the message „Empty!“ is displayed Scenario: Few Money Given a selected drink And I provided too few money And the outstanding amount is displayed When I press cancel Then the already inserted money will be released into the coin compartement


Automate the Behaviour


@Given(“â filled compartment$“) public void given() {

machine = new Machine().withCompartment(1, “Can“) .withDrink(“Coke“).withPrice(2);

}

@When(“Î select the desired drink$“) public void when() {

m.selectCompartment(1); } @And(“Î provide the right amount of money$“) public void when() {

m.putMoney(2); }

@Then(“^the drink falls down in the tray$“) public void then() {

assertFalse(m.getOuputTray().isEmpty()); assertEquals(“Coke“, m.getOutputTray() .getDrink().getName();

}

Scenario: Successful Buy Given a filled compartment

When I select the desired drink And I provide the right amount of money

Then the drink falls down in the tray

Inner-‐ & Outer Quality


Inner Quality is inside the system

TDD improves inner quality


RED GREEN

REFACTOR

Write a failing test Make it compile Make it work in production code

Make it nice eliminate duplication increase expressiveness

No production code without a

test

TDD is not an op4on


Built in Regression Bever Design

Fewer Bugs Faster Development

RED GREEN

REFACTOR

What is Pair Programming?


Driver Navigator

Pair Programming


Faster, but more Effort

Bever Code & Design

Half of Bugs Knowledge spread

Double pack!


RED GREEN

REFACTOR

Address Outer and Inner Quality in your Development Process


Test Refactor

Code

Test Refactor

Code

Test Refactor

Code

Select a User Story

Identify Acceptance Criterias

Implement Acceptance test(s)

Failing Acceptance

Test

Passing Acceptance

Test

Refactor Acceptance

Test

Customer Acceptance

Behaviour Driven Development

Test Driven Development

Check against Requirements

FuncIonal Check if the System works as required •  Unit Test •  Integra4on Test •  Regression Test •  User Acceptance Test

NON-‐FuncIonal Check if the System operates as intended •  Technical Tes4ng

•  Build •  Deployment

•  Load, Stress & Performance •  Security & Penetra4on •  Usability


Checking vs. Tes4ng

Checking •  Automated •  Expected Result •  Developer-‐Mindset •  Developer Know-‐how •  Basis for Tes4ng


TesIng •  Manual •  Exploratory •  User-‐Mindset •  Business Know-‐how •  On Top of Checks

Test Automa4on is not an op4on!


UI

Services

Unit

Checks & Tests

08.02.12 About Quality, pragma4c solu4ons gmbh

Unit Tests

Single Unit Mock Objects Coded TDD Refactoring

Integra4on Test

Check Test Environment Mul4ple Units Prepared „Real“ Data Coded & Configured Expected Output

Regression Test

Replay Unit-‐ / Integra4on-‐Tests Don‘t break something else

System Tests

Manual Exploratory User Mindset Acceptance

NON-‐func4onal

Usability Performance Security

41

Checking Strategy

Addi4onal Automated Checks

Unit Tests Integra4on Test Regression Test

Con4nuous Build & Deployment

Nightly Build Con4nuous Build

Automa4c Build & Deployment

Product Build Plazorm Build Deployment Migra4on

Source Control Management (SCM)

Mul4ple Check-‐in‘s a day Single Branch


Banching Paverns


/trunk

/rel1.0 branch

2.0 Dev

merge

Release 1.0.0 tag

merge

Release 1.0.0 tag Release Branch

/trunk 1.0 Dev

/feat1-‐1

branch merge tag reintegrate

Release 1.0.0

2.0 Dev

Feature Branch

Environments

DEV • Development Worksta4on

BUILD • SCM Server • Build Server • CI-‐Server

INT • Con4nuous Deployment • Integra4on & Migra4on

QA • Controlled Distribu4on • Produc4on-‐like Setup • Review & Acceptance

PERF • Load & Performance • Security & Penetra4on

PROD • Produc4on Environment


Development

Opera4ons

44

Con4nuous Integra4on is NOT an op4on


Build

Test Deploy

Publish reports

Con4nuous Integra4on


SCM CI-‐System

Build Server Test-‐Environment

Check for Change Developer

Worksta4on Ceck-‐Out

Build

Deploy

Automated Tes4ng

Feedback

Check-‐In

Feedback

Feedback

Customer Worksta4on

Manual Tes4ng

46

Idea

3 4mes as Efficient


Idea

Idea Idea Product

Development


Effec4veness Efficiency 3x


CONCLUSION


Idea

Twice as much in half-‐4me – even more – is possible!


Idea

Idea Idea Product

Development


Effec4veness Efficiency 3 x 3 = 9

Quality Improvement thru Agile Prac4ces will boost your performance!

Line Management

Project Management

Engineering Prac4ces


Management 3.0

Scrum

eXtreme Programming

Download - Twice as much in half time - What's about the Quality?

Top Related