Regression Testing: Down the Rabbit Hole Neil Studd, Towers Watson

About Me

•  10 years of testing •  Cambridge-based •  Work for companies

with red logos

Only the names have changed…

Chasing the Holy Grail •  We’ll hear lots today

about how regression testing should be done –  …in an ideal world –  …easiest for new projects –  …or when starting afresh –  …when there’s wider

business buy-in, e.g. continuous delivery

•  The “holy grail” of regression testing…

I took the red pill

•  Desktop software •  Infrequent releases •  Client-driven features •  Client-driven deadlines •  (Time v features v quality:

Quality often loses) •  Manual regression cycle •  At the end of the release

Our sacred texts

•  Tests are treated as a product bible

•  Handed down through generations

•  Revered and followed without question

•  Very much “of their time”; not modified to reflect new evidence

Oh, the things I’ve seen…

•  Tests not testing what they claimed to test

•  Expected result = “a sensible error”

•  …but that was actually a bug!

•  Not enough detail •  Too much detail

All the information, all at once

Why was it done this way?

We need to go deeper •  Five whys:

–  Not peer-reviewing –  Short of time/resources –  Fixed project deadline –  Unrealistic promise to

customer –  Salespeople too far

removed •  Dev/test separation,

driven by disrespect (dev) and fear (test)

•  “Testing is a tester’s problem”

We fell for the dark side •  Don’t allow your tools to

start working against you! •  TFS: Supports multiple

references to one test •  TFS: Supports “shared

steps” in tests = quickly multiplies setup/teardown

•  Just because you can easily record a regression test, doesn’t mean you should

What I didn’t do

•  Not burning books… •  …written in good faith •  …useful metadata •  …cross-referencing •  …gives information

about previous perceived severities

How I’m surviving

•  Rewriting/reducing •  Piecemeal •  Session-based •  To answer “Is there a

problem here?” •  …Which involves

looking at the product

How I’m trying to change things

•  Training devs to test •  Pairing/reviewing

developer unit testing •  Automating black &

white checks •  (…but not to replace

human interaction) •  More code reviews •  …which feed testing

There’s still room to improve

•  More automation •  Run more easily/often •  Increased testability •  Address the causes

of regressions, rather than fixing the fallout

•  Focus on providing value and information

Any questions?

•  More thought to come (yes Simon I’ll write that article for The Testing Planet)

•  Blog: neilstudd.com •  Twitter: @neilstudd