A lot of development projects are now concerned with delivering services and clients that enable companies to expose their products and services to an ever increasing diversity of client entities. I use the word entities, as the end user could be a person, or a display fridge, and a great deal of effort is put into providing a quality service to all users of the system. This is a good thing from a developer point of view because it makes us think about disconnecting a user’s abilities from their requirements, and enables us to provide an ecosystem of software that takes in people, computers, and machines.
As this ecosystem permeates more and more organisations, we see ever more opportunities to improve the cost of quality. It is easy to see how the, “Internet of things,” can improve total quality in a factory setting, or in a commercial supply chain, reducing waste, and overproduction, and enabling a, “Just in time,” capability.
“Even in organisations that clearly demonstrate a commitment to total quality principles, the practice in software testing sometimes falls short of the quality around the product or service they deliver to their customers.”
Sometimes, however, the facility that new technology brings, is taken for granted, and is sometimes so subtle that it is not noticed. Both of these issues seem crazy when you think that, people who are concerned with cost of quality, are well aware of the need to test. Testing, and testing early, are very old ideas as it goes. Post war Japan soon got a handle on the fact that it was cheaper to fix defects at the factory than it was to deal with them in cars that had already made it onto the road. However, even in organisations that clearly demonstrate a commitment to total quality principles, the practice in software testing sometimes falls short of the quality around the product or service they deliver to their customers.
It’s easy to wonder how that can be possible, but if you think about a large organisation with different divisions procuring their own software, and paying consultants to integrate it where they have to, you can start to see how the outlines of the software assets become blurred. When you consider that the software usually contracts “Washing Machine Syndrome,” where it has thirty different programs but you only use two or three, you may understand better how hard it is to picture the shape of the software assets.
As testing is an essential part of my development practice, I am loathe to make any change to a large software ecosystem without figuring out how to test, but in the scenario I have described above it can be hard to work out where to test in order to gain a consistent picture of what the software is doing and what it’s dependencies are.
In order to get a good idea of the boundaries of different software systems, it can help to think of them as existing in an ecosystem. Where they touch on each other is a boundary, across which information can flow, and there are a number of architectural patterns to interpret this connected environment.
To really succeed in testing the right things with the right weight of test, you have to get clear sight of the boundaries, and what exactly is moving across those boundaries. This gives you the power to take control of your software assets, and have them adapt rapidly to ever changing business requirements.
