February 8, 2016 // By Sam Flood
If all of the information from Part 1 sounds like a lot of work, it can be. Bringing a resource onto a long-standing and complex project is a lot of work for a lead. But it doesn’t have to be painful. There are things you can do from day 1 of your project that will make your life much easier on day 278 when you are newly responsible for onboarding a tester.
Much like the Three Keys we talked about, there are 4 tips I can attest to as being effective.
1) Document Early and Often
This comes down to documenting everything from the first day you join the project. Record critical meetings. Track process discussions, and complete the loop by documenting the process flow. Save emails about how the system will or should work. Keep track of those UI Wireframes, or database specification documents. As you learn how to use a testing tool, record a demo. Keep it all, until it goes obsolete or changes (and then—you guessed it—document the new process/change!).
By doing this, you’ll quickly build a repository of items that pertain to all of the Three Keys You’ll have recorded your project processes and will easily be able to share them (and will have the secondary bonus of having a reference document if you need to correct other people during the project). You’ll have documentation on how to use your most critical testing tools. And you’ll have lots of domain documents that will help your new resource understand the project at its current state.
Do pay attention to matching the tool you use for documentation to the type of documentation. Visio or PowerPoint work great for documenting process. Email or a voice recording (unless a specifically designed presentation) are less effective. Excel is great for storing lists. Word can be fantastic for detailed instructions.
One final note: Keep this documentation organized! You won’t make your life much easier if you throw everything in a single folder on your desktop and wait until 9 months later when you need to actually figure out what’s relevant, what’s obsolete, and where everything is.
2) Store Everything in a Shared Space
Because you’re already documenting everything, this should be easy, and is a logical next step to make your life easier: You already need an organizational structure (see point 1), and a place to put everything that is shared makes an organizational structure just that much easier!
SharePoint can be a useful tool in this regard, as it allows any authorized user to create folders, and upload documents (so you can involve your team in the process of documenting everything and don’t have to do it all yourself). Wiki-sites are another way to do this which is shared and where the work can be crowd-sourced.
Whatever the tool you use, the idea is to provide a shared space, where you can organize and store both project domain information and process information. You may also use this space for status reporting, a forum for questions, etc. It does take some up-front work to setup, but having it can be a major time-saver for you as a lead.
Mentorship comes in two forms. Firstly, you need to be available for your new resource and must maintain yourself as a constant source of aid as necessary. Stress repeatedly that they should feel free to ask you questions, come to you if they get stuck, and/or if they need help finding something. Check-in occasionally as well, even if they haven’t come to you first. Secondly, and particularly for larger projects, assigning your new resource a “buddy” or “mentor” can be a time-saving and helpful device. This mentorship relationship can (and for the most part should) be informal. A simple checklist of ‘topics to discuss’ to help the resource may be all that’s needed for the mentor. Of course, as was mentioned last week, how much actual ‘mentoring’ may be needed depends on your new resource. An experienced Test Engineer with 15 years of industry experience will probably not need the same mentorship relationship as a brand new tester out of college who has never written a test case before. Whatever the context, the real payoff for the role comes in giving a structured, accessible relationship for your new resource. They may feel more comfortable coming directly to a ‘mentor’ with questions than they would to a ‘lead’, and they can thus spend less time blocked or stuck on tricky questions and concerns. You may also encourage your mentor to schedule time with the new resource for them to shadow the mentor, in particular watching while core project duties are performed or technical tools are utilized, giving a simple forum for additional questions.
4) Start the onboard early
In some ways this is the easiest part of the whole process to implement. It’s very simple: if you know ahead of time that you’ll be receiving a new team member, don’t wait until their roll-on date to get started in the background work that you’ll need to do for them to be functional resources. While it can be hard to think beyond today’s fire, or tomorrow’s deadline, this will save you time and effort. A week or two in advance, start getting the requisite licenses, logins, database accesses, billing time-buckets, meeting requests, etc. so that when they start, they can really dive into everything with both feet and don’t have to wait half-active while you acquire these necessary items for them.
In conclusion: Onboarding can be hard, especially for a large-scale project in mid-flight. But it doesn’t have to be! By focusing on providing resources with the Tools, Process, and Domain that they need, and by following a few easy steps early in the project—Documenting, Storing, Mentoring, and Starting Early—you can make onboarding almost painless, and much more efficient. In the long run this will save you time (as a lead), will save your project money, and will allow you to deliver better software with higher quality!
If you’d like to contact Magenic, email us or call us at 877-277-1044.