Interview with Matt Heusser, keynote speaker at the Test Automation Day

I had the chance to meet Matt Heusser (@mheusser) during the Agile Testing Days 2012 conference... and it was great! Matt's keynote was brilliant, excellent, I really enjoyed it. But I think what I liked the most, was that he seems to be a humble and honest guy.  One of those guys who's got a lot of experience, knowledge and prestige, but talk to you with respect even if he doesn't know who you are. My good friend Ivan Stepaniuk was lucky and got the chance to share more time with Matt, where he gave us some advise.

Now I've had the honour of interviewing Matt thanks to the organization of the Test Automation Day conference, which will be held in the Netherlands in June 2013. Matt will be keynote speaker in the conference and the whole event looks very promising. If you are a tester living in Northern Europe, don't miss the event

Let's go to the interview:

----------

- How is it going Matt? What have you been working on recently?
Thank you, Carlos, I’ve been busy.  Right now I am working on a local ecommerce test project, doing a lot of writing, helping to organize the test and quality track for the Agile Conference, organizing an online test competition in April, and trying to organize a peer conference in Wisconsin, likely in August, 2013.

- In the last decade, teams used to see testers as second class citizens. Testers haven't been involved in the requirements or in development stages, but just as part of the UAT process. Do you see changes in the last couple of years?
It’s a big world, and I see testers at different companies doing different things, so it is hard to draw trends.  The complaint of ‘second class citizens’, or being involved too late -- we’ve seen those sorts of complaints for a lot more than this decade.  If you go back to the test conference materials of the 1980’s, I expect you would find the same sorts of suggestions, to get involved upfront, to get the requirements right, that sort of thing.
I think two really big things happened in the first decade of this century, though.  First of all, the context-driven movement changed the question, asking “If I wasn’t involved up front, and I am brought in late, what can I do to improve outcomes anyway?”, which I think is a healthy question.
Second, the customer-facing testing branch of the Agile School started to talked about what they called Acceptance Test Driven Development (ATDD).  Part of ATDD is getting concrete, testable examples early in the process -- helping to augment requirements with specification by example.  Deming would have called it ‘operational definition.’  No matter what you call it, testers are good at coming up with the cases of software in use, and programmers are using that to drive development, which means the software is higher quality when it comes out the door.  That is eliminating dev/test defect churn, and people are noticing.

 
- Do you still find companies delivering software without a professional QA team or is that already overcame? How would you explain to them, in short, that they need QA?
Well, I think they need to do testing as an activity, and probably are, though they may be doing it poorly.  Programmers tend to not be great at testing for defects, customer-testing, because testing is a sort of destructive activity, and programmers tend to be constructive in thinking.  (I am a former programmer, I can say that.)   There certainly are problems small enough that that is not a big deal -- a company hiring programmers to write database reports might not need testing as a role.
On more complex things I want to look at the defects the company is showing to the customers.  Do they matter?  Are they coming in late?  Is the company experiencing lost sales or returns because of poor quality?  Are programmers spending more time fixing than in building new software?  If the answer to any of those questions is ‘yes’, the company may ask for testing help, and, at some point, get more serious about the tester role.  I don’t want to force that, though; I’d like the company to decide and then ask for help.

- Where do a professional agile tester start her career? Where is it that one can learn how to become a professional agile tester?
Well the easy way to do it is to find a company doing Agile Software Development, interview, and get hired.  That is the easy way (laughs).

I guess I don’t understand the context. Is if if you are a tester now, how do you become an Agile Tester?  My advice would be to change your organization ... or ... change your organization. Is the question how to be an agile tester, that is, how to learn what agile software development is an how testing plugs into it?  For that I would recommend finding a local user’s group, going to meetings, and reading everything you can find on the subject, from books to blogs to twitter.

 
- What skills are needed to be a professional tester?
Offhand, I would start with curiosity and systems thinking and the desire to learn.   By systems thinking, I mean the ability to model a situation in your mind, to make trade offs, and to figure what happens when those tradeoffs happen.  This is the kind of thing you can learn by playing Chess; Gerald M. Weinberg has a couple of good books on the topic.  Most of the other things can be taught.  Most teams following an Agile approach also require a little bit of teamwork, but  to be an effective tester, that is not always required. (laughs)

 
- What do an independent agile tester like you offer to companies? What is the value they can get from hiring you as a testing consultant?
 It depends on what you bring me in to do, but I can give you some examples.  The short answer is  expertise.  When a team has a problem they could probably solve, but they have other things to focus on, they can bring a consultant to get to the bottom of the problem.  My role at Excelon is a little different because in addition to consulting, I also stick around and help implement the ideas on real operational projects - I actually do testing.  That’s the second half of the value; instead of solving the problems, I can work with the teams to solve problems themselves.  Not by lecture in a classroom with powerpoint, but by working through actual operational problems.
One common thing I can do on any project, at any phase of development, is start testing.  No requirements document?  Fine.  I can test.  No access to a customer? Fine, I can test.  No spec, no project plan?  The software won’t build?  My gamble is that I can find something to do to add value to the project to justify the investment.  Given a little time, I can teach it, so you get skills on the team plus the project is actually done-done earlier, which is something you don’t get with traditional “conduct interviews and write a report” style consulting.

 
- Is the market asking for more professional testers? are there many job opportunities out there?
It’s funny you should ask.  I don’t know about in Europe, but right now in the United States I have a had a great deal of requests lately from all over the place in America.  At our last meeting of the Grand Rapids Testers, I think perhaps half of the people there were either building test departments or recruiting testers!

- Why should people attend to Test Automation Day conference?
Too many of us feel vaguely bad about ourselves that we aren’t doing more test automation, and when we’ve tried, we’ve had a fair bit of failure.   Test Automation has been the bugbear of software testing for years.  Let’s face it.  We aren’t likely to solve this ourselves, but by coming together, we’ve got a chance.

- What are the top three books you recommend to learn about software testing?
It depends on the audience.  To a professional tester I might recommend Lessons Learned in Software Testing by Pettichord, Kaner, and Bach.  Second, How to Reduce the Cost of Software Testing, a collection of essays I was involved in - and perhaps third, the Lee Copeland book on test design.  For a manager, executive, or someone new to the concept, you can’t beat Weinberg’s “Perfect Software” book.

- I do know agile testing is continuously evolving, is non-agile testing evolving too?
In some ways, what the agile folks were pushing for twelve years ago when they signed the manifesto are becoming the norm for all the companies I consult with - frequent meetings, (more) frequent release, a willingness to plan iteratively, and so on.  So even the “non-agile” problems are become more “agile” - lowercase a.
But I think I take your meaning.  There certainly are traditional projects; here in the United States they are likely to be financial, embedded, avionics, that sort of thing, that have a high price of failure that require a more specific process.   The context-driven world has made some big strides in that area; I also think that some of the ideas about High Volume Test Automation, the work of people like Dr. Cem Kaner and Doug Hoffman, are starting to gain traction.

- How is agile testing going to evolve in the next decade?
 Well you have to ask, in 2003, if I could have predicted where we are today.  Could I have predicted that testing would need to scale to hundreds different types of mobile devices running twitter and facebook and google plus and GPS?  Probably not.  Could I have predicted ‘the cloud’?  Certainly not in how it played out.
So testing will probably evolve to scale the needs of software we can’t predict.
Now do I see trends?  Sure.
Right now I see a new field emerging, the quality engineer, that comes out of devops. QE’s might be building the build system, the test automation, tying things together, or creating the developer tools to enable self-service environments, push button builds, and deploys/rollbacks to production.
The reason it is a new field is because the companies doing it are doing it with open source tools.  Everyone is rolling his own.  It is possible, over the next few years, that some commercial companies (or very successful open source projects) make this the sort of thing any company can implement easily - that we start to build a body of knowledge around chef and puppet and such.  When that happens, a lot of waste is going to disappear from the system.  Testers on those sorts of projects will need to find new ways to contribute and add value.
The second disruptive innovation I see are crowdsourcing projects uTest that allow companies to harness exploratory testing from the cloud.  That is going to eat into the market for testers.  Once again, to stay in the game, we’ll have to improve, because companies will be able to outsource the quick attack stuff to a crowd vendor cheap.
Of course there will continue to be big, slow, traditional companies building traditional software that don’t change much; many banks still run COBOL.  The testing equivilant to COBOL will be with us for years to come -- it just isn’t very fun!

----------

Thank you very much for your time and your inspiring answers Matt!

I hope the readers will enjoy the answers as much as I do. This post is going to be updated in the next couple of days/weeks, I will add links to the many references Matt points out in the interview.