Test environments

But behind all this lies another set of preparations. The work required to set up the test environments. After all, where will the testing be carried out? Should it be done in a discrete environment. Should they be secure?

What software versions should we use? What platforms are we running on? Behind each successful test environment there is normally a build team responsible for putting the environment together.

Test environment preparation work starts well in advance f any delivery of code for testing. It consists of many activities to create the test environment and get the 'application to be tested' correctly installed and configured to enable the testers to start test execution.

The activities are highlighted below and form a checklist of questions, concerns, operations, responsibilities and undertakings from various technical disciplines within an organisation.

• Test Management Tools Probably the first task to be carried out to allow testers to commence with the test preparation.
• Build Plans that show the construction sequence, configurations and dependencies of the 'application to be tested'
• Test Data Do testers require data from conversion, production, day 1 or specific individual hand crafted test data? Don't forget data volumes.
• Test Strategy and Approach Does the environment match the type of testing to be carried out? Are we testing with low volumes/throughput or high volumes to simulate a peak period for performance testing?
• Fault Reporting Tools Ensure tools are in place and accessible by both testers and development support.
• Environment Libraries The setting up of secure load/object libraries with the illusion of quick-fix libraries.
• Change Management Ensure software version control place and baselined versions are taken.
• Test Automation Tools Ensure correct test automation/execution tools in place.
• Code Stability How stable is the code that is being handed over? What testing was done prior to handover.
• Debugging Tools What debugging tools will be made available when problems are encountered during testing?
• Test Harnesses Will any utilities/tools be supplied or built to aid the testing?
• Testing Isolation Separation of test environments to accommodate different testers and different forms of testing.
• Test Scheduling To arrange the test execution process so that all testers are accommodated.
• Software Changes To be prepared to handle the frequency of change once the testing has commenced.
• Software Licences Surprise, surprise, it's amazing how many times we get caught out on this one!
• Contact names Ensure all contact names and processes are communicated to the testers and establish a first point of contact during times of trouble.
• Install Programs Most client/server systems now come with some form of Install disk. How is the software rolled out - on individual desktops or via the network?
• Uninstall Programs Most applications now often come with an Uninstall process should things get hairy.
• Naming Standards Ensure correct naming standards are established, so that components can be easily identified.
• Security & Access During build process, ensure correct security in force and testers have the correct access set-up to carry out their testing. Ensure developers cannot insert quick and dirty 'quick fixes'.
• Backups and Recovery No backups, then be prepared to face the rancour of unsatisfied testers!
• Integration with other systems/legacy systems/MIS - always an old chestnut.
• Co-ordination between technical disciplines and testing support teams - Environment versus Application. Always causes consternation with the technical disciplines as they always want to ensure system set-ups and configurations are kept within themselves. There is no way Root or Admin access will ever be passed down to testing support. Always ensure correct bonding in place.
• Batch Execution and Control Yet another favourite. Who runs the batch cycles - test support, tester or operators?
• Production Readiness How many times have you been caught out where development have handled over the cobbled up piece of software (which you know requires major re-work to enable it to hit production).
• Testing End Dates In nine times out of ten, development always runs late, but the testing end date is solidly engraved in concrete. There's a lot of testing to be done, and the midnight lamps have just been turned on!

Urmil Laxman, Independent Consultant