The world of testing is
becoming a lot more technical than it once was. While there is still a
need for strong exploratory testing, the need for test automation is
increasing dramatically. Test automation requires programming at some
level. Good test automation requires skilled programmers. Thus the
need for test developers is increasing. As I've said before, learning
to program is hard. As a manager of a team of non-programmers (or
semi-literate programmers), is there a way to train them to become what
you need? Is it better to just go hire programmers and teach them to
test? As I've said elsewhere, I think it is easier to teach a
programmer to test than to teach a tester to program. This post,
however, is about doing just that: developing programmers out of an
intact test team. Here is my advice on how to do that.
First, don't expect everyone to make the transition. For some it will be impossible. For others, there will be little interest. Remember, you still need manual testing. You don't want your whole team to convert. Look for the ones that show interest and aptitude. To find the ones who really show interest, you have to make it clear you don't expect everyone to move. You have to make it clear that this isn't a promotion. If getting promoted (or keeping your job) requires learning programming, everyone will want to.
Provide opportunity to learn. Expecting people to know how to program before you give them the opportunity to do so will guarantee failure. If you only give programming assignments to those who already know how, you won't develop any new programmers. Learning programming on your own time is something only a few will be able to accomplish. It is hard. Instead, find some tools you need written or features you need added to existing tools and offer the chance to work on them. See who grabs the opportunity and push them.
Give them time to learn. Beginning programmers won't be productive. It will take them 10x as long to do something as an experienced coder. That's okay. You have to budget for that time. The payoff will come later. It is important that management guard that time also. I've seen many times when management hands out an opportunity but then quickly piles up the non-programming work so there is no time to learn. If you ask someone to write a tool, make sure they have long, uninterrupted blocks of time to focus on it. As an upper-level manager, hold your leads accountable for providing this time.
Provide mentors. Books and blog posts only cover so much. There are a lot of little details and corner cases they don't discuss. New programmers need someone they can approach to ask questions. Getting stuck on a problem for 2-3 hours is healthy. Being stuck for 2-3 days is discouraging. If you have test-developers on your team, utilize them. If you don't, talk to the dev manager about using his people in this role.
Make it an assignment. Hold the aspiring programmers accountable for their output. Learning to program shouldn't be extra credit. When things get busy, extra credit falls by the wayside. Instead, make it part of their commitments for the period. Discuss the assignment during your 1:1s. If they don't get it done (whatever done means) by review time, hold it against them. It has to be treated like any other assignment. If they didn't get their test pass done, you would care. They need to know you'll care if they don't learn how to program.
Give real assignments. Don't ask them to write something you're going to throw away. Have them working on production code. Pick a simple tool. Better yet, have them augment an existing one. The assignments should also be in the same language as the application. Teaching them to program Visual Basic in Visual Test isn't training them to understand your product. Their utility will be limited if they can't interact with the developers. Finding mentors will also be harder.
Finally, give them an escape hatch. Programming isn't for everyone. If someone determines it isn't for them, let them go back to exploratory testing or whatever they were doing before. Forcing someone to learn something they don't want to is doomed.
http://blogs.msdn.com/b/steverowe/archive/2007/04/26/teaching-your-team-to-program.aspx
First, don't expect everyone to make the transition. For some it will be impossible. For others, there will be little interest. Remember, you still need manual testing. You don't want your whole team to convert. Look for the ones that show interest and aptitude. To find the ones who really show interest, you have to make it clear you don't expect everyone to move. You have to make it clear that this isn't a promotion. If getting promoted (or keeping your job) requires learning programming, everyone will want to.
Provide opportunity to learn. Expecting people to know how to program before you give them the opportunity to do so will guarantee failure. If you only give programming assignments to those who already know how, you won't develop any new programmers. Learning programming on your own time is something only a few will be able to accomplish. It is hard. Instead, find some tools you need written or features you need added to existing tools and offer the chance to work on them. See who grabs the opportunity and push them.
Give them time to learn. Beginning programmers won't be productive. It will take them 10x as long to do something as an experienced coder. That's okay. You have to budget for that time. The payoff will come later. It is important that management guard that time also. I've seen many times when management hands out an opportunity but then quickly piles up the non-programming work so there is no time to learn. If you ask someone to write a tool, make sure they have long, uninterrupted blocks of time to focus on it. As an upper-level manager, hold your leads accountable for providing this time.
Provide mentors. Books and blog posts only cover so much. There are a lot of little details and corner cases they don't discuss. New programmers need someone they can approach to ask questions. Getting stuck on a problem for 2-3 hours is healthy. Being stuck for 2-3 days is discouraging. If you have test-developers on your team, utilize them. If you don't, talk to the dev manager about using his people in this role.
Make it an assignment. Hold the aspiring programmers accountable for their output. Learning to program shouldn't be extra credit. When things get busy, extra credit falls by the wayside. Instead, make it part of their commitments for the period. Discuss the assignment during your 1:1s. If they don't get it done (whatever done means) by review time, hold it against them. It has to be treated like any other assignment. If they didn't get their test pass done, you would care. They need to know you'll care if they don't learn how to program.
Give real assignments. Don't ask them to write something you're going to throw away. Have them working on production code. Pick a simple tool. Better yet, have them augment an existing one. The assignments should also be in the same language as the application. Teaching them to program Visual Basic in Visual Test isn't training them to understand your product. Their utility will be limited if they can't interact with the developers. Finding mentors will also be harder.
Finally, give them an escape hatch. Programming isn't for everyone. If someone determines it isn't for them, let them go back to exploratory testing or whatever they were doing before. Forcing someone to learn something they don't want to is doomed.
http://blogs.msdn.com/b/steverowe/archive/2007/04/26/teaching-your-team-to-program.aspx
No hay comentarios.:
Publicar un comentario