We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Software Test Management and Metrics

Vishi Viswanath

Software Test Management - Plugging Holes in Test Coverage for an Application in Production

Vote 0 Votes

This blog provides a glimpse of techniques used in enhancing test coverage of an application under test (AUT). The AUT was an application that had evolved from legacy perspective and came with very little documentation. The AUT was being used around 1800 installations around the nation and had seen many features added to it since the time it was brought to the customer. The customers had significant issues in dealing with errors reported from the field (end-users).

The AUT was developed originally using Microsoft VB and later had .NET parts added to it. The additions were made with fairly good level of documentation and standard approaches. The problems arose when the release was moved into production. The interaction of the application components with the various legacy modules was unpredictable. The testing process proved inadequate as the releases began to increase in a steady manner.

The customer was faced with the situation of either reverse engineering the AUT to capture the functionalities or re-writing the entire legacy component. It was impossible to do either as the team that supports this AUT was constantly under pressure to deliver newer features. On top of this, the AUT was undergoing migration to later versions of VB or additions being done in .NET.

After a lot of struggle, the management was able to allocate a budget to mitigate this issue and invited a team that specialized in testing to improve the test coverage.
The team came in and did an orientation exercise of the current scenario. It was determined that the optimal way to capture the functionality of the AUT was to look at from the way the user sees the functions and features. Following this approach, the team built the various scenarios of the AUT. The scenarios included the roles and user profile based models.

This approach though was a great way to build a repository of modules in an AUT, it also created lot of duplicate paths as the functions are used in several different ways. Therefore, the team devised a filtering model to uniquely identify functions or program parts of the AUT for the purposes of deriving test cases and test data. The filtering model included rationalization and aggregation of functional flows and components of the AUT.

The test cases were classified further in terms of common functionality and specific functions. For example, common data variables (ex. Date of birth, date of visit, etc.,) were grouped under one scenario. Also, the grouping of boundary, positive and negative value test cases provided clarity and ease of use.

Additionally, the team looked at the defects that had been logged and used them to define the test case conditions. This ensured that the defects that had been reported were covered by the test cases, that is, the defects were recognized within the test cases.

A 10 point selection criterion was used in determining the candidate test cases for automation. The automation approach was based on creating a set of test scripts that included a driver script. Again this was done to improve the ease of use and maintenance of the scripts for the future.

The test cases were prepared and test scripts were created. They were run once as part of the exercise and cataloged into the repository.

The test coverage was seen to increase to near 100% after the exercise. This is one way to look at improving the quality of applications that are out there for a long time. However, it is a time consuming and arduous task and needs to be executed with precision and thorough planning.

Leave a comment

Software Testing is an important aspect in software development and maintenance. Irrespective of the models deployed for the development of systems, there is always a need for measurement and management of testing.This blog attempts demystify the testing challenges and guides you to measure the required testing efforts.

Vishi Viswanath

Vishi is a managing partner in Intellisys Technology, LLC. He has been in the information technology field for over 29 years.Progressively grown from a programming position to the executive level.

Recently Commented On


Monthly Archives