Sunday, September 21, 2014 at 8:47 AM

The lost art of software testing

I remember when I first encountered a software tester. I had just signed up with a publisher, and they employed testers, and one was assigned to my product. His first report was a total shocker. He found so many problems with my product. I thought some of them were really petty, some indicated he didn't understand the product, and in a very few cases he found real bugs.

Over time, though, my point of view shifted. Petty problems or not, I wanted to know how my product worked for real people who weren't working on the code. Here was someone whose job it was to tell me. Things he didn't understand about the product were the most important for me, as the developer, to know about. Why? Because it's not about algorithms, or coding, these are the mistakes we made in the 70s, it's actually about creating functionality that real people can use, with minimum effort. It's all good data. And having a great tester on a team pretty much guarantees you won't ship garbage. (It can happen.)

A tester approaches a product as a user would, and does the things that occur to users. All the time taking notes. After that, the tester goes through the docs, and tests them too. Do they accurately describe the product? In what ways did I get lost?

A tester gives you all the information she has that could help you find the problem and fix it. And when you ask for more, the questions are answered clearly and directly.

When I started a company, and had developers working for me, we always had testers on the shipping team. They didn't report to the developers, they reported through an entirely different structure, direct to me, the CEO. I wanted to hear the unvarnished truth about our products, and I wanted to be sure the developers were hearing it too.

I think all developers go through the initial hatred of the tester, feeling unloved, and depressed because the labor of our love is so awfully buggy, broken and badly designed! Oh. But you eventually come to see that knowledge is power. It's where the we make shitty software idea came from. I get it. Our software sucks. Now let's make it suck a little less.

What got me going on this thread was a comment under my narrative about my new iPhone 6, a few days ago. He complimented me for doing a good job. I said it's not unusual, it's the kind of thing any software tester could do. And then I realized that my blogging about products is very much like a tester's reports. And perhaps that's why the developers of the products I write about get so angry with me. "He should know that's not the way the product works! Oh that's just petty." See. But if you really embrace the experience of other people, people not schooled in the details of your implementation, you can learn how to make your work easier to absorb, and therefore more effective at what it's designed to do. This would be a better place for budding computer programmers to start. First, learn how to be a great user.

PS: Google, would you please fix the clipboard in Chrome! Being forced to restart the browser just to link to something is such a huge step backwards and so un-weblike.

PPS: Another idea, people who write about tech should also be schooled in software testing. A lot of the ridiculous ignorant ideas that take root in the press would be snuffed out. They listen to developers too much, as they tell you how great the products are. Sure it's interesting to hear the developers' stories, but it's equally important to hear what the products are like to use.


Last built: Sun, Mar 22, 2015 at 5:50 PM

By Dave Winer, Sunday, September 21, 2014 at 8:47 AM. Still diggin!