Justification and Considerations in Profiling Automated Testing in Software Maintenance Organizations for E Type Systems

The decision to implement automated software testing will get most of its attention during the early stages of the system development life cycle. Traditionally, if it\u27s not introduced then, it is likely it will not be introduced during the maintenance cycle. However, the bulk of development on a system occurs during its maintenance cycle, and the internet has made legacy systems even more susceptible to an unpredictable environment of peaks in volume access not witnessed before. This paper asserts organizations should evaluate the need for automated test tools at a strategic level in the context of their value to the business and also presents a tool to facilitate that discussion. Premise: If automated testing was not introduced during the development of a large system, is it no longer necessary to consider? Apparently, some large Fortune 500 corporations believe it is not [Survey02]. This paper asserts that it is necessary to evaluate the need for automated testing for software which is about to be transitioned to or already exists in a maintenance environment. Its three primary contentions are as follows: 1. Transition to a maintenance environment takes on new dynamics in personnel skills, staffing levels and support requirements. It would follow, then, that a different perspective of the product\u27s value and development needs from the original producers will exist. Further, the completion of the development and delivery cycles does not imply the software package is complete and free of faults. 2. Automated software testing must have a demonstrated value to the business to ensure budgetary support. 3. The first step in gaining budgetary support is to establish a profile which can be represented in a tool to facilitate communication between information technology professionals and senior managers of a business. Automated software testing is not a silver bullet to software engineering. [Fewster99 p288, Dustin99]. However, automated testing can provide significant gains in labor savings to an organization [Dustin99]. Given that 70 percent of most developers are assigned to work in maintenance roles [McNurlin02], it would appear that the maintenance environment with limited or no automated testing would be an area to derive the greatest benefit. Robert Poston warns, though, tools should be introduced only as changes are required. This paper does not disagree with Poston\u27s contention. However, in the case of E-type systems, which continually experience change [Lehman00], a change in the view of the software happens once it is placed into a maintenance environment. [Pfleeger01] Due to that, maintenance organizations should reevaluate their need for automated testing upon receipt of new applications, particularly where complex interoperability of systems exists