Redefining software quality for Continuous Delivery
Software-driven organizations must constantly deliver a new and relevant user experience, in order to attract and retain experience-driven consumers.
That quality matters in software development is a given. How quality is to be defined, however, is a hotly disputed question.
I believe, however, that fundamental definition of quality does exist, especially for customer facing organizations. It is set out below.
Business and Product requirements converge on one thing: user experience. Delivering quality and attracting experience-driven consumers in the Application Economy therefore depends on delivering new and innovative user experience, ahead of the competition.
That customers are now driven by experience can be seen, for example, in how 47% of web users said that they will abandon a webpage if it takes more than 3 seconds to load.
80% of them said they would not return to the site – that’s traffic being driven away from your site to competitors, reflecting how business requirements depend on delivering good user experience.
The need to constantly deliver good user experience has brought business and IT initiatives into close alignment.
Like business requirements, product requirements must define how software can deliver a valuable user experience – in terms of functionality, usability performance, etc. – and IT is under increasing pressure to deliver quality software at speed.
If IT cannot deliver, the business risks being forced out of a market by digital disruptors like Uber and Air BnB who have introduced new and innovative user experiences into established markets.
Organizations should place experience first, and should strive to deliver what Jonathon Wright once described to me as a “Minimum Viable Experience”.
They should work to iteratively define the desired user experience as early as possible, with an emphasis on research and development and user interaction, to verify the model before a line of code has even been written. Approaches such as Test Driven Development and Behavior Driven Development have arisen partly in an effort to make this possible.
The model must be flexible, so that it can be constantly updated as a better understanding of the desired user experience is gained.
Critically, creating quality requirements that accurately define the desired user experience and the implementation of these requirements should not be treated as distinct phases, as in a traditional, Waterfall environment.
Quality should be built in at the very start, while the Business Requirements themselves should also function as Product Requirements.
This will eliminates rework and manual effort, as the business requirements will contain all the qualitative information about a system needed to reliably develop and test them. Testers should further be able to automatically derive all the assets they need to assure quality directly from the requirements.
This is made possible, for example, with flowchart modelling, which is accessible to the business, but also provides a mathematically precise model of the system.
Verifying user stories with the Business and user is quick and easy, while the flowchart can also be overlaid with all the functional logic and data involved in a system. This means that testers can derive test cases which provide 100% coverage automatically from it.
The model can also be easily updated, auto-updating the test cases and data derived from it. This is what it really means to “shift left” the effort of testing, allowing testers to exhaustively test a system, on time and within budget.
Doing so, an organization can become more reactive to changing user needs, and can provide the market-leading user experience which has allowed.