Several years ago, long before the community was actively talking about Test Driven Development, I worked for a short time at a company as a “bug fixer.” That was my role. They had hired me because they had some software that was “basically done” but “had some issues.” It should only take a few weeks.
The first thing they needed me to fix was that the web site was supposed to send out email. It turns out it was a configuration problem. But they were so impressed (“the last guy we had in here spent two weeks on that problem and still hadn’t solved the problem.”) that they gave me more and more bugs.
This Is The Job That Never Ends
The gig that was suppose to be a couple of weeks long was quickly turning into a perpetual job. Soon I learned that what I was working with was a system that had a lot of bugs, but no one was willing to admit that. Eventually, frustrated by the fact that this system seemed to have a new bug every day, I asked for the specs so that I could create a test plan. That’s when I found out the worse news of all about this system.
They had lost the specs. Not only had they lost the specs, but they were unwilling to admit this to the client and instead they were relying on the process of fixing the bugs to eventually squash all of the bugs so they could end up with a stable system.
Since I was not yet familiar with the concepts of unit testing or Test Driven Development, I accepted this as the best we could do. Hey! At least I was getting paid well.
Oh, but the story gets worse.
The Plot Thickens
About three months into this gig, the manager of my project went on vacation which left the project in HIS manager’s hands. That’s when the poop hit the fan.
The Oracle consultant that was working with me and I were called into the office.
“Why does this system still have bugs?!!” Oh, he was angry. That should be all bold and all caps and all underlined.
Well sir, several weeks ago I asked for the requirements document so that I could write a test plan and I was told the requirements were lost. If we can’t write a test plan, we never will be able to ensure that the system is working the way that it should.
“I want you to write a test plan.”
To which I repeated my need for a requirements document.
We went back and forth with him insisting that I write a test plan and me stating that it could not be done until I finally said, “I think I’ve done all I can do here.” Walked out of the office, packed up my stuff, went home, and immediately called my recruiter to make sure he got MY version of what happened first.
But, it didn’t have to end like that.
A Better Way
Had I known about test driven development, every time a new bug came in, I could have written a new test, even if it was only unit test and not acceptance test, every time a new bug came in. Eventually, I would have created not only the test plan, but I would have created the specification, or at least the parts that tended to break, and we would have ended up with a stable system like they thought they were going to get.
Other post in TDD
- Why Don't You Practice Test First Development? - February 20th, 2014
- Test Driven Specifications - February 25th, 2014
- Unit Test Structure - March 11th, 2014
- When You Really Need All Of Your NUnit Test In One Class - March 18th, 2014
- TDD Isn’t All About Testing - March 25th, 2014
- Automated Web Application Functional Testing - April 1st, 2014
- What Not To Test - April 9th, 2014
- Make Your Test Work For You - April 18th, 2014
- Don’t Comment Out That Test - April 24th, 2014
- The Proper Function of QA - May 1st, 2014
- TDD Saves Time – A Story - May 22nd, 2014
- It is called "Unit Testing" for a reason - August 28th, 2014
- Is Your Architecture Crippling Your Unit Testing? - September 4th, 2014
- Selenium Performance Improvements - October 2nd, 2014
- Technical Debt Is Inevitable - October 16th, 2014
- NUnit, Unity Dependency Injection, MOQ and Private Fields - October 23rd, 2014
- NUnit & Visual Studio - December 4th, 2014
- Software Architecture without Test Driven Development is DANGEROUS! - January 29th, 2015
- NUnit Test Code Structure - February 5th, 2015
- Excuses For Not Testing - February 26th, 2015
- Why Johnny Can't do Test Driven Development - March 5th, 2015
- Changing Habits - March 19th, 2015
- 100% Code Coverage Possible? - March 26th, 2015
- TDD Gamification - Turning Test Driven Development into a Game - April 23rd, 2015
- Run NUnit from Visual Studio - April 30th, 2015
- The Parable of The Road Line Painter - May 28th, 2015
- The Fallacy of Motion - July 23rd, 2015
- Test Driven Learning - An Experiment - March 24th, 2016
- 3 Reasons You Believe 100% Code Coverage Is Impossible - May 26th, 2016
- What If Unit Testing Wasn’t Necessary? #noTDD - June 27th, 2017