Search

This article is devoted to the survey, analysis, and classification of operational profiles (OP) that characterize the type and frequency of software inputs and are used in software testing techniques. The survey follows a mixed method based on systematic maps and qualitative analysis. This article is articulated around a main dimension, that is, OP classes, which are a characterization of the OP model and the basis for generating test cases. The classes are organized as a taxonomy composed of common OP features (e.g., profiles, structure, and scenarios), software boundaries (which define the scope of the OP), OP dependencies (such as those of the code or in the field of interest), and OP development (which specifies when and how an OP is developed). To facilitate understanding of the relationships between OP classes and their elements, a meta-model was developed that can be used to support OP standardization. Many open research questions related to OP definition and development are identified based on the survey and classification.

This article on teaching software reliability engineering (SRE) represents a consensus of views of experienced software reliability engineering leaders from diverse backgrounds but with ties to education: directors of software reliability and software reliability training in industry, a consultant who teaches SRE practice to industry, and university professors. The first topic covered is how to attract participants to SRE courses. We then analyze the job-related educational needs of current and future (those now university students) software practitioners, SRE practitioners, researchers, and nonsoftware professionals. Special needs relating to backgrounds, limited proficiency in the course language, and work conflicts are outlined. We discuss how the needs presented should influence course content and structure, teaching methods, and teaching materials. Finally, we cover our experiences with distance learning and its special needs. Some of this article applies to any course and is not SRE-specific.

Model-based testing is an effective black-box test generation technique for applications. Existing model-based testing techniques, however, fail to capture implicit domain-specific properties, as they overtly rely on software artifacts such as design documents, requirement specifications, etc., for completeness of the test model. This article presents a technique, HOTTest, which uses a strongly typed domain-specific language to model the system under test. This allows extraction of type-related system invariants, which can be related to various domain-specific properties of the application. Thus, using HOTTest, it is possible to automatically extract and embed domain-specific requirements into the test models. In this article we describe HOTTest, its principles and methodology, and how it is possible to relate domain-specific properties to specific type constraints. HOTTest is described using the example of HaskellDB, which is a Haskell-based embedded domain-specific language for relational databases. We present an example application of the technique and compare the results to some other commonly used Model-based test automation techniques like ASML-based testing, UML-based testing, and EFSM-based testing.