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 repace 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.”
| Name | TC-47: Verify that lowercase data entry results in lowercase insert
| Requirement
| FR-4 (Case sensitivity in search-and-replace), bullet 2
| Preconditions
| The test document TESTDOC.DOC is loaded (base state BS-12).
| | Steps |
- Click on the “Search and Replace” button.
- Click in the “Search Term” field.
- Enter This is the Search Term.
- Click in the “Replacement Text” field.
- Enter This IS THE Replacement TeRM.
- Verify that the “Case Sensitivity” checkbox is unchecked.
- Click the OK button.
| Expected Results
|
- The search-and-replace window is dismissed.
- Verify that in line 38 of the document, the text this is the search term has been replaced by this is the replacement term.
- Return to base state BS-12.
|
|
