In my view, the first thing is to make sure you have a coherent understanding of testing yourself.
Document your philosophy and processes
I never thought about that much until I started to write training material rather than just sitting and talking about it. Writing test process documents to support bids also forced me to think more deeply about what we do, and this was quite literally transformational.
Let them explore and make mistakes
Be aware that beginners won’t be able to understand some fundamental concepts until they have some experience. This is a bit chicken and egg, and it’s why you shouldn’t expect them to be very productive at first. For instance, there is no general agreement as to what “quality” means or how to measure it, or what it means to test something, even though it’s what we do all day. There are several very different definitions for all these things.
This doesn’t mean that beginners can’t do anything useful, but it means you sometimes need to explain that what they have been doing is over-simplified and that they need to go backwards a bit in order to go forwards.
We specialise in exploratory testing, so I always encourage beginners to explore an application, use it as a user does and just see what users can and can’t do. Observing what they do and what they find always prompts further learning opportunities. That was pretty much all we did until I documented our testing philosophy and practices, which made it much easier to teach them to beginners.
Third-party material and coherence
I don’t advise that you rely on stuff written by third parties because it probably doesn’t align with what you do or want. With the hindsight of many years, I realised that the training I received on day one was an incoherent hodge podge of material from ISEB (the predecessor to ISTQB), IEEE 829 (a documentation heavy “best practice” methodology) and James Bach’s 1990s exploratory testing internal training material at ST Labs (who I joined after he had left). No wonder I was confused! Now, I only refer to third-party content to the extent that it supports our testing approach.
Don’t expect too much
I used to reckon an absolute beginner wouldn’t make a net contribution for at least a couple of months. They would do some useful stuff, but they would need a lot of checking, supervision and support. If you are not willing or able to provide that much support (which means you’re taking time out of your own job), don’t recruit newbies. Good testing is extremely difficult, and you’re not going to get that from a newbie without a lot of support and patience.
Make them study in their own time
There is a massive learning curve in testing and indeed in all IT roles. If a newbie wants to become useful rapidly, achieve excellence and stay at the top, they can’t treat it as a 9 to 5 job. They might achieve mediocrity, but I don’t recruit people with such low aspirations.
I recommend the company pays for all the books, courses, webinars, conferences etc. that a tester wants, and that the tester should study in any downtime at work. But they must be prepared to study in their own time. Yes, I’m a wicked slave driver, but that’s the price of excellence.
