ToPing in Testing

Some people might know that my biggest hobby is 'being a Casualty Simulation Victim' and since it's basically 'testing' Medical staff (and other first responders) I had the opportunity to extract some very valuable lessons from the Casualty Simulation scene to use in my work as Software Tester. This is a more comprehensive description of one of those lessons so that you might benefit from it; it's called the Time Out Protocol, or ToP in short.

Let me explain where it comes from. In a hospital somewhere in the world, eye surgery was performed numerous times a year. At that time a switch was made at a rate of nine times per year. You read it correctly: nine times a year the left eye was operated on while it should have been the right one (or vice versa). The hospital started an investigation in which one of the findings was that the most risk was run when transferring the patient from one discipline to the next. They implemented a check-list with short, simple questions, which had to be answered by - for example- the physician that transferred the patient to the OR personnel just before the patient went into the operating room in presence of this patient and with the patient still conscience. The questions where - among others- 'name of patient', 'date of birth', 'which eye?', 'diagnosis' and 'allergies?'. You can imagine that when you hear 'left' in stead of 'right' in this transfer, that you as patient will respond 'wait a minute!; it should be right!'. After implementing this check-list only one switch was made every two years. When they investigated the cause of this switch, it proved that the protocol was not used.

The check-list was adopted by numerous hospitals after the success in the first. Although useful in all situations within the treatment chain, it seemed especially useful in emergency situations.
When checking into this particular aspect; there seemed to be a correlation between the stress levels and things you might forget in those situations; the check-list provided a moment rest to clear the minds of the medical staff, facilitated the ability to take a moment to create a bird-eye view and (using a second check-list with specific steps for that particular emergency) provide a checkpoint to verify that every possible action was taken to treat the patient. The check-list was named 'Time Out Protocol', using it only takes a minute tops. Now, a minute may seem long in an emergency situation, but the minute used to elaborate on things is earned back many times over when thinking of the harm that could have be done to the patient when something was forgotten in the treatment...

During one of the first emergency drills I participated in, I saw this check-list being used and I was impressed by the effect it had in the room and with the medical staff; it really was a moment of calmness and retrospective and provided a very clear to-do-next list of activities. I couldn't help but wonder if the same kind of 'protocol' could be used within my work as software tester. I took a copy of the Time Out Protocol, in short: ToP and looked carefully at the questions on it.
It seemed that there were some generic questions on the list, that apply to each situation when handling a patient, and there were very specific questions on the list, which only apply to the discipline using it. One of the conclusions I made from this, is that a ToP is at one side a specific list for a specific situation (and might even apply to a specific time and place). In the original ToP I brought with me, the questions are applicable for all patients coming in that particular department of the hospital and the list has now been in use for some time now, so, on the other side the ToP generic enough to be beneficial for a longer period of time.

In Software testing I made an analogy with the ToP with project level, because at that time the unit to be the most practical for a ToP was at project level. I can imagine that different ToPs are possible; in smaller project a 'project level' would do for example, but in SCRUM a 'sprint' or 'release' based one could be beneficial (maybe 'sprint' is even a bit too small a unit, to make a generic one every 2-4 weeks, so that could be a list which would contain a lot of 'generic' questions and some changeable ones for that sprint), in larger projects (waterfall type) one can think of test level ToP's etc. The main thing is that the list will contain questions that will make you think about the common things (that you might easily forget otherwise) and important 'really not to forget' things, that are applicable for your work for a longer period of time (specific unit of work/ project etc.) so you should choose a wise unit of 'measurement'.

I took my time to design questions that would benefit me most with my work. I remember having some thoughts about the items in my 'to-do' list or 'remember-to' list every time I was in my car (or train) back home and thought they would be excellent items on my ToP, since if I put them on my check-list, I wouldn't have to 'keep it in my head' al the time. I also thought of typical questions related to testing which seemed to be generic for most of my projects. I thought about the very common things that seemed so obvious and basic in my mind and marked them specifically (those are typically the questions that contain the most risk of be forgotten!) and last I wrote down some keywords of things that were crucial to the project and really not to be forgotten (the things that keep buzzing in your head - a bit the same as the 'remember-to' things). In short, these are categories of questions you should have on your list:

1. Questions regarding items that keep busying your mind (to-do's / remember-to's)
2. Questions related to the things that seem TOO obvious or simple to you
3. Questions regarding the success of the (testing) project (crucial factors)

For an example I will share some of my questions on my list for the project at that time (waterfall type project):

• What's the name of the (part of) the system I have under test?
• Which version(s) of the system do I have/ must I have under test?
• Is the test environment loaded with the correct version?
• Is the test environment loaded with the correct data?
• Does the test environment need any connections to outside systems?
• Are the connections to outside systems operational or is there a stub in place? (which are they?)
• Are the correct user(s) defined and do they have the correct roles and authorizations?
• Which date is the cut-off date for bug reporting
• Which stakeholders are involved?
• Are the stakeholders informed?
• Do I have enough input for the testers to do their execution?
• Are all the tools in place and do the users have the authorisations needed?
• Are there known defect(s) that should be mentioned?

For a SCRUM-type list I can imagine you'd have something of 'what user stories are to be covered' on the list and it even could be as simple (in waterfall type projects) as 'which test level am I testing on?.

The TimeOutProtocol is a check-list that will, when used daily, create a moment where you can step back from the busy work schedule, reflect on the work you are doing and let you focus on the things that you should have been doing. The 'ideal' ToP will not take a half hour to run through all the points, but will take a maximum of 2 minutes to complete. Questions you can't answer should be written down an found out after the use of the ToP (when already applicable of course).

It's not just for management (as the example list I showed you earlier might imply) but for all expertises in a project (a test analyst might have questions as: 'which version am I testing on', 'do I have the right authorisation(s) to do my tests?' and 'which functionality did I cover?'). YOUR TimeOutProtocol can't be written by your manager, (s)he might have a ToP with questions that you CAN use, but the checkpoints are still the questions (S)HE would like to have answered.
YOUR TImeOutProtocol is a list that will benefit YOU and YOU are thus the person that should design the questions on the list that will benefit YOU and YOUR WORK (although it could be beneficial to let somebody review your list so (s)he might have extra suggestions (especially those things that are TOO obvious and might not be on your list, although important). It also might be a good idea / suggestions to share the different ToP's that are made by your fellow-projectmembers or even a colleague tester from an entirely different organization; it will probably inspire to add or sharpen questions that might benefit you.

Well. That's it about the TimeOutProtocol. I hope you find it a useful tool to use in your daily work and if you want or can (mind the questions that might be under NDA's!), I would appreciate it if you'd like to share your ToP or comments/ suggestions to ToP's as a comment to this post, so more testers might benefit from the things you have on your list.