Setzen Sie die Agilität mit veränderungsbasierten Tests wieder in die agile Entwicklung ein

Das schmutzige kleine Geheimnis der agilen Entwicklung

Agile wird häufig falsch verkauft, um dies zu erreichen schneller Time-to-Market, wenn das Ziel wirklich ist genauer Lieferung auf den Markt. Das schmutzige Geheimnis, das wir niemandem erzählen, ist, dass dies tatsächlich mit Kosten verbunden ist… langsamere Markteinführungszeit! Ja, wir veröffentlichen häufiger (dh „früher“), aber es dauert letztendlich länger, bis die gesamte Funktionalität auf den Markt kommt. Warum dauert es länger, wenn wir das Problem nur in kleinere Teile zerlegen? Der mit Abstand größte Schuldige ist die Erkennung von Fehlern im späten Zyklus und die Engpässe, die durch Maßnahmen zur Risikominderung entstehen.

Ein Großteil der versprochenen Geschwindigkeit der agilen Entwicklung wird durch inkrementelle Codeänderungen, insbesondere deren Auswirkungen auf das Testen und die Stabilität des Gesamtsystems, beeinträchtigt. Jeder Sprint endet normalerweise mit einem Strich bis zur Ziellinie, da sich die Qualitätssicherung / das Testen auf die Validierung der neu implementierten Funktionalität konzentriert. Aufgrund des Mangels an Verständnis für die indirekten Auswirkungen von Codeänderungen müssen Unternehmen dann eine vollständige Regression durchführen, wenn sich die Veröffentlichung nähert. Dies deckt häufig spät im Zyklus zahlreiche Probleme auf, was zu späten Stunden und schwierigen Geschäftsentscheidungen führt.

Es muss einen besseren Weg geben!

Konzentrieren Sie sich auf das Risiko

Aufgrund der Komplexität der heutigen Codebasen kann jede noch so harmlose Codeänderung die Anwendungsstabilität auf subtile Weise beeinträchtigen und letztendlich „das System beschädigen“. Diese unbeabsichtigten Konsequenzen können durch manuelle Inspektion nicht entdeckt werden. Daher ist das Testen von entscheidender Bedeutung, um das Risiko zu verringern, das sie darstellen. Wenn Sie jedoch nicht verstehen, was erneut ausgeruht werden muss, können Sie keine effiziente Testpraxis erreichen. Wenn Sie bei jedem Sprint zu viel testen, verlieren Sie viele der Gewinne, die durch agile Entwicklung erzielt werden. Wenn Sie zu wenig testen, setzen Sie sich der Erkennung eines späten Zyklus aus.

Was benötigt wird, ist eine Möglichkeit zu identifizieren, welche Tests erneut ausgeführt werden müssen, und die Testbemühungen (Komponententests, automatisierte Funktionstests und manuelle Tests) auf die Validierung der Funktionen und des zugehörigen Codes zu konzentrieren, die von den letzten Änderungen betroffen sind. Mithilfe einer Kombination der Codeanalyse-Engines von Parasoft (Jtest, C / C ++ - Test, dotTEST) und der Process Intellligence Engine (PIE) in Parasoft DTP können Entwickler und Tester die Änderungen in der Codebasis zwischen Builds verstehen und auf die zugreifen Versprechen von Agile. Das nennt man Änderungsbasiertes Testen.

Change-Based Testing (CBT) hält den Sprint am Laufen

Der Schlüssel ist zu wissen, welche Tests verfügbar sind, um die Codeänderungen zu validieren, und hier liefert Parasofts korrelierte Abdeckung die Waren. Wenn Sie wissen, welche dieser Dateien sich geändert haben und welche spezifischen Tests diese Dateien berührt haben, kann die Analyse-Engine (PIE) von DTP das Delta zwischen zwei Builds analysieren und die Teilmenge der Tests identifizieren, die erneut ausgeführt werden müssen. Das folgende Bild zeigt ein Widget aus dem DTP-Dashboard, das ein Kreisdiagramm der Ergebnisse der CBT-Analyse anzeigt. Diese Tabelle zeigt die Teilmenge der Tests, die zur Validierung der Codeänderungen verfügbar sind, kategorisiert nach ihrem Teststatus: bestanden, fehlgeschlagen, unvollständig und muss erneut getestet werden.

Diese übergeordnete Ansicht zeigt an, dass es eine Reihe von Fehlern gibt, die der geänderte Code eingeführt hat, und dass es eine Reihe von Tests gibt, die noch nicht ausgeführt wurden, aber verfügbar sind, um die Änderungen weiter zu validieren.

 

 

 

 

 

 

 

 

Ein Status von Bestanden, Nicht bestanden, or Unvollständig Gibt an, dass diese Tests bereits für den Build ausgeführt wurden, entweder als Teil eines vollautomatisierten Testprozesses (z. B. eines CI-gesteuerten Build-Schritts) oder während des Testens der neuen Funktionalität. Die Tests mit dem Status erneut testen, Es handelt sich jedoch entweder um manuelle Tests, die noch nicht ausgeführt wurden, oder um Tests, die Teil von Automatisierungsläufen sind und deren Ausführung während des aktuellen Sprints nicht geplant ist.

Wenn wir tiefer in das Diagramm eintauchen, können wir schnell erkennen, wo im Code die Änderungen aufgetreten sind, wie die vorhandenen Tests mit diesen Änderungen korrelieren und wo die Testressourcen konzentriert werden müssen.

Von hier aus können wir einen Testplan erstellen, der fehlgeschlagene und unvollständige Testfälle mit der höchsten Priorität behandelt und die Empfehlungen für den erneuten Test verwendet, um die Planung zusätzlicher automatisierter Läufe zu konzentrieren und manuelle Testbemühungen zu priorisieren.

Der Verstoß-Explorer in DTP bietet die Schnittstelle zum Definieren und Verwalten des Testplans. Beim Navigieren durch die Tests und Ergebnisse zeigt der Explorer Details zu jedem Testfall an. Verwendung der Priorisierung In der Ansicht zum Festlegen der Testmetadaten können Benutzer jedem Testfall Eigentümer und Aktionen zuweisen und die Priorität festlegen.

So wenden Sie einen CBT-Workflow an

Wie hilft dies einem agilen Prozess? Es ist einfach die Fähigkeit, schnell und präzise zu identifizieren, wo Ihre Testressourcen angewendet werden müssen. Indem nur das getestet wird, was im Vergleich zu allem benötigt wird (oder einfach nur geraten wird), wird die Testzeit erheblich reduziert. Die Qualität steigt und der Sprint wird pünktlich erledigt.

Wie würde das in der Praxis funktionieren? Während die Ergebnisse der CBT-Analyse (Change Based Testing) auf verschiedene Arten verwendet werden können, würde ich den folgenden Workflow als den praktischsten für die Fokussierung sprintbasierter Testbemühungen vorschlagen.

• Identifizieren Sie Ihre Basislinie. Dies ist der Build mit den abgeschlossenen Testbemühungen, die Sie für gezielte erneute Tests verwenden möchten. In der Regel ist dies der Build ab dem Ende des vorherigen Sprints oder der vorherigen Veröffentlichung.
• Führen Sie Unit-Tests und verfügbare automatisierte Funktionstests durch. Integrieren Sie automatisierte Tests in Ihren CI-Prozess und messen / überwachen Sie die CBT-Ergebnisse anhand des neuesten Builds. Auf diese Weise können Sie sehen, wie es Ihnen geht, und den Aufwand für den erneuten Test planen.
• Schließen Sie die Lücke für den erneuten Test. Testen Sie anhand des Ziel-Builds und senden Sie die Ergebnisse der erneuten Testbemühungen zur Analyse zurück. und überprüfen Sie das Ergebnis der CBT erneut.
• Setzen Sie Ihre Grundlinie zurück. Verschieben Sie am Ende des Sprints die Grundlinie in den Build, für den Sie die Tests abgeschlossen haben, und setzen Sie sie für den nächsten Sprint zurück / wiederholen Sie sie.

Fazit

Wir müssen die Testproduktivität in der agilen Entwicklung steigern. Das Testen ist ein großer Engpass bei der kontinuierlichen Lieferung, da am Ende des Freigabezyklus aufgrund falscher Tests zu viele Fehler festgestellt werden. Um die besten Ergebnisse zu erzielen, konzentrieren Sie die Testbemühungen auf die Auswirkungen der von Ihnen vorgenommenen Änderungen und setzen Sie Agilität frei, um die Markteinführung zu beschleunigen.