Not another theoretical quality assistance article, please!

My ongoing “real life” journey to Quality Assistance

If you work in the Quality World you’ve probably heard of Quality Assistance, but how much do you really know about it?

When I arrived at Openclassrooms I was the first to wonder what this Quality Assistance buzz was all about “for real”. There are some great articles ( here and there), but the topic is far from being easy. There is something tricky about describing what is not just a simple modification of a process, but a complete change of mindset.

“So , indeed, what is Quality Assistance?”

A very quick reminder about quality assistance principles on which I base my daily work here at Openclassrooms and, after that, let me tell you a personal story… ready?

Quality Assistance 3 main principles

Mentor:

Helping create a quality aware group of people.

Educate:

Teach how to spot risks and avoid pitfalls.

Monitor:

Surface the data showing quality.

So these are the 3 principles, “but how do I apply them in real life?”
Time for my personal story:

Context: AGILE team operating as an independent feature team.

One morning our friend “Barbara”, UX designer, writes on the team’s internal messaging channel:

“Hi, I’ve finished the first working version of our new credit card payment page, you can find it here (Link to FIGMA page) I’m waiting for your feedback”

What a Quality Engineer (QE), inspired by the Quality Assistance approach, should do?

The QE should be a facilitator.

In this example, that means the QE should be sure that SEVERAL people in the team have “reviewed” Barbara’s deliverable.

QE main’s quality is to be flexible, adapting to a team, being where they need you to be. Being a facilitator.

The QE will start to have a look at the work of her comrade and ask what need(s) it must meet, if it meets them, if it corresponds to the visual and ergonomic standards of the company, if it re-uses existing components.

Why? Is it better to create new ones? Do we have a design system? Items already exist? Should they be added?

As a QE, I don’t necessarily need to know all the answers to these questions. But I need to find the good questions that will challenge the product.

And, what if the frontend devs know some of the answers I need? I, as QE, will then involve the front devs in the subject making sure that they will take into consideration all the relevant aspects. I could do the same with the backend as they could have an important contribution to the subject like removing inconsistencies (“we do not have this data in the database for the moment”, “ we cannot display it / this info already exists via the Toto API”, “ no need to redo this action…”)

The PM/PO likewise also ensures that everything is in order with respect to the needs, to the following of the roadmap, all the while everyone using their own eye, their own scope, their own feelings.

Once everyone is relatively satisfied, the model is tested! It therefore reaches a first level of quality, very early in the process, since it was executed at the “Early version” mock-up stage.

If these reviews, exchanges, actions that I just described are not executed at this time, what could happen?

In the “classical” quality assurance process, everyone will base him/herself on written specifications which will often end up generating misunderstandings. Only when the new credit card payment page will be developed, important questions will be raised. Even worse, the tests will intervene at the end of the development cycle, just before it goes into production, and they will be run exclusively by a QA team member who will own the responsibility of the tests… and bugs…

So what if at that late moment of the cycle, the “product people” realizes that “this is not what was expected !!“

Or if the “quality assurance people” detects anomalies on the mobile version which had not been presented on the model.

Or the frontend realizes at the integration phase that the data is duplicated, or it’s absent and asks the backend to add it…

It all becomes expensive, time consuming, stressful for everyone and a totally ineffective process…

The QE should ensure that all levels of testing are done.

Unit, Integration, E2E, Acceptance, Performance, Security, Accessibility… no matter the test levels or types you perform or not, the Quality Assistance mission is to enforce it.

API tests, WEB tests, data tests, performance tests… We will check that all our test levels are ok, that no regression has been introduced by the new feature, and that our standards about accessibility / performance are respected.

The QE should educate devs about doing necessary new tests, that old ones are ok, that the right integration tests are carried out… that E2E tests are green, that the performance is still ok etc…

The QE should involve the rest of the team

First use pedagogy and educate, one step after another, take advantage of any moments you spot some errors or inconsistencies in their product to kindly remind him/her, that

“If we add some Unit test, we would have directly detected the error and would not have this error anymore, so let’s fix it together”

It’s one of the best ways to explain, by example.

It is not always easy to test code, to find the right perspective to do efficient tests, as a QE, as a quality coach, you can help create these tests, and step by step, involve the people you coach in test activities.

For instance, even with no or low coding skills, you could become a “rubber duck” and ask the dev: “explain your method/ function/class as if I were a complete beginner”

It will force simplicity and effectiveness. If the developers have trouble explaining their code… there is probably something wrong! And therefore potential anomalies!

During these sessions (which I advise timeboxed so as not to drive people crazy, and become counterproductive 😊 ) ask all the questions in the world! (Related to the topic obviously)

Do not hesitate to ask why there are 2 identical variables or other kinds of trivialities which should not pass the review, but which, if eliminated during these early stages, will save time for everyone 😉

This kind of action gives the QE a better view on the more technical aspects of the feature. And, believe me, having a good knowledge of how the code works is very useful for finding bugs during exploratory test sessions 😛.

The QE should care about quality (not testing)

Obvious huh?

But, remember? In quality assistance, it is not supposed to be the QE who tests❗

We remain the ‘experts’ in quality subjects and it is therefore up to us to lead to autonomous people in these tests. There is a kind of vital minimum to check for the feature to be validated, it is up to us to define it, alone or with other QE(s) or squad members, this process can and should be participatory.

We monitor the good health of our platforms. In order to ensure a high level of quality for final users, we put in place different metrics that help us to quickly respond whenever we need it. We check platform performance, accessibility, error rate, bug ratio,… any metrics that can help us increase quality for our end users.

📋 Let’s summarize:

What should a Modern Quality Engineer do?

Our mission is therefore to find the right balance between our own convictions as QE, the expectations of users, the needs, our knowledge, the issues and the constraints of the company, budget, time…

Quality assistance, at the end of the day, is about listening, advising, exchanging with the other team members, it’s keeping things on track if necessary,… and, of course, a little bit of test activity 😊 This is how to make a team autonomous, how to educate it to think (more and more) about quality at the very beginning of any processes. It’s an endless transformation, a very cool and collaborative journey to continuous improvement.

• QE knows its product, its scope and the stakeholders QE raises questions!! All the time, to everyone (well, think a bit about your question before asking it 😁)
• QE is a coach for the team on good quality practices, it defends them, it promotes them, it adapts them to its context, it challenges them, facilitates communication and exchanges between stakeholders.
• QE is a quality expert, who keeps up to date, learns, improves all the time (and who likes it 🙂)
• QE is someone who also knows that, like any other team member, he makes mistakes, they do not know everything (often!) and learns things to become a better teammate as part of a process of continuous improvement.
• QE needs to be the bridge between each silo, each expert of the team, be the “generalist expert”, the “Scrum master in quality”.

This is what a modern quality specialist does, always working between the abstract (the relational, the coaching, the listening, the human…) and the concrete (the factual verification, a + b equal C not D, the code, the feature…).

We, the QEs, are not “more” or “less” important than the other team members, we are not here to point out mistakes, but to help, to improve things, people and ourselves. And that’s maybe the coolest thing in the Quality Assistance approach: learning for others, and with others, how to build a better product. And, on a more personal level, just learning how to keep yourself constantly improving 😊

The purpose of this article was to give a “real” example, not just a theoretical point of view.

I am deeply convinced that quality assistance is the natural evolution of quality assurance.

If these few examples can help you to understand how to implement quality assistance, mission accomplished! :)