Abstract
Testing interactive systems is known to be a complex task that cannot be exhaustive. Indeed, the infinite number of combination of user input and the complexity of information presentation exceed the practical limits of exhaustive and analytical approach to testing [31]. Most interactive software testing techniques are produced by applying and tuning techniques from the field of software testing to try to address the specificities of interactive applications. When some elements cannot be taken into account by the software testing technique, they are usually ignored. In this paper we propose to follow an opposite approach, starting from a generic architecture for interactive systems (including both software and hardware elements) for identifying in a systematic way, testing problems and testing needs. This architecture-driven approach makes it possible to identify how software testing knowledge and techniques can support interactive systems testing but also where the interactive systems engineering community should invest in order to test their idiosyncrasies too.
Highlights
Some recent work has been trying to extend the part of the Application Under Test (AUT) beyond the graphical user interface (GUI) by considering the execution platform (e.g. Android [38])
To highlight how interactive system testing is difficult, we present some informal examples of the diversity of requirements and constraints that have to be taken into account while testing (Table 1)
These examples find their origins in the definitions of elements of interactive systems, in the specifications of interactive systems or in authors’ experiences with interactive systems
Summary
Interactive systems testing involves different methods and techniques depending on the objectives of these tests. The field of software engineering has been focusing on finding defects that affect software quality and software-related properties (such as reliability, performance, availability, security...) This field has been developing methods, techniques and tools to perform software studies involving the Application Under Test (AUT) and a list of input to be provided to reveal defects. In this paper we propose to follow an approach starting from a generic architecture dedicated to interactive systems (including both software and hardware elements) for identifying, in a systematic way, testing problems and testing needs. This architecturedriven approach makes it possible to identify how software testing knowledge and techniques can support interactive systems testing.
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.