Aiding exploratory testing with pruned GUI models

Abstract

Exploratory testing is a software testing approach that emphasizes the tester's experience in the attempt to maximize the chances to find bugs and minimize the time effort applied on satisfying such a goal. It is naturally a GUI-oriented testing activity for GUI-based systems. However, in most cases, exploratory testing strategies may not be accurate enough to reach changed code regions. To reduce this gap, in this work, we propose a way of aiding exploratory testing by providing a GUI model of the regions impacted by internal code changes (for example, as result of change requests to fix previous bugs as well as for software improvement). We create such a delimited GUI model by pruning an original GUI model, quickly built by static analysis, using a reachability relation between GUI elements (i.e., windows, buttons, text fields, etc.) and internal source code changes (classes and methods). To illustrate the idea we provide promising data from two experiments, one from the literature and another from our industrial partner.

An automated Android exploratory testing based on code evolution coverage

“…ArcWizard is a tool to aid exploratory testers to focus their work on the most recent changes detected from two versions (code evolution) of a given APK [4]. Although the goal of ArcWizard is to provide English-based test scenarios so testers can understand and execute, ArcWizard uses source code to develop its task.…”

“…To face those challenges, we developed a tool called AETing, which reuses ArcWizard test scenarios (to be exercised by testers) [4], to generate automated test cases that cover the differences between two versions of code evolution of a given APK through screen navigation and Monkey testing [5]. This approach does not require a human for (1) maintaining test case descriptions (2) or even automating test cases based on incoming changes.…”

HSP: A hybrid selection and prioritisation of regression test cases based on information retrieval and code coverage applied on an industrial case study

“…Last but not least, it would be possible to identify the area of code that was not exercised during the test campaign. Using this information together with Reis and Mota [2018] it would be possible to have the navigation that would reach the non-exercised area. In order to complement the test and ensure consistency the work Sampaio and Arruda [2016] helps to solve the dependencies of the test and ensure that it could run.…”

An Automated Testing Framework For Smart TV apps Based on Model Separation

“…As a result, we could not find a tool or a strategy that follows the same approach to re-engineering the app and generate the mega-model. Following the literature, an alternative and natural comparison solution are to compare with the manual exploratory testing approach [27]. However, the manual exploration of the app could be subjective in some situations as it might be affected by the participant who is doing the testing.…”