For the purposes of this sample, we will assume that our application produces a report of clients’ details (name, address, and post code) for new clients entered each date.
This report is being changed, so that the clients’ date of birth is output as well.
To test this we would firstly produce a copy of the report, from our UAT / Model Office environment. As no changes have been made, we can accurately say that this report is correct, and we can safely use this as the baseline for our testing.
Ensuring that no new clients are entered, we would then ask for the changes to the report to be installed.
Running the report again should produce the same clients, in the same order, with the same relevant information, with the only difference being the inclusion of the date of birth (which we would then check back to the client database and ensure it is the right one)
This testing proves two things
In my company such a change would have been initiated by a business user, and therefore would need signing off as correct, to allow the changes to be implemented into the production application.
Such a testing methodology makes this process easier, as it quite effectively demonstrates the success of the change.
I have always referred to this type of testing as ‘before and after’ testing, as the identical processes are executed twice.
Once before the changes are made, and the results of this run of the testing is documented as the baseline.
The identical testing is then done again after the changes have been installed, and compared to the baseline results return from the before run.
The only differences should be those that are ‘meant to happen’. Any other differences are therefore unwanted, and can easily be identified as being caused by the change, as they did not happen when the before run was made (and you can prove it because you have the documentation from that run).
This is a very useful methodology, but to apply it properly you must ensure;
Either of these will invalidate your baseline run.
Such a methodology may be used when (e.g.) testing the validation present in a data entry application.
Such an application would allow the entry of data to the application, where it is then processed. This data is usually subjected to quite stringent validation checking to ensure that (as much as possible) only clean data is entered.
When testing such an application, a testing methodology would be to define a matrix of the validation checks, and the parameters required to break them (example below)
Validation Check |
Parameters |
| Title is mandatory | Omit client title (fail) |
| Title and sex must be consistent | Enter title as Mr. and sex as Female (fail) Enter title as doctor and sex as female (accept) |
| Cannot enter client aged over 100 | Enter date of Birth as 04/04/1870 |
A client would then be entered as clean (i.e. with no validation errors).
This client’s details will then be amended as described in the parameter column, and necessary validation message will be produced.
After the correct result has been documented, the client’s details will be restored to clean, and the next test executed.
This loop is then repeated until all the validation messages have been successfully produced and documented.
Home | Read my CV | Search the WWW | Pictures
User Acceptance Testing | Learning to Program in C
ICQ Page (including Software Testers ICQ Group