I recently found myself in a very unique situation of mentoring/doing a hand over to 3 different testers across different levels of experience and testing types. Let me explain 🙂
The time has come to change the project/domain I have worked on for the past 5 years. The reason for the change was mostly due to the fact that I was given an opportunity to now work on a brand new system that would be replacing one of the main enterprise systems at the company I work for. What a great challenge to start afresh on a system from the bottom-up.
Due to the future change of this existing legacy enterprise system there was quite a major reshuffle with personnel across the team, as many sub-teams formed as part of this change.
I found myself in a situation (along with another tester within the domain) to train and mentor 3 new testers. 1 an External Automation Tester with the chosen Testing Tool experience but no domain knowledge, the 2nd a Junior Test Analyst who would now be moving into the most Senior Test Analyst in that team, so she had some business and testing knowledge but needed more ‘Senior Testing’ related knowledge transfer and 3rd a brand new tester from the business, a person who understood business process well but was totally new to testing and the IT world. So you should be able to gather that this would require 3 very different approaches at a different pace.
Let me give a brief rundown of my experience and approach during this exercise
The Automation Tester
Since I am an Automation Test Analyst, let me start with the Automation Tester and that knowledge transfer. When we first found out that we needed to hire an Automation Tester to take over my current scripts, we were faced with a few important questions some of which included:- hiring internally vs externally, tool specific experience, system under test past experience, domain knowledge, contractor vs permanent.
We finally decided to go for a tool specific, system/technology experienced contractor Automation Tester :-)…that’s a mouthful (the rationale behind the questions and the decision deserves another blog post on its own, so I won’t go into that detail now)
So the challenge in this approach was more the Automation tester just understanding the domain, processes and current scripts. That was how I approached that knowledge transfer- focused and only passing on relevant info. I began the process by taking her through the key business functionality as it was critical that she understood what our user objectives were before she looked at the scripts. The process went quite well but I found myself dropping that technical hat and speaking user language instead. Just so that she had the full picture of their world. That was the key aspect of this knowledge transfer. The next step which was vital was taking her through our Test Environments and its rules, then followed by our sprint and release processes.
It was only then that I felt that Automation scripts and its coverage will make sense to her in order to add immediate value thereafter. I proceeded to take her through our Automation Coverage, Execution process and what still needs to be covered via Automation.
the outcome (present day)
1 month later and I can safely report back that she has immersed herself quite well into the team. She approaches me occasionally just for a few questions/ideas which I welcome. She is now maintaining, executing current scripts and also starting to create brand new scripts based on latest functionality.
The Junior Test Analyst>Intermediate Test Analyst
The next knowledge transfer/mentor task was a little tricky. This was someone who originally transferred from business into a sort of Junior Test Analyst role/support.
So someone who knows the IT world and its process, along with the business knowledge- however she needed a bit more senior testing related ammunition. So I approached this once again by doing a custom handover. Just discussing and passing over knowledge in terms of Risk identification and logging, Integration and End to End testing co-ordination with other domains and all those other fun more experienced related Testing stuff.
the outcome (present day)
She has already seen through 1 successful release as the main tester, and attended all the cross-team sessions. I am confident that this approach was the correct approach in getting her on her way to making the next step in her testing career.
The business consultant>Test analyst
The final knowledge transfer task was another different approach. So here we had someone who had quite a few years business related experience, but little to no IT, Software process and Testing experience.
So I didn’t have to do the domain transfer here, but rather had to paint the full Software Delivery process from scratch, the Agile world, Test Environments, System overview along with integration points, Test Case creation from specs and other Testing tasks.
This was a full on 3-4 hour a day, 2 week crash course 🙂 I was aware that the pace had to be much slower in this transfer as the lingo and terms used was not something that he used to as he was exposed to more business related language daily. It was a whole new world for him and I was patient in explaining and handing over.
He had tons of valid questions to ask which made me believe that we had chosen the right guy to challenge thinking and break systems 🙂 that’s what tester do after all!
the outcome (present day)
He has created his own test logs and test cases for the upcoming release and has run them by me for a review, which I am glad to do until he is comfortable with these tasks.
He has that inquiring mind and gives me comfort in believing that we now have found the correct combination to keep the current team performing at a decent rate with quality intact
In my post above I basically eluded to that fact that for knowledge transfer and mentor-ship to be successful you would need to understand your recipient and custom make the handover process. Its not a one size fits all in my books. Give people only what they need, to keep them engaged and asking the right questions.
So far this strategy has worked for me, and is only 3 examples of testers I have handed over to or mentored over the years. Hopefully the others who I have mentored/coached over the years are reading this and can attest to this method (or madness) 🙂