A test scenario approach to support regression testing

Abstract

Software maintenance is a process of modifying delivered system due to a change in user requirements or other parts of software system. A system undergoing any modifications is seen to have a tendency to introduce new unintended errors into the program (Rajlich and Wilde, 2000). In order to alleviate these problems, regression testing is required as a process of retesting the software after modification. Regression testing is a process of testing changes to software programs to make sure that the previously run functionalities still work with the new changes. Regression testing activity is necessary at showing that the codes have not been unfavorably affected by changes, but on one hand, it is a costly and lengthy process (Soloway et at., 1988; Corbi, 1989). Common methods of regression testing include rerunning the entire batch of test cases previously run against the system is considerably laborious and costly. As such, a more acceptable solution is to be more selective when choosing the appropriate test cases for regression. Modified codes are usually retested with the test data sets previously used. Successful regression requires the retention and management of old test data sets throughout the software development life cycle. There are efforts of regression working on static analysis e.g. (Wilde and Casey, 1996; Ibrahim et al., 2005). They claim that their effort can minimize the complexity of testing and reduce time. We agree with the principle that regression testing by dynamic analysis produces an accurate result as it involves program execution (Rajlich and Wilde, 2000). Dynamic regression is preferable by many software engineers as it can traverse all the possible paths that the static analysis may miss. The only considerable initiative is how to manage the task with appropriate approach and tool supports. A test scenario approach that is being coined in this related work is Software Reconnaissance (Wilde and Casey, 1996). Reconnaissance technique was originally inspired by the industrial maintainers about the need for better ways to locate software features in large systems. It was a result of discussion and comments from the maintainers’ point of view in handling maintenance tasks as expressed by the Software Engineering Research Centre (SERC), an NSF supported consortium of universities and software organizations. However, the approach and implementation of reconnaissance techniques may vary depending on the problems and objectives being handled. In this paper, we would like to present our experience in using reconnaissance techniques and associated tools we developed at the Centre For Advanced Software Engineering, University of Technology, Malaysia. These tools were built to support maintainers locate parts of the code being impacted by each functional requirement. In other words, it helps maintainers identify those impacted code being executed by a concept or feature during test scenarios. Section 2 of the paper discusses the theoretical aspects of the concept location. Section 3 presents the software reconnaissance techniques. Software dependency and its related issues are discussed in Section 4 followed by a case study of OBA project in section 5. Section 6 highlights some results of the case study and discussion. Section 7 presents some related works followed by a conclusion.