July 30, 2011

...Learn TDD with Codemanship

Using Tests To Debug Your Business

Here's a quick idea for the weekend.

You know how we tackle bugs, right? (just nod and agree. It's quick and it's painless.)

When a bug's reported, we ask the customer what should have happened, then we write a test to reproduce the bug that will fail until the software does what it should have done.

Why not apply that to "bugs" in our business? When a customer complains - let's imagine, ooh, just off the top of my head, that you bought a ticket for a dinner event online and weeks later you still haven't recieved any details about the event from the vendor - write a script that reproduces that scenario, defining what should have happend, and then fix your business so that in future what should happen does happen.

Add these scripts to a library of business tests, and on a regular basis, regression test your business by reenacting these scenarios and checking that the required outcomes, er, come out.

Then, and this is the good part, actively encourage customers to complain if they're not happy. The faster the complaints come in, the quicker the problems will get fixed, and the sooner your business will evolve from crappy service to Goldstar Service.

Debug the problems like we debug our code. Step through the business "call stack" (the layers of interactions between different parts of the business) and pinpoint the source(s) of the bug. Give that part of the business the responsibility for fixing it, and the authority and autonomy to do what's necessary. Empower teams and departments to improve. If it helps, encourage teams and departments to build a library of test scripts just for their part of the business, explicitly defining their responsibilities within business processes. These would be your "unit tests". Having unit tests is good, because when things break we can pinpoint the problem much, much faster.

So, if the reason we didn't get our dinner confirmation is because the PA was on holiday, then we can fix that by sharing that responsibility among several employees and requiring that at last one of them is working in any given week. If we execute 20-30 business tests for our department every Monday morning, if our business is "broken" (e.g., the person who was supposed to be sending out emails is off sick and the others are on holday), we'll get an early warning and a chance to apply a temporary solution before it affects any customers.

Posted 9 years, 7 months ago on July 30, 2011