Change-Based-Testing

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.

Um optimale Ergebnisse bei der agilen Entwicklung zu erzielen, spielen Tests eine entscheidende Rolle im Workflow. (Bild: Parasoft Deutschland GmbH)

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.

Autor: Mark Lambert,
Vice President Products,
Parasoft,
www.parasoft.de

Seiten: 1 2Auf einer Seite lesen

Ausgabe:
Parasoft Deutschland GmbH
www.parasoft.de

Das könnte Sie auch Interessieren