In every software organization’s lifecycle, there comes a point when you can no longer depend on the ‘Grace of God’ to release a Quality product. I would argue that this point should be well before shipping any product, but the reality of start-ups is that they are usually developer driven. This is when you need to turn to professional testers.

Where to start?
The first person you should hire is someone who has been around the block and has had experience in both a start-up and mature organizations. Working in a start-up poses it’s own set of challenges and you might as well have someone who has encountered them before. However, if you have someone who has only ever worked at start-ups, and there is a few of those type of people especially in tech hub areas, then you run the risk of having someone who doesn’t have a ‘world view’ of Quality that someone who has worked in a large company — with customers even. This person will spend likely around 90% of their time doing hardcore, pure testing. The other 10% will be in starting to lay the groundwork for the future Quality processes that will be used in the future. Lets call this person our QA Lead.

Lead vs. Manager. An Aside
Here is another one of these little definition gotchas. Quite often the terms ‘QA Lead’ and ‘QA Manager’ are used interchangeably, and in some contexts they should be, but there is a difference between a Lead and a Manager. The difference is about the nature of the relationship with your reports. If you have people taking their day-to-day marching orders from you, then you are Lead. If you have control over their career (promotion, vacation, reviews, etc.) then you are a Manager. For this post, lets use the two interchangeably.

Whats next?
Clearly, as companies grow in size, the number of testers will need to increase. So who should be next brought into the fold? That answer will change from group to group and will be the result of an internal needs assessment. If you have a security product, you might bring in someone who has some knowledge there. Similarly for a database dependent app. I think bringing in an intermediate level tester is a good idea at this point as you need them to be able to work relatively independent, but you likely don’t want to burn all your money on salaries. The next couple hires I would make would be junior levels and more or less straight out of school. Earlier releases of products are the easiest to test, so bodies count more now. Later, brains count just as much if not more, but hopefully you have groomed your junior bodies into intermediate brains by then.

Ideal Structure
A healthy test team will resemble a nice little pyramid with the QA Lead at the top with progressively more people below them at more junior levels. One possible layout is shown below.

The nature of this will of course change if you had multiple products. And any number of external forces. This however gives a nice mix of experience and body count.

Needs Assessment
One question the QA Lead should be able to answer at any given moment is “Assuming no cataclysmic changes in product direction or technology, where would you like to see the QA/Test team to be in 18 months/3 years/5 years?”. The answer to this question drives all staffing. Some examples of answers and their action are as follows.

    • Answer: We will have a robust set of GUI Automation tests.
    • Action: Initially, look at acquiring a more senior level person who has implemented an entire GUI Automation framework to plan and lead the effort. If budget allows, get a junior for this as well.
    • Answer: We will be able to provide accurate performance numbers throughout the development and test process.
    • Action: Similar to the Automation action, you should look at leveraging someone’s existing experience in hiring to fulfill this action.
    • Answer: We will have a solution for testing all publicly available interfaces to our SDK.
    • Action: Contract a programmer to develop an easily extensible framework for calling each method and teach the team how to use it

Team Diversity
Related to team Needs is that whomever you hire should come from diverse backgrounds and experiences. Nowadays, I think having someone who can read and write a double-byte language is extremely important to any team. Especially a new one. The software marketplace is global and not everyone communicates in ascii. I can pull random characters from the charmap, but there is much greater value in using appropriate ones in appropriate fields. As the team gets larger, getting someone from a Writing/Literature background could only help your testing of the documentation.

Permanent vs. Contract
Casual evidence (Monster.ca, headhunters, etc.) is showing a trend to having test teams be more and more contract oriented and are only brought in for the actual testing phase. While this likely plays well on the balance sheet, I think this has serious long-term consequences for a product’s long-term Quality. Each contractor needs to be brought up to speed on the product and corporate policies and procedures regarding Quality and Test, which detracts from the time they could be testing. QA also uses the lull that occurs between release drives to implement infrastructure projects just as automation. If you decimate the group between releases, this infrastructure cannot mature at the ideal pace. If at all. Finally, contractors tend to cost more. If you keep hiring the same contractors over and over (so you can do infrastructure work with them or not lose training / product knowledge) you are just getting taken to the cleaners. Offer them full-time or replace them with someone who is. The exception to this is of course when you have a specific one-time need that cannot be addressed through your available resources. For example, my group could desperately use a programmer for 6 to 8 months to work on something and as none of us are programmers, the tapping contract pool would be ideal.

Leveling
Every organization will have different definitions of what each level of job maturity entails, but here is my rough thoughts.

  • Junior – Creates and Executes test cases. Assists in implementation of QA Infrastructure tasks. Juniors will likely stay as such for 3 – 5 years as they learn the ropes. This is the most boring part of being in QA, and if they still want to be in test after this, then they have likely found their calling. Make sure to mould their testing philosophy here.
  • Intermediate – Creates and Executes test cases. Creates Feature Test Plans after hashing out the details with the Lead. Can lead smaller scale QA Infrastructure projects. Acts as mentor to Juniors
  • Senior – Creates and Executes test cases. Creates Feature Test Plans with little guidance. Leads QA infrastructure projects any scope. Acts as mentor to others in the team.
  • Lead – Everything plus Project Test Plan creation and strategic direction of the group.

I think this covers the vast bulk of generic Test Staffing topics I have. I’ve intentionally left out how you actually select someone from the flood of resumes you will receive from Monster or Workopolis. That is a separate post unto itself.