Other Strategy Issues
20.0 Approvals
The approver(s) should be the person or persons who can declare that the software is
ready to move to the next stage. For example, the approver on a Unit Test Plan might be the Development Manager. The approvers on a System Test Plan might be the people in charge of the system test and whoever is going to receive the product next, which may be the
customer if they're going to perform the Acceptance Testing. Since this is a Master Test Plan, there may be many approvers including developers, testers, customers, QA,
configuration management, among others. One of the important parts of the approval
section of the test plan is the signature page. Figure 3-13 shows an example of a signature page.
Figure 3-13: Sample Signature Page
Key Point
The approver(s) should be the person or persons who can declare that the software is ready to move to the next stage.
The author(s) should sign in the appropriate block and enter the date that this draft of the plan was completed. In our sample signature page, we've also included a place for the reviewer to sign and date the document and check the block indicating whether or not he/she is recommending approval. The reviewers should be technical or business experts and are usually not managers. If some of the approvers lack the technical or business expertise to understand the entire document, their approval may be based partly upon the expertise and reputation of the reviewers.
In our sample signature block, we've included a space for the approver to sign and date the document and indicate approval "as-is" or conditionally. The approver(s) should be the
person(s) who have the authority to declare accept/reject the terms of this document. Even though we're anxious to get the approvers to "sign off" on the plan, we really want their buy-in and commitment - not just their signature. If you wait until the plan is written and then circulate the document for approval, it's much harder to get buy-in and the most you can hope for is just a signature. In order to get the commitment we want, the approver(s), or their representatives, should be involved in the creation and/or review of the test plan during its development. It's part of your challenge, as the test planner, to determine how to involve all the approvers in the test planning process.
Key Point
In order to get the commitment we want, the approver(s), or their
representatives, should be involved in the creation and/or review of the test plan during its development.
Ideally, we'd like to have the developers and users actually help write the test plan. For example, convincing the development manager or one of the senior developers to explain how unit testing will be conducted is much more effective than having someone from the testing group try to describe how unit testing will de done. Often, though, the key developer and/or user may not be willing (or may not have enough time) to actually write the plan.
We've found that one way to involve developers and users early in the development of the test plan is to invite them to a test planning meeting. While few people like attending
meetings, many prefer them over helping write the plan. During the course of the meeting, you should go through the entire template and identify the issues. Then, publish the first rough draft of the plan as the minutes of the meeting. You might want to preface your e-mail with, "Is this what we agreed on?" If you follow these steps, you're well on your way to achieving buy-in for your test plan.
Test planning is a lot of work and can be time consuming. If you're under the gun to get the next release out the door, you may argue that you can't afford to spend time creating a test plan. On the contrary, we hope that you will agree that you can't afford to begin testing without a good test plan.
Team-Fly
Team-Fly
Chapter 4: Detailed Test Planning
Overview
"You've got to be careful if you don't know where you're going 'cause you might not get there!"
— Yogi Berra
To be most effective, test planning must start at the beginning and proceed in parallel with software development. General project information is used to develop the master test plan, while more specific software information is used to develop the detailed test plans, as illustrated in Figure 4-1. This approach will target testing to the most effective areas, while supporting and enhancing your development process. When fully implemented, test planning will provide a mechanism to identify improvements in all aspects of the system and
development process.
Figure 4-1: Planning Phase
Process A level of test is defined by a particular environment, which is a collection of people, hardware, software, interfaces, data, and even the viewpoints of the testers. Table 4-1 lists some sample environmental variables. This list may vary significantly between projects and companies. Some companies, for example, may have only one level of test, while others may have ten or more.
Table 4-1: Sample Environmental Variables
Attribute
Level
Unit Integration System Acceptance
People Developers Developers &
Testers Testers Testers &
Users Hardware
O/S
Programmers' Workbench
Programmers' Workbench
System Test
Machine or Region
Mirror of Production Cohabiting
Software None None None/Actual Actual
Interfaces None Internal Simulated & Real Simulated &
Real
Source of Test Data
Manually Created
Manually Created
Production &
Manually Created Production Volume of
Test Data Small Small Large Large
Strategy Unit Groups of
Units/Builds Entire System Simulated Production
What determines the number of levels required? Typically this decision is made based on complexity of the system, number of unique users, politics, budget, staffing,
organizational structure and so forth. It's very important that the test manager help define what the levels are and ensure that there aren't too many or too few levels. We can hardly afford to have overlapping levels and, conversely, we don't want to take the risk of having big gaps between levels.
Key
Point Cohabiting software is other applications that reside on the same platform.
Creating a test plan for a specific level requires a clear understanding of the unique considerations associated with that level. Product risk issues, resource constraints, staffing and training requirements, schedules, testing strategy, and other factors must all be considered. Level-specific or detailed test plans are created using the same template that we used for the Master Test Plan (refer to Chapter 3 - Master Test Planning), but the amount of detail is greater for a level-specific plan.
Figure 4-2 shows the relationship of the Master Test Plan (MTP) to the Project Plan and the Detailed Test Plans.
Figure 4-2: Master versus Detailed Test Plans There are many names for the levels employed by different groups and companies. Here are only a few that we've encountered recently: unit, component, code, developer, build, string, thread, integration, system, system integration, acceptance, user acceptance,
customer acceptance, interoperability, alpha, beta; Verification, Validation, and Testing (VV&T), and others. You see, there are many different names, and you may very well have some that we didn't list here. In the long run, what you name your levels is
relatively unimportant. What's important is to define the scope of the level and what that level is supposed to accomplish; then, create a plan to ensure that it happens.
Key Point
It's important to define the scope of the level and what that level is supposed to accomplish; then, create a plan to ensure that it happens.
Throughout this book, we use the level names defined by the IEEE: Acceptance, System, Integration and Unit. While these names are no better or worse than any others, they are convenient, as they provide a basis for discussion. This chapter will focus on the highest levels first and then progressively move to the lower levels of test.
This is done because the level-specific plans should usually be written in reverse order of execution. That is to say, even though the acceptance test is normally the last one to be executed, it should be the first test to be planned. Why? Simply because the acceptance test plan is built on the artifacts that are available first - the requirements -and this group of tests is used to model what the system will look like when it's
complete. The "V" model of testing in Figure 4-3 shows that the system test should be planned next based on the high-level design (and requirements); integration testing should be planned using the detailed design (and the high-level design and
requirements); and unit testing should be planned based on the coding (and the detailed design, high-level design, and requirements).
Figure 4-3: The "V" Model of Software Testing Key
Point
The level-specific plans should usually be written in reverse order of execution.
Without a doubt, some readers may be more concerned with one level of test than the others. However, we encourage you to read about all of the levels of test in this
chapter even if you're not directly involved, because it's important to understand all of the types of testing that may be occurring in your company. Also, as a matter of style in writing this book, we sometimes discuss issues in one level of test that are
applicable at other levels and may not necessarily be repeated in the other sections of this chapter.
Team-Fly
Team-Fly