“Where to start?”
That’s one recurring question for organizations looking to start moving from Quality Assurance (QA) to Quality Engineering (QE).
Their common trait is to reach limitations of traditional QA practices such as a dedicated team, acceptance criteria definition, or test automation.
First steps in Quality Engineering are structuring as they have to address the entire software system to implement valuable changes that stick over time.
This article shares 5 ways to start moving from Quality Assurance to Quality Engineering based on enterprise case studies.
Make Quality part of the company mission
One main issue of QA departments is to feel alone in defending quality, like trying to sail against the tide of other engineering teams.
The main argument is that quality activities in itself are supporting ones, and thus, should be the priority of other software teams.
But if we look at the value of software quality starting from the business:
- Business depends on customer satisfaction
- Customer satisfaction depends on quality attributes
- Quality attributes are delivered through software.
So until a company clarifies that fulfilling the quality requirements through software is a common mission within the organization, quality efforts will be wasted.
Organizations can funnel the efforts of multiple actors in a common direction of value creation for their organization through a shared vision and mission.
Including quality as part of the mission is done by:
- Compiling factually existing pains
- Convince at least one executive sponsor
- Review company and department mission statements.
As examples, companies studied share the business impact and costs of a slow developer cycle-time, or a huge bugs backlog as a lack of software quality in the first place.
Change the focus through acculturation
While evolving the company mission is an initial trigger, it remains to embark the rest of the organization in the move to Quality Engineering.
And again, trying to change things alone will be a waste of time as the existing forces will bring you back to the initial point of inertia.
People will change their focus if they can:
- Understand the why
- Visualize the results
- Gain something.
That’s where vision and acculturation are needed.
Acculturation consists in making people aware of other cultures—that is, accepted codes and behaviors—to eventually make them adopt them.
That process requires an effort of communication during a period of time to reach a tipping point when people will accept changing their ways of working.
Changing the focus is achieved by:
- Defining and sharing a compelling vision
- Acculturation with successful external contexts
- Adapting system key outcomes and incentives.
Some examples of these practices are to craft a QE team vision such as “enable confident deployments in less than 5 minutes”, acculturate with Uncle Bob “QA should find nothing”, or Dan Buckland “Quality Assistance Model”.
Align the Quality roles and responsibilities
Now that the organization has a vision, mission and readiness for Quality Engineering, concrete changes to quality roles and responsibilities can start.
And not only for the QA team—most of the teams are impacted.
The short version is to translate “quality is everyone’s responsibility” into concrete responsibilities for roles along the software lifecycle.
Changes are multiple:
- Evolve name, scope, mission first of the QA team
- Quality deliverables ownership: switch to product or engineering acceptance criteria, defects backlog, or deployment decisions
- Quality review & support: QA interactions evolve from a bottleneck to advisory.
The vision of the QA team will evolve to the one of Quality Engineering enablers, reducing their bottleneck to interact with advisory roles, and usually keep the quality and testing expertise that do require that specific added value.
As each context depends, the best way to set the priorities is to:
- Map value-streams that are business critical
- Clarify quality deliverables and collaboration on the flow of work
- Update team, roles, and responsibilities per position.
Concrete examples are to rename a QA department to Quality Engineering, making the head part of more important steering and governance mechanisms.
More drastic changes can be to affect existing QA profiles under the product or engineering scope, to keep a core Quality team of advisors and mentors to develop the expertise in value-stream teams. That QE core can even host architecture or craftsmanship functions.
Adapt processes to change day-to-day outputs
Many “restructuration” fails to change the day-to-day when they superficially touch the organization, only reallocating people and updating the organizational chart.
The outcomes of an organization will only change if the interactions between its actors change—making that action a priority.
Evolving to Quality Engineering interactions require to:
- Change rituals and deliverable responsibilities
- Lead and support the changes being on the field
- Measure the outcomes, sharing progress and wins.
These evolutions are best led in small increments, adapting fast, and learning with retrospectives on a reduced scope of the organization.
Successful practices can be deployed in next stages leveraging the acculturation, celebration of success, and a proven responsibility model.
Organizations for example initiated:
- “0 bug policy” switching that responsibility to value-stream teams that would benefit the most from this practice
- “Daily release train” as the only way to ship software for a specific product line, requiring to work in trunk-based development with non-regression tests.
Evolve from early wins to sustainable wins
The changes identified will act as the transformation trigger for moving from Quality Assurance to Quality Engineering.
That’s a first maturity step usually identified as “Quality Assistance” or “Quality Advisory” depending on the organization.
The goal is to diffuse the practices within multiple teams to accelerate value delivery with more quality and more speed, before going to the next level.
There’s no point trying to rush changes as it will result in the so-called “superficial transformation” that stops by themselves lacking to reach a momentum.
Quality Engineering is about driving a systemic transformation addressing the entire software system on methodologies, organization, and culture.
It’s challenging, but worth the effort.
References
Dan Buckland, Taking a phase approach to adopt Quality Assistance, Medium.
Antoine Craske, There’s no more Quality Assurance at Manomano and OpenClassrooms, QE Unit.