Matt Heusser wrote an interesting post about “boutique testers.” I like the idea of boutique testers (boutique intellectuals of all kinds, actually, which is why I wrote my new book.) And I am an example of one. The testing I’ve done in recent years has been mostly on court cases or part of coaching testers, though. I want to do more ordinary testing. I need that in order to keep up my practice.
I live on an island, making travel expensive and annoying. But I have a great Internet connection.
There are important challenges to being a remote tester, though. The main technical problem, in my experience, is acquiring and configuring the product to test. Getting up to speed fast benefits from being onsite. The main social problem is trust. Hiring a remote tester, especially one who’s supposed to be high powered, is a little like hiring a therapist. In my experience, developers feel more sensitive about a well-paid, high status outsider poking at their work, than they do about an internal tester who probably will disappear in a few weeks.
Then there’s communication. Despite all the tools for modern communication, we haven’t yet developed a culture of remote interaction that lets us use those tools effectively. Even though I’m always on Skype, and people can see I’m on Skype, they still ask permission to call me on Skype! And I also feel nervous about calling other people on Skype. They might be annoyed with me. I do use GoToMeeting, and that helps a lot. Michael Bolton and I have been collaboratively writing, recently, using it. We like it.
Finally, there is one big logistical problem: availability. You can call me up and have me test for you. But, being a fully independent consultant, my time is chopped up. I have a week here and a few days there, usually. This is the main reason I go in for short-term consulting and coaching. Unless a rich client comes along and induces me to clear my schedule, I can’t afford to have only that one client.
Still, with the price of travel so high, I think this is the direction we need to go: each of us developing ourselves into unique thinkers with strong brands, and then remotely connecting (interesting oxymoron, eh?) with our clients.
Phone: 360-440-1435
Email: james@satisfice.com
Skype: satisfice
I’m betting my career that this is a sustainable model somehow. You might like this for general information:
http://www.remoterevolution.com/.
I’ve written about this a few places:
“Distributed Agile Day to Day” (about halfway down the page) http://www.stickyminds.com/Media/eNewsletters/Iterations/Default.aspx?eNewsletter=200905#powerbookreview
There’s some more behind the paywall at stickyminds, too.
I like the idea of boutique testers, too. I’ve been thinking about some of the problems of being a remote
What if you didn’t have to remotely do the bits of testing that benefit from being physically present? Configuring environments, watching people use the software, interacting with the test data and tools close to the terminal, chatting with the programmers over coffee/lunch, experiencing the software and its development in the flesh… What if you had eyes and ears and brains on the ground, in the right places at the right time?
What if you could use local testers to do those things for you, while you got on with the things you can do effectively from a remote location?
Would having a network of real /trusted/ testers on the ground prevent some of the logistical and communication problems associated with being a remote boutique test shop(?)
The trust issue becomes more of a problem in this scenario. Now you have to:
1) Get the client to trust you as a remote tester
2) Trust the local testers you place on-site to be self-managing, effective and somewhat representative of your values
I’m starting to think that a network of recommendations could be a good way to help boutique shops gain trust and build good relationships with businesses, in any profession… Will business owners care? How do we make them relevant and available on a global scale?
Hello, James. I’m glad to hear the idea resonates.
I’ve been working for an all-remote agile team for about fifteen months now, and writing a monthly column for a test magazine for almost the same. When I taught modeling with spreadsheets last semester at Calvin, our guest lecture was Dan Bricklin – and he did it with Skype. As such, I have unfortunately discounted the issues you bring about with trust, availability, and missing on-site presence.
There are a few markets that are both jam-packed with businesses and either geographically small (SF) or have excellent transportation systems (Chicago, New York) – so the boutique tester could be on-site. There are also a few consultants and professionals (Karen Johnson comes to mind) who are able to travel and operate as a boutique tester effectively.
My ideal gig would be remote with a certain number of hours per month on multiple contracts. I’m not sure the model is fleshed out; most of the people I know doing it also do a fair amount of training, either because training is easier to sell or because it’s good marketing – probably both.
I did /not/ bring up the idea of test labs because it’s rare that I see a test lab with longevity. Mobius in Indianpolis, or Quardev and QALabs in the Pacific Northwest come to mind – but it will take a few more years to validate that models. And it’s hard to call QALabs boutique when they employ 100+ testers …
One thing that strikes me about remote testing is feedback. Alistair Cockburn did some very nice examinations during the 90s on this topic, raising principles such as “two people communicate best at a whiteboard” expressed in graphics like these: http://alistair.cockburn.us/People+communicate+best+interactively+face-to-face.gif
From my expertise the ongoing question on WHEN to best start testing activities during a project, stays unanswered and I consider it to be context dependent. During two recent projects I made the experience that starting test automation late pays off, when testing i.e. exploratory testing and document reviews and asking the right questions made pretty much sense for that particular project, where we had the customer within our company. With a project setup of spreaded teams in Rio, Germany, Poland and Romania I doubt the same thing will work. Your proposal of the remote boutique tester will work better in some situations as in others. Knowing these situations requires proper experiences.
Hi James,
I think you’ll be in luck. As oil prices are -and will be- continually rising from here on end the customer preparedness to engage remote services will rise. The cost of on-site will get more expensive and the in
I think with things like Skype, remote screen sharing and video we have the needed technology to work off-site. What I still see as a big issue are the conservative and naive views of infrastructure and network administrators. They seem to be overly protective/change averse of any access/change to their systems. This is especially true for governmental and military customers. They don’t like doing the most simple things (like putting in VPNs, configuring firewalls,…).
So the issues and limitations are human in nature as you have also pointed out. Not only from a perception point but also people being change averse.
Oliver
Hi James,
I suppose I am a boutique tester and I do a bit or remote work. In Australia, testing remotely is quite common. Perhaps the consequence of a large continent with a small population? In ireland, I am finding its a lot more face to face and who you know. My experience has been that:
a) its not sustainable and needs to be supplemented with other work
b) a lot of the time you drive the context (the customer does not know or is unwilling to communicate the context)
c) it works well because of the flexible nature
d) Work tends to be short & sweet (3~5 days)
My speciality is working with startups, so that may tailor my experience.
Its a lot of fun, and keeps me on my toes…
Hi, James –
I thoroughly enjoyed my conversation with you and Jon last week at PNSQC, and I was delighted to be the butt of your playful jabs in your ET class.
Following up on that conversation, looking at this thread might be a good place to start. Boutique testing. I mentioned during the class that doing the exploration needed to find a way to automate a particular script in a particular environment was where I usually got my ET ya-ya’s. Often there’s an assumption of a ‘happy path’ to get into a context for a text, and I have run into a lot of cases where that’s the only way a group will enter that context. But like the rooms in “adventure”, there’s most likely more than one way into a room, and it is also frequently not readily apparent. (Adventure was very instructive that way. Some rooms could not be entered from the same place you exited them from.)
I’m thinking this might be one of several possible titles for a paper for a conference. Thanks for the tools, time, teaching and teasing.
Lou
[James’ Reply: Come to think of it, is there ANY room that can be entered from the same place you exited? I mean, if you were in the same place you exited, you’d already be IN the room!]