The field of Quality Assurance is evolving more or less rapidly in its maturity in organizations.
Talking about an “agile coach” or a “test enabler” is becoming common for quality roles that were once inspired by industry quality control.
A Quality only at the end of the chain, a posteriori, has many times shown its limits and difficulty in integrating into the product.
At the same time, the DevOps movement has spread widely in the ecosystem.
Even if it is often perceived as a particular technical subject, its cultural, organizational and change management aspects are the most key to address.
At the crossroads of Agile, Developer Experience and automation at scale, platform engineering supported by a cross-functional team emerges as a powerful model.
The emergence of Platform Engineering
We can turn the problem around by asking ourselves: what happens without platform engineering?
Each team will solve similar problems in silos, in parallel and probably differently.
We will deploy services lacking in interoperability, scalability and maintainability.
Imagine trying to integrate systems without an integration standard, with different environments, API headers or authorization management.
These types of impacts remain are limited on a small scale but will grow with the expansion of the organization.
The most structuring points leading to an approach of Platform Engineering are:
- The need for acceleration and organizational scalability
- The ability to integrate complex technologies
- Control of the costs necessary for profitable growth
Just like a digital product in the hands of customers, different actors can access a platform supporting automation, self-service, etc.
The platform is often supported by a dedicated team, at the service of other teams.
But what about QA?
The horizontalization of interactions and the acceleration of delivery rates are also pushing QA to reinvent itself.
To ensure its impact in the software delivery ecosystem, shouldn’t it also evolve transversally, providing services to the various players?
The lack of quality inclusion in the different stages of the process is a point of difficulty that is often raised.
Even if we share on the BDD, Test in Production, the practices are rarely found integrated into the development cycle.
We need to learn and accelerate learning to mature from other disciplines.
The value provided by quality will be increased by its transversality and overall impact in the organization and its value chains.
Ideally, we want to achieve a Quality Built-in managed and led by the various players: Product owner, Developer, Tester, etc.
This is why I am convinced that structuring a Quality Engineering approach with a platform vision can increase the impact of quality in the organization.
Beyond a perspective of Developer Experience and Developer Productivity, quality must ensure that the business value delivered is that expected for customers, while providing a productive quality system in support.
We speak more of Business Quality Engineering and Engineering Productivity.
So quality should do everyone’s job?
This is a possibility but it will not be sustainable or scalable, as the DevOps ecosystem has realized.
Eventually, a bottleneck will materialize and the quality will be reduced.
As an alternative, quality can be seen positively, as a provider of added-value services for the different actors.
Counterintuitively, it is this investment in a platform that allows quality players to spend more time in collaboration with its users.
It must, like DevOps, automate repetitive tasks and requests, improving their performance and scalability.
Quality, therefore, does not have to do everyone’s job but must succeed in integrating the different dimensions of quality into the processes of the organization.
Can we talk about the Quality Engineering Platform?
I am convinced that it is an interesting avenue to explore and verify through concrete experiences.
Let us analyze some use cases of such a platform and what would be its differentiation.
Upstream of the development cycles, there is the need to identify the differences in requirements, which must then be aligned in verifications.
For the use-cases, we would like to be able to validate them automatically with BDD. Not just between the product owner and the tester, but making them available to the developer in his development iterations.
Once in production, we would also like the main use cases to be supervised.
These needs are often met by manual and semi-automated silo processes.
We align use cases with development tickets, by integrating BDD into manual tests and luckily, a BDD framework for the developer.
The production supervision part will remain in the hands of operations, considered too technical for the business.
Are not these processes that the quality seeks to be systematically integrated?
The services that a quality platform can provide
Services must meet several requirements.
They must be available in self-service, automated while meeting the needs of security, traceability, performance.
Today, it is possible to provide the first snippets of this platform.
Systematizing quality gates in CI/CD pipeline templates is the first step.
We can then add tests from the deployment in production, which will be supplemented by the supervision of the user journeys identified by their use-cases.
Tomorrow, we can envision providing more value-added and mature services, like the path taken in DevOps.
We could allow the Product Owner to choose which customer journeys he wishes to supervise, and how to be notified.
The developer could activate the bi-synchronization of the repository of the test cases with his local database cases.
Why not integrate crowd testing automatically via APIs with each delivery, opening the necessary tickets and notifying the teams?
Quality requires a Quality Engineering Platform to accelerate its impact
My conviction is that quality must evolve in automation and the provision of services.
This amounts to building a real platform around the needs of the various actors in the ecosystem.
This platform will support the different phases of the project, from the definition of the need to operations.
The quality ecosystem will be more and more integrated into the technological ecosystem, depending on the advances made in software development and DevOps.
This growing maturity is what will allow better interoperability and provision of services through a QA platform.
A platform, which will not forget, as its ultimate goal, to allow better collaboration between actors.