Test Plan and Test Cases
Throughout the entire software project, the team does many things to find and prevent defects. Once the software has been built, it’s time to look back and make sure that it meets the requirements. The goal of software testing is to make sure that the product does what the users and stakeholders need it to do. Software testers review the final product to make sure that the initial requirements have been met.
In software testing, quality is defined as “conformance to requirements.” Every use case, functional requirement, and other software requirement defines a specific behavior that the software must exhibit. When the software does not behave the way that the requirements say it must behave, that is a defect. This means that software testers are responsible for figuring out whether the software that was produced by the team behaves in the way that the requirements it was built from say that it should.
Test Plans and Test Cases
The goal of test planning is to establish the list of tasks that, if performed, will identify all of the requirements that have not been met in the software. The main work product is the test plan. There are many standards that can be used for developing test plans. The following table shows the outline of a typical test plan. (This outline was adapted from IEEE 829, the most common standard for software test plans.)
Purpose
A description of the purpose of the application under test.
Features to be tested
A list of the features in the software that will be tested. It is a catalog of all of the test cases (including a test case numberand title) that will be conducted, as well as all of the base states.
Features not to be tested
A list of any areas of the software that will be excluded from the test, as well as any test cases that were written but will not be run.
Approach
A description of the strategies that will be used to perform the test.
Suspension criteria and resumption requirements
Suspension criteria are the conditions that, if satisfied, require that the test be halted. Resumption requirements are the conditions that are required in order to restart a suspended test.
Environmental Needs
A complete description of the test environment or environments. This should include a description of hardware, networking, databases, software, operating systems, and any other attribute of the environment that could affect the test.
Schedule
An estimated schedule for performing the test. This should include milestones with specific dates.
Acceptance criteria
Any objective quality standards that the software must meet, in order to be considered ready for release. This may include things like stakeholder sign-off and consensus, requirements that the software must have been tested under certain environments, minimum defect counts at various priority and severity levels, minimum test coverage numbers, etc.
Roles and responsibilities
A list of the specific roles that will be required for people in the organization, in order to carry out the test. This list can indicate specific people who will be testing the software and what they are responsible for.
The test plan represents the overall approach to the test. In many ways, the test plan serves as a summary of the test activities that will be performed. It shows how the tests will be organized, and outlines all of the testers’ needs that must be met in order to properly carry out the test. The test plan is especially valuable because it is not a difficult document to review, so the members of the engineering team and senior managers can inspect it. The bulk of the test planning effort is focused on creating the test cases. A test case is a description of a specific interaction that a tester will have, in order to test a single behavior of the software. Test cases are very similar to use cases, in that they are step-by-step narratives that define a specific interaction between the user and the software. However, unlike use cases, they contain references to specific features of the user interface. The test case contains actual data that must be entered into the software and the expected result that the software must generate.
A typical test case includes these sections, usually laid out in a table:
* A unique name and number
* A requirement that this test case is exercising
* Preconditions that describe the state of the software before the test case (which is often a previous test case that must always be run before the current test case)
* Steps that describe the specific steps that make up the interaction
* Expected results that describe the expected state of the software after the test case is executed
The following table shows an example of a test case that would exercise one specific behavior in the search and replace requirement. This requirement specified how a search-and-replace function must deal with case sensitivity. One part of that requirement said, “If the original text was all lowercase, then the replacement text must be inserted in all lowercase.”
(Click on the below image to see the clear view)
SPONSORED LINKS
Comments :
0 comments to “Software Test Plan - STP”
Post a Comment