Topic: Presenting Test Plans

Message

Presenting Test Plans

        In a sense, the usability test itself is a presentation of the test plan. The test plan is the agenda for the facilitator's meeting with the participant. But this is not the kind of presentation we're talking about here. Instead, this section will provide strategies for preparing and doing presentations with the test plan as a deliverable, as work product. Like any documentation review, the structure and agenda for the meeting should be driven by the meeting's purpose.

Meeting Purpose

        There are a few main reasons to review a test plan with the project team and stakeholders. In a high-level meeting, your aim is to get buy-in for the overall approach, while at the other end of the spectrum, you may want to do a dry run of the usability test, digging into every detail.

Securing Buy-In

        If your stakeholders do not have much experience with usability testing, you may need to stage a buy-in meeting to review the overall process with them. You could hold a session that provides an introduction to usability testing in general, but this won't be as meaningful to stakeholders as a test plan that deals with their particular product. In this kind of meeting, you must go through every aspect of the plan, but you do not need to go into a great level of detail on the script. Instead, spend even amounts of time on the objectives, the methodology, and the script.

Soliciting Input

        Once your stakeholders are comfortable with the idea of usability testing and the approach you're taking, you can solicit input on the script. There are two kinds of input you need. First, you need to know if your range of scenarios covers every possible use of the system. Second, you need to know what to get out of each scenario. If you're already familiar with the system, you should be able to do most of this yourself, but the stakeholders may have some input.

Testing the Test

        The best way to get input on a test plan is to do a mock test, running through each step of your plan with a participant who might be another member of the team not directly involved with the design. Doing a dry run of the test is a good way to ensure that the scenarios aren't too goofy and that you can do everything you need to in the given amount of time. A dry run can uncover potential logistical issues—for example, transitioning from one scenario to the next—or identify major holes in the script where scenarios or instructions for the facilitator should be.

Meeting Structure

        A test plan isn't a hard story to tell, especially if the project team has bought into the idea of usability testing. While other documents in this book lend themselves to different meeting structures, the only decision you'll need to make for a usability test plan is how much time to spend on each section.

         If you have only one meeting to review a test plan, make sure you cover each part—don't leave anything out—but you don't need to go into great detail on the logistics and methodology. If your stakeholders aren't big "detail people" you can also just hit the high points of the script, describing what scenarios you're testing and how those correspond to the different functions or areas of the web site.

Effective Presentation of the Test Script

        If you've provided a lot of information in your test script, as in Figure 3.4, you need to decide how you will go through all the details during your review meeting. For the majority of reviews, describing the scenario and stating what will be read to the user may be sufficient. In these cases, you can gloss over the other information. If the scenario is especially complex, you may want to go through every detail. Additionally, if you're meeting with developers who will be building the product to test, you may want to spend more time on the expected product behavior—what the web site does in response to user actions.

Author	Message
Amrita Groupie Joined: 13Feb2007 Online Status: Offline Posts: 57	Topic: Presenting Test Plans Posted: 19Feb2007 at 2:25pm
	Presenting Test Plans In a sense, the usability test itself is a presentation of the test plan. The test plan is the agenda for the facilitator's meeting with the participant. But this is not the kind of presentation we're talking about here. Instead, this section will provide strategies for preparing and doing presentations with the test plan as a deliverable, as work product. Like any documentation review, the structure and agenda for the meeting should be driven by the meeting's purpose. Meeting Purpose There are a few main reasons to review a test plan with the project team and stakeholders. In a high-level meeting, your aim is to get buy-in for the overall approach, while at the other end of the spectrum, you may want to do a dry run of the usability test, digging into every detail. Securing Buy-In If your stakeholders do not have much experience with usability testing, you may need to stage a buy-in meeting to review the overall process with them. You could hold a session that provides an introduction to usability testing in general, but this won't be as meaningful to stakeholders as a test plan that deals with their particular product. In this kind of meeting, you must go through every aspect of the plan, but you do not need to go into a great level of detail on the script. Instead, spend even amounts of time on the objectives, the methodology, and the script. Soliciting Input Once your stakeholders are comfortable with the idea of usability testing and the approach you're taking, you can solicit input on the script. There are two kinds of input you need. First, you need to know if your range of scenarios covers every possible use of the system. Second, you need to know what to get out of each scenario. If you're already familiar with the system, you should be able to do most of this yourself, but the stakeholders may have some input. Testing the Test The best way to get input on a test plan is to do a mock test, running through each step of your plan with a participant who might be another member of the team not directly involved with the design. Doing a dry run of the test is a good way to ensure that the scenarios aren't too goofy and that you can do everything you need to in the given amount of time. A dry run can uncover potential logistical issues—for example, transitioning from one scenario to the next—or identify major holes in the script where scenarios or instructions for the facilitator should be. Meeting Structure A test plan isn't a hard story to tell, especially if the project team has bought into the idea of usability testing. While other documents in this book lend themselves to different meeting structures, the only decision you'll need to make for a usability test plan is how much time to spend on each section. If you have only one meeting to review a test plan, make sure you cover each part—don't leave anything out—but you don't need to go into great detail on the logistics and methodology. If your stakeholders aren't big "detail people" you can also just hit the high points of the script, describing what scenarios you're testing and how those correspond to the different functions or areas of the web site. Effective Presentation of the Test Script If you've provided a lot of information in your test script, as in Figure 3.4, you need to decide how you will go through all the details during your review meeting. For the majority of reviews, describing the scenario and stating what will be read to the user may be sufficient. In these cases, you can gloss over the other information. If the scenario is especially complex, you may want to go through every detail. Additionally, if you're meeting with developers who will be building the product to test, you may want to spend more time on the expected product behavior—what the web site does in response to user actions. Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


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