Unlocking potential. Accelerating performance

QA and

AGILEScrum

19th March 2013Clinton Bosch

Scrum is …

NOT agile

Agile fluency

Fluency | how a team develops software when it’s under pressure

distinct stages of agile, each with specific benefits and challenges

“Star” system

Entire teams fluency – not individuals

Teams evolve in a predictable order

Fluency at all previous levels

3

1 2

4

One star create business value

• Management pillar• Easiest • Focus on team success

Benefit: Greater visibility into team’s work; ability to redirect

Investment: Team development and work process design

Core Metric: Team regularly reports progress from a business value perspective

Achievement: 45%

Time: 2 – 6 months

Source: http://martinfowler.com/articles/agileFluency.html

team

Two star deliver on market cadence

• Technical pillar• Deliver to market cadence• Technical skills take time & effort, reduce productivity

Source: http://martinfowler.com/articles/agileFluency.html

Benefit: Low defects and high productivity

Investment: Lowered productivity during technical skill development

Core Metric: Team ships on market cadence

Achievement: 35%

Time: 3 – 24 months

EXTREME PROGRAMMING“moments to learn, lifetime to master”

Cost of change A critical concept that motivates full lifecycle testing is the cost of change

Co

st o

f C

ha

ng

e

Development Time

Traditional

TDD / Agile

By retaining the minimum amount of project artefacts required to support the project, there is less to update when a change does occur

automated testing

• Have you ever integrated a third party library into your project?

• You got a big manual full of nice documentation. At the end there was a thin appendix of examples. Which of the two did you read?

• That's what the unit tests are!

• They are the most useful part of the documentation.

• They are the living examples of how to use the code.

• They are design documents that are hideously detailed,

utterly unambiguous, so formal that they execute, and they cannot get out of sync with the production code.

The sooner you test, the cheaper to fix

Design Implementation Test Post Release0

200

400

600

800

1000

1200

wtf is uncle bob?

1. You are not allowed to write any production code unless it is to make a failing unit test pass.

2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

tdd

• If you have ever tried to add unit tests to a system that was already

working, you probably found that it wasn't much fun.

• You likely found that you either had to change portions of the

design of the system, or cheat on the tests;

• Because the system you were trying to write tests for was not

designed to be testable.

• For example, you'd like to test some function 'f'. However, 'f' calls

another function that deletes a record from the database. In your

test, you don't want the record deleted, but you don't have any way

to stop it.

• The system wasn't designed to be tested.

tdd forces decoupling

• When you follow the three rules of TDD, all your code will be testable by definition! And another word for "testable" is "decoupled".

• In order to test a module in isolation, you must decouple it.

• So TDD forces you to decouple modules. Indeed, if you follow the three rules, you will find yourself doing much more decoupling than you may be used to.

• This forces you to create better, less coupled, designs.

software testing pyramid

}}White

Box

BlackBox

where does that leave the QA

In order to manage my company’s asset register

As an asset manager

I want to be able to add new assets

Questions

??

? ?

??

? ?

?

Contact Us

Thank you for joining us!

www.bsg.co.za@bsgafrica

www.facebook.com/bsgcareers