Software Application Testing in Insurance, Part I: Automated Testing

In my last post I talked about the vendor proof of concept as a way for insurers to avoid buying “a lemon”. The same risk management needs to apply when an insurer develops software internally, and that’s achieved with strong testing practices. Software testing is a huge topic, and I’m going to split the discussion up over a series of blog posts. There are a lot of great books and articles out there about software testing, but in these posts I’ll try to give it an insurance industry spin. You might run into different issues depending on whether you are building web portals, data-heavy applications, server utilities, or mainframe applications, though in general the same methodologies still apply. Topic 1: Automated Testing From the lowest to highest level, test cases can be broken into the following three categories 1. Unit Tests: Code-based test cases that developers write to test their own code. Typically these are written using developer tools such as the open source JUnit. 2. Automated System Tests: Test scripts that can be run against the entire system, and can be created by developers or test teams. These are typically written with applications that are specifically geared to help write tests for web-based, Windows-based, or Java-based applications. 3. Manual Tests: Test scripts that are manually executed by a test or QA team. The biggest testing issue I see at insurance companies is that there are too many manual test processes and not enough automated testing. Manual tests are important, but they are slow, difficult to reproduce reliably, costly, and aren’t scalable. Plus, it’s much more likely that previously fixed bugs will pop up again without being noticed. With a full suite of Automated System Tests and Unit Tests, large changes can be made to a software application with confidence. Many developers complain about writing unit tests or skip this step, claiming the responsibility lies with the QA team, or saying they will take care of it later (and then never do). The more unit tests written, the easier it gets to write them, and the less time will be spent fixing bugs later. And, remember, the later a bug is discovered and fixed, the costlier it becomes, especially when the bug isn’t found until the system is in production. To increase the automated test footprint on a system built using only manual testing, start requiring new unit tests for all bug fixes going forward. Each time the test group discovers a bug, an Automated System Test or a Unit Test should be written to repeat that bug before the developer fixes the code. Once the code is changed, the team can verify that the bug has been fixed by running the new test case again and seeing that it now works. This also creates a repeatable automated test that prevents the bug from reintroduction.