This interview with Rikard Edgren is part of our series of “Testing Smarter with…” interviews. Our goal with these interviews is to highlight insights and experiences as told by many of the software testing field’s leading thinkers.

Rikard Edgren has been a humanistic and technical tester since 1998. He currently works with testing healthcare software at Nordic Medtest in Karlstad, Sweden. Rikard enjoys the dynamics between people/machines, objective/subjective and whole/details.

Personal Background

Hexawise: What drew you into a career in software testing?

Rikard: Like most people it happened by accident; I wanted to become a programmer, but had a chance to start at a company with testing as a stepping stone.

I realized I liked testing and was good at it, and wasn't upset that I never got the chance to be "promoted" to developer, and just went with it by doing a lot of testing.

I did a couple of years as project manager (good insights for a tester), but went back to what I enjoyed most.

I think I love testing because of the dynamics between the technical and the humanistic; the details and the whole; the objective and subjective.

And of course the thrill of being first to see a nasty problem!

Hexawise: You share authorship of the thoughts from the test eye blog with a few of your former colleagues. This joint author setup is fairly rare; what advantages do you see from this arrangement?

Rikard: Henrik Emilsson and Martin Jansson tricked me into this in 2008. In the beginning it was great to have two readers!

We also commented on each others posts, which made us learn more. We also did some joint efforts, e.g. a list of generic Software Quality Characteristics.

It is a benefit that the blog keeps going also when one or two are very occupied with other things. It also gives a healthy pressure to provide to our common project. The activity is lower nowadays, but still alive.

It has kept the three of us more in touch even though we have worked at different places and locations.

So I see only positive aspects from the joint setup, and encourage writing as a learning process, with sharing as a good side-effect. Ideas you discuss, try, discuss, are typically better than ideas you work out by yourself.

Views on Software Testing

Hexawise: In your book, The Little Black Book On Test Design, you write: "You want to create tests that are testworthy, and typical examples can be those tests where you don’t know if it is important or not, but you want to make sure." How often do you see software developers providing guidance on testing focus due to concerns about the code? My background is in software development and often we know when certain aspects of the code have higher potential for bugs - often due to complexity or novelty. But in my experience this insight (that could focus software testing) is not provided as often as would be useful.

Rikard: In my experience I haven't received important information like this on direct questions. However, when I have worked together with the developers for some time, and (hopefully) have earned respect by digging up interesting information, this sort of guidance come more and more often. I hope it is because they realize that my testing can act on vague and disparate information, and that they value the findings and want more of it. It doesn't seem to be enough to say that you can test the software well, you have to actually do it first in order to gain a healthy respect that everyone benefit from.

Once the trust is there, communication is more open and better, and it is easier also for me to admit areas where the testing wasn't the best.

Respect isn't given, it must be earned, and you do that by finding information others need, that they wouldn't have found by themselves.

Hexawise: Do you have any specific suggestions on how testers can gain respect from developers and encourage them to see a tester as someone to assist them in creating great software. Too often it seems software developers can view software testers as a bother rather than a help?

Rikard: Make sure you provide valuable information. Find bugs the developers want to fix. Give feedback on things that work well. Find bugs that other stakeholders want to fix. Listen to developers input on what needs testing. Collaborate. Be nice and do good work.

Hexawise: In your book you also mention the value of combinatorial testing to discover problems that don't appear in isolation but only with interaction between components of the software and different use cases. Do you have a favorite example of a combinatorial bug? How did that bug illuminate a challenge in software testing?

Rikard: I will never forget a dialog box that crashed when you clicked Cancel, but only if the dialog first had been moved. I don't think I would have come up with the idea of testing just this, it was something I stumbled on because I like to do things differently. It is still a mystery how someone managed to create this bug, and I don't know if it was important to fix it. This illuminates the challenge in software testing on which parameters to explicitly deal with, and which parameters to implicitly deal with by serendipity-enabling variations in our testing.

Hexawise: What is one thing you believe about software testing that many smart testers disagree with?

Rikard: I think many would disagree that it often is a good idea to run tests without no particular reason; that a random test can be better that one carefully picked; that using my subjectivity will help me test the product better.

These work (according to me) because testing is a sampling business, and we should have serendipity working for us.

Also, people have phenomenal capacity when motivated, so I would rather have you perform five tests you believe in, than one that I think is better.

Industry Observations / Industry Trends

Hexawise: Do you believe testing is becoming (or will become) more integrated with the software development process? And how do you see extending the view of the scope of testing to include all the way from understanding customer needs to reviewing actual customer experience to drive the testing efforts at an organization?

Rikard: I think testing have been integrated with the software development process for a long time, and I think good testing often needs to understand customer needs and actual experience. In my 19 years with testing this is how I have worked, unless there are circumstances that make it impossible.

But I have heard similar comments before, and I rather believe that there was some years where there were loud thoughts that testing must be totally objective, both in regards with who we work with, and with the sole objective to verify the documented requirements. Nowadays more people say that they look for more things than what was defined in advance, and that they collaborate with developers as much as possible. Testers have been doing this all the time, and it is a good thing that the idea of "test documentation over insights" is retiring.

Hexawise: What do you wish more developers, business analysts, and project managers understood about software testing?

Rikard: That it is difficult, but done well software testing provides a lot of value to any software where quality is important (but not every project needs testing!)

That they can influence us: tell us about what is important, and we will find out useful stuff about this (good and bad things.)

That automation is great, and exploratory testing too.

Staying Current / Learning

Hexawise: How do you stay current on improvements in software testing practices; or how would you suggest testers stay current?

Rikard: I think each testing situation is unique, so I try to stay current by doing the most effective testing in my current situation. This might include old stuff, recent stuff, brand new stuff, or at least a combination of "stuff" that makes sense for me and the project at the moment. I try to do small experiments with new tools, and disregard most of them, but maybe learned something in the process. By going deeper into the current context, I learn a lot in that area, but maybe not about what is the latest in general.

Many new ideas come right out of the blue when I do something else, so I think my subconscious is helpful to me.

My suggestion to testers would be to use whatever methods they think are fun (and valuable if it is work time), because that will keep up the motivation, and enhance the learning process.

Hexawise: Have you incorporated a new testing idea into your testing practices in the last year? Will you continue using it? Why? / Why not?

Rikard: I don't think I have incorporated any brand new testing idea the last year. But of course there are new combinations of old ideas for my specific purposes.

Recently our team created a "TimeBlaster" in SoapUI; the results from a request is analyzed for time elements, and then many requests are sent with different start-end times (some of them randomized) whereupon the new responses are analyzed for conformance to the specification. Since these rules for time is somewhat complicated, this automation makes us (and other users of the same services) test better and faster, so we will continue using it.

My ongoing, low-frequency, private research currently deals with mental models; how I and other testers think, how we come up with new ideas, how we act on certain perspectives, but not on other. How we handle the complexity of software and human interaction and figure out what we should be testing with limited time available.

But I don't have any answers yet, at least in my head it is a multitude of (invisible) mental models that interact in mysterious, and productive, ways.

Hexawise: What software testing-related books would you recommend should be on a tester’s bookshelf?

Rikard: The best testing book for me is Lessons Learned in Software Testing, by Kaner, Bach, Pettichord. Another favorite is Exploring Requirements by Weinberg/Gause, which (secretly) is about "test analysis" - finding out what is important.

The most brilliant free article is Heuristic Test Strategy Model by James Bach, because it is generic for any software project, and the reader has to do all the hard work by themselves when using the structure it gives for attacking a test project.

My favorite blogger/youtuber is Alan Richardson.

There is lots of good stuff available on the net, and a lot of bad stuff as well, so a healthy dose of skepticism is needed.

And to practice "a healthy dose of skepticism" is something we need to do as testers!

Profile

Rikard Edgren has been a humanistic and technical tester since 1998. He currently works with testing healthcare software at Nordic Medtest in Karlstad, Sweden. Rikard enjoys the dynamics between people/machines, objective/subjective and whole/details.

Rikard has been as a consultant with many education companies and higher vocational studies programs. Teaching is a learning experience, with the number one testing question: What is important?

He is a regular at international conferences, with many appearances at EuroSTAR. He is co-organizer of Swedish Workshop on Exploratory Testing (SWET).

Links:

Blog: thoughts from the test eye

Book: The Little Black Book On Test Design

Presentation: ExploratoryTestDesign

Previous Testing Smarter with... interviews: Testing Smarter with Mike Bland - Testing Smarter with Alan Page - Testing Smarter with Dorothy Graham

Subscribe to the RSS feed for our blog.