Matthew Heusser's blog

Have you ever been in a conversation that went something like this?

A: "Visual Basic? It’s really easy. You just code it."

Matt: "What do you mean?"

A: "There’s really nothing to explain, you just do it."

Or perhaps:

A: "Does everyone know what page objects are?"

Matt: (Raises hand) "I might, but my readers might not. Could you explain it for us?"

It was in graduate school, in CS 641 (Management of Software Development), about fifteen years ago. Our professor, Dr. Roger Ferguson, was explaining the great benefit of the waterfall model for software:

The great benefit of the waterfall model is that it is easy for management.

This year I've been talking about skills in testing, and today I want to talk about a big one: Multi-Variate optimization. 

Sounds impressive, don't it?

Don't worry. While Multi Variate Optimization is important in test, it is also a simple concept, one you probably use at work every day ... and one that you can get better at.

We all all familair with optimizing a single variable: Trying to get the best price for a product without trading off anything else.

Multi-variable optimization involved trading off other things. 

Last time I took a swing at the huge and treacherous territory of communications.

Today I'll take another swing, at miscommunications, starting with an actual story of a recent phone conversation:

Two consultants walked into a company that made bar stools ...

Believe it or not, no, that's not the opening to a joke. It is, instead, the beginning of a story. 

I'd like focus this blog in 2014 on “hard” tester skills - to get past vague generalizations and slogans. (If the ideal is the T-shaped tester, with broad general skills that are shallow and a deep speciality in test - well, how exactly do you get that deep line in testing? What testers do, and how can they do it well?)

In my previous blog post, I pointed out that skills in testing matter. These skills are a bit like muscle memory; they can be learned by practice and attention to detail.

Now we come into the rub -- that you can’t practice test skills the way you can, say, hitting a ball or dunking a basket. Once you’ve tested the system once and know where the bugs are, a re-test exercise is trivial.

Or is it?

It is not every day that I find myself playing billiards with some of the best thinkers in software testing.

It was almost seven years ago. I was reading the end of Professional Software Development by Steve McConnell and was struck by his suggestion that advancing the practice will require practitioners to write about the work in practice, not in theory.

There is a story circulating around the world of software development that comes in many different flavors. Here’s a common version:

(A) Thanks to modern development methods, software quality is drastically improving.

(B) Thanks to the Facebook effect, customers are willing to live with software that is much lower quality.

(C) Thanks to DevOps, we notice problems in production very quickly and can “roll back” before most customers ever have a problem.

Therefore, we do not need software testers.