Hello again guys,
I am new in my position as QA Manager and I am currently building the skills and competencies for the QAEngineers based on their level. So Basically what I am asking is that if anyone has some good reference example ? My goal is I wanted to build the team as hybrid where they can both Manual and Automation testing.
And also, I always wanted to fair mostly when it comes to the promotions and evaluations. Thank you in advance.
This is relatively easy if you have an unlimited budget, but it’s much more difficult (and unfair) when you don’t, which is all the time.
Reality sucks
In practice, you have to pay some people as little as possible in order to pay more to the people you are sure will leave if they don’t get a promotion and pay rise (assuming you want to keep them). It sounds horrible, but it’s reality for most of us.
I was on the wrong end of such decisions for most of my life until I started my business. Employers knew I was so dedicated (to the work and the clients, if not to the company) that they could and did promote junior people over my head. I eventually left, but not because of that.
Soft skills
Leaving money and promotions aside, many of the factors you will want to take into account are subjective and some might be showstoppers regardless of a person’s other traits. Examples would include inquisitiveness, tenacity, logical thinking, presentation skills, negotiation skills, assertiveness, interpersonal skills, desire to learn, attention to detail etc. For junior testers (say less than 5 years’ experience) I regard these as more important than technical skills because most cannot be taught.
Team structure
Its unlikely I would build a hybrid team like you suggest, but that is making an assumption about what you mean by manual testing. If you mean writing test scripts or methodically checking that requirements in the backlog are met, I wouldn’t do that at all. You’ve got a serious problem if your developers are turning out code that doesn’t meet such a low requirement, and that needs to be fixed first.
I would employ skilled exploratory testers and skilled automation specialists. These are entirely different skillsets and require entirely different ways of thinking. Extremely few people are skilled at both, and they are very expensive. Each needs to have a good understanding of what the other can and can’t do, and I would expect them to feed ideas into each other and to collaborate.
My experience is that some skilled exploratory testers (like me) have absolutely no interest in automation - if I recognise a need for it I will get someone else to do it. I would not take a job that required me to do it. The reverse is also true - literally everyone we taught to do automation ended up leaving to do a full time automation role elsewhere.
If you’re going to do trivial manual testing (scripts, methodical checking etc.) then you could get your automation people to do that, although they are unnecessarily expensive. You can get people with a year or two’s experience on less than half the salary to do that sort of manual testing (although I wouldn’t do it at all).
I worry about things like competencies and so on for this kind of reason.
If we use them to encourage employees to be better at something they’re missing, then that can be okay, provided they have enough time and enthusiasm to do so. If we use them to judge salaries or titles then it’s hard to evaluate.
I can only imagine it being vague and minimal. Vague so that anyone can have the opportunity for promotion, trying to avoid discriminating against differently competent people, and minimal so that we get the basics of what we need without excluding people who excel in other areas.
I know it can be hard to get what I suppose I’d call deep testers, and certainly not cheap, but I think most people can be trained in the exploratory nature of testing much faster than they can be trained in test case execution and reporting. Provided they are motivated to find problems, of course. I think a good automater is a good tester first (when designing against a strategy rather than supporting someone else’s), but I relate a lot to the upsetting idea that I’d be relegated to development all day.
I don’t have an answer for this, but I’ve always been curious on how it’d work. Especially between levels of the same title, like what makes a tester worth two gold stars instead of one. What we can fairly demand of someone. I’ll keep thinking on it, hoping a later answer will bring enlightenment.
If you’re a QA Manager, you already understand the key differences between junior, mid-level, and senior QA engineers, as well as the technical and soft skills expected at each level, etc. You also know your company’s specific needs, team dynamics, and project realities, so you can determine what skills are most important and what’s nice to have, etc.
Promotion and evaluation should be based on different aspects:
-
- Technical skills
-
- Soft skills
-
- Experience and ownership
-
- Company/team fit
Your evaluation always will be subjective and it’s okay generally speaking but you have to push yourself to maintain objectivity in your judgment. You have to establish clear criteria that your team will understand and accept, and set some goals and expectations, measurable ones but they have to be real not just for the sake of some BS KPIs.
Speaking about promotion, the first thing to figure out is what you really mean by it. Are we talking about a salary raise, changing someone’s level (like from junior to mid-level), or maybe giving them a new title? Or is it more about adding responsibilities, like having them take charge of bigger projects or mentoring others? Define what kind of promotion you’re thinking about and come up with criteria that are suitable for your team and project and budget and other companies policies, it makes it easier to know how to evaluate people and what expectations come with it. It’s not always just about the money or title - it could be about their role growing in different ways. They may see promotions differently than you so you have to sync your views with theirs.
Job titles can be really problematic so we avoid them to a very large extent. All our functional testers had the same job title even though their salaries varied by as much as £25k and experience varied by as much as 30 years. We don’t have those roles now, and we only have two job titles - Accessibility Consultant for people with 10+ years’ experience and Principal Accessibility Consultant for people with 20+ years’ experience.
It’s the same with pay scales. I understand why large companies have to have them, but in a small company you need the flexibility to negotiate with each person unless you are so profitable you don’t have to worry about paying someone more than you need or ought to.
An employee’s performance depends on dozens of parameters, most of which cannot be measured or assessed objectively, so you can’t sensibly reduce it to a number of stars or a job title. Even if you somehow reduce it to a single dimension (e.g. how much you value a person overall), it’s a continuous spectrum.
In practice, it’s a lot more unscientific than most employees would hope and most managers would admit. But so are most other aspects of running a business.
Hi, make sure you involve your engineers in building this so that they buy into it. You will have your own ideas but learn from them as well.
@ross - It’s certainly not easy but building a hybrid Test/QA team is exactly what I have done in my last two roles. Budget constraints in both a smaller private sector company and now a Public sector government agency essentially have meant this approach was a necessity. But actually, having a team of testers who have a broad range of testing skills or “strings to their bow” is no bad thing at all.
At the base, there needs to be an aptitude, a spark, an urge to investigate things. After that, what people don’t know, well… they can be taught to a large degree.
In general, it’s all about the value someone adds. X years’ experience doing essentially the same type of testing means less to me than someone who has had less time in any job but has had exposure to lots of different types of testing.
I prefer a “jack of all trades” over than having a team of individual Subject Matter Experts. Yeah, there may be times where specialist expertise is needed for any given project but I tend not to like backing myself into a corner with single points of failure. E.g. If your dedicated Automation resource goes off long term ill and there is no budget to bring in a contract resource then your project could be severely hampered. Being able to hot swap existing resource is very important to me, right now.
I’ve always found that a hybrid tester approach can often more easily shape your team’s Personal Development Plan. This, in turn, will help give weight to any argument that someone is in line for a promotion of any sort. What more can they do now? i.e. what value do they add?
As stated above, job titles are tricky. Some folk crave a new title, some simply crave more money. It was MoT that taught me that job titles don’t matter… e.g. the whole “Boss Boss” concept
Promotions should be based on what someone can now do OR something they have done recently that deserves reward. Promotions should not be based the number of years a person has been in a role - this horrid sense of entitlement should be guarded against as it promotes laziness in the ranks. Beware!
At the end of the day your hands may simply be tied if there is no budget to allow a promotion and you may run the risk of some team members moving on as a result. This can’t be avoided I’m afraid, but you should see this as a personal challenge, to develop the next person that comes in, the next hybrid tester, giving them the opportunity to learn new skills and add value. It can be tough but equally rewarding.
Good luck with your new team.