Hiring newbies for your QA team is a bit of a gamble, because you’ll have to invest a lot in teaching without knowing beforehand if you’ll actually get a good tester out of it. But there are ways to make the process easier (though no less time-consuming) and more likely to succeed. You need to hire correctly, teach correctly and – let’s face it – fire correctly.
First, to dispel a myth: people who have just finished a testing course, a B.Sc in any software-related field and former programmers don’t know how to test. If you accept this truth, you’ll save yourself some heartache. When you’re hiring an inexperienced tester, the most you can hope for is that you won’t have to break some bad habits.
Realizing that hiring newbies means you’ll have to teach testing should help you approach the hiring process correctly. First: knowledge means nothing, only brains and personality matter. Pick someone smart, with learning skills and patience. Look for an ability to accept and learn from mistakes, critical thinking skills and an unforgiving eye. Second, know in advance what you mean by “testing” and how to teach it, estimate the required teaching time, add ten percent and then find the point in your deployment schedule where you can fit it all.
You can understand from this that you shouldn’t be hiring newbies if you don’t have time and patience. If you need someone who’ll be fully independent in a couple of weeks, you’ll need to pay for the experience that requires.
Getting Ready for the Newbie’s First Day
When your newbie arrives, have the following ready:
1. A testing guide that uses examples from your own system. Include examples of bugs that were cleverly discovered and bugs that were missed and caused a serious problem in production. If you can’t write a testing guide to save your life, then create a series of links to well-written ones that you think are relevant.
2. A guide to your own systems, if it exists. Prefer one that gives the context in which the system works, and not one that assumes field expertise, even if it’s a simpler, shallower guide. You can give the more complicated one later.
3. A dedicated tester-teacher whose job load was reduced to accommodate teaching. You cannot ignore this point – newbies are a drain on experienced testers’ times, and you cannot expect regular output from your teacher for the first few weeks of teaching. Please think carefully about who you’re assigning to this role. Some measure of patience is required, as well as an ability to explain things clearly (rather than repeat them in a louder voice) without spoon-feeding.
4. A small box of chocolates. It’s nice and welcoming, and the sugar will be appreciated come the info-dump of day one.
Teaching and First Steps
Start by explaining the world in which your system works. Product managers are usually very good at this, if you don’t feel like doing it yourself. Give your newbie time to play around with the system, and time to read your guides.
There’s no point teaching system architecture on day one. Let the newbie start with the client-side, and only move on to server-side teaching when the basic ideas and work-flows of the system are clear. Complex information is easier to learn when the simpler information can be used as an anchor for understanding and memory.
One of the best ways to teach QA is to go over good bugs together. This teaches both testing and your product. It also teaches the specific work-flow in your company, the bug tracker, how you like bugs to be written and so on.
The easiest first independent step for a newbie is to verify fixed bugs (assuming your bugs are properly written). Obviously start with the very simple ones, and let the newbie work up to the complex ones. The previous work done on the bug should provide the newbie with plenty of testing clues. This is the point where a newbie really starts learning – focus on thinking beyond the obvious tests to the important ones. If you don’t put in the effort now, you’ll get a tester that never gets much further than pointing and clicking.
The next step should probably be verifying very small changes, progressing in complexity. Keep an eye on how many good – rather than obvious – bugs the newbie finds, and how many are found by the teacher instead (when they review the feature together, after the newbie declares it done). The balance should shift slowly between them, until the newbie gets most of the important bugs, leaving nothing major for the teacher to clean up. For small changes there shouldn’t be too many bad bugs, however, so at some point you’ll have to let the newbie start testing full features, with the teacher as a co-pilot. Again, check the balance between their bugs – with both of them testing, they should eventually even out.
Don’t attach your newbie and teacher at the hip. Let the newbie work alone and with other people, and let the teacher have some time alone – teaching is exhausting.
When to Give Up
It’s easy never to give up, because you keep telling yourself that you’ve already invested so much in your newbie that it’s not worth it to discard everything and start all over again. But that’s very faulty logic, because it leaves you with a bad tester that continues to be a drain on your resources. Sometimes, it’s best to start over.
But giving up requires assuming that the newbie will never be a good tester. How do you know that? Some people are slow learners, but once they “get it” they become very good; while others are very fast learners, so they make a very good impression, but really they never develop the QA nose, that ability to sniff out the less-than-obvious bugs. So to know when to give up, you must first understand what you expect the newbie to know, and when, to qualify as a “will be good” tester.
I don’t know how you define a good tester, and I won’t bore you with my definition of it. But usually there are two aspects to a good anything: skills that can be learned (like writing queries) and skills that we usually assume can’t be learned in a meaningful time-frame (like an ability to connect the dots). It’s up to you to define and evaluate these skills.
If you want a good tester, the DIY approach requires patience and time, but often pays off. The important thing is to understand that knowledge cannot be instantly imparted by the air in the office; it must be taught, and it takes a while for it to all sink in.