Metaphorical talk about testing. Interview with Rik Marselis

Rik Marselis is one of Sogeti’s most senior Management Consultants in the field of Testing and Quality Assurance. He uses his 34 years of experience in IT to bring fit for purpose solutions to organizations, having assisted many businesses around the world to improve their IT processes and establish a successful test approach.

Rik has trained and coached many testing professionals ranging from novices with an ISTQB Foundation training, to experienced testers with TMap NEXT, TPI NEXT and ISTQB Advanced training courses. Also he developed a number of training courses, for example on Agile testing, and he regularly contributes to the testing profession through research and development.
Rik is a fellow in Sogeti’s research network, SogetiLabs, and has contributed to a variety of articles and books on quality and testing. His most recent books are “The PointZERO Vision”, “Quality Supervision” and “TMap HD”.
Since Testing and Quality are his hobby, Rik also contributes to the testing world at large, currently he is the chairman of TestNet, the independent association of software testers in the Netherlands with over 1700 members. Rik is an experienced presenter at conferences throughout Europe. His presentations are always appreciated for their liveliness, his ability to keep the talks serious but light, and his use of practical examples with humorous comparisons.

a1qa:Do you think testing is more about tools, techniques or maybe people?

Rik Marselis: In my opinion if testing goes wrong it’s because of failing people and when it goes well it’s because of skilled people. So the difference is made by people. But of course skilled people will apply techniques and tools at the right moment, depending on the situation, the time available and (very important) the level of quality-risk that the system under test brings.

Nowadays, with the Agile application lifecycle model gaining more and more followers, tooling is rapidly becoming more and more important. If you need to deliver working software of which the quality level has been proven to be fit for purpose, it is almost impossible to do the necessary testing without tools.

But testers should keep in mind the old saying “a fool with a tool is still a fool”. Some testers seem to think that as soon as they have learned to use testing tools they can forget their manual testing skills. But hey, let’s take a metaphor: A carpenter uses a hammer to bang nails into the wood. Then he start using screws and still uses his hammer, that doesn’t work well. He starts using a screwdriver, but get’s tired quickly. He learns about a modern tool, the battery-powered screwdriver, and he is very happy and swears never to work without his new tool any more. And then he needs to put a nail into the wood… (have you ever tried to bang a nail into wood using a battery-powered screwdriver? it does work somewhat, but you’ll ruin your tool ;-))

a1qa:You have greatly contributed to TMap method. What is so special about it that differs from others?

Rik Marselis: TMap is a testing method that was first published in 1995 (almost 20 years ago) but actually goes back to 1987 when a first handbook of testing was created.
TMap is often compared with ISTQB, and some people have even thought that ISTQB and TMap were competing, but now people agree that ISTQB and TMap complement each other. ISTQB is a good framework for testing, it tells you what products you need to create (for example a test report, test plan and test cases) and what standards you might use (my favorite is IEEE829, especially for test plan topics).

But ISTQB doesn’t say a lot about HOW to do your testing.
And that’s where TMap comes in. The TMap method gives you a set of possible actions you can take to create the necessary testing products. All focussed on giving the relevant stakeholders insight into the quality of the information system and into the product risks that remain at the moment a decision to go live has to be taken.

Last month (October 2014) we have introduced the latest update of TMap, called TMap HD. HD stands for Human Driven, to underline the importance of people in testing. Actually TMap HD has 5 elements: People, Simplify, Integrate and Industrialize are four elements that together, when filled in properly will lead to the fifth element “confidence”, that is confidence in the quality of the system and confidence that te remaining risks are acceptable.

TMap HD is part of the TMap Suite. An important role in the TMap Suite is played by the website, www.TMap.net which contains the background knowledge a tester needs. Using building blocks the tester adapts his approach to the situation at hand. By implementing this adaptiveness the tester can use TMap to his advantage in any situation, ranging from traditional waterfall projects to state-of-the-art DevOps teams.

a1qa:Do you think in modern QA there’s a need for reviews?

Rik Marselis: When using the word “testing” all too often people only think of “banging the keys on the keyboard”, the dynamic testing.

If however we talk about structured testing, as a proper way to measure quality and report about risks, then we need to create a test strategy that has both static testing and dynamic testing. And it is a common wisdom (at least amongst skilled testers) that reviewing is a much more cost-effective quality-measure than dynamic testing.

In a recent project we investigated for every defect that was reported, the so-called “escape phase”, that is the phase in the application lifecycle where this defect could have been found (which was often much earlier than where it actually was found). In many cases a defect could easily have been found by static testing, even by doing easy informal reviews, but certainly by performing more thorough technical reviews or inspections. And this way we could calculate how much money could be saved by doing static testing, thus convincing the stakeholders to spend a little more time in the early stages of a project, and thus prevent a lot of lost time at the end of their project.

a1qa:Quality and testing is your profession and a hobby. Is test training a hobby too or the contribution to testers` education?

Rik Marselis: QA Testing is a real profession. To be able to do good testing someone needs knowledge and skills. I always find a lot of pleasure in helping people in extending their knowledge and skills. What I, in my role as trainer and coach, always try to do is make people aware what is needed to become a better tester. Which is a much nicer goal then to just study to be able to pass an exam and get a certificate. Some people in the world of testing don’t like certification. And I can agree to some extent with them that a certificate in itself doesn’t prove that someone is a good tester. But I have experienced in over 10 years of being a trainer for testing courses, that people that know they have to do an exam pay much more attention during a training course and this way are able to extend their testing skills much more than people that only join a training course on a “sit-back-and-listen” basis.

By using real-life examples and humorous comparisons I try to make my training courses entertaining so that the trainees will really feel involved and thus, hopefully, get just as excited about the testing profession as I am.

a1qa:And in the end, you are in testing for so many years. Is there any test approach or a technique that is “close to your heart”?

Rik Marselis: Exploratory testing is my favorite. However, often I come across testers that say they do exploratory testing but actually they don’t do anything more than ad hoc testing. To me the difference between ad hoc testing and exploratory testing is that in exploratory testing the tester puts a lot of thinking and preparation in what he does. The only difference with purely scripted testing is that preparation and execution are combined in a test session. Good exploratory testing has a charter (which is an assignment, maybe even a very tiny test plan) and is preferably done by two people (one subject matter expert and one testing professional). Also in exploratory testing the tester must be able to use coverage types, because when for example you come across a boundary, a skilled tester will do boundary value analysis on the fly.

By combining exploratory testing with coverage types the tester actually will be able to make a well-founded statement about the level of quality, the benefits that are achieved and the remaining risks in the system under test.
Because that’s what testing is all about: measuring quality and reporting about risks and benefits.

Thanks for this interview. I trust that when testers across the globe work together we can assist each other to enrich our profession and make the work more effective, efficient and, above all, more fun!

Rik thank you for the great interview and for sharing your experience. We hope to talk to you again and cover other interesting topics.