Ein großer Teil der von der agilen Entwicklung erhofften Schnelligkeit wird durch inkrementelle Codeänderungen aufgezehrt, und hier speziell von ihren Auswirkungen auf das Testen und die allgemeine Stabilität des Systems. Jeder Sprint endet üblicherweise mit einem furiosen Finish kurz vor der Ziellinie, wenn sich die Qualitätssicherungs- und Prüfabteilung darauf konzentriert, die neu implementierte Funktionalität zu validieren. Weil man die indirekten Auswirkungen von Codeänderungen nicht genau versteht, müssen die Unternehmen dann noch einen kompletten Regressionstest durchführen, wenn die Freigabe näher rückt. Hierbei werden häufig in einer späten Phase zahlreiche Probleme aufgedeckt, was Überstunden und schwierige geschäftliche Entscheidungen nach sich zieht. Hier gibt es eine bessere Möglichkeit.
Fokussierung auf die Risiken
Die hohe Komplexität der heutigen Codebasen führt dazu, dass jede noch so harmlose Codeänderung auf subtile Weise Einfluss auf die Stabilität der Applikation haben und das System letztendlich scheitern lassen kann. Über die manuelle Inspektion lassen sich diese unerwünschten Konsequenzen unmöglich aufdecken. Das macht das Testen entscheidend wichtig, um die mit den Änderungen einhergehenden Risiken abzumildern. Solange man allerdings nicht versteht, was genau erneut geprüft werden muss, kann man keine effiziente Prüfmethode erarbeiten. Lässt man den Prüfaufwand bei jedem Sprint zu groß anwachsen, büßt man viele der mit der agilen Entwicklung möglichen Vorteile ein. Prüft man andererseits zu wenig, läuft man Gefahr, dass Defekte zu spät erkannt werden.
Gefragt ist eine Methode, mit der sich herausfinden lässt, welche Tests man wiederholen muss. So lassen sich die Prüfmaßnahmen (Modultests, automatisierte Funktionstests und manuelle Tests) auf die von den jüngsten Änderungen betroffenen Features und den mit ihnen zusammenhängenden Code konzentrieren. Eine Kombination aus den Codeanalyse-Engines von Parasoft (Jtest, C/C++test, dotTEST) und der Process Intellligence Engine (PIE) in Parasoft DTP erleichtert es Entwicklern und Testern, die zwischen den Builds an einer Codebasis vorgenommenen Änderungen zu verstehen, um so die von der agilen Entwicklung versprochenen Vorteile umzusetzen. Man bezeichnet das als „änderungsbasiertes Prüfen“ beziehungsweise „Change-Based Testing“ (CBT).
CBT hält das Tempo beim Sprint
Wichtig ist zu wissen, welche Tests zum Validieren der Codeänderungen zur Verfügung stehen. Genau hier kommt die korrelierte Überdeckung von Parasoft ins Spiel. Durch das Wissen, welche Dateien geändert wurden und welche spezifischen Tests mit diesen Dateien zu tun hatten, kann die Analyse-Engine PIE in DTP die Unterschiede zwischen den beiden Builds analysieren und herausfinden, welche Tests erneut durchzuführen sind. Abbildung 1 zeigt ein Widget aus dem DTP-Dashboard, das die Ergebnisse der CBT-Analyse darstellt. Zu sehen sind diejenigen Tests, die zum Validieren der Codeänderungen zur Verfügung stehen, aufgeschlüsselt nach ihrem Teststatus: bestanden, nicht bestanden, unvollständig oder erneuter Test erforderlich.
Abb. 1: Dieses Widget aus dem DTP-Dashboard zeigt die Ergebnisse der CBT-Analyse
Die abstrakte Übersicht zeigt, dass der modifizierte Code eine Reihe von Fehlern mitgebracht hat und dass es einige Tests gibt, die noch nicht durchgeführt wurden, aber zum weiteren Validieren der Änderungen zur Verfügung stehen.
Lautet der Status Pass, Fail oder Incomplete, so bedeutet das: Diese Tests wurden bereits mit dem Build durchgeführt, sei es als Bestandteil eines vollautomatischen Prüfprozesses (wie bei einem CI-getriebenen Build-Schritt) oder beim Testen der neuen Funktionalität. Bei Tests mit dem Status Retest handelt es sich dagegen entweder um noch nicht durchgeführte manuelle Tests oder solche, die zu Automatisierungsläufen gehören, die während des aktuellen Sprints nicht vorgesehen sind.
Geht man der Tabelle genauer auf den Grund, so erhält man schnell Aufschlüsse darüber, wo im Code die Änderungen erfolgt sind, in welchem Zusammenhang die existierenden Tests mit diesen Änderungen stehen und worauf man die Prüf-Ressourcen fokussieren sollte.
Hiervon ausgehend, kann man einen Prüfplan aufstellen, der fehlgeschlagenen und unvollständigen Tests die höchste Priorität zuweist und die Retest-Empfehlungen nutzt, um zusätzliche automatische Prüfläufe zu planen und die Priorität manueller Prüfmaßnahmen zu koordinieren.
Der Violation Explorer in DTP dient als Oberfläche für die Definition und Verwaltung des Prüfplans. Nimmt man die Tests und ihre Ergebnisse unter die Lupe, so legt der Explorer einige Details zu jedem Testfall offen. Eine spezielle Prioritization-Ansicht zum Einstellen der Test-Metadaten (siehe Abbildung 2) gibt den Anwendern die Möglichkeit, Eigentümer und Aktionen zuzuweisen und die Prioritäten der einzelnen Testfälle einzustellen.
Abb. 2: Der Violation Explorer in DTP führt Details zu jedem Testfall auf
Anwendung eines CBT-Workflows
Für einen Agile Prozess ist das durchaus hilfreich, weil sich schnell und prägnant feststellen lässt, wo die Prüf-Ressourcen ansetzen müssen. Der Zeitaufwand für die Tests lässt sich enorm reduzieren, wenn nur das wirklich Nötige getestet wird, anstatt alles zu prüfen oder einfach auf Gut Glück zu testen. Die Qualität verbessert sich, und der Sprint wird rechtzeitig erledigt.Wie wäre der praktische Ablauf? Grundsätzlich kann man die Ergebnisse einer CBT-Analyse auf verschiedene Weise nutzen, dennoch hat sich der folgende Workflow (siehe Abbildung 3) als die praktikabelste Möglichkeit zur Fokussierung auf sprintbasierte Prüfmaßnahmen erwiesen:
Abb. 3: Für optimale Ergebnisse bei der agilen Entwicklung spielen Tests eine entscheidende Rolle im Workflow
- Ausgangspunkt festlegen: Hierbei handelt es sich um den Build mit den absolvierten Prüfmaßnahmen, den man für die zielgerichteten Nachprüfungen verwenden möchte. In der Regel handelt es sich dabei um den Build, der am Ende des letzten Sprints oder Release entstand.
- Modultests oder verfügbare automatisierte Funktionstests ausführen: Integration von automatisierten Tests in den CI-Prozess und Messen beziehungsweise Überwachen der CBT-Resultate anhand des letzten Builds. So lässt sich beurteilen, wie man abschneidet, um die Retest-Maßnahmen entsprechend zu planen.
- Retest-Lücke schließen: Prüfen anhand des Ziel-Builds, Ergebnisse der Retest-Maßnahmen zurückleiten für die Analyse und Bewertung des CBT-Resultats.
- Ausgangspunkt anpassen: Am Ende des Sprints erfolgt das Verlegen des Ausgangspunkts zu dem Build, dessen Test eben abgeschlossen wurde; Neustart/ Wiederholung des nächsten Sprints.
Bei der agilen Entwicklung ist es notwendig, die Prüfproduktivität zu steigern. Das Testen ist ein entscheidender Engpass für die Continuous Delivery, wenn aufgrund falschen Prüfens am Ende des Release-Zyklus zu viele Fehler aufgedeckt werden. Um optimale Ergebnisse zu erzielen, sollte man die Prüfmaßnahmen auf die Folgewirkungen der vorgenommenen Änderungen fokussieren. So lässt sich die agile Entwicklung tatsächlich für eine schnellere Markteinführung nutzen.
»KONTAKT«
Parasoft Deutschland GmbH Unter den Linden 10
10117 Berlin
Telefon: 0 30 – 70014 03 57
E-Mail: info-de@parasoft.com
