title: Multi-Aspect Test Case Specification and Automation based on Cause-Effect Analysis a Case Study in Industrial Environments
Creators: name: Sherstneva, Serafima
Publisher: name: TU Wien
Year: 2022
Subjects: subject: Risk Management
subject: Case Study
subject: Knowledge Model
subject: Mult-Aspect Testing
subject: Cyber-Physical Production Systems
subject: Multi-disciplinary Engineering
subject: Test Case Specification
subject: PPR Asset Network

description: Kontext und Motivation. In “Multi-disciplinary Engineering” (MDE) Umgebungen, ist das Wissen über unterschiedliche Aspekte eines System, wie “Product, Process and Resources” (PPR) Spezifikationen, als auch Umweltfaktoren und deren Einflüsse auf das Produkt und den Prozess häufig auf Experten unterschiedlicher Disziplinen verteilt, die divergierende Blickwinkel auf das System haben. Dadurch fällt es oft schwer, dieses Wissen an einem Ort zu konzentrieren. Testen ist eine Methode, um beabsichtigte Effekte zu erforschen, wie zum Beispiel ob das Produkt die erwarteten Anforderungen erfüllt, ob der Produktionsprozess die notwendige Durchsatzleistung erbringt, oder Risiken, die zu unerwünschten Effekten führen, zu überprüfen. Traditionelle Testmethoden betrachten of nur Effekte, die einer bestimmten Disziplin zuzuordnen sind. In MDE’s, etwa bei “Cyber-physical Production Systems” (CPPS) ist die Formulierung und Validierung von Ursachen-Wirkung-Hypothesen eine komplexe Aufgabe. Dadurch bleiben Risiken, auch bei der Verwendung von systematischen Testmethoden, oft unentdeckt. Ziele. Das primäre Ziel dieser Studie ist der Entwurf eines Ansatzes, der die systematische Testplanung, Messung und Analyse in MDE Umgebungen, auf Basis der Ursachen-Wirkung-Analyse, ermöglicht. Methoden. Basierend auf dem Ziel wurden die folgenden Forschungsfragen formuliert:(1) Welche Risikotreiber motivieren Multi-Aspekt Risikobasiertes Testen von Ursachen-Wirkung-Hypothesen zwischen Eigenschaften des Produktionsprozesses und Parametern/Einflüsse der Produktionsressourcen? Das Subset der Risikotreiber wurde durch den Forschungsüberblick und Workshop-Veranstaltungen mit Fachexperten abgeleitet.(2) Welches Wissensmodell kann Multi-Aspekt Ursachen-Wirkung-Hypothesen zwischen Eigenschaften des Produktionsprozesses und Parametern/Einflüsse der Produktionsressourcen repräsentieren? Aufbauend auf der “Failure Modes and Effects Analysis” (FMEA) zur Unterstützung von systematischem und effizientem Risikomanagement, “PPR Asset Network” (PAN) Metamodell zur Beschreibung einer CPPS Struktur und “CPPS Risk Assessment (CPPS-RA) Metamodell und Methode die FMEA, PAN und Ursachen-Wirkung-Analyse Aspekte verbindet, erweitert um testrelevante Aspekte, wurde das “Multi-aspect Test Case Specification” (MATCS) Metamodell erstellt und fachspezifische Wissensmodelle abgeleitet. (3) Welche Prozessschritte sind zur Unterstützung von Multi-Aspekt-Testung in “CPPS” und Softwaretechnik erforderlich? Basierend auf dem “Test Driven Development” (TDD) Ansatz zur Unterstützung von Software Design, der “Equivalence Class Partitioning” (ECP) Technik zur Aufteilung des Testraumes in Datenklassen und Gherkin Notation zur einfachen repräsentation von automatisieren Tests, wurde MATCS konzipiert. Die Risikoteiber, das MATCS Metamodell und die MATCS Methode repräsentieren in Kombination den MATCS Ansatz. Um die Forschungsfragen zu beantworten, wurde der “Design Science Research” Ansatz angewandt. Ergebnisse. MATCS führt das Subset an fachspezifischen Risikotreibern, das MATCS Metamodel und Methoden ein. Die Evaluierung des Ansatzes zeigt aussichtsreiche Resultate im Kontext von zwei Fallstudien in den Bereichen von CPPS und Softwaretechnik.Der Ansatz unterstützt die Fachexperten bei der Spezifikation von effizienten Testfällen für die Validierung der Ursachen-Wirkung-Hypothesen, der Definition des Umfangs und Limitationen der Testautomatisierung und macht das Experimentieren für Systemverbesserungen systematischer im Vergleich zu traditionellen Ansätzen. Ein PAN ist die Voraussetzung für eine effiziente Anwendung des Ansatzes. Fazit. MATCS hilft dabei, das implizite Wissen der multi-disziplinären Fachexperten explizit zu machen und schlägt weitere Schritte für die Qualitätsexperten vor, um Multi-Aspekt Testfälle zu spezifizieren und sowohl Umfang als auch Limitierungen für die Testautomatisierung zu definieren. Die initiale PAN Definition erfordert zwar Mehraufwand, macht sich aber in zukünftigen Iterationen im Kontext einer kontinuierlichen Verbesserungsstrategie bezahlt.
description: Context and Motivation. In Multi-disciplinary Engineering (MDE) environments, knowledge on different aspects of the system, such as product, process and resources (PPR) specifications, as well as environmental factors, and their influence on the product and process quality is often distributed among experts coming from multiple disciplines and having different views on the system, and has been found hard to concentrate in one place. Testing is a method to explore intended effects, such as whether a product matches expected requirements, a production process meets performance goals, as well as to check for risks, which could cause undesired effects. Traditional testing methods often consider causes responsible for the effects coming from one discipline. However, in MDEs, such as Cyber-physical Production Systems (CPPS) engineering, due to their multi-disciplinary nature, systematic formulation and validation of cause-effect hypotheses is a complex task, therefore risks often remain undiscovered by systematic testing methods. Objectives. The primary objective of this study was to design an approach to enable systematic test planning, measurement and analysis in MDE environments based on cause-effect analysis. Methods. Based on the goal, the following research questions were formulated: (1) Which risk drivers motivate multi-aspect risk-based testing of cause-effect hypothesesbetween production process characteristics and production resource parameters/influences? The sub-set of risk drivers was derived from the literature review and workshops with domain experts. (2) What knowledge model can represent multi-aspect cause-effect hypotheses betweenproduction process characteristics and production resource parameters/influences? Built on the Failure Modes and Effects Analysis (FMEA) to support systematic and efficient risk management, PPR Asset Network (PAN) meta-model to describe a CPPS structure, and CPPS Risk Assessment (CPPS-RA) meta-model and method which connects FMEA, PAN and cause-effect analysis aspects, extended with test related aspects, Multi-aspect Test Case Specification (MATCS) meta-model was designed and domain specific knowledge models were derived. (3) What are the process steps to support multi-aspect testing in CPPS and softwareengineering? Based on the Test Driven Development (TDD) approach to support system design, Equivalence Class Partitioning (ECP) technique to divide the test space into classes of data, and Gherkin notation to allow easy representation of automated tests, MATCS was designed. Risk drivers, MATCS meta-model and MATCS method combined represent the MATCS approach. In order to answer the research questions, the Design Science Research approach, supported by a literature review was followed. MATCS was evaluated in CPPS and software engineering industrial case studies, which included workshops and experiments. Results. MATCS introduced the sub-sets of domain specific risk drivers, MATCS meta-model and method. The evaluation of the approach has shown promising results in context of two case studies, in CPPS and software engineering domains. The approach supports the domain experts in efficient test case specification for cause-effect hypotheses validation, definition of scope and limitations for test automation and makes experimentation for system improvements more systematic in comparison to the traditional approach. High quality PAN is the prerequisite for efficient application of the approach. Conclusion. MATCS helps to make the implicit multi-disciplinary expert knowledge explicit and suggests steps to the quality experts allowing them to specify multi-aspect test cases and define the scope and limitations for test automation. The initial PAN definition requires considerable effort, however, it is expected to pay off in future iterations in context of continuous integration strategy.