Interview about Sacem’s testing activities
Here is a summary of the interview of Doriane Zohar, Quality Assurance and Acceptance Manager at Sacem. In this interview, realized in April 2022, she talks about the context in which her test team operates as well as the different tools used to carry out her missions. To access the complete interview, you can click the video at the end of this article.
Could you start by presenting the role of Sacem?
Sacem is the Society of Authors, Composers and Publishers of Music. One of the main objectives of Sacem is to collect royalties on the French territory in order to be able to redistribute their rights to music creators.
What is your job at Sacem?
Today, I am Quality Assurance and Acceptance Manager for a team of about 30 functional testers.
What was your career path to get there?
I have been working at Sacem for eleven years. Before that, I started my career as a developer, then I quickly moved on to training. I arrived at Sacem as data entry operator, then I evolved as tester, analyst, test manager and today, I am Quality Assurance Manager.
How is your team organized?
My team is composed of test leads by functional area and then we have test analysts who will actually test the applications. There is also a small team of automation engineers (which represents 10% of the test team workforce).
What is the main challenge for you in your current missions?
Sacem has a complex IS with about 200 applications. Our goal today is to have the highest possible coverage rate. We already test more than 100 of them. We therefore wish to fully engage in automation to increase test coverage. Last year, for example, we increased our scope by 235% in one year on automation, so we are in a good dynamic.
What type of applications do you test?
Most of our applications are web applications including GUIs which are accessible via browsers. Many of them are internal applications, but some of them are exposed like the portal, that is our website, which contains secured spaces. We also test mobile applications as well as a small number of thick clients.
What type of manual testing do you perform?
At Sacem, we have set up a global testing strategy which encompasses the 8 quality criteria that are described in the standard ISO 25010. My team will not cover all the tests, but our global strategy allows to cover all the criteria.
Since the unit tests are done by the developers, my team will cover:
• Functional tests, i.e. GUI tests, end-to-end tests that also include integration tests
• Compatibility tests (API tests or file exchange tests)
• Portability tests
• Validation tests with our end users.
With that in mind, when did you start looking at using Squash?
We have been fully committed to Squash since 2019. At that time, we were looking for a tool that would address both Agile and Waterfall methodologies. We heard about Squash through our professional relations. So we evaluated it and I think testing it is adopting it. We were then convinced and we now have about 40 Squash users.
What tool(s) did you previously use to manage your test repository?
We were using HP Quality Center. We chose Squash because in terms of “mindset”, it was really close to Quality Center and our teams quickly got used to it. We had to do a bit of change management. We installed the free version, we did presentations to the various testers of our teams, then the tool was made available to them with one project per person. They could do their different tests during a dedicated half-day, with the help of the “Squash Team” YouTube channel in which there are tips, tricks and operating procedures.
So you called on the services of Henix, which is the publisher of Squash?
Yes, some technicians came and accompanied us in the recovery of our automated scripts and our manual campaigns. We were accompanied by Henix on our questions. Then, the tooling change was done in “big bang” mode, we did the migration with Henix and, from one day to the next, we turned off QC and we disconnected QC and we moved to Squash.
And since last July, have you been able to take in hand the new Squash TM interface?
We do one upgrade per year so one version upgrade out of two. We began using this interface in January 2022. It took a little time to get used to it but, finally, teams tell me that it’s much clearer, easier to use and that it totally answers their expectations.
Are there any other key features of Squash TM that meet your needs?
Since we have Squash, we now write all our tests (even manual tests) in BDD. So, in addition to making it easier for us to automate our tests, everyone shares the same language and the developers also necessarily understand much better anomalies when they see a test written in BDD.
The other positive aspect about Squash TM is the graphs that are automatically generated. Let’s not forget that in our previous tool, we had to parametrize a graph each time to display it in our tracking. These are small things which allow us to save a little bit of time, so finally, we are much more efficient with this tool.
Do you use other tools of the Squash suite?
As we use Jira as a collection of US, yes, we use Xsquash every day. It’s a really useful plugin because it allows us to automatically synchronize the US of a Jira project in the Requirement workspace of Squash. At a time when we are advocating transparency within Sacem, the possibility to upload test cases and execution reports in Jira allows us to create an emulation between POs and developers. In any case, developers are asking us much less questions, because they know what have been tested, how it is tested and they can reproduce the error cases on their side.
Since 2020, we also use the plugin Jira Bugtracker to report bugs from Squash to Jira.
We are also Squash TF users to manage the automation of our tests. Today, our functional testers do test design and use Squash’s internal workflow to make automation requests to our automation testers. Behind that, our automatician team mainly uses Cucumber, but also Selenium or UFT. So they manage the automation request then the automated script can be launched via Squash TM directly. The advantage is that our functional testers are integrated in the product teams. The script execution requests are very often made by the PO or by the developers during a delivery and they are completely autonomous, with the tester integrated.
We are migrating to Squash AUTOM which should be installed within a week or two maybe.
Were you doing automation before using Squash TF?
Before Squash, we mainly used automation to generate data sets.
What’s most interesting about Squash is the interaction that can be done through the tool for automation requests. So we set up a process to identify and validate what should be automated before an automation engineer starts the automation process. After the automation, we do our demo to POs and to the Product team once we finished our tests and we get into production.
What are the features of Squash AUTOM that push you to install it?
On the automated side, it will allow us to have a follow-up in Squash TM of all the executions. Right now, for all our executions that are scheduled, we don’t have statistics that go back into Squash, because they are in our Jenkins. We would like to be able to put different tracking in the automated script execution report so that they can be evaluated at their true value. So we hope that Squash AUTOM can meet this need.
What types of automated tests do you primarily perform?
It’s mainly non-regression tests (automatically launched twice a week) which we use in an Agile context.
We also do automate API tests for our REST service tests.
The next step will be to be able to do automation as we go along to test our applications, but we’re not there yet.
Are you also interested in the DevOps logic?
We are currently in the midst of a transformation of our information system, inspired by the SAFe framework, and the first trains have left. We started this transformation in January and, of course, the testing part is also very important, so we are working on it and looking for our model inspired by SAFe. So we’re really in the early stages.
Let’s go back to Xsquash, was it important for your testing tool to interact with Jira?
Yes, it was a prerequisite when we chose the Squash solution. The ideal test tool had to interact with our existing tools, we didn’t want to have to do duplicate work by copying the requirements into the test repository manually, etc. It had to be interconnectable with our existing tools and Squash was also chosen for its interconnection with Jira as well as for its openness to other automation tools, such as Katalon for example.
The fact that the Squash project is scalable is very positive for us.
Is there a major development axis that you expect on the Squash side?
As we would like the POs to be able to write their tickets in Gherkin, it would be nice if we could get this directly into Squash without having to copy them.
The Squash User Club is hosted once a year during the Software Quality Club, have you ever participated in this event?
Already two or three times yes. It was beneficial because there are always exchanges with other users and I was able to benefit from various interesting feedbacks during the presentations.
Did you also benefit from Henix training on Squash for your test teams? Or any other type of service?
To date, the only service we have used is for the migration of our test assets when we switched from QC to Squash. In all transparency, I was not even aware that you were doing other things. So that’s noted for the future.
Any last comments?
I wanted to say a word about the Squash Support. We are very happy, because you are always super reactive. We always get an answer in the hour and the resolution is also very fast. So I wanted to thank them because, when we have our tool that goes down or a problem and when I have to manage sometimes 50 people who are waiting for the resolution, I am very serene to know that I will have some answers within half a day.
Discover the complete interview in the video below (English subtitles are available on YouTube):
