Here’s an email I sent to David Whitehurst a few weeks ago. We’re working together on an open source project at herculeangrp.org.

Work from home is definitely the goal. Or rather “remotely” — especially if it can be done from the boat with a satellite connection midway between Ecuador and Fiji; but at a dock on the ICW wouldn’t be too bad either.

I’ve been doing QA since 2000. Before that I did construction and part time sysadmin and web design at small ISP. I code in Java and PHP and am learning Ruby and forgetting Perl, haven’t use C or C++ since school.

I’m a big open source guy and Linux fan. I obsess about process improvement when I should probably be getting things done quick and dirty. I don’t mean CMMI, IEEE, or sixsigma when I say process, I’m thinking more about agility, –not Agile. I’m not religious.

So I was glad to see your post on jroller about “Using JIRA, Confluence, Maven, SVN, CruiseControl or similar? Why Not?” Only I’m not a fan of Maven, though I can see why you need it if you’re hacking on open source Java projects.

Evangelizing just such a stack is my business idea. I don’t mean giving lectures at conventions, though that’d be good money if you can get it. I don’t want to become ThoughtWorks. I mean building it, and maintaining it. Providing the IT and QA infrastructure for development teams, and facilitating agile (little A) project management.

I think the target audience is a startup that’s suddenly outgrowing the core team, who are now trying to manage new employees who are expanding their original fast becoming spaghetti codebase. It’s remarkable how many organizations I hear from that know that they should have revision control, documented requirements, testing, and continuous integration but they don’t have the discipline or resources to get started. So I aim to help them get started. First with hosted (VPS) tools, then moving in house when bandwidth or security demand it. I’ll even provide VMWare images so folks can get started on their own.

Of course any developer worth half their salt can install subversion and some sort of bug tracking tool, and since there are plenty of open source tools, there’s no value added there. It’s moving up the stack and doing the dirty work where I think I can make a difference.

Outsourcing unit tests is a common practice, and potentially a good one if you can get together a good spec. Though really, developers should be writing their own tests, first. But if you’ve a legacy code base, it could be the best way to rein it in, or extend or replace it.

User level automation with tools like Selenium is a step up, and something most developers deem beneath them, and most testers don’t have the skills for. Those that do demand developer rates, anyway. And I think it’s actually pretty hard to build a useful, maintainable set of GUI level automation tests. There’s a lot of record and playback the happy path a million times testing out there.

Same idea with retrofitting documentation. No one (technical) wants to spend all day typing away in MS Office, and certainly no one wants to spend all day reading reams of printouts full of boilerplate. Lightweight, up to date specs and requirements are another area that most organizations would love to have, but nobody wants to do.

Test cases are documentation too, and sometimes substitute for specs (only no one ever lets the tester have the final say about functionality.) Again, the trick is keeping it lightweight, thorough, precise, and easy to execute. Even testers hate reading (and writing) essays in spreadsheets. Good tests are a good way to tease out good documentation. And a great stepping stone to useful automation.

I use lightweight in two senses. One is in the tools used for docuementing tests and requirements. Wikis over word processors. Simple forms over spreadsheets. I think there’s some room for improvement here. Fitnesse is a great idea but could be further developed. And as you mentioned on your blog, a custom specialized tool is almost always better than an expensive generalized one.

I’m ambivalent (bordering on mildly hostile) about code level speccing tools like RSpec. Nobody wants to learn yet another DSL (even in Ruby), but the truth is that a lot of people (good testers and functional analysts) would rather be writing concise bastardized Ruby than mounds of spreadsheets and boilerplate word docs.

The other sense I mean “lightweight” is that with some thought, you can be more concise and more accurate. But nobody has the time up front to do that. You have to figure out the full scope of the domain before you can simplify it. I think of Pascal’s famous letter where he apologises for writing a long letter because it didn’t have the time to make it shorter.

So that’s my domain. My plan is to relieve the pain at the build/testing level. Or if I can’t relieve it, get paid to take it at home (or at sea.)

As you can see, I should invoke Pascal’s apology myself.