Change-Based-Testing

Change-Based-Testing

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 GmbH)

(Bild: Parasoft Deutschland GmbH)

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 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.

Der Violation Explorer in Parasoft DTP legt Details zu jedem Testfall offen. (Bild: Parasoft Deutschland GmbH)

Der Violation Explorer in Parasoft DTP legt Details zu jedem Testfall offen. (Bild: Parasoft Deutschland GmbH)

Das 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.

Seiten: 1 2Auf einer Seite lesen

Ausgabe:
Parasoft Deutschland GmbH
www.parasoft.de

Das könnte Sie auch Interessieren