Testing - So how are we with the basics?

About a year ago I left the UK to spend some time in New Zealand working and travelling. To paraphrase my overall experience: beautiful country, a little behind the times with its IT thinking (or, so I thought at the time).

 Since returning to the UK I have struggled to settle, I have been looking for somewhere and something where I could use my experience and help to make a real difference. While searching, I have been working largely on short term contracts, mostly on projects that are in a little bit of a bind and are well advanced towards an unmoving delivery objective.

 And so I find I have a little bit of time on my hands once again, trying to work out why my patience and tolerance is wearing so thin so quickly and asking myself if I am searching for a nirvana that does not exist or should I just shut up and take the money, which is pretty much what I have been doing for most of my life in IT.

And then I started reading one of my very old testing books that I recently unpacked from a box in the loft.

 I quote directly from this book:

 â€œThe bottom line is that effort appears to have been saved at the unit level but emerges later in extra expense at higher testing levels or in field changes after delivery. It is better to leave untested code out altogether than to falsely claim program completion through the insertion of untested garbage: because untested code is garbage and remains so until tested. If you still believe that it’s possible to test and integrate a system without meeting the minimum standard of 100% coverage, then there’s no point continuing with this book. There’s a philosophical chasm between this writer and the reader that only the reader’s future bitter and expensive experience will bridge.”

Author: Boris Beizer – Software System Testing and Quality Assurance. Circa: Early 1980’s. If you don’t know who Boris Beizer is and you are involved in Test Engineering then please correct this omission immediately.

 The tools and technology stack get updated every few years – new ideas, new tools and buzz words. But the fundamentals have not changed at all – think it; design it; build it; test it. Repeat until done and don’t skip on any aspect of that process. There are lots of tools to help speed up and assist with artefact creation, maintenance and measurement but they are in no way a replacement for actually doing the required work with good test engineers.

 In my last three engagements (since returning to the UK) I have met and worked with test engineers who were “cheap” but did not know how to test, resulting in rubbish tests. They were led by test managers who did not know what was happening on their watch, so progress reporting was complete fiction.  Business owners who had commissioned work and did not have the faintest understanding of the reports they were receiving – and therefor had no idea how to act on them. And technical managers who thought QA was optional and available for selection and use on a case by case basis on the premise that they alone could predict where the defects would arise and what impact they would have, in advance.

 If anyone reads this and is wondering what my point is – It is simply this:

 I can assert with absolute certainty that Boris was and remains, spot on! The cheapest most cost effective way to deliver any working software product is do ALL the required work as and when it is required. Not doing adequate testing is not cheaper, it doesn’t deliver earlier and the best tool to use for the job is a properly qualified, experienced, motivated human supported by the correct tooling.

 Test Engineering is a fundamental part of the SDLC. Testing not complete? Job not done! Why is that so difficult to comprehend?