2010年10月20日星期三

On Mentoring Software Testing Interns - Clear Assignments










Being software tester for 5 years, I have brought up half a dozen interns. All of them are good kids - smart, passionate for new technique, with not much experience in a real project, and sometimes careless. But the later ones are more productive. The interns join us this year can deliver a tool in a week or two, while it takes the last year's interns almost a month. There are several factors that make this difference, factors that change cross years. And it seems they are all about me.

The first thing makes this difference is about how I assign a task. Take my latest assignment as an example. In my team, we have a set of automated tests currently need an enhancement. I want to assign this to an intern who just get on board for a month.

In the old days, I would book a meeting room for a whole afternoon, introducing and demoing our framework to her. Since our framework is based on an internal automation system, I have to introduce that too. The system is written in TCL, include that too. Then she finds out that our test cases are not in TCL language, oh yeah, we are adapting data driven, then we have to include that concept. It ends up by I talking too much, she writting down too much.


When she gets back, she feels a little bit un-certain about this framework or data driven, so she starts googling and gets lost in the exploding information. A week later, I check on her status. "I'm still having a little trouble with the framework, I see several other framework online, better than ours, easier to understand. Do we have plans to migrate?"

The problem about the old way is huge gap between concept and experience, the gap between knowing and doing. When you are handling a tremendous of information, hundreds of keywords and concepts. Sometimes you just get lost.

What do I do now? I split this assignment in 4 - 5 days. 


  • The first day's like this:
info: internal automation system help page
todo: write a test case in it, execute it, make it pass and fail once


  • The second day:
info: our product document
todo: make it work to add/delete


  • The third day
todo: write a case in automation system to call our product to add/delete


  • The forth day
todo: abstract out of scripts, make it a data copy


  • The fifth day
todo: the enhancement

Within this way, each assignment only takes me 10 minutes to introduce, and 10 minutes to check up. I divide the tasks into several domains where each one is either separate or based on precious one. Then define a clear goal for each domain. A goal like "to get familiar with this automation system" is not clear. She may wander around in the help pages, just try to understand the concept, what schedule is, tasks, test cases, results, log levels, etc. On the other hand, "write a test case, execute it, pass it then fail it" is better. She knows what to look for, and what to accomplish. After doing so, after seeing this thing works, she could just figure it out, this is a job contains test cases, a test case contains several check points. 


With this solid connection between information and experience, she learn much faster by herself, and adapt faster in her next assignment.

3 条评论:

匿名 说...

Which methods to choose should be driven by goal. What's your goal of bringing up an intern? It's not introduced clearly here.

匿名 说...

Devide and conquer, nice practice.

jarodzz 说...

For an intern or any type of employees, I don't see any other goal except for put the kids into work.

Divide and conquer is quite a summary, but the conquer needs to be clear, actionable. It's quite a pity a lot of people end up saying: be a good engineer, understand deeper, but they never say what exactly to do. :)