Select Appropriate Implementation Technique
Select the most appropriate technique to implement the test. For each test that you want to conduct, consider
implementing at least one Test Script. In some instances, the implementation for a given test will span multiple Test
Scripts. In others, a single Test Script will provide the implementation for multiple tests.
Typical methods for implementing tests include writing a textual description in the form of a script to be followed
(for manual testing), and the programming (captured-recording or generation) of a script-based programming language
(for automated testing). Each method is discussed in the following sections.
As with most approaches, you will get more useful results if you use a mixture of the following techniques. While you
do not need to use them all, you should not confine yourself to using a single technique either.
For more details, see the Select Appropriate Implementation Technique section from Guideline: Implementing Tests.
|
Set Up Test Environment Preconditions
Set up the test environment, including all hardware, software, tools, and data. Ensure that all components are
functioning properly. Typically, this will involve some form of basic environment reset, restoration of underlying
databases to known state, and so on, in addition to tasks such as loading paper into printers. While some tasks can be
performed automatically, some aspects typically require human attention.
For more details, see the Set Up Test Environment Preconditions section from Guideline: Implementing Tests.
|
Implement the Test
Using the Test-Ideas List, or one or more selected Test Case artifacts, begin to implement the test. Start by giving
the test a uniquely identifiable name (if it does not already have one) and prepare the IDE, capture tool, spreadsheet,
or document to begin recording the specific steps of the test. Work through the following subsections as many times as
are required to implement the test.
Note that for some specific tests or types of tests, there may be little value in documenting the explicit steps
required to conduct the test. In certain styles of exploratory testing repetition of the test is not an expected deliverable. For very
simple tests, a brief description of the purpose of the tests will be sufficient in many cases to allow it to be
reproduced.
For more details, see the Implement the Test section from Guideline: Implementing Tests.
|
Establish External Data Sets
In many cases, it is more appropriate to maintain your Test Data external to the Test Script. This provides
flexibility, simplicity, and security in Test Script and Test Data maintenance.
For more details, see the Establish External Data Sets section from Guideline: Implementing Tests.
|
Verify the Test Implementation
Especially in the case of test automation, you will probably need to spend some time stabilizing the workings of the
test when it is being executed. When you have completed the basic implementation of the Test Script, it should be
tested to ensure that it implements the individual tests appropriately, and that they execute properly.
For more details, see the Verify the Test Implementation section from Guideline: Implementing Tests.
|
Restore Test Environment to Known State
While this step might seem trivial, it is an important good habit to form to work effectively with the other testers on
the team, especially where the implementation environment is shared. It is also important to establish a routine that
makes thinking of the system state second nature.
When you are in a primarily manual testing effort, it is often simple to identify and fix environment restore problems:
remember that automated testing has much less ability to tolerate unanticipated problems with environment state.
|
Maintain Traceability Relationships
Using the Traceability requirements for the project, update the traceability relationships as required.
|
Evaluate and Verify Your Results
You should evaluate whether your work is of appropriate quality, and that it is complete enough to be useful to those
team members who will make subsequent use of it as input to their work. Where possible, use checklists to verify that
quality and completeness are good enough.
Have the people who perfomr the downstream tasks that rely on your work as input review your interim work. Do this
while you still have time available to take action to address their concerns. You should also evaluate your work
against the key input work products to make sure that you have represented them accurately and sufficiently. It may be
useful to have the author of the input work product review your work on this basis.
|
|