Test Plan Section | Description |
---|---|
Summary | Lists the test plan owner and provides a full text editor that you can use to write a detailed Description of the test plan. It also includes the Status of the work item that tracks the progress of the test plan. |
Business Objectives | Specifies the business rationale for the release. Business objectives are often tied to financial goals, for example winning market share from a competitor or improving product usability and reliability. |
Test Objectives | Identifies the success criteria for the project that can be measured and reported. You can define the goals for the planned testing effort. For example, an objective might be to track successes, failures, defect status, and issues in order to provide feedback to development before software is delivered to customers. |
Formal Review | Lists the people who must review or approve your test
case and defines the approval process. Use to institute a formal review process
that can help your business processes comply with applicable industry or corporate
standards and regulations. Each team member that is listed receives a work item notification. When team members respond, the plan owner is notified, and a summary of the results is displayed. The team owner then updates the plan accordingly and repeats the process until all team members approve. |
Requirements | Lists the requirements for a particular test cycle.
You can create new requirements right in the test plan or import them from
an external tool, such as IBM® Rational® RequisitePro®. After your requirements are added to the test plan, you can associate them with test cases. Once you establish the linkage between requirements and test cases, you can create coverage reports to determine the percentage of requirements that are covered by test cases. By maintaining this tight coupling between requirements and test cases, you are able to set up traceability throughout the project lifecycle. |
Application Security | Lists the available test policies that you can add to
the test case script. A test policy is a predefined set of security tests that defines the tests you can perform, such as threat classes tests, application or infrastructure tests, and invasive or noninvasive tests. Click the test policy link to view and edit the details in AppScan Tester Edition. |
Test Schedules | Defines the schedule for the test plan. In this section,
you can create multiple milestones or iterations, each with their own start
and end date. Click the |
Test Estimation | Defines the high level planning effort and test execution effort associated with this test plan. Effort can be entered in person hours, days, months or years. |
Test Environments | Use to specify the test environments that must be supported
and the resources that are available. You can use this information to determine
the environments to be tested for each test case. You can provide this information manually or automatically by using the product to generate this information. You can also add existing environments from a configuration catalog. After you include this information in the test plan, you can run a gap analysis of the environments that the test plan specifies against the machines that are known to be available for testing. In addition, you can create requests for lab resources. |
Test Team | List the members of each test team. As an administrator, you can perform various administrative tasks, such as adding users to team areas and creating new project areas and team areas. |
Quality Objectives | Lists in table format your quality objectives for a release. Typically, quality objectives provide various measurements of quality for the overall release. You might list several performance objectives, such as the maximum allowable response time for certain functions or the minimally acceptable number of concurrent users. You might also list several objectives that pertain to usability or reliability. |
Entry Criteria | Use to specify the conditions required to begin testing, such as the minimum level of product and feature quality necessary before testing begins. |
Exit Criteria | Use to specify the conditions to meet for a particular test cycle to be considered complete. For example, you might specify that testing is incomplete until 100% of the test cases have been run and that all of the most severe defects have been fixed. During the course of a test cycle, you can adjust the exit criteria. |
Test Cases | Lists the test cases associated with the test plan. You can add and remove associations to test documents and create and associate a new test case. Removing a test case will remove the association to this test plan but not delete the test case. |
Resources | Specifies the various shared locations to the artifacts referenced in the test plan. |
Attachments | Use to attach files and documents to the test plan, such as previous test plans, test iterations, screen captures, and other supporting material. |