Let's talk about continuous improvement...

December 1, 2020
Frank Paymans and Youri Thielen.
Frank Paymans and Youri Thielen.

Testersuite is constantly evolving. A new release becomes available every two weeks. This requires an intrinsic motivation within the development team to want to continuously improve; continuous improvement! In this special edition of Let's Talk About Test, Frank (product-owner) and Youri (lead-developer) give a look behind the scenes of the development team of Testersuite. Let's talk about continuous improvement!

The principle of continuous improvement seems quite difficult. How do you facilitate that within your team?

Frank: It's about the general starting point and the will to continuously improve yourself and the team. That starts with the culture within the team and propagating and monitoring it. For example, making mistakes is allowed. You are not punished for it, but you do have to learn from it. As the person with final responsibility, this starts with me. I have to stand for a climate of trust and respect towards each other.

This allows you to be critical with each other about what you do. As a team member, you have to be open to this. If people can't handle it, it becomes difficult to guard the culture. I'm quite critical and people accept that. Conversely, team members also become critical and that works well.

Furthermore, a good balance between the short and long term is important. Too much of one comes at the expense of the other and vice versa. If you only focus on short-term improvement, you forget to invest in order to remain viable. It is a matter of finding the balance in the field of tension between commerce, the product owner and the developers. Sometimes, indeed, something has to be done 'quickly'. However, development should not have the feeling that when commerce wants something quickly, it just delivers.

Frank: "It's about the Boy Scout mentality...".

Youri: It starts with the right people. Some people naturally look for improvement and others stick to how things have always been done. It's really a mindset, if you're not interested then it becomes difficult.

Within our development team, we have a book club in which we discuss books on methods and practices. From these books, we can make improvements that we can translate into the way our team works. Our current team has this mentality. That is also what is selected for. It has to come from both sides. The company facilitates you but you also have to want to. Continuous improvement is not a method that you implement. You choose it because you want to continuously improve yourself.

If you want to put it down as a system, PDCA (Plan, Do, Check, Act) is the idea behind it. We apply the scrum methodology and do retrospective work. How did it go and how can it be improved. We do this every fortnight. But this is only possible with people with the right mindset.

Youri: "It's continuous everything..."

Why is continuous improvement necessary? Can't it be done right the first time?

Frank: No, you can't. You act in a world and environment that is constantly changing. Things that are good now will no longer be good enough in a month's time. You have to be and remain critical of yourself. Grab that moment and step out of the operation. As Youri said, look at what is going well and what can be improved.

You do try to do it right the first time. Especially if you are in the tension field of 'it has to be done'. As long as you put it right afterwards and keep an eye on the balance. You are constantly working on that. It also feels like getting a step higher all the time. Being able to become even better. Take the Barcelona team of a few years ago, for example. You see them play and you think that this is as good as it gets. However, the next match it appears that they have started to play a step better. They keep looking for improvement because the competition is watching and learning fast. Standing still is going backwards. When it comes to software development, many people have no idea. They don't understand why it just becomes more and more work.

If you keep working on quality from a technical point of view, you can also build on improvements very quickly. This means that the foundation must be well thought out. To get it right and keep it right, you have to be critical of your choices in architecture and technology. We review this every time in our retrospective sessions.

Youri: As Frank points out, not everything can be done right at once. It is a continuous process. Thinking that everything will go well at once means stagnation and thus decline. With the danger of falling behind the competition, not being able to guarantee continuity and having dissatisfied users. The people within the Testersuite team must think along at different levels about how things can be improved. This applies not only to the development team but also to marketing and sales, for example.

Does the Testersuite-fan also have a role within the principle of continuous improvement?

Frank: It depends on how broadly you draw it. How we solve things technically the Testersuite-fan will not notice anything if it is good. But if we don't set it up technically it can certainly have negative consequences for Testersuite users. Think of an increased chance of regression problems when implementing changes. Or deterioration in application performance. Or worse, security problems.

If we don't do well the Testersuite-fan is going to notice it in a negative way. We are constantly monitoring that. We also get input from our users that we work with. We proactively ask for that through support, update Webinars and customer days.

"An idea can sometimes be quite good but only become interesting at a later stage."

So continuous review within the team is important?

Youri: Yes, definitely. When you're building, sometimes you lose the helicopter view. That's what the retrospecitves are for. As lead developer, I also think a lot about the big picture. We mustn't go off in all directions. That can sometimes be difficult if a developer has an idea that does not quite fit in with the vision and direction we want to go. Timing is also important here. An idea can sometimes be quite good, but only becomes interesting at a later stage.

We also do code reviews. The four-eyes principle or also called 'peer reviews'. Does the code meet the quality requirements we set and the architecture? You also want to avoid building up a lot of technical debt.

Frank: I agree with what Youri says. We do still have components that were built in the past and no longer quite meet the standards we use today. Of course, it takes time to convert these parts and the user will not benefit from this functionally. But still, we do it and we spend a lot of time working off this 'technical debt'. I call it the Boy Scout mentality, leaving wherever you've been neatly behind. Clear up the technical debt.

But also when building new functionalities, we want to build up as little technical debt as possible. Sometimes it seems attractive to go for the quick solution, but in the long run you shoot yourself in the foot because the quality is reduced.

Doesn't that take up a lot of time?

Youri: That is not so bad. We try to keep it short by checking a maximum of 15 minutes. You offer something for review that requires a maximum of 2 days of work. That means that you deliver your code in chunks.

Code review always takes time but you should also look at what it delivers. On balance, it delivers more. We also do unit tests, GAT tests and FAT tests to find bugs. But learning from each other is perhaps the most important reason why we do this. Everyone reviews each other. A junior can also review the code of a senior. You learn from that. All in all, it takes me two hours a week.

The development team at Testersuite doubled this year. What does that mean for your continuous improvement philosophy?

Frank: You are dealing with a different dynamic and that takes some getting used to. You shouldn't underestimate that. You are going to formalise and lay down more working arrangements. There are some creaks and groans. It takes time and energy to find the new balance. In the end, it worked out well. Mainly because we stick to our culture. So be open to criticism, have respect for each other and a deal is a deal.

Youri: With the retrospective, we did try to find some kind of working method and cadence with all of us. Every time a new person joins, the dynamic changes completely. The same applies when someone leaves. A change in your team means you have a completely new team. The team has recently expanded again, so that means you have to reinvent yourself as a team. The character of the person also plays a role. What are someone's character traits and what knowledge does he/she bring.

It has been said before that constant improvement is a matter of mindset, especially for a small company. There, there is more thought at all levels. In a large organization, you can sometimes hide yourself for a while. That's not possible at Testersuite , we deal a lot with Frank as a business owner.

People who are new here are sometimes shocked by the high level and the fact that you are constantly in the spotlight. We don't yet have procedures and guidelines for everything, so you have to work at it yourself. The need for structure arises as you grow. Continuous improvement fits in very well with that.

And now suddenly everyone is working from home. Is that bad for continuous improvement?

Frank: Shared sorrow is half sorrow, let's say. Partly, we were already used to working at home, so it was not entirely new. We did have to tighten some things up. It has become more important to make better use of the tools we use. That also supports you. You don't want to keep calling each other via Teams about small things. Although Teams does make a number of things more efficient. Sharing your screen in Teams is even an improvement.

The chemistry of personal contact is less, of course. Although the vrijmibo is better now that we close the week online. Everyone is there now! That was never possible at the office. I also advise everyone to go for a walk every now and then. It keeps your head fresh. It also fits in with our culture of trust.

Youri: It's also about your mindset. This is independent of your work location. There are no barriers anymore in that respect. At the office, you can just switch faster at the coffee machine and the social aspect is greater at the office. The Teams-calls are sometimes a bit more business-like, but in principle you can build software everywhere. There are plenty of remote-only companies. This does require the right people, mentality and work structure. There are software companies that have never worked otherwise.

"We are going to work according to the API-first principle".

What technical improvements can we expect to see in the Testersuite application in the near future?

Youri: Technically, there will be a huge expansion of the API, which we are really going to build on. We are going to work according to the API-first principle. The current API only came after TS was built. Now we are going to turn it around and build everything on the API. That is a huge improvement. This means that linking to numerous other tools will soon be the rule rather than the exception. This is something for the long term, though.

The ability to work in Testersuite with multiple Testersuite environments is also coming up for next year. This has had a major technical impact because you will be offering multiple databases per client.

What "milestones" has the development team at Testersuite achieved to date with continuous improvement?

Frank: The Implementation of the information security management system (ISMS) according to ISO 27001/NEN7510 and the final certifications are a milestone. Of course we achieved this with the entire Testersuite team. In addition, we now have a well-attuned development team that keeps each other sharp and can replace each other well by spreading knowledge. We also record who has which knowledge areas. As a result, you can pass on issues to a colleague who has less knowledge of a subfield and help him or her out. In this way you spread knowledge and ensure continuity.

I love the imported book review. Some weren't used to it and others were. That increases knowledge, because you have to know what you're talking about in the next book review. That's how you keep each other focused. The fact that the development team has a very good cadence with the fortnightly update cycle, the standard automated unit tests, the code reviews and retrospective meetings are also great improvements.

Youri: I concur with that. And that we are able to deliver new functionality every two weeks in a stable way for our Testersuite-fans.

What are currently the biggest challenge of the development team at Testersuite?

Frank: For me, it is the mutual contact. The face-to-face contact that allows you to get to know each other in a different way. We are doing well and we are in good shape. Of course, there are challenges. The spirit is up, but how do you keep it up? But that applies to everyone at the moment in these strange times.

Youri: The team is in the process of being put together. We are also looking at scalability and performance. More and more customers are joining us, which means we are working hard on that. We are also working hard to expand our automated technical tests.

"It is a beautiful journey!"

Is there anything else you want to say?

Frank: I think it's cool that together we continuously take up the challenge to improve ourselves. I see that reflected throughout the company. It is a beautiful journey!

Youri: It is continuous everything. That's how I see it. Whether it's continuous integration, delivery or deployment. It's a total package and you have to live up to that.

Let's talk?

Do you have interesting experiences in the testing profession that you would like to share? Let's talk!

More news?

Sign up here for the latest Testersuite news.


Do you also want to test better and smarter?

Discover our easy-to-use cloud products

Testersuite uses cookies. Please indicate which cookies you accept. View our Privacy Statement for more information.