We’re Mike and Andy, and between us we’ve spent a fairly ridiculous amount of our working lives around software delivery, testing, assurance, projects, suppliers, consultancies and organisations confidently declaring things finished before anyone has checked whether they actually work.
We also provide independent testing, assurance and delivery consultancy. If that’s why you’re here, head straight to Need Testers? and tell us what’s going on.
Mike’s background is mainly in software testing, quality assurance, automation, transformation and delivery, across government and financial services. That has included hands-on testing, test management, leading automation and testing functions, directing testing across complex organisations and senior test and assurance roles.
Andy is an experienced project delivery consultant, following a successful career in assurance. His background brings the other side of the problem: whether the project around the software is genuinely under control, whether the evidence stacks up and whether what senior people are being told bears any resemblance to what is actually happening.
Between us, we spend a lot of time asking fairly simple questions that can produce surprisingly uncomfortable answers:
What are we building?
Does it work?
Was it tested properly?
Is the project actually under control?
Does anybody understand the risk?
And why does the dashboard say everything is green when production appears to be on fire?
WHY WE CREATED BLAME THE TESTER
Testing has a strange place in software delivery.
When everything works, nobody particularly cares who found the defects before release.
When everything breaks, everybody suddenly remembers the test team exists.
Hence Blame the Tester.
We created the site to take the piss out of the ridiculous things that happen around technology delivery: impossible deadlines, meaningless dashboards, defects disappearing through creative wording, suppliers producing enormous documents nobody reads, projects declaring themselves successful before the thing actually works, and management discovering that “green” was apparently not a technical property of the software.
The stories are exaggerated for entertainment.
The behaviour underneath them often isn’t.
WE ACTUALLY DO THIS STUFF
The site is funny.
The experience behind it is real.
Between testing, assurance and project delivery, we’ve worked around the sort of problems organisations normally discover after they have already spent a lot of money creating them.
Sometimes it is a small product where nobody really knows how much testing is enough.
Sometimes it is an established delivery team that keeps releasing defects despite having plenty of testers.
Sometimes it is a supplier producing impressive reports while avoiding the awkward question of whether the software actually works.
And sometimes it is a large programme with enough governance to require its own postcode but no clear answer about whether it is genuinely ready to go live.
Those are completely different problems.
They should not all receive the same consulting template.
SOMETIMES TESTING IS THE PROBLEM
Despite the name, we don’t believe testers are automatically innocent.
Sometimes testing is shit.
There are testers who execute scripts without thinking.
There are test teams proudly maintaining thousands of test cases nobody needs.
There are automation functions measuring success by the number of automated tests rather than whether any of them find anything useful.
There are test managers who can tell you the pass percentage to two decimal places but cannot tell you whether the customer can complete the main journey.
If testing deserves the blame, we’ll blame testing.
Developers, suppliers, delivery teams, project managers, executives and consultancies are afforded exactly the same courtesy.
Nobody gets protected because they have the right job title.
TESTING ISN’T THE SAME AS ASSURANCE
Testing tells us things about the software.
Assurance asks a wider question:
Should we actually believe what this project is telling us?
You can have excellent testers working inside a badly controlled delivery.
You can also have immaculate project governance surrounding software nobody has tested properly.
Neither is particularly useful.
That combination of testing experience, assurance experience and project delivery experience is a big part of what we bring.
We care whether the thing works.
We also care whether there is any sensible basis for everybody believing that it works.
WE ARE NOT PROCESS FUNDAMENTALISTS
More testing is not automatically better.
More governance is not automatically better.
More documentation definitely isn’t automatically better.
A small app built by one developer does not need the same testing and assurance as a major platform handling money, sensitive information or millions of users.
If you’ve built something small, you can pay somebody twenty bucks to click around it and tell you whether anything obviously breaks.
That can be perfectly useful.
Just understand what you bought.
Someone clicking around your app is not necessarily someone working out where the biggest risks are, whether the coverage makes sense, what has been forgotten or whether there is actually enough evidence to launch.
The same applies to project delivery.
Adding another governance board to a troubled programme does not automatically make it more controlled. Sometimes you’ve just given the problem another meeting to attend.
Sometimes the answer is more.
Sometimes it is different.
Sometimes it is simply stop doing the pointless bit.
QUALIFICATIONS HAVE THEIR PLACE
We have the qualifications as well.
Testing, project delivery, professional training and the usual collection accumulated after enough years working in this industry.
They’re useful.
They’re not magic.
You can learn testing techniques, project methodologies and assurance frameworks from a course.
You cannot learn every awkward judgement call that comes with doing the job for years.
A certificate can explain what a risk register is.
Experience teaches you to recognise the meeting where everybody knows the risk register is fiction but nobody wants to be the first person to mention it.
We value the first.
We place rather more value on the second.
WE HAVE A LOW TOLERANCE FOR CONSULTANCY WALLPAPER
We have both spent enough time around consulting to know that an expensive answer isn’t automatically a useful one.
There are consultancies capable of assessing an organisation for several weeks and eventually producing 70 slides explaining that it needs to “improve quality maturity” or “strengthen delivery assurance.”
There will be circles.
There will be arrows.
Someone may introduce a maturity model nobody had asked for.
The phrase target operating model has a reasonable chance of making an appearance.
And after all of that, you may still have absolutely no idea what you’re supposed to do on Monday morning.
We prefer starting with the actual problem.
Show us the software.
Show us the delivery.
Show us the testing.
Show us the evidence.
Show us the report everybody says is green.
Tell us what keeps going wrong.
Then let’s work out what the problem actually is.
Sometimes the answer genuinely requires a substantial piece of work.
Sometimes the useful answer is:
Stop doing that. Do this instead.
We’re comfortable with either.
THE STORIES ARE JOKES. MOST OF THE PROBLEMS AREN’T.
The stories on Blame the Tester are written for entertainment.
Characters are fictionalised. Situations are exaggerated. Sometimes several bits of delivery stupidity get combined because reality occasionally needs editing to become believable.
But anyone who has spent long enough around technology will recognise the behaviour underneath them.
Impossible deadlines.
Green dashboards hiding red systems.
Testing being asked to prove something works after the decision to release it has already been made.
Defects becoming “known behaviours.”
Suppliers measuring success by how much activity they performed.
Projects where everybody owns a piece of assurance and nobody owns the actual answer.
And, inevitably, somebody asking why testing didn’t stop everybody else doing something stupid.
That’s where the name came from.
NEED SOMEONE TO LOOK AT YOURS?
If you’ve got a testing problem, delivery problem, assurance problem — or you’re not entirely sure which one you’ve got — get onto us.
Tell us what’s happening.
We’ll look at the problem, tell you what we think and recommend what you should do next.
No coloured-circle maturity model required.