Testing firewalls have proven to be a useful approach for regression testing in both functional and objectoriented software. They involve only the modules that are closely related to the changed modules. They lead to substantially reduced regression tests but still are very effective in detecting regression faults. This paper investigates situations when data-flow paths are longer, and the testing of modules and components only one level away from the changed elements may not detect certain regression faults; an extended firewall considers these longer data paths. We report empirical studies that show the degree to which an extended firewall detected more faults, and how much more testing was required to achieve this increased detection. L. WHITE ET AL.based on a repeated software change, and the goal of the regression testing is to find residual problems in the unchanged parts of the software.A primitive regression testing strategy would re-run all tests that validate functionality of all software components that were not impacted by the change. However, the regression tests need to be repeated frequently, making the re-run of the complete regression test too expensive; therefore, several heuristics were developed as a response. Selective testing means that although an initial test suite has been developed and is available, the programmers select only a subset pertinent to testing the specific changes made in the software [1,2]. Another approach emphasizes prioritization, where the priority is established among the tests and the tests are run within the available time, based on their priority [3].Selective and prioritization testing assumes that the regression test suite exists and has the desirable quality. However, we have found that often in industrial practice, the initial test suites are inconsistent and poorly constructed. For this situation, we have developed an approach to regression testing called firewall testing that emphasizes an on-demand test creation rather than selection from a given testing suite; of course, existing tests can always be reused, if they satisfy the firewall criterion. The firewall testing considers only components that are directly interacting with the changed components (one level away) and thoroughly tests them. Firewall testing is based on the observation that most residual bugs are caused by a failure of the programmer to propagate the change to some directly interacting program components. The firewall is an imaginary boundary between these components and the rest of the software system.As a method of regression testing for industrial situations, the testing firewall (TFW) has proven to be a useful approach for both procedure-oriented and object-oriented software. It has turned out to be particularly useful in the situations where the test suites are incomplete, which is a common situation in industrial software development; the firewall allows the identification of missing tests and provides a simple procedure to develop these missing tests. TFW has been developed for vario...
A testing firewall involves identifying various components that are dependent upon changed elements, but are just one level away from the modified elements. This paper investigates situations when data flow paths are longer, and the mechanism of thorough testing of components one level away from the changed elements may not detect certain regression faults caused by the change; this research has led to the notion of an extended firewall that takes these longer data paths into account. Empirical studies are reported that show the extent to which an extended firewall can detect more faults and how much more testing is required to achieve this increased detection.
Many software development organizations support reuse by moving towards assembling software products using multiuse components that can fit a wide range of products and environments. In order to support the design and integration of multi-use components we are presenting the usage of component interaction adapters. Adapters are used to encapsulate, interconnect and manage multi-use component interactions.Isolating and managing the components' interactions outside the components using adapters decrease components' complexity, increase their reusability, and eases their integration.
In software development, stakeholders of the same project often collaborate asynchronously through shared artifacts. A traceability system links a project's artifacts and therefore provides support for collaboration among stakeholders. Different stakeholders are interested in different types of traceability links. The literature often states that traceability is useful but expensive to build and maintain. However, there is no study showing reduction in effort when traceability links among various software artifacts are provided and used during the maintenance phase. This paper presents a study evaluating the benefits of using traceability among requirements, design, code, code inspections, builds, defects, and tests artifacts in the maintenance phase. Before the study, a survey was conducted at a large industrial firm to determine the type of links that different stakeholders are interested in. Twenty-five stakeholders from this firm participated in a survey to define the type of traceability links that were of interest to them. With this result, a traceability link model is proposed that categorizes different types of traceability links based on stakeholders' roles. This link model was used in the study. Twenty-eight subjects from industry and academia participated in the empirical study that was conducted after the survey. A prototype link-tracing tool, TraceLink, was developed and used in the study to present traceability links to the experimental group, whereas the control group was not given any links to solve the tasks. Five maintenance tasks were used in the study. The results show a significant improvement in task accuracy (86.06%) when traceability links were given to the subjects. In conclusion, a traceability model based on an industrial survey provided traceability views that are based on stakeholders' roles. This empirical study provides evidence that traceability links are effective in solving maintenance tasks with higher accuracy.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.