Assuring Quality

We've recently been exploring the project, the digital product, and how it is specified. If we were considering the software development lifecycle in a linear fashion it would be a natural time to go deeper into the specifics of the work that software developers do, building on the concepts of primitives, the factory, the supply chain, divisions of labour, and various aspects of what I have referred to as "the field of truth". We're going to look beyond that for the time being and delve into what happens once the work is (allegedly) done and in the hands of people that have been tasked with ensuring requirements have been met.

Quality Assurance.

When features are delivered and a version has been produced, QA staff will access a build of the software and begin testing units of work. Often they will initially do this on a preview environment, as mentioned in the piece about deployments. QA interact with the digital product. They have no knowledge of the factory, and they shouldn't, outside of agreed upon testing considerations. Their responsibility is to assure the quality of the digital product, not the quality of the digital factory.

They take the requirements and they validate the naive path to success, but they also validate other paths: a pool of scenarios that represent real user behaviour. They attempt to use the software in ways that users would. They leverage their professional experience to exert pressure on the factory and test its resilience. But the volume of scenarios is vast. It is not realistic, for economic reasons, to expect full coverage. Devices, network conditions, accounts, scalability concerns, (this is non-exhaustive) just as developers need be concerned with a field of truth, so too should the assurers of quality.

A challenge for these professionals is that the implementation of the digital factory and the corresponding field of truth have a significant influence on their work and yet they are generally not in a position to shape decisions, and they are perhaps not in a position to access information they need to in order to make effective decisions.

QA are often the last (perhaps only) serious stress test before software reaches users. There is no certainty that their tests, however strenuous, are 'enough' to make guarantees about software quality at scale. More is always better, but the reality is that the field of truth is often too large to conquer.

Until next time.