Topic: Making Test Plans

Message

Making Test Plans Airtight

        Here are a couple tips for making sure you cross all the t's and dot all the i's in your test plan. The best strategy, however, is not in document preparation, but in the planning itself. If you've made your testing methodology airtight, your test plan will follow.
Save the Script for Last

        Before digging into the script details, you should make sure the test's objectives and logistics are more or less nailed down. By saving detailed script development until after these other pieces are in place, you ensure that your work on the script is compatible with the test objectives and with the methodology. For example, if you're conducting a test on a semifunctional prototype, that may limit the number and type of questions you'll ask participants. If you do not have the time, budget, or personnel to develop the prototype further, those facts will establish boundaries for the tasks participants can perform.
Format the Document Appropriately

        Consider how the facilitator will use the actual document during the test. Even if the sessions are being recorded, for example, the facilitator may want to take notes on the script itself. Different facilitators have different preferences, so ask yours what he or she wants. (If you are the facilitator, make sure no one catches you talking to yourself.) A document designed to be a note-taking tool will look different than one that's simply a series of prompts. If the test includes pre- and post-test questions for participants to answer on their own, perhaps these can appear on separate pages so they can be easily removed and distributed.

Risks in Creating Test Plans

        When putting your test plan together, you may run into a couple different obstacles. Realizing these shortcomings during the test itself is way too late, so you'll want to diagnose and mitigate these risks as early as possible.
Incomplete Script

        A script can be incomplete for any number of reasons: The read-aloud part does not adequately describe the scenario, the expected behaviors aren't explicit, there are crucial scenarios missing. The single best remedy for these problems is to conduct a dry run, which takes the usability test out of the abstract and into the real. Anything missing from the plan appears quite starkly when in the thick of a test. If you don't have time to test the test, as it were, you can also cross reference the script with the user profiles to identify potential holes in the scenarios. You can do a cheap version of the dry run by reading the scenarios aloud to colleagues and seeing if they understand them. A set of expected behaviors is simply a set of instructions for doing a particular activity on the web site. Hand someone the list of expected behaviors for a scenario and see if they can follow it to the goal. These are low-impact ways to diagnose potential holes in the script.
Document Unusable for Testing

        It's one thing to review a test plan in a meeting and quite another to bring it into a testing situation. The content of the document may work, but the formatting may not be appropriate for use during an actual test. Again, the best way to mitigate this risk is to do a dry run of the test. By putting everyone (the facilitators and note-takers) and everything (the web site or prototype and the test plan) through its paces, you can establish whether the document format is suitable.

Author	Message
Amrita Groupie Joined: 13Feb2007 Online Status: Offline Posts: 57	Topic: Making Test Plans Posted: 19Feb2007 at 2:21pm
	Making Test Plans Airtight Here are a couple tips for making sure you cross all the t's and dot all the i's in your test plan. The best strategy, however, is not in document preparation, but in the planning itself. If you've made your testing methodology airtight, your test plan will follow. Save the Script for Last Before digging into the script details, you should make sure the test's objectives and logistics are more or less nailed down. By saving detailed script development until after these other pieces are in place, you ensure that your work on the script is compatible with the test objectives and with the methodology. For example, if you're conducting a test on a semifunctional prototype, that may limit the number and type of questions you'll ask participants. If you do not have the time, budget, or personnel to develop the prototype further, those facts will establish boundaries for the tasks participants can perform. Format the Document Appropriately Consider how the facilitator will use the actual document during the test. Even if the sessions are being recorded, for example, the facilitator may want to take notes on the script itself. Different facilitators have different preferences, so ask yours what he or she wants. (If you are the facilitator, make sure no one catches you talking to yourself.) A document designed to be a note-taking tool will look different than one that's simply a series of prompts. If the test includes pre- and post-test questions for participants to answer on their own, perhaps these can appear on separate pages so they can be easily removed and distributed. Risks in Creating Test Plans When putting your test plan together, you may run into a couple different obstacles. Realizing these shortcomings during the test itself is way too late, so you'll want to diagnose and mitigate these risks as early as possible. Incomplete Script A script can be incomplete for any number of reasons: The read-aloud part does not adequately describe the scenario, the expected behaviors aren't explicit, there are crucial scenarios missing. The single best remedy for these problems is to conduct a dry run, which takes the usability test out of the abstract and into the real. Anything missing from the plan appears quite starkly when in the thick of a test. If you don't have time to test the test, as it were, you can also cross reference the script with the user profiles to identify potential holes in the scenarios. You can do a cheap version of the dry run by reading the scenarios aloud to colleagues and seeing if they understand them. A set of expected behaviors is simply a set of instructions for doing a particular activity on the web site. Hand someone the list of expected behaviors for a scenario and see if they can follow it to the goal. These are low-impact ways to diagnose potential holes in the script. Document Unusable for Testing It's one thing to review a test plan in a meeting and quite another to bring it into a testing situation. The content of the document may work, but the formatting may not be appropriate for use during an actual test. Again, the best way to mitigate this risk is to do a dry run of the test. By putting everyone (the facilitators and note-takers) and everything (the web site or prototype and the test plan) through its paces, you can establish whether the document format is suitable. Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Software Testing @ OneStopTesting : Test Plans @ OneStopTesting