The Boutique Tester

Generations ago, craftspeople lived in the center of town, owned the building, and lived upstairs. They generally owned their own tools. Independent craft was such a part of their being that when it came time to pick up last names, they took up the last name of their craft: Cooper, Miller, Smith or Carpenter.

A few hundred years later, when it was time for young Matt Heusser to start his career, that independent spark was all but gone - at least from software development. Oh, it still existed in some of the trades; you can still find an independent plumber. But even then the American people had begun to declare war on work; as Mike Rowe put it, we relegated that plumber in our minds to a 300-pound slob "with his butt crack hanging out."

And at the time (1997), it was very hard to be an independent software contractor. To distribute software you needed to print CD's, stuff them in boxes, and market then to large retail stores. The few people who were on-line were using dialup modems and wouldn't stand to download win32 software. Building a web presence was expensive; you needed to build a server farm, rent a T1 connection, and hire an army of developers, DBAs, system administrators, analysts and testers. The few craftsmen making shareware and open source software were hobbyists - it wasn't expected to pay your rent. Why, even the methodologies popular at the time pushed you toward an assembly-line of specialists.

While you could work as an independent contractor for companies, the idea of making things for yourself just wasn't part of the scene. Huxley was right; the brave new world had come.

... time passes ...

Today it's 2009, and I again see a world where software craft is possible. Computers get faster and cheaper; now I can rent a box that will run PHP, stuck inside a colo, connected to the internet, for a hundred bucks a month. A majority of Americans have a high-speed internet connection, and the web has evolved to nearly match the functionality of traditional windows programs. Free programming tools, at higher and higher levels of abstraction, combined with methods (like XP) that focus on the generalist allow the programmer to be programmer, developer, tester (?) and system administrator at the same time.

All of a sudden, it does make sense to hire one guy (or maybe two) to write your website. Custom software development - and the craftsman - is back, baby.

And back big time. The Ruby on Rails movement alone is full of small companies like 8th Light, Obtiva, and Atomic Object that have generalists making custom software.

I believe this is a real good thing.

... but what about the tester? Why, the software tester doesn't make anything. The tester is just part of some assembly-line. That's a job that should just go away as we all become generalists, right?

Well gosh, I hope not. Sure, I've done development. I've done analysis. I've been a generalist responsible for everything. It's just that I enjoy testing. It's what I want to do.

So if we have found a space for the boutique developer, can we find a place for a boutique tester? And, if yes, what would that look like?

I believe the answer is yes and no. To compete as a craftsperson, the tester role will have to evolve. He'll have to be smarter, sharper, faster. In the boutique world, he will have to explain his services to people who are skeptical of such services and believe they can do it themselves. In the words of Harry Harrison, in his novel the stainless-steel rat:

It was easier in the old days, of course, and society had more rats when the rules were looser, just as old wooden buildings have more rats than concrete buildings. But there are rats in the building now as well. Now that society is all ferrocrete and stainless steel there are fewer gaps in the joints. It takes a very smart rat indeed to find these openings. Only a stainless steel rat can be at home in this environment.

So what would a stainless-steel (boutique) tester look like?

Imagine a development project that is outsourced to one of these boutique dev shops. The programming budget is in the area of at least $50,000, and also has an outside design firm and internal costs. The total cost of project is probably in the $100,000 range. (I'm not making this up; this is the range of budget typical for a project for the consultancy "hash rocket", another boutique rails shop.)

Now, imagine the project is halfway through. The customer begins to be concerned with functionality. This is a make-or break project, they explain. Perhaps the customer is a media outlet, like NBC. They start to talk about how it "has to work" and legal implications. The development staff, a bunch of craftspeople, start to hear about contracts and clauses.

What's does CEO of a shop with SEVEN employees do now?

Hopefully, he tells the customer that the logical thing to do is to hire a tester; someone independent, who can make an assessment of the software. Someone they can air-drop in to mitigate risk for two to five percent of the development cost. After all, if the customer is so worried, why not spend $5,000 on a $100,000 project to mitigate risk?

This means the tester isn't going to moan that they were not involved early or insist on detailed documentation - they will have to actively contribute to the project right now.

Perhaps, over time, this service becomes so valuable that the development shop plans on using a tester as part of it's risk-management strategy in general. Sure, the devs will do test-driven development and perhaps even automate story-tests for the customer. And the final layer - the piece de la resisstance - is the air-dropped tester.

With a few shops to work with, it's possible that tester could create his own boutique test consultancy. There are already a few people who do this sort of thing; stainless steel testers in the maze.

Keep in mind - testing as a profession is not going anywhere. There will be plenty of testing roles in larger organizations in the years to come. But is a testing boutique possible?

I sure hope so.

Alan Kay, the man generally credited with object-oriented programming, once said that the best way to predict the future is to invent it.

Let's go prove him right.