How to Introduce a Test Driven Mindset

Recently, I was helping a friend of mine introduce OpenAgile into their environment. They are a software development house with some local and some overseas developers. I am occasionally following up with my friend to see how they are doing.

Their development has been going well since adopting Agile practices with the exception of a recurring problem with “returning bugs”.

A bug will be discovered, fixed, and then several weeks later will show up again after some other modifications.  This is a sure sign that Test Driven Development is not happening.

Consider the following:

  • There is a master data entry screen called “Shipment Entry”.  The first field on the form has a “Shipper” field that allows the entry of a Shipper Code.
  • If you press CTRL-N, you Should get a sorted list of Company Names ordered by CompanyName, paged 20 at a time, with a smaller selection if some of the characters of the company name have been filled out.  The resulting list should appear within 3 seconds.
  • Today you downloaded the code, recompiled and find that the drop down does not sort anymore.
  • You know that you have fixed this before.

Introduce the Test Driven Development Mindset.

Instead of opening a ticket, sending an email, complaining or whatever your process is, consider trying the following and introducing something like this into your source / version control.
Shipment Entry Screen Tests
Shipper Field is Empty, CTRL-N pressed List Appears, paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has “ABC”, CTRL-N pressed List Appears (filtered to show all companies containing “ABC” in the company name), paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has an invalid entry “INVALID”, CTRL-N pressed Within 3 seconds, a pop-up appears indicating “NO COMPANY FOUND”, the shipper field is blanked and the cursor is returned to that location. The popup disappears.

If any developer works on that screen, before checking in, they need to do all the tests on the SHIPMENT ENTRY TESTS document to ensure they have not broken anything.Don’t get me wrong. The idea is not to document the entire screen up front! Try to avoid designing the ENTIRE UI up front in this way. That has it’s own non-agile problems. This is just an easy way to introduce future changes using a different mindset.In my example above, there is a field called “Mode of Transport”. It currently shows a list of numbers which internal employees “KNOW” from years of experience with the application. When that number is selected, it gets converted into something like “MAIL”, “COURIER”, when it is printed on the final document. Your team has agreed to do work to have it show the appropriate labels in a drop down on the screen.Traditionally (non-test mindset), you would send out an email or open up an issue with a request for this change. Then, the cycle will continue again. As time goes by, you will always need to re-check this is working properly.

Try something like this instead:

When you have finished your planning and have decided this “story” or “feature” will be introduced to this cycle or Sprint, simply modify this document as follows;

Shipment Entry Screen Tests
Shipper Field is Empty, CTRL-N pressed List Appears, paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has “ABC”, CTRL-N pressed List Appears (filtered to show all companies containing “ABC” in the company name), paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has an invalid entry “INVALID”, CTRL-N pressed Within 3 seconds, a pop-up appears indicating “NO COMPANY FOUND”, the shipper field is blanked and the cursor is returned to that location. The popup disappears.
Mode of Transport Entry into Field Within 1 second, when entering this field, a drop-down list appears show full descriptions, sorted alphabetically by Mode of Transport.

Granted, the tests will eventually become cumbersome. However, please remember that someone will eventually be testing these screens and find these bugs in a never ending circle. My friend found that every morning they were having to go through all the screens to see what “new things” were broken.

Why not just try to get it right during your Cycle or Sprint ?

In the above example, as soon as someone takes on this task, they will have a failing test (Red), they will do what they need to do to get the test to pass (Green), and then will adjust the code to be efficient (Re-factor).

Although Test Driven Development is better done at other places in the code, this is a great way to introduce the “Mindset” into your team.

Someone will eventually say “This is getting to be a hassle. Can we automate it somehow?”, which as an Agile person is exactly the words you eventually want to hear.

Maybe now, you can start to introduce it at the Unit Test, or Functional Test or whatever level is appropriate to your organization. There are some more formal ways of doing TDD such as Extreme Programming (XP).

The important thing is that your company will have shifted to a Test Driven Mindset.

The quality of your product will increase and stay that way and the need to go back and fix old bugs in a never ending cycle can soon be a thing of the past.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

One thought on “How to Introduce a Test Driven Mindset

  1. Pingback: TDD: Links, News and Resources (2) « Angel “Java” Lopez on Blog

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>