Insurance & Technology is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


05:36 PM
Connect Directly

Applications Developed Via the Agile Method Require Tailored Automated Software Testing

How can software recipients and developers test the fast paced, agile software iterations to assure proper functionality and confirm that their business criteria have been satisfied?

By Jeremy Greshin, Telesis

While many insurers have started using software that is developed using an agile methodology, as opposed to the more traditional waterfall model, software testing has not made the transition nearly as well. Without the right automated software testing, agile development can lead to more time spent on testing and to more software bugs going into production than with traditional software development.

Software developed for the insurance industry comes from many difference sources. Some companies write their own software applications, while others purchase commercial packages and either use an application 'as is,' or customize it to support their business model. Traditionally, these various software developers produced their software using a sequential or waterfall model for their software development process (e.g. SDLC): requirements specification, software design, integration, testing, installation, and maintenance. However, a growing insurance industry trend is for software developers to deliver numerous agile software versions to better accommodate statutory, state-of-the-art, time-sensitive initiatives. The agile development model relies on an iterative or incremental approach to software development to enhance speed-to-market delivery times. While the software development models have migrated toward an agile approach, unfortunately the quality assurance (QA) and software testing models have not kept pace. QA and testing are still using traditional approaches for automating software testing, such as a heavy reliance on coding test scripts. While these test approaches may have had some success with SDLC, they do not work with agile development. Test script coders cannot keep up with the rapid changes that agile development produces, or the havoc that dynamic object property changes bring to automation. Manual testing is extremely time consuming and labor intensive and yields many errors in production. What is needed is an agile software testing model.

So how can software recipients and developers test the fast paced, agile software iterations to assure proper functionality and confirm that their business criteria have been satisfied? The ideal solution is to design, configure, and build a turnkey, automated agile regression test solution unique to the software application, and deliver it in a timely manner. This is a multi-step process.

Step 1: Establish priorities. Identify the critical, most used, end-to-end business transaction pathways within the enterprise portfolio for the application. Prioritize those business scenarios from an end-user's standpoint. Also prioritize them using an enterprise risk perspective to (1) assure that the most important, high-risk business scenarios are tested prior to production release, and (2) accomplish as much testing as possible, within the project timelines, so that the major functionalities used by the majority of the business are adequately tested. Make sure that business analysts validate the results.

Step 2: Develop the Architecture. Create an automation test architecture using the appropriate functional test tools. Make sure that the architecture supports the automated test script processing, while minimizing test script coding. This significantly reduces future maintenance costs. Strive for durable and reusable (not just coded) automated test scripts within the agile development process.

Step 3: Develop Test Case Templates. The templates are used for automating the application. Identify the key fields to vary in using data parameterization. By minimizing test script volumes, future test automation maintenance costs also go down.

Step 4: Move the Data. Identify a full data migration solution from the legacy system, based on the necessary elements of the new application. Your automated test scripts should be architected so that you can use them for data conversion as well.

Step 5: Execute. Build and automate as many of the end-to-end test transactions for the application as possible, within the iteration's user acceptance testing (UAT) schedules. Then, execute the test scripts (automated test cases) during UAT, report defects, and maintain a testing status dashboard for project status results. Use these reports to make acceptance decisions regarding the software upgrades.

Step 6: Keep Going. After the software go-live date, continue to expand and enhance the regression test base, and test the new version releases for any regression impact from the implementation of new business initiatives (e.g., adding a new state or functionality), policy growth, or the testing of new product enhancements. In addition, maintain the library of automated test cases. Coordinate test execution runs to accommodate vendor release schedules and UAT schedules.

The goal of automation is always repeatable and reusable test scripts that do not require significant maintenance work. This is especially important in an agile development environment, when code is constantly and quickly evolving. This successful agile testing method can be utilized for all the latest Web 2.0 technologies, including: Flex, Flash, Ajax, GWT, Silverlight, Dojo, YUI, Java, Windows Presentation Foundation, and other Rich Internet Applications (RIA) frameworks.

About the Author: Jeremy Greshin is vice president for business development at Hartford-based Telesis, a provider of QA and software testing solutions. He can be reached at (860) 289-4504 [email protected]

Register for Insurance & Technology Newsletters