JIT Testing

One of the fundamental principles of quality assurance that I gleaned from the SQA course I did in 1993 was the idea of doing things just-in-time (JIT).  The phrase was coined by Japanese quality assurance experts initially for inventory control but can be applied to almost any process.  Basically, it means that you should delay doing anything until you need to do it.  This idea is especially important in software development as I explain below.

Rework

The big advantage of JIT that is it reduces "rework".  In most software projects things can change so often and so much (even including our understanding of the purpose of the project) that if you do something before you have to, you will more than likely have to do it again later.

There are other advantages to JIT, such as continuity.  If you work on the design of a module but delay the implementation (coding, units test, etc) for a month, a week, or even a day it means you have to spend time and effort understanding the problem and the proposed solution again (though I guess this re-thinking could also be classified as "rework").  Further, you will be inclined to assume you understand it and take shortcuts that can create bugs (or worse, gaps in your units tests).

Note that the agile community (especially XP) have picked up on this quality assurance idea.  For example, it is the idea behind JIT-design.

JIT and Testing

But there was one thing that confused me until recently.  In SQA (and agile too, I believe) we are told to test as soon as possible.  All forms of testing should be done as soon they can and not wait for some "acceptance testing phase" of the project.  Especially important is that programmers should be testing their code as they write it.  In "test driven development" it is even required that the tests be created before the code is written.

Isn't this the exact opposite of JIT?!?  Well actually if you think about it differently you realise it's actually another good example of JIT.  To say test as soon as possible is the same as saying delay coding until you are ready to test just as you should delay design until you are ready to code.  The important point is that you do the testing straight after the coding just as you do the coding straight after the design.

Chaos

When I discuss all this with other developers they often dismiss my ideas as complete nonsense.  Just designing, coding, and testing on the fly will apparently create the sort of chaos in software devlopment that we have been striving for the last 60 years to eliminate.  But all the difference is made by experience and a little bit of planning.  The negativity is caused by past experiments with this sort of development ...

Almost every programmer I have talked to can relate a story of when they were learning to program which goes something like this...  First, they had a really good idea for a program and an idea of how to write it so they committed their idea to code but they encountered problems which meant they could never get it to work or work properly.  Of course, during the process they learnt a lot about how to create the program properly but it meant going back to the drawing board.  They tried again and perhaps got further before encountering a different problem.   Eventually, they got something workable after several iterations, or perhaps they just gave up.

The good news is that something wonderful was happening in this process.  Though they might not have realised it they were not only learning the best way to create that particular program they were learning how to create any sort of program.

I guess my point is that given experience in writing software and some agile techniques and a bit of planning, writing software this way can often be the best way.

Unit Tests

Of course, the design may still need to be modified.  Even the most experienced developers occasionally make mistakes, and unanticipated requirements changes may make refactoring necessary.  This is where unit tests come in.  Units tests allow you to complete redesign the software and be confident that it still works correctly.

If you haven't heard of unit tests then you should make it a priority to find out about them.  I have been advocating them since well before they became fashionable (my name for them was the less catchy automated module regression tests).  Though they don't get a lot of press coverage I believe units test are at the heart of agile software development and one day will be considered standard practice.

I will have a lot more to say on unit tests soon.