On Testing, Databases and Testdata - TDD Success Story

I was on-site at a large software company, reknown and with a ton of reputation. They are doing things with your money, you know. So they have to be secure.

Now, there was a habit there, to use live data for testing. Something which is sometimes done.
Anyway, they claimed that, because it was live-data they were testing with, it was a very good thing to use live-data and because every second day there would be an update of data from the live database to the test database, everything would be up-to-date. Good idea. You might think.

And then, after three months of development, it happened.
A customer dared - yes I use the word DARED by intention to point out the irony - he dared to use the core feature of the the software, which was to create or change price models.

There were not ten price models. Not a hundred. There were a thousand price models. Something in that range. And the customer decided to change about 90% of them. Yes.

The very next morning, the data had already been cloned into the dev database.
Because the administrators are unfortunately overwhelmed by the amounts of data they are dealing with, they do not manage to perform a rollback.

Prior to the next release, which was planned for the next day, they were admittedly unable to do a rollback. The testers, experienced guys, external employees like I, said in the emergency meeting that the software cannot be reliably tested.

That was it. To cancel the release would have meant breeching contractual agreements with at least two of the largest customers. What could we do?

2 months before I had a personal interview with the Head of Development, a good guy with profound knowledge who is suffering from a constant lack of resources (by saying resources the company means actual human employees, just to make it clear). He instructed me NOT to write too many UNIT tests. Because this would only slow down the development which is under constant pressure from the business side because it performs at a pace being considered too slow for the mega advanced Management. So omitting the Tests would speed it up. So he said.

Needless to say that I ignored it. I wrote tests for the most important functions, basically a lot of math for financial calculation. UNIT based, independent from the database. Maybe the Head of Dev would have cancelled our contract if he would have known at the time. But I knew that arguing would not make a difference for a person being under such pressure. The team had tried before and been ignored.

Now, when we had this emergency meeting, I said: "We can do the release."
Eyes stared at me with the expression of a panicking animal. "What?"
I said: "We can because I have UNIT tests for all your business functions."
"What?"
"Yes. Calculation is correct. Let's do the release."

The release was done and everything went pretty smoothly.

A few days after, the Head of Dev approached me by saying that doing UNIT Tests for the business critical parts of the software would be a very good thing and encouraged the whole team to establish this technique from now on. Really true.

I even managed to introduce them to Pair Programming, my favorite XP technique besides TDD, but that is another story, eh, post.

All the best,
Tim