Me too about great testers :)
Submitted by Ainars Galvans on Fri, 16/02/2007 - 18:14.
people issues | perspectives
Steve [link fixed on 02/22/07] is talking about tester’s programming abilities as key aspect and are attacked a lot, although none is against using programming to earn credit as Mike suggests.
I‘m trying suggest there are no key technical skills: great tester is jack-of-all-trades – able to pretend to posses any skill to some degree. Meanwhile John touches psychology while Antony looks at tester from a team perspective rather than skill set. He touches something that I am unable to write too clear about: great tester’s ability to be able to give up his identity and look the world through the ayes of another person – of any person within a team. Let me share a little bit of my own experiences of hiring, training and motivating professional growth for testers.
Skills to look for in novices ?
I’ve been participating tester’s hiring process and seen test leads (next boss for the candidate) asking questions to learn if a candidate (especially those without testing experience) is able/has experience in:
a) reporting technical issue, even using any defect tracking system
b) documenting technical steps – writing test cases
c) the specific programming/scripting language that is used in the project
d) experience in specific tools/technologies they use in their projects (e.g. “do you know how to manager Oracle users”).
e) used to chat (e.g. prefer to use skype over e-mail)
In other words they look for person who will be simple to manage and get up t speed immediately – without any training/guiding on special tools/languages. They never look for person who will be a great tester within a year. One who will be able to find the defects they miss themselves. Never look for a person who could take a lead at improving practices. They look for monkeys, trained monkeys, don’t they?
Training testers?
We well know there are testing hand-books, tester certifications accomplished with few days training, etc. Those do not teach how to use defect tracking system or write a test case. But they don’t tell you how to find defects that non-trained person will not find. How to earn credit, use programming skills, your jack-of-all-trades ability or become a jedi knight of testing. Best to my knowledge the only training initiative aimed at that are led by Cam Kaner and James Bach . If you know of any other, please let me know – I would be happy to learn.
I believe that the best way to train testers is experience. Show them bugs they missed, review their testing ideas, strategies and show what they are doing that are not particularly necessary – having low power/credibility/whatever your goal is. Lead them: show how You earn your credit, what exciting tests/bugs you discover how you communicate with developers and managers. Delegate them everything but slowly. Let them make their mistakes and learn from them. Help them when they ask – find time to do that (I admit I don’t always do that myself, hope to improve on that however).
Performance reviews/professional growth
I’ve seen managers to asses testers by number of bugs they are reporting, test cases they are running per given time period and other stats (cancelled defect rates, etc.).
And then – what are the growth you are able to propose to your team members? Doing more job, writing test cases faster, writing test cases that are easier to read? Not bad as one year goal, but not a goal for whole career. I’ve found a way to allow each member to try out different tasks. For example allow everyone to try out performance testing. Suggest them to learn/practice programming language, participate design reviews, do some presentations, change management, training and leading new colleagues, etc.
Few pool results
Here in Latvia we’ve got yearly testing conference. Last years it seems to be a common practice to have at least one pool presented. I’ve run my own pool asking tester’s what they think are the key skills, but I don’t like to talk about it any more. So let me tell you other pool results: pool on what do we testers like show that we like open communications and prefer them to phone and messaging/chat. E-mail is also accepted. We like to analyze specification and communicate with customers but we don’t like to complement those specifications or write tests without them. Strange, isn’t it? We are ok with preparing test data and communicating test results. Another pool shows that whole team (managers and programmers included) believes we have to learn new stuff fast and be patient at the same time. Do you know what we are? We are compilers or mentats “that can extract the essential patterns or logic of data, and deliver useful conclusions with varying degrees of certainty”. The hesitation to complement missing information ourselves are essential aspect as well – “Mentats cultivate "the naïve mind"”. However we still need a lot of technical skills/knowledge to extract the require information ourselves and to be able to communicate that data out of technical people like developers.
I‘m trying suggest there are no key technical skills: great tester is jack-of-all-trades – able to pretend to posses any skill to some degree. Meanwhile John touches psychology while Antony looks at tester from a team perspective rather than skill set. He touches something that I am unable to write too clear about: great tester’s ability to be able to give up his identity and look the world through the ayes of another person – of any person within a team. Let me share a little bit of my own experiences of hiring, training and motivating professional growth for testers.
Skills to look for in novices ?
I’ve been participating tester’s hiring process and seen test leads (next boss for the candidate) asking questions to learn if a candidate (especially those without testing experience) is able/has experience in:
a) reporting technical issue, even using any defect tracking system
b) documenting technical steps – writing test cases
c) the specific programming/scripting language that is used in the project
d) experience in specific tools/technologies they use in their projects (e.g. “do you know how to manager Oracle users”).
e) used to chat (e.g. prefer to use skype over e-mail)
In other words they look for person who will be simple to manage and get up t speed immediately – without any training/guiding on special tools/languages. They never look for person who will be a great tester within a year. One who will be able to find the defects they miss themselves. Never look for a person who could take a lead at improving practices. They look for monkeys, trained monkeys, don’t they?
Training testers?
We well know there are testing hand-books, tester certifications accomplished with few days training, etc. Those do not teach how to use defect tracking system or write a test case. But they don’t tell you how to find defects that non-trained person will not find. How to earn credit, use programming skills, your jack-of-all-trades ability or become a jedi knight of testing. Best to my knowledge the only training initiative aimed at that are led by Cam Kaner and James Bach . If you know of any other, please let me know – I would be happy to learn.
I believe that the best way to train testers is experience. Show them bugs they missed, review their testing ideas, strategies and show what they are doing that are not particularly necessary – having low power/credibility/whatever your goal is. Lead them: show how You earn your credit, what exciting tests/bugs you discover how you communicate with developers and managers. Delegate them everything but slowly. Let them make their mistakes and learn from them. Help them when they ask – find time to do that (I admit I don’t always do that myself, hope to improve on that however).
Performance reviews/professional growth
I’ve seen managers to asses testers by number of bugs they are reporting, test cases they are running per given time period and other stats (cancelled defect rates, etc.).
And then – what are the growth you are able to propose to your team members? Doing more job, writing test cases faster, writing test cases that are easier to read? Not bad as one year goal, but not a goal for whole career. I’ve found a way to allow each member to try out different tasks. For example allow everyone to try out performance testing. Suggest them to learn/practice programming language, participate design reviews, do some presentations, change management, training and leading new colleagues, etc.
Few pool results
Here in Latvia we’ve got yearly testing conference. Last years it seems to be a common practice to have at least one pool presented. I’ve run my own pool asking tester’s what they think are the key skills, but I don’t like to talk about it any more. So let me tell you other pool results: pool on what do we testers like show that we like open communications and prefer them to phone and messaging/chat. E-mail is also accepted. We like to analyze specification and communicate with customers but we don’t like to complement those specifications or write tests without them. Strange, isn’t it? We are ok with preparing test data and communicating test results. Another pool shows that whole team (managers and programmers included) believes we have to learn new stuff fast and be patient at the same time. Do you know what we are? We are compilers or mentats “that can extract the essential patterns or logic of data, and deliver useful conclusions with varying degrees of certainty”. The hesitation to complement missing information ourselves are essential aspect as well – “Mentats cultivate "the naïve mind"”. However we still need a lot of technical skills/knowledge to extract the require information ourselves and to be able to communicate that data out of technical people like developers.
