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

Matt Heusser is a software craftsman with a deep background in software delivery and testing.

In 2014, Matt received the Most Influential Agile-Test Professional Award at Agile Testing Days in Potsdam, Germany.

Personal Background

Hexawise: If you could write a letter and send it back in time to yourself when you were first getting into software testing, what advice would you include in it?

Matt: My advice would be to trust your instincts and experiences more than what you read in books or online. Often the advice I read in books and online seemed vapid (shallow), or simplistic, or I felt it "just wouldn't work here." Eventually I realized that a lot of it (this was the testing advice of the 1990's) wasn't working well most places.

Today we have better advice. The time from research to publish is short, and there is a lot less "loss" in the system. Still, what works for Google and Microsoft might not work for your 20 person company, and what works for that cool, 100% physically distributed, 40 person software company might not work for your 2,000 employee insurance company. Take it with a grain of salt, trust your instincts - but always keep exploring and experimenting.

Hexawise: Which person or people have had the greatest influence on your understanding and practice of software testing?

Matt: It's hard to come up with a list of influences, but Cem Kaner, James Bach, Ken Pier, Brian Marick, Johanna Rothman, Lee Copeland, Jerry Weinberg, Kent Beck, and Ron Jeffries all come to mind.

Hexawise: What one or two software testing-related experiences have you found to be most personally satisfying in your career?

Matt: I remember once we wanted to get a insurance data extract out on a friday, but it had to be right. Serious students of testing will tell me you can never know that it is right - but non-serious student customers don't know that. I had about a half a day. The change was to one field, and we had the results in a database table. The table-to-file and the file transfer we had confidence in; the change, not so much. So I wrote my own computer program to loop through every current member in the insurance plan, over four hundred thousand, calculate the expected result, and compare them.

We found a small bug in the requirements; an edge case that was ambiguous. The programmer and I had interpreted the requirements in different ways that were both arguably correct. The "differ" program I wrote found the case, the customer explained that either was acceptance - and we shipped!

Views on Software Testing

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

Matt: A decade ago, when I went to the Google Test Automation Conference, one of the speakers said that automation was better because it was "repeatable." I almost stood up and asked aloud "so what?"

Every build of the software different. If the software is different, if the risk picture has changed, if we have some idea of what tests we ran before and how valid they might be on this build - why would we ever test the exact same way?

Software isn't an assembly line. Every build is different. The way we test it can be different, but I certainly don't see a ton of value in spending extra money to make sure we test things the exact same every time.

Turns out you don't need to remove the friction from handoffs. Often, you're better served to make communication cheaper and getting good at collaboration.

Hexawise: Can you describe a view or opinion about software testing that you have changed your mind about in the last few years? What caused you to change your mind?

Matt: It's going back a bit, but in graduate school, I wrote a paper "On the optimization of physically distributed requirements, development, test, operations, and management development groups" The body of the paper was considerably shorter than the title - the body was "You're Screwed."

At the time, the literature suggested that communication costs were high, so we needed get everything right prior to "the handoff." We needed to get every document, every bit of code, everything complete, consistent, correct, unambiguous, before "the handoff."

I knew that trick never worked, and thought the fix was co-location.

Then I learned about agile/XP, which was still focused on co-location - still, part of XP was making communication, collaboration, and change cheaper. Then I worked at Socialtext, where my co-workers were all over the world - Ingy took a skiing vacation in France, skiing during the day and working core hours at night. And it was far more productive than any other job I had ever had.

Turns out you don't need to remove the friction from handoffs. Often, you're better served to make communication cheaper and getting good at collaboration.

Hexawise: You have written about the benefits of lean thinking in software testing. What advantages do organizations gain when they adopt a lean thinking view of software testing?

Matt: You know that thing that happens, where you can't do your job because you filed a ticket and it will take the DBA's a week to add a column to a table, so you can't do your job, for a week?

Or whatever else it is? Right now I've got a contractor billing on my team with no laptop. He'll have it nine days after he started ... if we're lucky.

Typically, when a company goes to lean thinking, that kind of stuff stops happening.

Industry Observations / Industry Trends

Hexawise: Do you have specific suggestions for testers working within an organization using agile or lean software development methods?

Matt: It's hard to come up with examples without context, but generally, I'd start by looking at the delays we have in our job and the amount of multitasking. Be sure to include failure demand - things that should be reasonably expected to work the first time, but took a round of fixes. Often you'll find what should take an hour is taking you a week.

Hexawise: What do you see as the most powerful trends in the software testing field over the last 5 to 10 years? What trends do you believe will be the most powerful over the next 5 to 10 years?

Matt: The past ten years? Test-Driven Development, Continuous Integration, REST APIs that can be tested at the integration level, Virtualization, Lightweight Virtualization.

The next five? The promise of continuous delivery might just be realized. I realize that sounds like a lot of technical stuff, and I'm a process and people guy. The challenges of the next few years will be all skill, people and process.

Hexawise: There is still a widespread belief in fairly mechanistic software testing (checking) by some of those using software testing. Lean thinking, exploratory testing, etc. encourage engaging the minds of software testers. Are you optimistic about the prospects for tapping more of the potential software testers have going forward?

Matt: Oh yes. That's what I hope the next five or ten years are all about.

You know that thing that happens, where you can't do your job because you filed a ticket and it will take the DBA's a week to add a column to a table, so you can't do your job, for a week? ... Typically, when a company goes to lean thinking, that kind of stuff stops happening.

Hexawise: Have you seen a particularly effective process where the software testing team was integrated into the feedback from a deployed software application (getting feedback from users on problems, exploring issues the software noted as possible bugs...)? What was so effective about that instance?

Matt: My preference is for cross-functional delivery teams, so I get a little down on the term "test team", but yes, I have seen delivery teams where customer feedback was part of the process. One team that Justin Rhorman and I worked with managed a fortune 500 retail website; they had a process that periodically popped-up requests for feedback. The testers worked through these in a rotation, summarizing them, reporting them to management and working with management.

I think that worked well because of the rotation - no single bottleneck. If multiple testers observed the same feedback independently week over week, it was harder to dismiss.

Staying Current / Learning

Hexawise: You have spoken at many conferences. What advice do you have for people attending software conferences so that they can get more out of the experience?

Matt: Try to come up with three things to do on Monday that justify the investment. These things should be entirely within your power to do. They should not require training, a team-level change in process, particular learning time, purchase of tools or hiring of consultants. Things you can just do - that you will not ask permission for. (Your boss probably doesn't know what you do anyway.)

Then do it and tell the team about it. If you want to write a trip report, it should be a one-pager, and describe what you are doing, not what you heard.

Hexawise: What software testing-related books would you recommend should be on a tester’s bookshelf? What blogs would you recommend should be included in a software tester's RSS feed reader?

Matt: I don't read blogs like I used to, instead I follow twitter and click on interesting links. A few weeks ago I wrote an article on 28 testers to follow on twitter that might be a good place to start.

As for books, I'd say How To Reduce the Cost of Software Testing, Lee Copeland's A Practitioner's Guide to Software Test Design, Lessons Learned in Software Testing and Jez Humble's Continuous Delivery book (the writing is a bit tough but it's worth it). I'd also suggest some non-testing books, like Out Of The Crisis by Deming, Peter Drucker on Management, and Taleb's Black Swan book.

Hexawise: We share an interest in seeing lean thinking concepts be adopted by software testers. How would you suggest someone interested in learning more about lean thinking in software testing do so?

Matt: You could try a google search for "heusser lean" and see what it returns, seriously I've written a lot. Here are two older articles that I think cover the start of it Applying lean concepts to software testing and The secrets of successful Lean software testing.

Profile

Matt Heusser is a software craftsman with a deep background in software delivery and testing. After earning his undergraduate degree in Math with a concentration in computer science in 1997, Matt began his career as a programmer, writing code in C, perl, PL/SQL, and Visual C++. Along the way, Matt was the initial organizer of Grand Rapids Perl User's Group ("Perlmongers"), earned a master's degree in CIS from Grand Valley State University, taught IS part time at night at Calvin College, and served as the initial lead organizer of the Great Lakes Software Excellence Conference.

After leaving Priority Health, a Health Insurance Company, in 2008, Matt went on to become a member of the technical staff at Socialtext, the world's first wiki company, where he worked with Audrey Tang, Ingy DotNet, and Dan Bricklin, the creator of the Spreadsheet, to help build a web-based spreadsheet/wiki that predated google docs. The test framework Matt worked on at Socialtext, WikiQTests, is documented as a case study (chapter 16) of O'Reilly's book "Beautiful Testing."

Matt left Socialtext in 2011 to become a full-time consultant. Since that time he reviewed Robert C. Martin's books "Clean Code", "The Clean Coder" (for which he wrote the preface) and "Clean Architecture." In 2014, Matt received the Most Influential Agile-Test Professional Award at Agile Testing Days in Potsdam, Germany.

Links

Blog: Creative Chaos

Twitter: @mheusser

Previous Testing Smarter with... interviews: Testing Smarter with Rikard Edgren - Testing Smarter with James Bach - Testing Smarter with Michael Bolton

Subscribe to the RSS feed for our blog.