I had introduced OpenAgile to a small software development company with team members in Toronto, Montreal and India. They have been using an iterative approach to development with continued improvements to productivity since then. At the time, we talked about the concept of thinking in terms of "How are we going to test this" before writing code.
Many people (including developers) have a hard time seeing the benefits of thinking about testing as a way to save time in the development process. Often, tests are created "after the fact". Unfortunately, this is often what causes the biggest hurdle to learning the practice. Trying to write tests for code that was not intended to be tested can be more troublesome than simply learning to create the test first. There are ways to test legacy code. I won't get into that here (at the end of this article, I'll put a link to wikepedia about mock objects or "mocking".
Back to the company that inspired this article...
It has been a tremendous help to the company to work on the highest ROI items first and to be moving forward toward their goal of potentially shippable software each cycle (OpenAgile uses cycles for iterations and encourages progress to be made primarily through Learning).
I have been visiting them for a few hours every week for a few months now, and have been reviewing problems they have been having with their application as they crop up. They modify something and a problem re-occurs from code they fixed weeks ago, or even months ago.
As each cycle goes by, they have a larger and larger list of regression testing to do as the tests are not automated. They find defects that they have fixed before because of a recent change. Sound familiar ?
As I introduced the Mindset to them back in September, they knew exactly what I mean with my usual response; "Hey, you know EXACTLY how to improve this situation. You just need to find a place to start."
I know it is very difficult for someone to immediately jump right on board the testing mindset. It can be a slow road and isn't easy to switch to if you're in fire-fighting mode... One step at a time is better than no progress at all.
Often, the difficulty is that the idea of Testing is too abstract or not directly related to what the company does to have it make sense. As defects from the past crop up, just gently bring them up as examples of problems that could be avoided with an Automated Test.
I find that nothing works better than real life examples.
Unfortunately, fixing old defects might be tougher to do as they were likely not designed to be tested. Start with something easy. You will find it likely that the team would prefer to start with something easy as well, so this will work out just fine. You can even get the ball rolling by including the "FIRST" test into their testing environment or Source Control. That test could simply be to make sure the testing environment works, such as 1+1 should equal to 2, or my favourite, Assert.AreEqual(true, true);
PLEASE be careful and prepared. If things happen like they did for me at this company, one day they will take you up on your offer and want you to assist them to create a Unit Test. You should be prepared to help them or, at least know someone who can.
It's a big deal that they are finally willing to give it a try. Don't lose this wonderful opportunity to help the company out!
by Mike Caspar
|Original Post -Sep 2011||Introducing a Test Driven Mindset|
|Test Driven Development||http://en.wikipedia.org/wiki/Test-driven_development|