There are many examples where the development of a product produces an inadequate product. Rather like this turn of phrase, what is developed is not totally unusable but its purpose is not quite what was intended. If the Benedictine monks experienced this when gas was invited during the vinification process, creating champagne in the process… others did not have this same happy ending.
Unfortunately, this is often the case during software development or process optimisation.
Analyses are carried out by business analysts, then handed over to development, then tested and put into production. However, when the client uses the new function in production, he finds that it does not meet his initial requirements.
This is because at each stage of the development chain, some information is lost or subject to interpretation…and in the end, the stakeholders only realise this at the end of the process…but by then it’s too late…the damage has already been done and the cost of correction will eat into the company’s finances.
While many industries didn’t care about the cost of rework before, the recent crises have forced the behemoths to think about how to minimise costs.
Coming from industry and software design, Lean and Agile methodologies suggest that we remove all doubt from the specification stage. Whether you call it “3 Amigos”, “Small Kaizen”, Know your process”, “shift left”, the aim of these methods is to get all the links in the chain together as early as possible.
I’ll take a real-life case study to illustrate this: one of the telecommunication majors asked us to intervene because too many defects were being reported by users on one of its core software products…and this required numerous upgrades…and therefore releases…and therefore testing…multiplying the costs.
By studying the development process, we were able to discover that, on a business need, the understanding of the various actors was different. In order to eliminate any interpretation we rethought the way of developing and specifying, by introducing from the beginning of the need definition, the test design. Thus, as early as the design phase, the testers presented the various scenarios intended to validate the development. From that moment on, there was no doubt as to how the feature should work. If the suggested test missed something, one of the stakeholders (developer or business representative) would immediately point it out in the meeting and the tester would incorporate the remarks into the test to be as representative as possible of the need.
As with any new method, some staff were sceptical about the theories being easily applied by outsiders. However, after two features treated according to this new process, these same sceptics had become spokespersons for the method…with among the benefits cited :
Concentrating the opinions of the various businesses upstream of development removes any doubt and ensures the cohesion of the requirement.
Planning the tests at the beginning of the development process validates the understanding of all the players and aligns them with the business needs.
Furthermore, if the tests are defined with the agreement of the business and IT and in the business language, they can be executed by anyone other than the tester himself…so UATs can rely on these elements and reduce the burden without restricting their evidential value.
In order to maximise and share the benefits of this method, the challenge now becomes not to burden the design process with recurring explanation and definition meetings. In addition to a strategic reflection on the development policy, it is vital that the tester is extremely proactive in the elaboration of the test and involved in understanding the need. And in certain sectors (banking, chemicals, trade, etc.) having a tester who is a business expert is an undeniable asset.
Sebastien Gillot
Head Quality and Financial Services
SCS Consulting
Comments are closed.