Entwicklungsbegleitende Testautomatisierung

von Dirk Beinert

1. Einleitung

Entwicklungsbegleitende Tests – im Gegensatz zu der Implementierung nachgelagerten Tests – haben den Vorteil der Just-In-Time-Verfügbarkeit von Aussagen zur Softwarequalität. Klassisch – auch nach dem V-Modell – war der Systemtest lange als Endvalidierung nach einem Code-Freeze angeordnet. Aussagen zu Stabilität der Software und zum Fertigstellungsgrad waren spät bzw. zum Abschluss einer Iteration gar nicht verfügbar. Regressionstests haben nur die finale Fehlerbehebungsphase begleitet, statt den Entwicklern während ihrer gesamten Arbeit frühzeitig die Auswirkungen ihrer Architektur und Wechselwirkungen mit benachbarten Modulen zu verdeutlichen. Entscheidende Warnungen aus dem Test zur Kopplung und Kohärenz der Software wurden somit nicht genutzt. Die nur temporäre Zusammenarbeit von Testern führte zur mangelnden Kooperation zwischen Systemtest und Entwicklung mit oft beobachteten Spannungen und Schuldzuweisungen.

Testing

Wenn zudem die späte Testphase noch manuell durchgeführt wird, dann leidet die Reproduzierbarkeit der Tests einerseits zur Verdeutlichung der Fehler für den Entwickler und andererseits für Re-Tests nach der Fehlerbehebung. Der Druck auf das Testteam schneller (und somit weniger gründlich) zu prüfen wächst, da die produktive Entwicklung ja abgeschlossen ist und nur noch die „unproduktiven“ Tester eine Freigabe verhindern. Der Weg für eine beim Kunden reifende und für Unzufriedenheit sorgende Software ist geebnet.

Frage: Was spricht also noch dagegen, parallel zur Entwicklung die Tests zu beginnen und diese auch gleich zu automatisieren?

Antwort: Nichts. Im Wesentlichen ist nur noch der realisierbare Return-on-Invest zu vertreten, der bei sorgfältiger Planung und Beachtung von Design-Prinzipien sichergestellt werden muss. Zum einen müssen sich die Testaufwände bei begleitenden Tests „auszahlen“, damit keine zusätzlich aufwändigen nachgelagerten Tests, wie im klassischen Fall, mehr anfallen. Zum Code-Freeze sollten lediglich noch Regressionstests notwendig sein. Der Hauptanteil der Fehler wird idealerweise entwicklungsbegleitend gefunden und gelöst.

Entwicklungsbegleitende Testautomatisierung Abbildung 1

Andererseits sind die Kosten der Automatisierung initial höher und zahlen sich erst bei mehreren Iterationen aus. Während im Falle einer weitgehenden und vorausschauenden Testautomatisierung in späten Iterationen lediglich automatische Regressionstest mit einem niedrigen Anpassungs- und Kontrollaufwand zu leisten sind, wären für rein manuelle Tests wiederkehrende und kontinuierlich steigende Aufwände notwendig. Steigende und wiederkehrende Aufwände bei manuellen Tests. Angaben beispielhaft in Aufwandstagen des jeweiligen Iterations-Gesamtaufwands.

Entwicklungsbegleitende Testautomatisierung Abbildung 2

Im Falle einer jahrelang fortlaufenden Produktweiterentwicklung hat sich ein Verfahren etabliert, das den nachlaufenden Test mit allen Nachteilen akzeptieren hilft. Die Pausen zwischen der Implementierung der Produktversionen können für Spezifikation und Tests genutzt werden und so den Entwicklungs- und Testleerlauf zumindest in geringem Maße begrenzen helfen.

Entwicklungsbegleitende Testautomatisierung Abbildung 3

Ein solches gewohntes, „klassisches“ Szenario auf dynamische und neue Projekte zu übertragen, wird jedoch zwangsläufig zu den beschriebenen Nachteilen wie Terminverzug und Mehraufwand führen, die der Geschwindigkeit der Märkte nicht mehr angemessen sind.

2. Testphasen innerhalb der Software-Entwicklungsmodelle

a. V-Modell (W-Modell)

Nach dem klassischen V-Modell werden lediglich die Modul- oder Unit-Tests entwicklungsbegleitend durchgeführt. Die Systemtests werden nach Abschluss der Implementierung durchgeführt, die Entwickler müssen sich für Bugfixing in ggf. geringer Mannschaftsstärke bereithalten. Allerdings können die Tests nach Freigabe der Designspezifikationen zumindest schon mal vorab spezifiziert werden.

Entwicklungsbegleitende Testautomatisierung Abbildung 4

Ideal wäre es, wenn die Testkonzepte und Spezifikationen schon während der Anforderungsspezifikation mit in die Überlegungen einbezogen werden. Dies hat zu einer Erweiterung, dem sogenannten W-Modell, geführt. Testbarkeit ist als wesentliches Requirement aufgenommen worden, auch wenn es mit dem für den Kunden sichtbaren Produkt direkt nichts zu tun hat.

Entwicklungsbegleitende Testautomatisierung Abbildung 5

Die Entwickler sind während der Implementierung für ihre Modultests (i.d.R Unit-Tests mit JUnit, NUnit) verantwortlich. Diese Tests können nicht nur für Clientsoftware (SiL-Test) am PC, sondern auch für Steuerungsfirmware z. T. schon auf der realen Hardware (HiL-Test) durchgeführt werden, wenn beispielsweise ein Monitoring des instrumentierten Codes und eine Stimulation per PLC-Anwenderprogramm verfügbar ist.

Im Integrationstest werden die unterschiedlichen Komponenten auf ihre SchnittstellenKompatibilität hin geprüft. Insbesondere für sicherheitsrelevante Steuerungen (Basisnorm ISO 6-/1508) ist dies die Phase, in der nachgewiesen werden muss (u. A. per Fehlerinjektion), dass die Komponenten gegen Ausfälle von Teilmodulen gewappnet sind und im Fehlerfall einen sicheren IO-Zustand erreichen. Der Systemtest ist gekennzeichnet durch Validierung der Kundenanforderungen und der Mengengerüst- und Belastungsgrenzen des Systems. Der Abnahmetest spiegelt in der Regel gezielt ein dediziertes Kundenszenario wieder.

Entwicklungsbegleitende Testautomatisierung Abbildung 6

b. Agiles Vorgehen (Scrum)

Bei agilen Projekten werden oft nur die Vorteile der kurzen und selbstbestimmten Implementierungszyklen betrachtet. Der Test der Software ist hier allerdings sogar noch besser integrierbar, da das Ziel z. B. eines Sprints immer ein lauffähiges, prinzipiell lieferbares und somit gut testbares Release ist.

Je nach Organisationsstruktur der Entwicklungsabteilung ist die Bildung eines heterogenen Scrum-Teams (Entwickler und Tester gemeinsam) oder auch die Trennung in ein eigenes Team für die Test-Crew (mit dem gleichen Sprint-Backlog) möglich. Per „Continuous Integration“ (z. B. mit den Tools: Hudson/Jenkins, Team Foundation Server) ist ein täglicher Abgleich der beiden Teams möglich. Die im V-Modell bezeichnete Testphase Integrationstest und die notwendigen Lasttests und Stresstests würden in einem geeigneten Sprint begonnen werden und als Re-Test in späteren Iterationen wiederholt werden.

3. Testautomatisierung vs. manuelle Tests

Manuelle Tests führen schneller zu Ergebnissen – das ist unbestritten. Auf lange Sicht lohnt sich allerdings die Testautomatisierung – auch das ist hinreichend belegt. Die Automatisierung, meist in Form von Testskripten implementiert, darf sich jedoch nicht darauf beschränken, bestehende Testskripten lauffähig zu halten. Die Gefahr besteht, dass erfolgreiche Smoke-Tests, mehr Bug-Einträge generieren. Voraussetzungen für das erfolgreiche Generieren von Testergebnissen sind stabile Schnittstellen, hinreichende Modularisierung der Testskripte und frühe Berücksichtigung des Testdesigns während des Softwareentwurfs. Andernfalls rauben die Änderungsaufwände am Testsystem die Zeit zum Auffinden neuer Fehler. Eine enge Abstimmung mit der Entwicklung ist notwendig, um Blindleistung für den Test sich noch ändernder Funktionen zu verhindern.

4. Testcenter vs. Entwicklertests

Der Einsatz eines auf Testaufgaben spezialisierten Teams hat sich bewährt, da diese keine Fehlerblindheit mitbringen und in der Regel bereits über hinreichende Erfahrung mit etablierten Testwerkzeugen verfügen. Entwickler hingegen sind durch Ihren konstruktiven Fokus in der Regel nur für die Unit-Tests ihres Codes zu gewinnen. Der Einsatz einer Testautomatisierung (z. B. für UI-Systemtests) hat allerdings das Interesse der Entwickler gefunden. Der Charme die eigenen Implementierungen nachts auf einem Continuous Integration Server testen lassen zu können und somit selbst Sicherheit zur Qualität der eigenen Software zu gewinnen, wird jetzt schon von den Entwicklern insbesondere für Dauertests genutzt.

Zudem können die automatischen Tests Fehler direkt am Entwicklungssystem des Programmierers nachstellen, statt sich wie in der Vergangenheit mit dem Austausch von Screenshots oder Captures zu Erklärung der Repro Steps begnügen zu müssen.
In der Summe beginnt sich damit der Anteil der Testaufgaben, die der Entwickler übernehmen kann und zu leisten bereit ist, leicht zu erhöhen.

5. Besonderheiten der Tests von GUI-Software

Automatische Tests der Benutzeroberfläche sind in der Regel in der Systemtestphase angesiedelt. Durch Adapter für Windows-Controls oder Browser-Elemente lassen sich die Zustände der Oberfläche auslesen und stimulieren.

Entwicklungsbegleitende Testautomatisierung Abbildung 7

a. Technologie

Zahlreiche Frameworks (HP Quicktest Pro, Borland Silktest, Ranorex, QF-Test, Froglogic Squish, Selenium, …) bieten mehr oder weniger komfortable IDEs mit denen per Capture&Replay oder Keyword-Skript basiert automatische Tests erstellt werden können. Dabei ist zu beachten, dass die Capture Verfahren bei UI-Änderungen eine neue Komplettaufzeichnung notwendig machen kann. Eine programmatische Lösung z. B. per ExcelSkript-Interpreter sichert eine deutliche höhere Wiederverwendbarkeit. Eine Besonderheit stellt das Ranorex Studio bereit: Einmal per Recording aufgezeichnete Tests können nachträglich modularisiert und für weitere Testerstellung wiederverwendet werden. Eine somit erstellte Bibliothek von modularen Teilaufzeichnungen lässt sich wesentlich leichter anpassen und Keyword-ähnlich zu neuen beliebig umfangreichen Testskripten komponieren.

b. Benötigte Ressourcen und Know-how

Capture&Replay Tests sind prinzipiell ohne Programmierkenntnisse erstellbar. Allerdings hat sich herausgestellt, dass jede UI-Technologie in geringem Maße an das entsprechende Testframework angepasst werden muss. Dazu sollten in jedem Fall mindestens 1/3 der Tester als Testsystementwickler einsetzbar sein und je nach eingesetzter Technologie über .Net, Java, HTML, etc. Know-how verfügen. Für Web-basierte Software muss derzeit die Testautomatisierung fast durchgängig (mit geringem) Aufwand betreut und beobachtet werden, da die Browser-Hersteller Updates in schneller Folge bereitstellen.

c. Abstimmungsbedarf

Prinzipiell arbeiten die Tester unabhängig von den Entwicklern. Allerdings sollte die Entwicklungsplanung und die noch zu ändernden UI-Elemente und Workflows allen bekannt sein, um Blindleistung bei den Tests und der Anpassung des Testframeworks zu vermeiden.

d. Testabdeckung

Die erzielbare Requirement-Abdeckung kann 100 % erreichen, jedoch sollten einfach zu beurteilende aber nur aufwändig automatisch zu testende, grafische Anforderungen manuell bewertet werden. Der besondere Nutzen der Testautomatisierung liegt in der einerseits schnellen, aber auch möglichen Langzeit-Ausführung. Es werden somit Fehler entdeckt, die ein menschlicher User nur schwer entdecken und reproduzieren kann.

6. Besonderheiten der Tests von multidisziplinären Softwareprojekten

Oft entsteht der Wunsch ein reales Kundenszenario automatisiert zu testen. Dabei kommt sehr schnell eine Vielzahl von Technologien ins Spiel: Native PC-Software für Inbetriebnahme und Visualisierung, Web-Oberflächen, Firmware auf Steuerungen und Netzkomponenten, Hardware- und Feldbus-Schnittstellen, u. v. m. Darüber hinaus werden Tests für die Vielzahl der mobilen Endgeräte zunehmend wichtiger. Kaum ein Testwerkzeug kann hier alle Anforderungen vereinen.

Ob eine vollständige Testautomatisierung der PLC-Steuerungssoftware notwendig ist, hängt davon ab, ob diese integraler Bestandteil oder nur Hilfsmittel zum Betrieb des SUTs (im hier gezeigten Fall das Visualisierungssystem und die Hardware) ist. Für eine weitergehende Testabdeckung und zur Auflösung von Komplexität ist eine Separierung der verschiedenen Softwareschichten sehr gut geeignet.

Entwicklungsbegleitende Testautomatisierung Abbildung 8

Fehler- und unübliche Massendaten lassen sich so gezielt per Mock (im Gegensatz zum Stub) in das System einspeisen. Dies ermöglicht Tests, die im realen Kundenumfeld nicht möglich wären, da Einzelkomponenten diese Daten ggf. abweisen würden, bevor sie die zu testende Komponente erreichen.

a. Technologie

Zentrale Angriffspunkte für die Testautomatisierung sind auch hier wieder die bereits erwähnten Tools zur Stimulation der GUIControls für PC- und Browser-Applikationen. Geeignete Adapter für Bus- oder IO-Hardwareschnittstellen hingegen haben oft einen proprietären Charakter. LabVIEW (National Instruments) mit seinen zahlreichen vorgefertigten Schnittstellen und Messinstrumenten bietet hier einen hohen Investitionsschutz und erhöht die Wiederverwendbarkeit von Tests in sich ändernden Hardwareumgebungen. Zusätzlich lässt sich LabVIEW seit 2011 mit dem GUI-Automatisierungsframework Ranorex fernsteuern, so dass eine Durchgängigkeit der Toolkette gewährleistet ist.

b. Benötigte Ressourcen und Know-how

So vielseitig die Schnittstellen sind, so vielseitig muss auch das Know-how der Tester sein. Das gilt im besonderen Maße für proprietäre Adapter. Bei einer durchgängigen Tool-Kette erweitert sich das benötigte Spezialwissen gegenüber der GUI-Testautomatisierung auf z. B. LabVIEW VI-Programmierung. Der Ressourcenbedarf skaliert mit der Zahl der verschiedenen Endgerätetypen. Insbesondere für Konformitätstests sich beständig erweiternder Feldbus- und anderer Zielgeräte müssen Testmitarbeiter fast durchgängig greifbar sein, aber nicht unbedingt permanent daran arbeiten.

c. Abstimmungsbedarf

Durch die Vielzahl der Schnittstellen und Einzelprojekte ist eine frühe Abstimmung und Testplanung unerlässlich. Oft muss das Fehlen einer Komponente durch Simulatoren oder Mocks vorübergehend kompensiert werden. Bei der Automatisierung der Hardware-Schnittstellen-Zugriffe wird oft die Unterstützung durch die jeweiligen Entwickler benötigt.

d. Testabdeckung

Eine rein auf Kundenszenarien ausgelegte Testautomatisierung wird ausgewählte Regressionstests solide erfüllen können. Eine höhere Abdeckung wird jedoch erst durch Adressierung der unterschiedlichen Interfaces bei entsprechender Belastung und Dynamisierung erreicht.

7. Fazit/Ausblick

Generell sollte ein hoher Automatisierungsgrad der Tests im Softwareprojekt angestrebt werden. Gerade bei Last-, Dauer- und Konformitätstests mit verschiedensten Endgeräten wird ein manueller Test nur eine unzureichende Testabdeckung erzielen können. Trotzdem werden manuelle Testergebnisse bei der Erstellung der Automatisierung (Skripte) gewonnen. Ein Anteil von 20 % manuellen Tests ist hier sinnvoll.

Vor jedem neuen Testprojekt kann es nützlich sein, sich über die aktuellen Möglichkeiten der GUI-Testwerkzeuge zu informieren und diese auf Eignung hin zu evaluieren. Die Hersteller von Testframeworks setzen oft unterschiedliche Prioritäten (Plattformunterstützung, Skriptsprachen, PLM-Integration). Der allen gemeinsame derzeitige Trend zur Erfassung von Oberflächen mobiler Endgeräte ist unverkennbar. Allerdings sollte man bei der Auswahl nicht jedem neuen Test-Feature „hinterherlaufen“. Die gewonnene Erfahrung aus bisherigen Projekten mit dem darin eingesetzten Tool ist ein nicht zu unterschätzender Vorteil, der den Einstieg für ein Alternativ-Framework deutlich erschwert.

Insgesamt hat sich daher bei infoteam das bereits beschriebene Setup aus LabVIEW und Ranorex bisher bewährt (s. Abb. 9).

Ein Test Runner (entweder Skript-basiert oder per Ranorex Studio komponiert) adressiert sowohl die PC-Oberfläche (hier infoteam OpenPCS) als auch ein LabVIEW-Frontend, das die Hardwarekomponente ansteuert. Eine Anbindung an Testplanungswerkzeuge (hier insbesondere der Team Foundation Server) ist möglich.

Entwicklungsbegleitende Testautomatisierung Abbildung 9

Zur Zusammenarbeit im entwicklungsbegleitenden Test hat sich eine Struktur bewährt, die das Projekt- und Testmanagement klar von den konzentrierten Problemlösungsaufgaben trennt. Im agilen Prozess sind dies die Scrum-Master, die den Teams „den Rücken frei halten“.

Insgesamt können die Testaufwände daher einen Anteil von ca. 40 % am Gesamt-Entwicklungsbudget ausmachen. Zufriedene Kunden sollten dies wert sein.

8. Glossar

  • VI – Virtual Instruments, Komponenten der LabVIEW Programme
  • (G)UI – (Graphical) User Interface, Benutzeroberfläche der Software
  • Continuous Integration – Verfahren, täglich (nachts) Software zu kompilieren und zu testen
  • Scrum – Agiles Entwicklungsmodell mit klar abgeschlossenen Iterationen
  • Repro Steps – Reproduction Steps, Testschritte zur Fehlerreproduktion
  • PLM – Product Life Cycle Management, Projektverwaltung
  • TFS – Team Foundation Server, Microsoft PLM/ALM-Werkzeug
  • ALM – Application Life Cycle ManagementSoftware-Projektverwaltung
  • Mock – Schnittstellen-Stellvertreterobjekt als leerer Adapter
  • Stub – Schnittstellen-Stellvertreterobjekt mit simulierten Daten
  • SUT – System under Test, Testobjekt
  • HiL – Hardware in the Loop
  • SiL – Software in the Loop
  • Re-Test – Reproduktions-Tests, Prüfung nach Fehlerbehebung
  • Regressionstest – Zyklische Wiederholung der Tests zum Nachweis
  • Lasttest – Performance- und Mengengerüsttest
  • Stresstest – z. B. Mehrfachzugriffe, Spannungsausfälle, Busunterbrechungen
  • Code-Freeze – Abschluss der Implementierung nur noch Korrekturen erlaubt
  • Code-Coverage – Unit-Test Metrik, Zählung der geprüften Zeilen, Funktionen, Bedingungen
  • PSG – Projekt-Steuerungs-Gruppe

 

9. Literatur

 

  • Testautomatisierung aus einem Guss mit LabVIEW, Ranorex und dem Team Foundation Server, Dirk Beinert, Andreas Turk, infoteam Software AG, Virtuelle Instrumente in der Praxis, Fürstenfeldbruck, 27.10.2010.
  • The W-Model – Strengthening the Bond Between Development and Test, A. Spillner, STAReast 2002, Orlando, Florida, USA, 15.–17. Mai 2002

Weitere Artikel vom testing experience Magazin

Automatisierung oder nicht – Lösen wir das richtige Problem? von Markus Gärtner

TMMi: Warum Reifebestimmung wichtig ist von Michiel van der Voort

 

Weiterbildung für Softwaretester

Grundlagenseminare

ISTQB ®  Certified Tester Foundation Level
ISTQB ®  Certified Tester Foundation Level Extension, Agile Tester

Aufbauseminare

ISTQB ® Certified Tester Advanced Level – Test Manager
ISTQB ® Certified Tester Advanced Level – Test Analyst
ISTQB ® Certified Tester Advanced Level – Technical Test Analyst

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

Recent Posts