How should we train our starting testers?

A couple of QA & Testing Forums around the Web have been discussing the question of how to train a tester, especially during the beginning of his/her career.

This is one of the most important and challenging question any good QA Manager should ask himself; if not for the sake of his Company and his Team, then for that of the tester, who most probably got to this specific Job as a stepping stone into a more “profitable and exciting” career, and with whom we have only a small window of opportunity to show him the real difficulty, dept and challenges hiding under the responsibilities of a QA Engineer.

I will concentrate on the training I believe should be transmitted during the first year of work, and at the end I will also mention a few thoughts about the follow-up processes for later years.

How to train?
I believe the best way to get someone up and running is by mentoring; this is the fastest & most effective way for a rookie engineer to get a good start. Mentoring also allows the person to learn in his own pace, to ask question and to see the more dynamic side of the Testing Work.

I have 3 recommendations around this method:
1. Implement a mentoring rotation, having your rookie engineer working for some time with different testers performing different tasks. This way he will get to see more aspects of the testing work.
2. Make sure the mentors know what they are doing. You don’t want to create the wrong impression by matching a new engineer with someone who either does not know how to communicate his knowledge and/or for some reason cannot invest the required time on his “student”.
3. Even if you implement a mentoring rotation, define a Senior Engineer as the principal mentor (or Big Brother) of the Rookie for the first year in the organization.

One-on-One mentoring is a good first step, and it serves mainly for the introductory part of the capacitation. After 3 to 4 weeks it is good to let the tester start working on real projects by himself (still under the supervision and help of both his mentor and his manager).
He should work on 2 to 3 projects (and around 12 months) “getting his hands dirty” both on the product and the testing before moving forward.

What to train?
Think about it, what makes a good Tester…?
I wish there was a way to teach common sense, but I guess that this is something to filter out during the interview process before the hiring.

Leaving my sarcasm aside, for now, there are at least 3 different aspects I think are essential for every starting engineer:

1. The Application Under Test (AUT)
By this I don’t mean only the system that he will be working on, but all the information needed to do a good testing job.

To name a few, the things I recommend reviewing are:
> Application History & Evolution – what brought the system to be what it is today?
> Company Culture & Values – what brings customers back to our product instead of going to the competition?
> Competitive Landscape – what’s the alternative to our product, where are they stronger, how is the market shifting, and what are we making to be ahead of the curve?
> Installation & User profiles – who uses our application, what characterizes our customers and their Organizations?

2. Testing Methodologies
This is the Strategic Part of the testing process.
How do you plan a testing project, what should be tested and how, what are the considerations when planning and specially when taking risks, etc.

The idea is not to have your rookie engineer plan his own testing projects up front, but he should understand the reasons for the operations he is performing.
Assuming the person you hired has enough common sense he will work better if he understands how his individual efforts fit into the complete scope of things.

3. Testing Tools (and I am not talking about QuickTest or Robot!)
You want your engineer to start working as soon as possible, so make sure he knows what he is expected to do and how. There are 2 types of tools, technological & methodological, and you should make sure he feels comfortable with both.

It is not logical or practical to try and teach all the tools at once, but as part of his mentoring rotation your engineer should get to know at least 3 to 4 of each relevant type.

I recommend also making sure that even if someone was hired to do a very specific type of testing (let’s say stress testing using LoadRunner for example), during his initial weeks in the Company he will get to know the other types of testing done, since this will give him the perspective needed later in his project.

Follow-up training and certifications
Just for the sake of transparency I am ISTQB CTFL and a member of the ITCB Advisory Board, but my views on formal training and certifications where made up some years before I even though of getting certified.

I think formal training for a Rookie is almost a complete waste of time. Without enough experience it is very difficult to understand why we need all the tools, what are the advantages and disadvantages of each, and most importantly when should we use one instead of the other.
This view goes both for testers who want to start their career by working with an automation (functional, API or load) tool as well as those going for certifications before having at least a solid year of manual testing experience.

Training (and here I include certifications, hoping no one does the exams just to have a diploma hanging on their walls) are an essential part of a testing career path. As an engineer starts working, he will understand what are his strong and weak points and that way he should decide what path does he want his career to take.

I will stop this point here, and probably re-take it on a future post…

Bottom Line
If you want to have good testers you have 2 alternatives, recruit people already with experience or recruit people with potential and invest on them in order to help them grow into good Test Engineers.

Training is a project on itself; it needs to be planned, executed, measured, reviewed and improved.

The worst mistake you can make when recruiting a new engineer is to let him sit on his desk and expect him to start testing without any guidance or training. It is the same as buying expensive cooking materials and placing them in the table to be eaten as-is; materials are a critical part of cooking, but not less important is how you cook and prepare them.

About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.

6 Responses to How should we train our starting testers?

  1. Anonymous July 11, 2008 at 5:06 pm #

    Dear Joel,
    While I fully agree with the need for a mentor, there are few points you either neglected, or I disagree with.

    1. Background knowledge – One should have some of that, before starting hands-on with the mentor.
    I truly dislike the way some companies give a pile of papers, and sends you for a 2 week reading journey.
    What I found quite useful for most, was Technical video presentations recording – and NO – don’t invite a cameraman yet…
    I think the best technical knowledge in a company main domain normally resides within the company !
    By asking key people to record their knowledge, as a predefined process, while 1st making a PPT Presentation, then reviewing it, and finally recording it from the comfort of one’s desk using a Screen video capture application, one can make a professional video, taking much less then an outside course, as well as much less then asking that expert to pass a presentation every 2 weeks for newcomers.
    I tend to attach a minimal set of the presentation slides, including NO Text slides, but only main drawings and key issues one might want to refresh on later on (as one will not go over the whole video again just to refresh knowledge)
    This works well for both in-house as well as remote activities resources training.
    And costs much less then other options.

    2. I do not agree to your opinion regarding certifications, or at least attending a basic course, as not useful for a newcomer.
    I think a basic course sets the base knowledge of a newcomer, as well as his lexicon of terms and is really important.
    He might not be able to use those yet, but he knows those methods or tools exist, in case he later needs them.
    A 4-5 day basic course is just right for that stage.
    At least regarding Basic QA course, having that after a year as you suggest, mostly proves as a waste of time, as people already gathered most of the knowledge (or bits of pieces of it) by themselves.

    3. One should have a tutoring plan ready made, reducing the parts a newcomer already know.
    As tutoring as you suggested is unpredictable, I prefer building a predefined Hands-On practice sets, where targets are known and meet with just the right amount of time needed.
    It is normally preceded by a short introduction to the tool by the tutor with most knowledge in this domain, then the newcomer get a task, which he needs to complete, while having to handle the tool by himself – if he needs help, the tutor can guide him with explanations, BUT STAY AWAY from mouse & keyboard.

    4. As we complete those, then we move into open mentoring as you have suggested.
    Here I fully agree with your idea of sampling several topics and tutors.
    One buy-in from this process, is that tutoring a newcomer makes the final stage of of a newcomer training (that sentence might be confusing…)
    By having to explain something to someone else, one retain and purify his knowledge of the topic.
    Thus the tutor gain as much as the newcomer.

    —————-
    Kobi Halperin

  2. Anonymous July 11, 2008 at 5:21 pm #

    Tips & Tricks instead of a full course.
    +++++++++++++++++++++++++++++

    I was amazed to find out, how little some professionals know about basic tools such as MS-Word or Excel (not to mention MS-Project, Visio etc.).
    It first hit me when I was tutoring my group regarding the structure of our documents, while I was stopped every 2 minutes, and asked “Hey, how did you just did that?”

    Now – I do not suggest to go 15 years back, to the time one would undergo a detailed basics course of such tools.
    I assume every technical professional knows how to handle the menu bar, format a text, and such basics.
    But I do think one should undergo a periodical Tips & Tricks training showing the powers of these tools (and others).
    This can be a 4-8 hours of training, but this is on high need.

    —————————
    Kobi Halperin

  3. Anonymous July 11, 2008 at 5:33 pm #

    Another major tool for every tester, is sharpening communication skills.
    This is something which only started getting credit in last 2-3 years,
    I do not mean those basic speaking or writing skills,
    A major part of our work, is based on our ability to understand the underlying intentions of the one we speak with, to query a bit more in order to squeeze the last bit of information (and not take his first answer as final & complete), to listen to a discussion and identify the fact that those 2 people are not in-line with each other, that there is a basic misunderstanding (or miscommunication) which blocks them from truly understand each other, while they feel they do understand each others intention.
    such a thing may raise in a review a hidden bug waiting to be made.

    Apart for experience, and view the alders ( 🙂 ) sort of a way, I have no suggestions of how to train someone for these issues – but this is a very important part of our work, while trying to reduce amount of bugs being created, and investigating the background for our test procedures.

    ————————-
    Kobi Halperin

  4. Joel Montvelisky July 11, 2008 at 8:54 pm #

    Hi Kobi,

    Maybe is my upbringing and background with informal education but I tend to give more credit to the things we can learn from a mentor up front. Having said that your idea of the videos with the principal information sounds both effective & efficient from the side of the newcomer tester, although I imagine it requires a company of a specific size in order to be cost-effective, still a good idea to implement if possible.

    Regarding formal certification and advanced testing training, I hear your point but my experience tells me otherwise. I don’t think we need a long course to teach regular manual testing (that is part of what a professional testing mentor should communicate), and I think that you need some miles under the chassis in order to appreciate more complex tools such as equivalent partitioning; still your opinion (based on your professional experience) is valid and I respect it.

    Lastly, I totally agree with the need to teach communication skills, and sometimes we should not be ashamed to reinforce written and verbal English when needed – they are a tool that some of our employees may need to acquire in the same way we teach them QTP or WR.

    Cheers!

    -joel

  5. Anonymous July 12, 2008 at 11:33 pm #

    Small clarification regarding the Video Trainings.

    Though I noted this issue, I didn’t quite explain all the reasons behind it…
    After trying both recording on the PC, as well as Video recording using a video-cam, I strongly suggest to go with the first.

    In most technical presentations, it is more important to hear a quality sound, and mainly get a high quality view of the screen – showing the presentation text & drawings, then to view the presenter himself (though it has some anti snoring effect :-), while also making the eyes more tiered ).
    When we use video-cam, normally we get low quality of the presentation, as this is presented with medium quality projectors, and then recorded by the video-cam from a distance.
    The presenter tends to hide some of the presentation while going back & forth in-front of it.
    And the sound quality is normally low, due to the distance of the microphone (though this can be handled with proper equipment).
    If no other choice but to record a live presentation using video-cam, OK, but the outcome will be with less quality, and normally side questions will be almost mute, so presenter should take the time to repeat each question before answering.
    In PC screen recording, one gets the best quality of the presentation, sound differ by the quality of the Mic.
    If one wants to add the presenter, he can do it by using a web-cam screen at one of the corners (I would suggest to have the coming for short intervals, just to keep the interest).

    As to the comment regarding being able to have those just from a certain company size – I hardly agree.
    Even a start-up, growing out from the core founders, has to recruit several developers, 1-2 sales persons, and hopefully more then 1 QA person.
    They also need to explain their product to customers to some extent.
    By having the CTO, spend up to 2-3 days preparing (Cut & paste the main drawings from brochures & standards)the basic presentations as well as recording & cutting out redundant footage – they gain a full training program which will last for most of future employees.
    And yes, I am aware that most don’t do that – but I think it’s a small effort which pays quite fast.
    It also gives a professional image for the company, when potential customers can view some of these presentations on the company site.

    —————–
    Kobi Halperin

  6. Joel Montvelisky July 13, 2008 at 6:40 pm #

    Hi Kobi,

    I think I missed the part of making this a desktop recording session, I was under the impression you meant a video recording (I used to work in a place where we did the second…)

    Now it makes a lot more sense & I think it is a great (and reasonably inexpensive) idea.

    Good Tip!

    -joel

Leave a Reply