A friend’s car displays an unexpected warning light on some journeys. There’s no degradation in performance and visits to the dealer to replace sensors hasn’t fixed the problem. The dealer now thinks it’s a software fault requiring a fix from the manufacturer, but there’s no timeline for this. Instead the dealer now just presses a ‘reset’ button every time it happens. The Badger’s friend is unhappy because she wants to sell the car. She’s complained to the manufacturer about their inadequate software testing! Hmm. Let’s see what happens.
The Badger’s reminded of many projects where poor testing led to client disappointment and significantly higher costs for the supplier. Testing was often the poor relation to sexier software design/development activity, and it was often squeezed by development overruns and commercial pressure to get paid on time. The Badger fondly remembers a related experience from his formative years.
The Design Authority (DA) for a major project the young Badger was working on was summoned by the Managing Director (MD) to explain why the number of defects found in testing was continually rising, and what action was underway to reduce this so a large payment milestone could be secured on time. The Badger and others attended the meeting that ensued to support the DA. The MD was aggressive and demanded the financial milestone be met. He believed the testers were being too picky and threatened to install a new test team if things didn’t improve. The Design Authority was unintimidated. He merely stated that there were 1 million lines of code being tested and that ‘there are as many paths through that code as there are stars in the universe’. He then asked the MD how many defects the team should expect to find in testing, and how the MD would judge that enough testing had been done? The MD was flummoxed. The Design Authority then just got up and left! The Badger and others were flummoxed too!
Testing continued. The milestone moved right, and the software benefited from the delay. The client was ultimately delighted with the final deliverable and the MD apologised to the team for his misplaced attempt to pressurise testing for purely monetary reasons. He admitted that the delay had cost the company much less than delivering something on time of questionable quality and robustness. This left two impressions on the Badger. Never skimp on testing, and good leaders and know when an apology is needed and have the sense to do so.
Today software and data run everything. Thorough testing is imperative especially when security, privacy and safety is relevant to every system we use. End users expect software to be robust, reliable and secure. So, let’s hear it for career testers! They’ve been the poor relation to software developers for far too long…
