Software Application Testing in Insurance, Part IV: Best Practices

Previous posts about testing Topic 1: Automated TestingTopic 2: Getting Test DataTopic 3: Test EnvironmentTopic 4: Best Practices in Application Testing: It's been a while since I've blogged about this subject, but I think the previous three posts could use some follow up. After talking about the need for testing, getting the test data, and setting up a test environment, we need to actually do the testing. The best practices for software application testing are not easy to set up and maintain, often requiring one or two full time IT resources with a test development specialty (often called a Software Test Engineer, or an STE). Not many technology vendors follow these best practices, let alone insurers, and the expense and effort might not be practical or possible for every insurance company. However, by understanding the best practices an insurer can at least take steps in the right direction. The ideal scenario is an automated system that is able to clean itself to a standard state before and after each test. For example, if the QA team wants to run manual tests for software application ABC, they would run a script that would:

• Drop all the tables in the database, recreate the tables in the database for ABC, and populate it with the same set of start data.
• Clear out any existing application code, then get and install the latest application code from development.
• In extreme cases, the entire test server OS will be reinstalled from scratch, though that is likely unnecessary for this level of application testing.

Later, if a different QA team wants to run manual tests for software application XYZ, they would run a similar process. Both teams are guaranteed a stable, repeatable base from which to begin their testing. By recreating the database and the application each time the tests are run, there is no need to worry about maintaining the database in a certain way, and multiple users can work with the same servers. Preparing to run the Automated System Tests should behave in a similar manner, with the reminder that the order of tests shouldn’t matter. That means it might be necessary to REBUILD the database between some automated system tests. In the case of Unit Tests, the ideal test environment should go one step further. Each unit test (and in many cases automated system tests) should contain its own code to add the data to the database needed by the test. Since unit tests are intended to be very focused, the typical test just needs a few rows of data. After the test is complete, it should clean out the data it just added. Since these are written by developers, there should be an application specific API for helping developers do this quickly, written by the IT resources devoted to test development. It's a lot of effort, and each IT group needs to determine the level they are willing to go to achieve the best possible test practices. As with the previous topics, however, once the intial set up is complete, following the best practices becomes easy and natural.