Creating a Test Pack
From our testing Business Analysis articles...
Contents
Creating a Test Pack
Testing is an expensive exercise. Not only do you have to create the test itself, but often you also need to create the circumstances prior to the test as well.
Before You Start
In order to have a test pack, your new application needs to have the possibility of a repeatable input and a measurable output.
As a simplistic example, if you had an application that updates a file, if you kept a copy of the "before" file and "after" file, you can then check that the differences are the ones expected. You can then build a set of "before" or input files, and the expected results. Keep this group of files and expected results, and you have a test pack.
This test pack can be kept up to date with changes and forms a ready made regression test. If this regression test is done often, then automating the file switching, running and results checking become worthwhile.
Extending our Idea of Input and Output
"Ah", you are probably thinking, "my application works off a database, so I cannot use this technique". We can, we just need to get creative with the inputs and outputs. The inputs to your process are the data within the tables of your database, the outputs are data within tables of your database - therefore similar principles apply, just that the storage and copying of different input sets is slightly more difficult (either importing from flat file or copying from back up tables). To counterbalance this, checking the output would be easier using SQL than a flat file check.
Breaking Up Processes into Chains of Input and Output
Testing a process end to end can be expensive, but once you have tested and proved the manual input system, firstly you can store away these examples, but secondly, can you then use generated test data using the same format that the manual input system would have created - particularly if you need volumes of data?
If it is possible without endangering functionality, designing your systems as chains of input and output can certainly decrease your test time and potentially the bugs as each part of the chain performs a simpler operation.
Right Here, Right Now - the fly in the Ointment
The system date is often a "hidden" input into many processes. The current date and time can be obtained from the database, the client and the server. If the design has not closed down the possible places the system date time can be obtained from, then testing can become laborious. There are methods to workaround this, setting the system date/time to an appropriate value. Oracle database also has a system parameter to help with this type of testing.
Hopefully, date and time are para,etherised so that testers can set the date/time for your functionality to determine how reacts at midnight, year end etc.
Another version of this same problem is geolocation services. If you have not allowed your application to manually set its location, then you will need to set this from within the operating system or test rig.
Case Study
You are testing an employee absence system, and in order to test the end of year accruals process, you need to create absences for employees in your system - at various levels of their annual allowance. You also need to hire employees at various times throughout this year and the next year on different work schedules to determine whether their entitlements are correctly calculated and processed.
So the (rather short) chain is:
- Hire employees
- Book and approve absences
- Run accrual process
Each part of this chain can be separated - the hire process can be tested (if it has not been already), the data created can then be checked and saved. The saved data can be "multiplied" by an automated process and checked.
The masses of new employees with various work schedules can then be booked various absences. Once this data has been checked and saved, this data too can be applied across all the employees and the automated checks reapplied. Now we can run the accruals process with real data volumes and a higher degree of variety.
All the saved data can be kept for the regression testing either in another year or for bug fixes. Either scenarios means you save money on test time.
