Planning to Test
 Randomly
flicking through screens and reports 'giving them a go' is not effective in finding
bugs and confirming functionality. User acceptance Testing should be structured
and documented. The first part of the User Acceptance Testing is the creation of
the 'test data' and 'test plan' documents.
The test data document is a detailed list of each of the sets of data that you intend
to use for your testing. The test data document can be a simple table with the following
columns:
- Number (just a sequential number for reference)
- Description of purpose of data
- Entity (is this a Customer, Invoice, Supplier, Job, etc?)
- Data (a detailed list of the data elements being scrutinised)
- System reference (the record number given to the entity when entered into the software
being tested)
The test plan lists all of the functionality that you intend to check, how you will
check it, and the results that will confirm that the test was successful.
The test plan typically contains the following columns:
- Number (just a sequential number for reference)
- Description (a short description of the functionality being tested)
- Process (a description of what you going to do to perform the test)
- Test data number (a reference to the test data document)
- Result (expected output or effect)
- Date (the date this test was last performed)
- Who (who performed this test last)
- Pass (Yes or No)
|
When you construct the test plan you may identify new items for the test data document
and you may see opportunities to re-use test data. This is the reason for having
a separate test data document. It saves having to describe the data you intend to
use each time on each separate test.
An easy way to start building a list of tests in the test plan is to look at each
element of functionality from the specification. For example, if you know you are
meant to be able to create a 'Customer' then add as many tests around this process
as you can think of. Additionally, you can create tests by thinking of end-to-end
processes. An example of the thought process might be "To create an invoice I know
I need to create products, clients, orders and jobs". This then leads to a number
of individual tests leading up to creating the invoice.
For every item of functionality you identify for testing you should try to think
of multiple 'positive' and 'negative' test plan items. A positive test
is a where you expect the software to accept all the input in a 'typical world'
and the result will be good. An example would be to say "Can I create a log entry?"
A negative test is where you expect the software to be challenged
by the input or action. You're testing whether the function will handle a bad situation
well or not. An example would be to say "What happens if I delete a log entry that
is related to another log?".
Planning to Record Issues
To allow Infosphere to effectively understand, reproduce and correct an issue (i.e.
bug or malfunction) we need a certain level of information. To collect this information
in a structured way we suggest creating an 'issue register'. Items in the issue
register can be created as User Acceptance Testing is performed.
Again, the issue register can be a simple table with the following columns:
- Number (just a sequential number for reference)
- Test number (reference back to the test plan)
- Description of what when wrong or what is required
- Reproduction steps (how to reproduce the error or understand the requirement)
- Specification reference (If this is an item from the specification indicate where
to find it)
- Urgency (level between 1 (correction is most urgent) to 10 (correction would be
good but is not critical)
|