Testers and test managers who come equipped with their own practices and tools can save time and effort and get a head start on their projects. In this column, test manager and consultant Fiona Charles describes the "go with me" collection she has built over many years and projects to help leverage her varied experience and provide a quick start on new deliverables.
As a tester or test manager, do you have an essential set of tools you take with you to new projects? Whenever I join a project I take with me the collection of low-tech tools I've designed and assembled to help me manage testing. It's tremendously useful to have at hand templates, spreadsheets, and practices that have worked for me in the past, to remind me of what's important and to get a head start on the work. Even when my client has standardized deliverables, I treat my own tools as checklists to supplement their templates, if necessary, with information I consider essential.
I call this collection my Test Manager's Vade Mecum, from a Latin phrase whose literal meaning is "go with me." The Random House Unabridged Dictionary (1997) defines it thus:
- Something a person carries about for frequent or regular use.
- A book for ready reference; manual; handbook.
This comprises a perfect description of my Vade Mecum.
The core tool is my notebook, new for each project. I carry my notebook everywhere I go when working on a project, so I buy a robust, eight-and-a-half-by-eleven, sewn book with square-ruled pages. I take time to set it up, pasting my business card and a calendar into the front end pages and a plastic envelope for the ever-changing phone and email list into the back end pages. That said, a glue stick is another essential tool!
I start entering notes as soon as it's clear I'm going to be on a project, even retroactively copying in notes from preliminary conversations with the client. All my notes of meetings, informal conversations, and hiring interviews go in, with the dates and participants and a clear termination line so I know when reading where one set of notes ends and the next begins. I record and date quiet-thinking sessions, flagging them with a little cloud drawing to distinguish them from meetings. I flag to-dos with a star. I try to review the most recent pages regularly for to-dos and check off the done or no-longer relevant ones. I then transfer these to-do items to a team action list.
Diagrams go in my notebook—sometimes hand-drawn, sometimes pasted in. I note whom I got a diagram from or developed it with and when. I save some pages at the back for really significant diagrams, like the system or test architecture, on the premise that I'll need to refer to them often or pull them out in meetings.
I note important voicemails but don't include copies of emails. Those I file electronically, although I do often note the date, recipient, and subject of important emails I've sent. Of course, doodles go in, too.
I keep a big chunk of pages near the back for recording lessons learned, and jot things down by the date whenever I think of them—with no attempt to edit or sort. Learnings can include anything I did or observed that worked well, things that were less effective, or failed experiments—whatever occurs to me. In cases where I expect to leave the project notebook with the client, I capture learnings separately. I also keep a section for recording key project decisions and significant events, with dates and participants. This habit has often proven useful on troubled projects, or projects that later became troubled, to reconstruct the sequence of events for myself and others.
The key point, though, is my notebook's utility as a daily management tool and reference source. I find it invaluable to keep everything important about a project in one place.