The parenthesis in our last event “How to succeed in your test automation project? (transversally) was not an error,
I personally thanks each of the participant for their presence and contribution :
- Iman Benlekehal, specialist in Software Quality Assurance
- Benjamin Butel, passionate about testing, Software Engineer in Test at Klaxoon, organizer of Ministry of Testing Rennes
- Xavier Pigeon. Expert Method and Strategy Quality & IT, author of gearsoftesting.org and founder of TestAsYouThink
- Anass El Bekali, CEO QSI Conseil, President of the CMTL
- Clément Vannouque, QA Lead at Decathlon
- Benoit Civel, Manager of Digital Solutions Center at Auchan
- Soraya Azzaoui, Test Leader at Pictime Groupe
- Siham Amzile, Consultant Software QA at Henix
In this event, we discussed the following points:
- What major steps in an automation process?
- What actions must be taken to secure the initiative as soon as possible?
- What questions to ask, what practices, at what stages?
Contextualization of the event
Test automation projects have a high failure rate, presenting real difficulties and particularities to be understood.
Unfortunately, it is often delegated to QA, to a trainee, or comes down to a tooling aspect.
As a warm-up, we filled in the following circle presenting traditional steps of an automation project.
The objective was to put our ideas in the different categories, the most central according to their importance.
From this base, Clément started a current sharing of experience which initiated the common thread of our conversation.
Through the discussions, several key points emerged and are explained in the following sections.
Evaluate the relevance of the real challenges of the project, at the highest level
A major difficulty encountered was found around an overall lack of quality support.
This point made us quickly converge on the level of visibility, understanding, and support of the organization for the automation process.
Product teams are the primary stakeholders in this work of conviction, but top management is often not addressed.
You might think that automation projects are not worth asking people in management, “they have better things to do”.
This is indeed a possible answer if the subject is technically shared, automation must remain a means of clearly expressed objectives.
Two important cross-cutting questions: “Why” and “For what”.
Iman Benlekehal
These two questions, “Why” and “For what (to do)”, enable us to step back and must be clearly stated in how automation will help to fulfill one or more business objectives.
This is where a business sponsor has to be sought out and convinced.
We have identified recurring examples of objectives from which it is possible to draw inspiration:
- Accelerate the delivery of functionalities for the customer while controlling the user experience.
- Improve the stability of the core functionalities of the product despite the new versions
- Improve the team morale and performance by freeing up precious time spent on repetitive tasks
These points remain examples that must be obtained by stakeholders in each context. Active listening will be key to identify the real objectives.
This exercise will clarify how the deliverables of the automation project are aligned with the defined business objectives.
But what if we do not manage to convince, despite a prepared argument?
Confronting the various players with the “cold” truth
We discussed this problem often encountered in teams where only the short-term delivery date counts, to the detriment of other objectives such as quality.
Various elements must be taken into account here: we are creatures of habits, a culture takes time to evolve, results-oriented people will not change.
An electrical shock is therefore often necessary in this type of context: does the team realize the non-quality and in what vicious circle they are embarked on?
Was the team confronted with the quality of the deliverables? This electroshock is necessary.
Benjamin Butel
This is in fact rarely the case with the necessary level of support.
From our sharing, we have identified that this cold shower is necessary.
We have identified that the most useful arguments come from the different team members and from the impact to the end customer of the product.
For example, is the team aware of the level of accumulated technical debt and the additional delay with each development? What indicators are available to show the condition and its evolution?
Do we measure the impact for the customer of non-quality? We will cite the number of malfunctions encountered, delivery delays, issues and rework during delivery.
The human aspect is also to be taken into account, the members of the team are probably stressed, with a number of accumulated hours, with regular frustrations.
This cold shower is necessary for us to stimulate a new dynamic, the contours of which should be defined.
Propose an approach rather than a project
We have identified that an automation project may not be a strict project.
How’s that?
A project is an often temporary organization that aims to fulfill defined objectives within a given framework of deadlines, costs, quality.
The reality of a software product in development is quite different:
- As the product evolves, the automation of tests, therefore, requires adequate maintenance, the AI not yet being there to automate this work for us.
- The product is co-built, the quality and automation are, therefore, more intended to be co-built than carried out in silos a posteriori.
- The test automation processes must be integrated with those of product creation, hence the need for adaptation over time.
An approach can be defined around two of these definitions:
- “A way of walking”.
- “A reasoning, a way of thinking.”
If we dedicate a full sprint to refactoring, we are no longer really agile. We lose the iterative and incremental contribution of quality within the delivery cycle.
Xavier Pigeon
Specifically for an automation project, we will rather want to put in place practices, a way of thinking, and collaborating that enable us to learn over time.
However, we must have specific steps defined with specific objectives, so that our approach leads us to the expected results.
We can more easily draw a parallel with the agility approaches that support the implementation via an incremental approach and driven by value.
We come to the next point: make the quality and automation process a subject for the team.
Include the whole team in the quality approach and ownership
Do the product owner and developers consider quality as a criterion in their daily tasks?
If so, the path to including quality upstream, throughout the build cycle and delivery is well underway.
Quality is a team concern, not only for the QA team.
Iman Benlekehal
For example, we discussed the Definition Of Done, which can be a concrete reflection of this taking into account by adding quality criteria.
The practice of joint testing and qualifying sessions was also shared as helpful in improving the product, collaboration, and mutual understanding.
The pillar of a transverse sponsor was also raised as a differentiating factor in the implementation of a quality approach, due to its weight and transversality in the organization.
Getting the Right Sponsor and Level of Expertise at the Right Time
A sponsor can make a real difference to the project.
However, it remains to succeed in convincing him of the contributions of the project. Talking about business contribution and value for the organization is necessary.
A convinced sponsor is what can also give access to additional resources to secure his project
The sponsor is a structuring element of an automation project.
Anass El Bekali
Sometimes you have to know how to get help and accept a different perspective.
Expertise can make sense in the initiation of an automation project in order to secure the organization.
Costly decisions are often taken upstream, not in a specific operational choice made later.
This contribution can take different forms, an initial audit, one-off degressive expertise alongside the project, a consultation on a specific point.
The main thing is to have the necessary humility and to use it wisely in the context in question, and to know how to defend the budgetary investment.
A test automation project requires a transversal approach
We recognize a need for verticality with top management up to the teams and for transversality in order to succeed in your automation project.
An approach remains more important beyond a project that can be idealized with a beginning and end a little too closed.
An iterative and incremental approach remains key to validate the gradual value addition and adapt the processes, tools, and organizations to reality.
Some things are not easy to obtain but will make the difference, such as a sponsor or expertise.
A cold shower to confront reality also often seems to us the step-through which to pass to stimulate the sufficient electroshock.
Other events are to come, I hope that our sharing will have been useful to you, find the content available in various audio and video formats.
Join the QE Unit to access early content, stay up to date with news, and receive exclusive content.
Content mentioned
Scrum Life & Jean-Pierre Lambert