Interview about the activities of the Squash AUTOM-DEVOPS and GitLab ProFessional Services (PFS)
Here is a summary of the interview with Florian Gautier, Head of Squash AUTOM-DEVOPS PFS and GitLab PFS at Henix. In this interview, conducted in February 2023, he reveals the diversity of the missions that punctuate his daily life and the profiles with which he is brought to collaborate in the context of test automation projects and/or their integration in a DevOps pipeline.
What was your background before and after you joined Henix?
I start my academic career in Lyon, which led me to do a thesis in theoretical physics. Then I had a first experience as a postdoctoral researcher in Munich. It is only afterwards, around 2017, via the School of Software Quality (EQL) and then the AFCEPF, that I arrived at Henix as a developer.
I then did a qualimetry mission on CAST at a major French bank and then I did test automation and development missions around Squash TA (before this module was renamed Squash TF) at the Informatique Caisse des Dépôts.
From 2020, I arrived at Henix HQ to help develop Squash TF (which has since been replaced by Squash AUTOM — Squash DEVOPS). Following the departure of the previous Squash TF Professional Services Manager in 2019, I took over this scope. Today, I am in charge of Squash AUTOM-DEVOPS PFS and, for the past year, GitLab PFS.
Sometimes we have the impression that we are involved in the development of the tooling methodology.
What attracted you to your current mission around PFS?
I would say that it was above all the variety of the subjects, allowing me to avoid falling into a form of routine. The technical subjects I work on are always topical. We are talking about environmental testing, continuous integration, continuous deployment, the Cloud… In this area, there is a lot to mature and implement. Sometimes we even have the impression that we are participating in the development of the tooling methodology.
What is the difference between the Squash TM PFS and the Squash AUTOM — Squash DEVOPS PFS?
While Squash TM PFSs provide methodology and expertise in test management with Squash TM, our work focuses on methodology related to the implementation of automated tests with Squash AUTOM and the integration of these tests into the DevOps chain with Squash DEVOPS. Our scope is therefore a complementary component to Squash TM PFS in order to implement best practices in the context of the overall use of the Squash suite.
Are the GitLab PFS distinct from the AUTOM-DEVOPS Squash PFS?
The GitLab PFSs are indeed autonomous and independent to meet different targets for the moment.
Is the pool of GitLab experts smaller than the one around Squash AUTOM — Squash DEVOPS at Henix?
It is indeed smaller, because this part of our activity was created only one year ago. However, the missions related to GitLab issues are clearly increasing at Henix and we now have enough experts to be certified as GitLab Professional Services.
All our consultants working on test automation or DevOps missions are becoming more and more skilled on Squash, on the associated methodology and on tools such as Robot Framework or Cucumber.
How many people make up your team and how is it organized?
We have more than ten experts who can be mobilized, two or three of them being specifically assigned to the Squash AUTOM-Squash DEVOPS PFS. At Henix, it is important to know that all our consultants working on test automation or DevOps missions are becoming more and more skilled in Squash, the associated methodology and the tools that are integrated into it, such as Robot Framework or Cucumber. Thus, they can be able to take care of PFS type services in their own mission or to increase our pool of mobilizable people.
Can you summarize the services offered by your Pole?
Globally, we support the implementation and use of tools, but we also offer services related to installation, training and methodology.
What are the preliminary steps before you can start this support?
Part of our work as a PFS is similar to pre-sales. We talk a lot with prospects to help them define and refine their current or future needs. This is the real added value of PFSs who do not limit themselves to offering off-the-shelf services.
My goal is to “build” a service adapted to the client.
What is your favorite aspect of starting a first exchange with a prospect?
What interests me is when a prospect comes in with needs that are not necessarily established. Rather than saying, “OK, we’ll do exactly that,” we think with them to deconstruct their pain points to better identify them. My goal is then to “build” a service adapted to the client. It is important to keep in mind that there are two distinct phases: the pre-sales phase and the construction of the need and the phase consisting of determining how we will be able to meet this need. It is therefore interesting for me to remind that the missions of PFS are not limited to implementation or delivery.
How could you summarize the realization/delivery part precisely?
Once we have defined the need, we have to define the missions, often short and with high added value, which will allow us to respond to customer problems while capitalizing on the benefits of the tools we know well.
What is the distribution of your time on these different missions?
I would say that 25% of my time is dedicated to pre-sales, 60% to implementation and the rest to support for the team and delivery management.
From your experience, what were the main surprises related to your position?
I was marked by the heterogeneity of cultures around testing and DevOps between customers and sometimes even between teams within the same customer. In the end, what surprised me was that every need is different and that some customers are very mature in certain very specific aspects, while being potentially less invested in other related areas. So even with the same size or with people with roughly the same skill set, there are always asymmetries and that was surprising at first.
Another pleasant surprise is to be able to feel the beneficial effects of our work every time we can relieve a pain. The client teams naturally have a lot of questions, and we encourage them to ask more and more, as I said earlier. The missions we take on often reveal real problems with high stakes. Despite this, in a week or two, we often manage to find solutions. Recently, with a client I already knew well and for whom I had historically done coaching and support with the help of Support, we made progress on five subjects in just two days. For each topic, I could feel the client’s relief growing.
Do you also have any assignments in English?
Yes, I am currently in contact with a team in India. Even though 95% of our current contacts are French or French-speaking, we sometimes organize meetings in English with teams based in Portugal and India.
Does this mean that all PFS missions can be done remotely?
Everything can be done remotely, but our missions often require adjustments that it is preferable to make on site, typically setting up access to platforms via VPN or technical tools. In my experience, it is always easier to have at least part of the mission in person. The example of the client mentioned above was a success with two days of remote work, but this was only possible after the 20 days I spent in their offices, which created a form of trust linked to the fact that the people I was dealing with knew me.
Do you prefer face-to-face interactions or do you prefer remote?
I prefer face-to-face interactions because it gives a fundamentally human dimension to our job. In addition, since we are generally trying to solve problems in a limited time, it is always preferable to humanize things as much as possible, which is easier when you are in front of a person rather than a screen.
Before starting to automate, you should […] make a matrix to see where your weak points are and where to place your automation effort.
According to your experience, could you summarize in which cases it is interesting to automate tests? And what are the opportunities to be gained from it?
I would say that before embarking on automation, you need to ask yourself the right questions to determine whether or not it is relevant to automate your tests. These questions are the following: Are we looking for more coverage? Better traceability? More confidence in our testing process? Or simply more time to do other things?
It is also necessary to list the different types of tests currently performed by the test team, because there are unit tests, more functional tests, more technical tests, integration tests in the middle, etc…
Based on this list and the answers to the above questions, it becomes possible to create a matrix that shows where the weak points are and where to place the automation effort. There are then an infinite number of answers when it comes to determining the opportunities of test automation.
Is there ever a time when the automation effort is misjudged by the customer?
Yes, one of the best examples to prove this concerns the user tests that are the most reassuring at the end of the acceptance process, such as end-to-end tests. These tests consist of reproducing the entire user path. However, these tests tend to be complex to automate because they potentially affect the entire IS. In addition, the higher the level of the test, the less close we are to the application code. With this type of test, it can therefore be complicated to indicate to the developer where to make corrections in his code.
Automating these tests is therefore not necessarily a good thing. The solution is to automate a certain proportion of your tests while defining other covers to increase your confidence.
One of the temptations when you start automating tests is to focus directly on business tests, even though these are the most complex tests. It is better to focus first on lower level tests, tests around a single functionality or to go towards Behaviour Driven Development (BDD), even if it means reconsidering the option of automating end-to-end tests with the experience of setting up the first automations.
What are the advantages of BDD?
BDD allows you to set up a technical language that testers and developers can understand, but also to use this language for reporting purposes. Instead of having very technical reporting at the macro level, it allows you to determine and report on which test step a test is failing.
And what are the key aspects when choosing your automation technology?
There are:
· The team (to put the human back in the center). Teams have knowledge of tools or technologies (typically, a team of developers doing Angular has certainly already touched Cypress) so the choice is dictated by the team’s experience. On the other hand, if you’re talking to people who want things that are more integrated because they’re less technical, you can favor studios that allow object capture, like Katalon or Agilitest. This will encourage scripting by putting in place scheduling bricks for the various test steps.
· The systems to be tested. For example, if you want to test web services, you can use Postman or a JS test framework with a component capable of making REST calls.
You should run your automated tests as often as possible and the best way to do this is to integrate these tests into CI/CD chains.
How often is it recommended to run automated tests? When is it appropriate to run them?
As often as possible, because we know that tests that are not executed will not be maintained and will eventually no longer be executable. We then lose the return on investment of the automation of these tests. So the right answer is as often as possible and the best way to do this is to integrate these tests into CI/CD chains.
In the context of the test automation missions you have worked on, how is Squash AUTOM an asset?
The advantage of Squash AUTOM is that it is linked to our test repository and that it allows us to execute tests quickly. Since the implementation of automation is costly, it becomes interesting to capitalize on Squash AUTOM because it allows you to:
· Quickly configure the replay of automated tests, in multiple contexts;
· Delegate the execution of automated tests to non-technical;
· Include execution results in more generic campaign reports.
The next interest is related to the use of Squash DEVOPS which allows these tests to be included in DevOps chains, ensuring that these tests are executed continuously.
Our expertise lies in setting up software factories that bring together a set of services that promote the proper development of applications right up to production.
What is the added value of PFS in terms of DevOps?
Our expertise comes down to setting up software factories that bring together a set of services that promote the proper development of applications right up to production release, with all that this implies in terms of application lifecycle management. The objective of PFS in this context is therefore to address the right solutions to help our customers at each stage of the software lifecycle, whether it is the plan, the package, the build or the deploy phases.
Our added value then consists of monitoring the proper use of the software factory by the project teams. We therefore have an engineering team capable of monitoring the proper implementation and appropriation by the teams of the tools recommended during the mission.
What are the aspects of your job that you like the most?
I really like the fact that my missions get me used to doing monitoring, because I am brought to see a lot of technical environments and I am therefore able to use Cloud technologies, container orchestration tools (such as Kubernetes), serverless tools, container registries, CI and test tools, languages and associated build tools, integrations with GitLab… It’s something very rewarding. It allows me to have a panorama of techniques, tools and methodologies quite appreciable and it prevents me from being locked in a single technicality.
The second thing I like about my work is my colleagues. PFS allows us to interact with a lot of people in-house. We are in front of the product team when it comes to pre-sales, and we are also with the business engineers when it comes to building proposals. Finally, we are also in contact with the strategic management because we are the first to learn about customer problems, which allows us to propose directions for the roadmap. I like being involved in these subjects.
In conclusion, how would you define the essential qualities to carry out your mission successfully?
I would say that above all you have to be able to “pass the ball”: the world of automated testing and DevOps is very vast, and you can’t humanly master everything. So we have to be able to analyze the moments when we reach the limit of our knowledge and know how to identify the person capable of having an answer to pass on the question, while making sure that this person has the ability to come back to us as soon as possible.
Secondly, I will talk about the need to know how to give advice, and sometimes to do so in a somewhat peremptory manner. It is a question of conveying the methodological knowledge of the PFS on the Squash tool in the clearest, most comprehensible and concise way possible. Thus, the client can have the keys to make the methodology live and adapt it to his context.
The third asset is to be comfortable and curious when it comes to the technical aspects of an assignment. For example, one of the leading tools for automation at the moment is the Robot Framework. So it’s a tool that I’ve studied extensively, even between assignments. However, if a client has development teams that use Cypress, we must also be (and are) able to support them with Cypress.
To contact Florian and his team about Squash AUTOM/DEVOPS related topics:
To contact Florian and his team about GitLab related topics:
