“It’s the fault of QA”.
It’s the recurring and easy excuse of a new delayed and buggy release. We need a culprit, and for once we can’t blame the network team. The QA, responsible for quality is an ideal target.
Moreover, “it’s not complicated to do tests”. Taking a step back, this position assumes that quality rhymes with testing. However, we do blood tests without necessarily being in good health.
This segregation of QA quickly reaches its limits to help create value. At best, we can run a few automated tests to find anomalies with a high cost of rework at the end of the chain.
This article shares the key elements of the Quality Assistance model inspired by leading players such as Atlassian or GitLab. You can find their implementation at Manomano and OpenClassrooms in this article.
Follow the QE Unit for more exclusive Quality Engineering from the community.
Quality Assistance, necessary for the creation of value
The traditional QA is too often perceived as the medical testing firm carrying out tests once the software development is finished. The logical next step is that of an organizational silo misunderstood and limited in value addition. And most importantly, his original goals are not being met.
The creation of a QA department emerges from a desire to address the quality of the software. A return on investment is expected, materialized by the creation of value. It is also necessary to have a definition shared between the different stakeholders; some will seek to improve the number of users, speed up software delivery, while others to improve stability.
“The problem with traditional QA is not creating enough value on time, becoming a waste instead of an investment, useless in Quality Engineering“
Antoine Craske
There is nothing wrong with a QA team. The problems materialize in its integration into the organization. Olivier and Vincent shared the same sufferings of an isolated team struggling to perform: better quality expected by “QA” tests, routing of dissatisfaction from the software to the “QA” team. Meanwhile, the software continues to be poorly built at its core for users who have no time to lose.
The current environment requires a capacity for continuous delivery of value, Quality at Speed. Delegating testing to an organizational silo away from user needs and software creation is far from addressing the true attributes of Quality. The goal is to create and deliver software at the expected level as soon as possible. It is therefore necessary to develop a “Quality as a capability” integrated into the organization.
For this, the QA silo gives way to Quality Assistance.
Quality Assistance, a systemic approach to Quality
Quality Assistance is not a team, it is the result of a business collaboration that creates value through quality. It’s a different paradigm integrating a systems approach. We can speak of Quality Assistance when the software quality is addressed to the base, transversally and continuously.
Quality at the base
A fundamental belief in Quality Assistance is that quality is intrinsic to the product from its inception. We cannot therefore rely solely on tests a-posteriori to “ensure the quality” of the software. It is necessary to ensure its creation as soon as possible, by measuring that the level of delivery is equal or superior to the definition of Quality. Collaboration and transversal alignment of actors is therefore necessary.
Quality transversally
Sharing the definition of Quality allows the necessary actors of software creation to have a common mission. The product owner, analyst, architect, developer and operator are all in the same boat (you will notice that there is no longer necessarily a “QA” role). If the team does not know how to deliver at the level of Quality continuously, it is their problem and that of the management, not only that of the QA.
Quality continuously
Quality Assistance is inspired by Lean to deliver fast the expected level of quality. The actors must collaborate efficiently and quickly. They must therefore use effective methods and have the right expertise. In addition, the organization must promote performance by having the necessary leadership, management and support. This is the pivotal role of Quality Assistance.
Despite its name, Quality Assistance does not aim to create assisted people, quite the contrary.
Quality Assistance creates an ecosystem for Quality at Speed
You have to see Quality Assistance as a double-sided part. On the one hand, it materializes by achieving Quality at Speed, delivering quality software quickly and continuously. On the other hand, it is supported by leadership and management to create and maintain this quality ecosystem.
The transformation to Quality Assistance does not happen overnight. A real dynamic aligned with a vision must be created in the organization. This leadership role is the responsibility of management, which must take this issue head-on. The change management must involve the actors in transverse so that they feel engaged in the transformation.
These steps were taken, for example, by QA managers in the case of Manomano, Open Classrooms and MangoPay. To be successful, it is not just a matter of proclaiming “Quality is everyone’s business”. Quality leaders must drive this initiative across the organization. They must both reinvent their organization but also those of other teams.
Switching to Quality Assurance often starts with visible changes that carry messages. The name and responsibilities of the “QA” team is often changed to a different acronym such as “Qcraft” (Manomano) or “Quality Engineering” (OpenClassrooms). We also review the expectations of existing roles to be as close as possible to the teams (coaching, support) or in transversal animation to maintain a balance.
The Quality Assistance model poses real questions of skills development.
Quality Assistance requires skills development
Habits are changing in Quality Assistance for all players. The engineering manager is explicitly responsible for the quality of his product without being able to hand over to a QA team. The historical profile of QA must be much more in the exchange to align its priorities.
The first important pivot in Quality Assistance is accountability for the quality of deliverables to frontline teams. It is therefore necessary to compose a team with the right expertise in the software development cycle to deliver Quality at Speed. This is the strength of the model: in some contexts, a real test automation profile is necessary, in others, only a manual QA closer to the functional will make the difference.
The decentralization of Quality requires a central counter force in order to maintain a coherent ecosystem. The accumulation of local optimizations ends up creating negative performance for the entire system. The historical role of QA manager is therefore evolving towards an orchestration role, ultimately guarantor of the performance of the various people contributing to Quality. Besides, the actors he animates are not all from QA.
Finally, the Quality leader must also broaden his cross-functional impact with his product, engineering and operations peers. You must therefore know how to use your QA background while remaining sensitive, curious and interested in transversal subjects to be relevant in the exchanges. The value of QA in itself does not exist, it must improve the attributes of Quality.
This is where Quality Assistance contributes to the creation of value.
Quality Assistance enables value creation
We all get paid to solve problems. Quality Assistance comes to help us resolve the issue of declining QA, mistreated and badly perceived in organizations. The objective is to proactively address the Quality of our products to better maintain it continuously, by being able to demonstrate it.
Measuring value creation is a real subject. It is not a question of calculating a financial ROI in the first instance. This exercise would most likely be wrong in addition to not being the first priority. The change towards Quality Assistance is measured from a customer point of view and also from an internal point of view. It is similar to a Balanced Scorecard exercise.
We measure the improvement of the user experience in various ways. Use of NPS and attraction and retention measures are good options. We must keep in mind their limits of interpretation of correlation and causation. Business performance and peer recommendation remain in-fine the most significant measures.
From another angle, the internal measures allow to link the outputs of outcomes of Quality Assistance. Olivier and Vincent notably mentioned the metrics of the report Accelerate such as cycle-time, availability or responsiveness in the event of an incident. We also find in common the measurement of critical bugs in production and its backlog; its decrease is a sign of quality addressed as soon as possible.
Quality Assistance is a different model for delivering software.
Quality Assistance, an organizational face of Quality Engineering
Quality Assistance is a structural change in responsibilities within organizations undergoing transformation. Seen from afar, it is about integrating Quality as early as possible into software value chains. The quality control models resulting from the industrial revolution have no place in the current ecosystem.
Quality Engineering is a transversal paradigm acting on the 5 pillars of MAMOS: Methods, Architecture, Management, Organization and Skills. Quality Assistance is part of the Quality Engineering framework mainly in the areas of organization and skills.
It is not enough to change the programming language to structurally improve our software. Organizational foundations are fundamental. Successful transformations also follow the principle of “Why, Who, Then What”. Having the right people with the right skills in the right organization is therefore a top priority.
Are you ready for Quality Assistance?