Agil und schnell
Die agile Entwicklung wird der Unternehmensleitung oft als eine Möglichkeit für eine verkürzte Markteinführungszeit verkauft, auch wenn das eigentliche Ziel in einer präziseren Einführung in den Markt besteht. Effektiv bringt sie nämlich eine längere Time-to-Market mit sich. Natürlich kommen häufiger (bzw. früher) neue Releases heraus, aber im Endeffekt dauert es länger, die gesamte Funktionalität auf den Markt zu bringen. Weshalb aber nimmt der Zeitbedarf zu, obwohl nur das gesamte Problem in kleinere Teilstücke zerlegt wird? Die mit Abstand wichtigste Ursache hierfür ist, dass Defekte erst sehr spät erkannt werden und dass die risikomindernden Maßnahmen zu Engpässen führen.
Bild: Parasoft Deutschland GmbHEin 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 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.
Auf die Risiken fokussieren
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 aber 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ß werden, 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 erneut durchgeführt werden müssen. So lassen sich die Prüfmaßnahmen (Modultests, automatisierte Funktionstests und manuelle Tests) auf diejenigen Features und den mit ihnen zusammenhängenden Code konzentrieren, die von den jüngsten Änderungen betroffen sind. Mit einer Kombination aus den Codeanalyse-Engines von Parasoft (Jtest, C/C++test, dotTEST) und der Process Intellligence Engine (PIE) in Parasoft DTP können Entwickler und Prüfer die Änderungen verstehen, die zwischen den Builds an einer Codebasis vorgenommen wurden, um so die von der agilen Entwicklung versprochenen Vorteile umzusetzen. Dies wird als 'änderungsbasiertes Prüfen' bzw. 'Change-Based Testing' (CBT) bezeichnet.
Bild: Parasoft Deutschland GmbHDas Sprinttempo halten
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. Die Abbildung vorne 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. Die Übersicht unten 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 passed, failed 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 die Prüf-Ressourcen zu fokussieren sind. 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 gibt den Anwendern die Möglichkeit, Eigentümer und Aktionen zuzuweisen und die Prioritäten der einzelnen Testfälle einzustellen.
CBT-Workflow anwenden
Hilft das nun einem Agile Prozess? Durchaus, denn so lässt sich schnell und prägnant feststellen, wo die Prüf-Ressourcen ansetzen müssen. Der Zeitaufwand für die Tests lässt sich tatsächlich 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 lassen sich die Ergebnisse einer CBT-Analyse auf verschiedene Weise nutzen. Dennoch hat sich der folgende Workflow als die praktikabelste Möglichkeit zur Fokussierung auf sprintbasierte Prüfmaßnahmen erwiesen:
- • 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 bzw. Ü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.
- • Ausgangspunkts anpassen. Am Ende des Prints erfolgt das Verlegen des Ausgangspunkts zu dem Build, dessen Test eben abgeschlossen wurde; Neustart/Wiederholung des nächsten Sprints.
Zusammenfassung
Es ist bei der agilen Entwicklung 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.
www.parasoft.de
Die agile Entwicklung wird der Unternehmensleitung oft als eine Möglichkeit für eine verkürzte Markteinführungszeit verkauft, auch wenn das eigentliche Ziel in einer präziseren Einführung in den Markt besteht. Effektiv bringt sie nämlich eine längere Time-to-Market mit sich. Natürlich kommen häufiger (bzw. früher) neue Releases heraus, aber im Endeffekt dauert es länger, die gesamte Funktionalität auf den Markt zu bringen. Weshalb aber nimmt der Zeitbedarf zu, obwohl nur das gesamte Problem in kleinere Teilstücke zerlegt wird? Die mit Abstand wichtigste Ursache hierfür ist, dass Defekte erst sehr spät erkannt werden und dass die risikomindernden Maßnahmen zu Engpässen führen.
Bild: Parasoft Deutschland GmbHEin 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 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.
Parasoft Deutschland GmbH
Dieser Artikel erschien in IoT Design 2 2018 - 19.02.18.Für weitere Artikel besuchen Sie
