You Can't Solve a Problem You Don't Understand

Let’s imagine that instead of working for an asset manager or project team, you’re working for a car manufacturer and you’ve developed a brand new, fully updated model that is going to be a big seller. However, time and budget are tight (when aren’t they?) and you still need to road test the car as it’s all been designed and built as a set of components.  Who do you choose to do your testing?

1. An experienced test driver who has been doing this for years—they cost a bit more but they really do know what they’re doing.

Or

2. A team of people who have never driven a car but have read the requirements for each component and been given a copy of “Driving for Dummies”—they’re cheaper resources and there are more of them.

To me option 1 is the only real option, but option 2 seems to be quite common in the software world. At the component level, maybe this works to a degree provided each component is small and the accompanying specification is sufficiently detailed to fully describe exactly how it should work—but how often is that the case?

Testing is the last thing that happens before the users get first sight of their shiny new system in the UAT environment, and first impressions count. If the system is flaky or misses some basic requirements then business confidence is lost and can be difficult to regain. Having experienced and knowledgeable testers sign off on the software prior to this will reduce the risk of major mistakes. Using those experts to walk the business through the new system at the start of UAT, and to support them during UAT is a terrific way to boost business buy-in and speed up implementation.

The agile world in particular relies on the involvement of experienced, knowledgeable people in short bursts to make a series of incremental changes to address particular issues. This will work best where the participants each understand their part. When it comes to software functionality, this has to involve significant knowledge of the business and its processes.

To go back to the car analogy, if the specification says the car needs a steering wheel and pedals to control it, then a test driver knows without it being written down that these both have to be in front of the driver’s seat. If the documentation says it needs a steering wheel and pedals facing forward,  then the non-driver tester may tick the box even if they are on opposite sides of the car.

I still firmly believe that you can’t properly test something—or analyse it or design a solution—if you don’t understand what it’s actually meant to do. Involving business-savvy resources who are also IT and project-literate at all stages of the project may involve some additional initial expense but will reduce the overall project and support costs by:

1. Ensuring that the system and associated business processes meets business requirements even where those requirements are poorly articulated.
2. Increasing business buy-in and confidence in the new system as it has a greater degree of fit to their needs.
3. Benefit business to IT relationships by demonstrating that IT truly understands what the business needs.

Here at Citisoft we fully believe that our maxim holds true: “There is no substitute for experience.”