The Boutique Tester Revisited
By: Matthew Heusser
Three years ago, back when I had one of those day job things, I published a paper called "The Boutique Tester." Since that time, I've gone independent, sold testing and training services, had a chance to test the business model, met a bunch of people who were also trying it out, and watched the world change. Between cloud computing, crowd-sourced testing, and the recent claim that "test is dead," I daresay the freelance software landscape looks different than it did three years ago.
If you want to become a boutique tester, or if you're thinking about collaborating with one, I have a few suggestions.
Any New, Disruptive Service Has Sales Challenges
The Boutique Model requires a fair bit of speed; your contract will be a short one, where you are air-dropped into a project and take off. If the paperwork takes a few weeks to process and the contract then needs approval from HR, legal, and a vice president, then the software may have already shipped by the time the contract is approved! This can make working with large companies difficult. In addition, those large companies tend to want employees on long contracts for forty hours a week, and they prefer to deal with institutions, not individuals. You can see how selling boutique testing services might be harder than it seems.
Large companies do have one advantage: They have budget, while startup and small companies might not. Yet, the small company has a lot of other benefits, like the ability to make quick decisions and the kinds of development practices to which a boutique tester can add the most value. Several of my colleagues have managed to carve out a niche by testing a few hours here and there for multiple startups at the same time, but I've found that medium-sized companies are the easiest to get into. By "medium-sized," I am not talking about number of people but rather the company’s mentality. A medium-sized organization is successful enough to have budget but small enough to make decisions quickly. Like large organizations, medium organizations tend to want extended contracts for forty hours a week, which makes losing a single customer kind of a big deal—the sort of risk the Boutique Model is designed to avoid.
It’s not business nirvana, but I've been independent for nine months now and am looking to stay that way.
Everyone Wants Test Automation
Ten years after James Bach published "Test Automation Snake Oil," I continue to get calls from companies that want me to come in for a three-month project to fix a broken test automation framework. Why is it broken? Some contractor came in for a three-month contract, wrote a bunch of stuff, then left. The company hit a crunch time, modified the GUI, and now the test automation is a big mess on the floor.
In a year, is this company going to call someone else to fix the code that I wrote?
The potential client often says that the great Matthew Heusser “really gets this stuff” and can design a "maintainable framework." That's flattering and all, yet I can't help but notice that the system forces are exactly the same for me as they were for the previous contractor. Nothing has changed. I do think I have something to offer these companies, but I'm not excited about answering that specific call or tricking them by coming in to do something other than what they’re asking. So far, I have always had a better opportunity to pursue.
Don't get me wrong. All the teams I've been working with automate some checks. The developers use test-driven development, the testers write scripts on demand, and we often have a high-level tool like Fitnesse to communicate requirements or have developers write Selenium code to demonstrate that the feature is "done." The thing I am talking about is having someone external—even contract—develop automation that drives a GUI after the code is “passed” to QA.
This can work and has for some organizations with certain types of problems. The work we did at Socialtext is often held up as a case study for a good framework. A few years later, I'm less excited. So few companies have the perfect mix of problems that lends itself to this sort of automation approach. Our case study may have been an exception, not the rule, but it's open for debate.
Adam Yuret, a boutique provider for management and test services recently put it this way: "I think test automation fetish is a pretty good heuristic for organizational dysfunction—not to say automation is always bad, but I think many dysfunctional organizations misidentify their problem as being a lack of automation."
Boutique Testing Services Can Be Sold by a Larger Company
When I wrote the original article on the Boutique Tester, I thought high-end testers would contract directly with companies. But, like I wrote above, it turns out that many companies want testing as a true service—like tap water they can turn on and off, with little concern over the "who" or if that person is available right now. The easiest way to do that is to hire a service-providing company, one with hundreds or thousands of testers who can be accessed at will.
Since that article was published, I've seen two companies move into that space: uTest, which offers crowd-sourced testing (as well as specialized test) services, and PQA in Canada. It turns out that PQA has been around for a long time, but they only recently got aggressive about competing in the US. Two of my friends, John Kotzian and Elena Houser, have done independent test work for uTest, accepting projects as they come and working on them when they want to from home. John tells me he even exceeded the cash salary of his old day job in his first year with uTest, working about forty hours a week.
On a related note, another challenge is that boutique testing only offers part of the solution, not the whole thing, so it creates a little more management work for the client. One fix for this is to partner with a developer and test on the projects the developer leads. My colleague Catherine Powell did this for several years. If you want to live the boutique life but can't take the risk, it might make sense to find a partner.
... to read more articles, visit http://sqa.fyicenter.com/art/