Abstract
Software Operational Profile (SOP) is a software specification based on how users use the software. This specification corresponds to a quantitative representation of software that identifies the most used software parts. As software reliability depends on the context in which users operate the software, the SOP is used in software reliability engineering. However, there are evidences of a misalignment between the software tested parts and SOP. Therefore, this paper investigates a possible misalignment between SOP and the tested software parts to obtain, based on experimental data, more evidence of this misalignment. We performed an exploratory study composed of four activities to verify: a) whether there are significant variations in how users operate the software; b) whether there is a misalignment between SOP and the tested software parts; c) if failures occur in untested SOP parts in case of misalignment; d) in case of misalignment between SOP and untested software parts, whether a test strategy based on the amplification of the existent test set with additional test data generated automatically, can contribute to reduce the misalignment. We collected data form four software while users were operating them. We analyzed this collected data in an attempt to reach the goals of this work. To evaluate the originality of this research, we performed a Literature Systematic Review (SLR) and presented its conclusions. The obtained results evidence that there are significant variations in how users operate the software and also that there is a misalignment between SOP and the tested software parts when we evaluated the four software mentioned above. There are also indications of the occurrence of failures in the untested SOP parts. Although the test strategy mentioned above has reduced the possible misalignment, the test strategy is not enough to avoid it, thus denoting the need of specifics test strategies using SOP as a test criterion. These results indicate that SOP becomes relevant not only to software reliability engineering but also to contribute to testing activities, regardless of the adopted strategy.

Abstract
Reverse engineering may be helpful for extracting information from existing apps to understand them better and ease their maintenance. Reverse engineering may be performed by a static analysis of the apps’ code but, when the code is not available, a dynamic approach may be useful. This paper presents a tool that allows extracting dynamically, in a complete black-box approach, the explored activities of Android applications. It is an extension of iMPAcT testing tool that combines reverse engineering, dynamic exploration, and testing. The extracted information is later used to construct an HFSM (Hierarchical Finite State Machine) with three distinct levels of abstraction. The top-level shows the interactions needed to traverse the activities of the mobile application. The middle level shows the screens traversed while in a specific activity. The bottom level shows all screens traversed during exploration. This information helps to understand better the application which facilitates its maintenance and errors fixing. This paper provides a complete description of the tool, its architecture and the results of some case studies conducted on mobile apps publicly available on the Google Store.

Abstract
In today’s software industry, systems are constantly changing. To maintain their quality and to prevent failures at controlled costs is a challenge. One way to foster quality is through thorough and systematic testing. Therefore, the definition of adequate tests is crucial for saving time, cost and effort. This paper presents a framework that generates software test cases automatically based on user interaction data. We propose a data-driven software test generation solution that combines the use of frequent sequence mining and Markov chain modeling. We assess the quality of the generated test cases by empirically evaluating their coverage with respect to observed user interactions and code. We also measure the plausibility of the distribution of the events in the generated test sets using the Kullback-Leibler divergence.

Abstract
In the context of SaaS (Software as a Service) where software has to be up and miming 7 days a week and 24 hours a day, keeping the requirements specification and related test cases up to date can be difficult. Managing requirements in this context has additional challenges that need to be taken into account, for instance, re-prioritize requirements continuously and identify/update new dependencies among them. When requirements change, related test cases need to be updated accordingly. We claim that extracting and analyzing the usage of the SaaS can help to maintain requirements and test cases updated and contribute to improve the overall quality of the services provided. This paper presents an extension to REQAnalytics. REQAnalytics is a recommendation system that collects information about the usage of a SaaS and generates recommendations to improve the SaaS provided. The evolution involves extending the analysis performed over the sequences of functionalities (requirements) and refining the data provided for Software Requirements Specification, with the purpose of helping the requirements engineers in the requirement maintenance activities, and to improve the overall quality of the services. Furthermore, the extension presented in this paper is able to generate test cases in a regression testing context. (C) 2021 The Authors. Published by Elsevier B.V.

Abstract
This paper presents Alloy4Fun, a web application that enables online editing and sharing of Alloy models and instances (including dynamic ones developed with the Electrum extension), to be used mainly in an educational context. By introducing secret paragraphs and commands in the models, Alloy4Fun allows the distribution and automated assessment of simple specification challenges, a mechanism that enables students to learn the language at their own pace. Alloy4Fun stores all versions of shared and analyzed models, as well as derivation trees that depict how they evolved over time: this wealth of information can be mined by researchers or tutors to identify, for example, learning breakdowns in the class or typical mistakes made by Alloy users. A data analysis library is also provided to support this process. Alloy4Fun has been used in formal methods graduate courses for 3 years and for the latest editions we present results regarding its adoption by the students, as well as preliminary insights regarding the most common bottlenecks when learning Alloy (and Electrum).

Abstract