Test Impact Analysis
Intelligenter testen, nicht härter
Fortsetzung des Artikels von Teil 1
Shift Right Testing
Die Schwierigkeiten, die sich aus dem Reproduzieren realistischer Testumgebungen und der Verwendung realer Daten und Traffic-Muster in Tests ergeben, veranlasst Teams außerdem häufig dazu, Produktionsumgebungen zum Überwachen und Prüfen ihrer Applikationen heranzuziehen. Ein Vorgehen, das durchaus Vorteile hat: So können zum Beispiel Applikationen mit realem Produktions-Traffic getestet und damit die Fehlertoleranz und die Leistungsfähigkeit verbessert werden.
Ein gängiger Anwendungsfall ist das sogenannte »Canary Release«: Dabei wird eine neue Software-Version zunächst nur einer kleinen Kundengruppe zur Verfügung gestellt. Erst nachdem Bugs gemeldet und behoben wurden, wird die Applikation dann sukzessive an immer mehr Kunden ausgeliefert. Auf dieses Vorgehen setzt unter anderem Roku, ein Hersteller von Multimedia-Spielen, beim Aktualisieren seiner Geräte-Firmware.
Eine solche »Rechtsverschiebung« der Tests ist allerdings auf eine Entwicklungsinfrastruktur angewiesen, die ein Release zurücknehmen kann, wenn kritische Defekte auftreten. Wird beispielsweise in einem Canary Release eine ernste Sicherheitslücke festgestellt, muss es zurückgenommen werden, bis ein neues, aktualisiertes Release bereitsteht (Bild 3).
Die Verwendung von Produktionsumgebungen zum Überwachen und Prüfen von Software hat jedoch ihre Tücken. Auch steht hinter dem Shift Right Testing nicht die Absicht, Modul-, API- und UI-Tests vor dem Deployment zu ersetzen. Vielmehr soll es eine Ergänzung sein und die Continuous-Testing-Philosophie bis in die Produktion hinein ausdehnen. Trotzdem können Unternehmen dieses Konzept auch leicht missbräuchlich als Rechtfertigung dafür nutzen, während der Entwicklung weniger Modul- und API-Tests durchzuführen. Um das zu verhindern, muss das Testen während der Entwicklungsphasen einfacher und produktiver werden – und qualitativ hochwertigere Software hervorbringen.
Jobangebote+ passend zum Thema
Fokussiertes Testen heißt: intelligenter testen
Der Großteil der Software wird nicht vollständig getestet. Was getestet wird, hängt meist davon ab, welche der Funktionen der Entwickler als kritisch betrachtet. Eine Entscheidung, die sich jedoch während eines SCRUM-Sprints oder einer Iteration in anderen Prozessen als äußerst schwierig erweisen kann.
Andererseits ist es aber auch keine Option, immer alles zu testen. Wegen knapper Zeitpläne werden daher oft nur die Teile der Software getestet, die aktualisiert wurden – obwohl in der Regel nicht bekannt ist, welcher Code genau betroffen ist. Zwar hilft in solchen Fällen die Testautomation, aber ohne genaue Kenntnis, wo und was getestet werden muss, bleibt die Testabdeckung auch hier immer noch unzureichend.
Test Impact Analysis
Abhilfe kann die Test Impact Analysis schaffen, eine multivariate Analyse von Testabdeckung, Codeänderungen und Abhängigkeiten, die genau aufzeigt, welcher Code getestet werden muss. Zusätzlich können diese Tests dann automatisch geplant und ausgeführt werden.
Die TIA arbeitet auf der Entwickler-Ebene innerhalb der IDE und sammelt Informationen darüber, welcher Code von welchen Tests ausgeführt wird. Diese Informationen werden dann in der IDE des Entwicklers beim Ändern von Code angewandt. Auf diese Weise kann der Entwickler die Tests identifizieren und ausführen, die nötig sind, um zu verifizieren, dass der geänderte Code bei keinen Tests durchfällt. Indem genau registriert wird, welche Tests durchgeführt und welche bestanden beziehungsweise nicht bestanden wurden, kann der Entwickler außerdem feststellen, welche noch durchzuführen sind oder welche fehlgeschlagen sind. Sind alle Tests ausgeführt und bestanden, hat der Entwickler die Gewissheit, dass der Code übergeben und dass weitergearbeitet werden kann.
Die TIA funktioniert im Rahmen eines CI/CD-Prozesses durch die nahtlose Integration in das Build-System eines Projekts (zum Beispiel Maven oder Gradle), sodass es bei Änderungen umgehend Rückmeldungen gibt. Sie stellt fest, welcher Code seit dem letzten Baseline Build, also dem letzten Nightly Build, geändert wurde, ermittelt die für den betreffenden Code nötigen Tests und führt diese anschließend aus. Dieser Workflow ermöglicht es den Teams, CI-Jobs einzurichten, die die Tests ausschließlich aufgrund der letzten Codeänderungen ausführen. So reduziert sich der Zeitaufwand zum Abarbeiten eines CI-Jobs von Stunden auf Minuten. Im Einzelnen bietet die Test Impact Analysis die folgenden Vorteile:
- Verstehen, was jeder einzelne Test abdeckt: Durch die automatische Korrelation von Testausführungsdaten mit Testabdeckungsdaten wird ermittelt, welche Tests auf der Basis des aktuell entwickelten Codes durchgeführt werden müssen. Die Anwender sparen auf diese Weise Zeit, weil sie unnötige Tests nicht ausführen müssen, während die Teams vom umgehenden Feedback bei der Entwicklung und nach dem Einchecken von Code profitieren.
- Verstehen, was sich geändert hat: Entwickler wissen oft nicht, welche Tests zum Validieren von Codeänderungen durchgeführt werden müssen. Damit ver bleiben ihnen drei Möglichkeiten: Sie checken den Code ein, ohne Tests vorzunehmen, sie führen nur einen oder zwei ihnen bekannte Tests aus, wobei leicht einige übersehen werden, oder sie führen alle Tests aus, was Zeitverschwendung ist. Die TIA dagegen ermittelt sofort, welche Tests für welche Codeänderungen erforderlich sind und führt diese automatisch aus. Durch die gründliche Vorabprüfung wird der eingecheckte Code darüber hinaus stabiler.
- Fokus auf Tests, die Änderungen und betroffene Abhängigkeiten validieren: Das Identifizieren und Ausführen von Tests, die zum Verifizieren sämtlicher Codeänderungen und der betroffenen Abhängigkeiten, die seit dem letzten Baseline Build (normalerweise der letzte Nightly Build) hinzugekommen sind, verkürzt den Zeitaufwand für CI erheblich.
- Umgehendes, fortlaufendes Feedback: Durch Aufdecken nicht nur der direkten Abhängigkeiten zwischen Tests und Code, sondern auch der indirekten Abhängigkeiten hilft die Test Impact Analysis den Teams dabei, möglichst bald nach dem Einchecken des Codes zu erkennen, welche Tests nicht bestanden wurden.
Test-Engpässe während der Entwicklung sind also weit verbreitet, müssen aber nicht sein. Die Test Impact Analysis erlaubt es Entwicklerteams dank Testautomation, die Testmaßnahmen auf die in den einzelnen Iterationen vorgenommenen Modifikationen zu konzentrieren. So wird also nur das Notwendige getestet. Zudem verringert sich der Testaufwand für die Teams im Entwicklungsprozess. Denn sie erhalten umgehend Rückmeldung, was getan werden muss, welcher Code die Tests nicht bestanden hat und welcher Code von neuen Änderungen betroffen ist.
Der Autor
Mark Lambert, Vice President of Products bei Parasoft, zeichnet verantwortlich dafür, dass Parasoft-Lösungen echten Mehrwert für die Unternehmen bieten. Sein Team unterstützt Kunden bei der Optimierung ihres Software-Entwicklungsprozesses, indem die spezifischen Entwicklungsanforderungen eingeschätzt und die angewendeten Technologien, Prozesse und Methodiken darauf abgestimmt werden.
- Intelligenter testen, nicht härter
- Shift Right Testing
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
OPC UA-Standard
Einer für alles
Scripted Streaming
Baukasten für Modulkameras
Tools für Softwareentwicklung
Multitasking für Raumschiffe
Mathworks stellt Update vor
Release 2019b für Matlab und Simulink
Gestensteuerung
Don't touch this
