I’ve talked to a number of companies over the last couple years about becoming their first ‘official’ qa person. Usually they come to some form of the realization that if they spend the money on another developer they can get more product into the marketplace. Either that or they are shocked that they cannot pay someone like me what they would for a junior developer.

During the rapid(ish) growth phase however, there are a number of steps a group can take on their own. Crazy enough, these are the sort of things I would hope a QA person who has been around a while would advocate for once one is finally brought in.

  1. Unit test. Unit test. Unit test. Yes, an application is more then just the sum of its nicely tested units, but it can also be far less.
  2. Unit tests are more or less useless unless they can be run from outside the IDE. Make it so.
  3. Tie your now-running-outside-of-the-ide unit tests and your versioning system together through Continuous Integration
  4. Introduce inspection tools, both source and compiled, into the CI mix
  5. Explore using Test Doubles to remove relationships from your tests (and as a by-product, make them faster)
  6. Flag places that are ripe for refactoring both in the code (perhaps with a big REFACTOR comment) and in the bug tracking system. Follow this up with starting to refactor the easy places first. The difficult ones likely will have a greater impact, but they are also riskier and can likely wait until your safety net is a little more robust (more unit tests for one, a professional tester for another).
  7. Start doing peer code reviews, and actually action on the items discussed. Doing code reviews without the follow up is just a waste of developer time.

Once you have these things in place, you really are ready for a fulltime tester. Nothing drives them/we/us more bonkers is to be given the green light to test a certain build to be thwarted by a really big, obvious bug. The above steps should go a long way in preventing that.