When I was managing software development, one of the messiest and least efficient areas was the system test region that was set up so programmers could unit test their applications.
In the fray of meeting tight project deadlines, we focused on allocating resources for application QA testing, staging and production. A lesser priority was placed on creating a system “sandbox” so developers could unit test their applications as they were writing them.
SEE: Hiring kit: Python developer (TechRepublic Premium)
The result was a growing number of wasted system resources that no one deprovisioned after they were done unit testing. Applications that took longer to pass QA, and they could even fail in production — all because programmers in early stages of application development were forced to test their apps against outdated data.
To be fair, there were reasons why shops worked like this. The thinking in the application development group was that it was the quality assurance team’s job to test and catch application errors. All the developer had to do was to ensure that the code compiled and that the application ran. Additionally, the database and systems groups were always overwhelmed with work. It wasn’t hard for either of these groups to deprioritize refreshing the data for an application sandbox.
This line of thought was and still is common practice in many IT departments, but with today’s resources, it doesn’t have to be.
How to improve your application testing system
Here are three ways that sites can use to improve their unit test environments for new applications:
Use template system allocation scripts
If an application developer needs to test their application on a specific distribution and release of a Linux operating system, they should be able to access a generic script for provisioning the OS and only need to make only minor adjustments. There’s no reason to hand-write a script for provisioning the correct OS environment for your app.
Continuing with Linux as an example, there are multiple vendors of this operating system that now have auto-provisioning of new OS’s for purposes of unit testing applications. The OS provisioning automation eliminates the need for developers to hand-code their own scripts for creating test OS environments for their applications. It also eliminates the possibility of human error that can be introduced during hand scripting.
Automate resource allocation and deallocation
A second sticking point in application unit testing is the allocation of databases and other system libraries that must be loaded in order to create a suitable test environment for the application.
Application developers must often wait in line for the database and system groups to be available to set up these test regions and resources for them.
To solve the issue, there are a number of vendors that now offer point-and-click interfaces for developers that allow them to select the database and system resources they need for their application unit test environments. This point-and-click resource selection enables developers to self-configure their own unit test environments without having to ask the database or systems groups for help — and it saves everyone time and effort.
On the back end of development, once an application is fully unit tested, there is usually no need to maintain the system resources and storage that were reserved for the unit test. Unfortunately, developers usually forget about that, so storage and resources sit idle.
SEE: Hiring kit: Back-end Developer (TechRepublic Premium)
This waste can be eliminated if the database and/or systems group set parameters for automatically deprovisioning the test regions. For example, a message can be sent to the developer that says: “In ninety days, your test region for application xyz will be de-provisioned if no use is detected.” This gives the developer a heads up.
Perform regular refreshes of test data
Data refreshes are often performed infrequently in application testing environments. When data is outdated, there is greater risk that the applications that are tested against this data will fail in QA and even in production.
The database group should have a regular schedule for refreshing test data. This saves everyone time during testing and QA checkout, and it precludes the possibility of a significant application error that could occur in production.