Fresh graduates often work as Testers at their first jobs even though their titles may reflect upon them as developers and might know nothing about testing. It is done because management fears bearing too much damage if the resource fails. In time, they are then promoted to being developers, their area of specialization.
Using testing as a transitional job for new programmers is not uncommon and is one classic hiring mistake. It does have a couple of benefits; why else would someone do it otherwise. For instance, it really does keep bad programmers from causing trouble. A bad tester can be much less damaging than a bad programmer. Moreover, it might serve as a good orientation and introduction to the business and its products for the programmer. S/he might learn some tricks as a tester that could help them later as a programmer.
All these benefits are outweighed by one huge disadvantage: the new hire HATES his job as a tester. That’s hardly conducive to good work. One could argue that the testers “have” to perform well to get their so called promotions. However, because people tend to be as motivated by effort as by results; they might not care much for their jobs.
Another classic mistake in organizing testing teams is to hire testers from amongst failed programmers. There could be several examples where bad programmers turn out to be brilliant testers. However, what happens when someone’s a bad programmer not because of the skill set but because of inappropriate work habits? For Instance, programmers who make lots of bugs because they are inattentive will also miss lots as a tester, for the very same reason.
So how should we then staff our software testing teams? What are the DOs for staffing QA experts?
1. When interviewing, we should concentrate less on formal qualifications than on intelligence and the character of the candidate’s thought. Know that a good tester has these qualities
o Methodical and systematic.
o Tactful and diplomatic (but firm when necessary).
o Skeptical, especially about assumptions and wants to see concrete evidence.
o Able to notice and pursue odd details.
o Good written and verbal skills (for explaining bugs clearly and concisely).
o A knack for anticipating what others are likely to misunderstand. (This is useful both in finding bugs and writing bug reports)
o A willingness to get one’s hands dirty, to experiment, to try something to see what happens.
2. Try to dodge the trap of testers who are not domain experts. Domain experts know more about the area of study and will help find the most relevant and useful bugs.
3. Good technical writers develop a sense of what’s important, what’s confusing and so on. Those areas that are hard to explain are often fruitful sources of bugs. Therefore; it is advisable to have some technical writers in the team. Like testers, technical writers often also lack detailed domain knowledge. However, they’re in the business of translating a product’s behavior into terms that make sense to a user.
If you keep in mind these guidelines while selection of your testing resources, you will successfully dodge a testing team that lacks, skills, quality and diversity. All of the members might lack some skills, but the team as a whole will have them all. Over time, in a team with mutual respect, the non-programmers will pick up essential tidbits of programming knowledge, the programmers will pick up domain knowledge, and the people with a writing background will teach the others how to deconstruct documents.