 |
Home > Detail: The Test Manager's Vade Mecum
| A StickyMinds.com Original |
|  | |
The Test Manager's Vade Mecum
By Fiona Charles
   
Summary: 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 week's 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.
The next most important item is my "handbook," a CD with a compendium of useful information and tools. It has two main sections: a Toolkit containing all the successful templates and sample processes I've developed and refined over the years and my Watchlist, an expanded and synthesized version of all the learnings I've compiled from projects I've worked on.
There are different Toolkit and Watchlist items for delivery and consulting projects. Toolkit contents vary from big things, like my template for a test strategy and high-level plan, to small things, like contact numbers for my favorite contract testers and Web links to useful resources.
Reviewing the handbook CD for this column, I was surprised to see how much is on it. Here's a partial list of items from my Toolkit for software development delivery projects:
- Templates for:
- System risk assessment
- Test data strategy and plans
- Test execution plans
- Test cases of various kinds, including spreadsheets with built-in calculations
- Testing budget, with sample categories
- Testing project plan, with sample activities and tasks
- Testing project risks and issues logs
- Status reports for different purposes
- Phase-end or project wrap-up reports
- Test team action list
- Tester question list to post online
- Samples of:
- GUI checklists
- Spreadsheets for planning and tracking
- Hiring interview questions
- Testing term definitions
- Field customization list for bug tracking systems
- Defect management processes for single-system and multi-system tests
- Planning/strategy considerations for UAT testing
- System risk assessment workshop process
- Phase and project acceptance criteria
- Descriptions of testing roles and responsibilities
Both the Watchlist and Toolkit are continually growing because I almost never do anything exactly the same way twice. After each project, I go through a debriefing exercise, asking myself what I did differently this time around and what I learned. I think about any new templates, spreadsheets, or processes I developed, or substantial alterations I made to existing ones. I reconstruct any I found useful and add them to my Toolkit, often making additional refinements in the process. For the Watchlist, I review the learnings I noted and synthesize the new notes with the existing ones. I ask what worked best on this project and what didn't work at all. What new things did I try, and how successful were they? What mistakes did I make? How could I avoid them in future? When I'm done, I cut a new CD and back it up.
These aren't the only tools that go with me. Because I work on customers' premises and it can be time-consuming to get basic office supplies, I bring my own pens, whiteboard markers, multi-colored highlighters, sticky notes, scissors, glue stick, and stapler. I often take useful and interesting books to keep on my desk and share with my team and others, and I always have a digital camera to capture whiteboard sessions or oddities like cash register screens.
The really essential elements of the Test Manager's Vade Mecum are my notebook, Toolkit, and Watchlist. These give me a head start on every project.
About the Author
Fiona Charles is a Toronto-based test consultant and manager with thirty years of experience in software development and integration projects. Through her company, Quality Intelligence, Inc., she works with clients in diverse industries to design and implement pragmatic test and test management practices that match their unique business challenges. Contact Fiona via her Web site at www.quality-intelligence.com.
Back to Top
StickyMinds.com Weekly Column From 8/4/2008
|
