In this blog series, we speak with testing professionals from various industries. At Testersuite , we like to hear the diverse views on testing and what makes a test professional tick.
In this edition of Let's Talk About Test, we speak with quality expert Rik Marselis. Principal Quality Consultant at Sogeti, former chairman of TestNet and winner of the ISTQB® International Software Testing Excellence Award 2022.
" ... it ultimately starts with the question of what problem do you want to solve..."
First the standard question: who is Rik Marselis?
Then we will start with a standard answer. My name is Rik and I live in Amstelveen together with my wife. My biggest hobby is photography and besides that I am the proud grandfather of three grandsons.
I work at Sogeti as a Principal Quality Consultant. My work consists of three things. First, I work on behalf of Sogeti as a quality coach and consultant with clients. I also develop training courses and provide training in the area of quality engineering & testing. I also create tailor-made training courses according to the needs of clients. Finally, I do research and development in the area of quality and testing. I do not think up new things, but bring existing things together to create something completely new. I talk about this in books, blogs and podcasts.
By now I have contributed to 25 books, six of which have my name on them. My smallest contribution to a book is taking a picture of the authors for the back cover. The book Quality for DevOps teams is my most recent and largest publication to date.
How did you get into the field of Quality Engineering?
That starts in 1980 when I was trained as a programmer. You have to make something that meets what is asked, and I learned that a program is not finished if it doesn't come with a test set. These days, that doesn't happen as much. I encounter developers who think they are infallible but that is rarely the case. Fortunately, there are also many developers who do understand that quality is important and testing is required.
Software is now much more complex than it used to be. So why do people think they are infallible?
These days we chop software development up into sub-goals. As a result, people are quick to think, 'my piece is finished and it wasn't that hard so it will be good'. That is where it goes wrong. When errors are found, people are quick to say 'that's not my piece'. In the past, you built a whole system in a small team and you could oversee the whole thing. Nowadays, people put too many things in a narrow framework and fail to see the complexity.
Does the business play a role in this as well?
The business also often makes unrealistic demands. When I go to the supermarket for a bag of chips, I can choose from a hundred varieties. Then I'm at a loss. And if I choose one bag of chips, there's a good chance it will be gone the next time. Marketers think that IT can do everything and so they offer the customer a hundred variants instead of three. This creates complexity and therefore errors.
I was once involved in an IT project where developers had to ensure that old insurance policies could be carried over into a new application. This project was going to cost a lot of money. I then asked the question: what problem are we actually solving? You can make all kinds of things but who is waiting for them? In the end it turned out that a handful of customers still had such an old policy. It turned out to be much cheaper to make these people a generous offer and convert the old policy to a new one.
What you also hear sometimes is that someone says 'my 15 year old nephew makes this in an afternoon'. Yes, only your nephew doesn't know anything about security, network systems, legislation, quality attributes, etc....
My point is, IT can indeed do a lot but ultimately it starts with the question what problem do you want to solve!
"Just asking questions like why then, who then and how then."
What excites you so much within the field of quality engineering?
This is mainly due to the fact that from quality you have to deal with all the IT aspects much more than others. Quality engineering is all about Product, Process and People. All three of these must be in order to get the right result.
From qualitiy engineering you are involved in everything. A joke I sometimes make is by asking what QA means in English. Everyone then shouts Quality Assurance. That is indeed correct but it also means Question Asker. That is the most important feature of quality engineering. Just asking questions like why, who and how.
When I ask a quasi-stupid question and someone has a good answer, I know that person knows what they are talking about. When I ask a question and someone goes off on a tangent, I know someone doesn't know what they are talking about. It's also a matter of experience allowing you to distinguish the right answers from the lame ones. As you get older, you realize that you don't have to know about everything to still make a good contribution to the whole.
What is the ISTQB anyway?
ISTQB stands for International Software Testing Qualifications Board. The Q does not stand for quality but for a qualification that you have obtained. So ISTQB certifies people in the field. You have to take an exam and for that you have to take training courses.
Recently you won the ISTQB International Software Testing Excellence Award 2022. What kind of award is this?
The first thing I always say is that it was awarded rather than won. I didn't have to do anything special for it like running. The award is given because you have contributed something to the field. It's not like you think I'm going to do something to win it.
Eight people were nominated by the various international 'boards' in 2022. Because of, for example, the books I write, my presentations at conferences, and the syllabi I contribute to, they felt I should be awarded the award this year. This was announced in May and it will be awarded in October. This will take place during the general assembly in Marrakesh.
What does this award mean to you?
Especially an acknowledgement to be proud of and an incentive to keep going like this. I don't feel like I'm doing anything special but if not many people are doing it, it's still special. Then it is nice to get recognition. An award like this stimulates me to continue. In addition, my international network is growing through this and that is also great.
"By the way, did you know that the foundation of TMAP was laid by the House of Representatives in 1986?"
Can you compare ISTQB to TMAP?
We once started TMAP by starting to capture practical knowledge about testing. This knowledge was then used for training and certification. With ISTQB it went the other way around, they first defined the exam requirements and then started creating training courses and literature to go with them. They are not competitors but complementary, where TMAP is more decisive because there are fewer people who decide on additions and changes. By the way, there is a shared history. When ISTQB was founded, TMAP had been around for about 10 years. One of the authors of the first TMAP book is Erik van Veenendaal. He has also been a big booster of ISTQB.
By the way, did you know that the foundation of TMAP was laid by the House of Representatives in 1986? There was a debacle with the IRS at the time(!) and the House of Representatives then decided that there should be a manual for testing. This evolved into TMAP.
Is the Netherlands so ahead in testing?
The Netherlands is definitely a forerunner in the field of testing. Especially in the 90's and 00's. Once I spoke at an event in Denmark where I had to say something about the future of testing. They advised me to tell what we did in the Netherlands. That was the future for the non-Dutch audience. You still see many Dutch speakers at international conferences. Considering our small country, that is quite special.
We sometimes encounter organizations that don't prioritize testing. How do you see this?
The first thing I always ask is how often does it go wrong in production. If nothing goes wrong then it is justified because then you apparently have brilliant developers. Often people don't think it's worth testing. Errors are then camouflaged, covered up or accepted. If there is no money for brilliant IT then a lot of things are done in a piecemeal fashion and people live with it. One makes the trade-offs what quality do you need and how much risk are you willing to run? We'll fix it if it goes wrong, is the reasoning.
What you also see is that people choose standard packages like Salesforce or SAP, for example. However, these are not standard packages but systems with which you can click the process together. That is also where it often goes wrong. People just still accept that because they don't think about it properly. The business doesn't make any noise about this and often accepts a workaround and there is no one to solve the real problem.
If these types of organizations think about quality a little more upfront and build quality into the teams, it will lead to better results from the IT systems and the organization. This keeps the testing effort (and especially all the work on fixing problems!!) within limits.
What do you think about the current way organizations handle software testing?
There is no simple answer to that. I observe two possibilities. One is that quality is important and one chooses the right approach. This comes down to the question of how much risk are you willing to run? That determines the right approach.
There are also organizations that see quality and risk as a cost. If you focus on cost then quality goes down. If you focus on quality, costs go down. The caveat here is that costs only go down significantly over time. You recoup it later. Many organizations start too late and cry "testing is so expensive. What they mean is that bug fixing is expensive and not testing.
Testing shows you what is going wrong and fixing that costs money. Testing itself is not that expensive. The cost goes before the benefit. Boehm's law runs parallel to this. People often want to save time at the beginning of a project by not reviewing. If problems come to light later, it is often too late. Repairing them will then cost a lot of money.
"Testersuite gives people structure."
How do you view a test management tool like Testersuite?
Many people have an interest in structure. Testersuite gives people structure. Many times people are unable to create the structure themselves. Therein lies a great advantage of Testersuite. In addition, Testersuite is low-threshold, which makes it helpful in getting it accepted and implemented.
What advice do you give the Testersuite Team?
Maintains not to make the tool too complex. More and more people want things added and you have to contain that. Testersuite excels because it is manageable. If you make it complex then you undermine one of the key success factors.
What advice do you give the test manager?
A good test manager starts by first thinking about how and what to report at the end. If you know what the stakeholders want to know, you can tailor your activities accordingly. Tip here is, never make a final report but a progress report where your last progress report is also your final report.
