Testing 1×1 – Regressionstest, Re-Test und Testautomation
Testing 1×1 – Regressionstest, Re-Test und Testautomation
Oftmals können ähnliche Begrifflichkeiten im Test zu Verwirrungen und Missverständnissen führen. In unserem heutigen Testing 1×1 wollen wir uns dem Regressionstest und dem Re-Test widmen und deren Rolle in der SAP-Testautomatisierung beleuchten.
Beide klingen ähnlich, haben jedoch eine komplett unterschiedliche Aufgabe in der Software-Qualitätssicherung.
Regressionstest
Sehen wir uns zuerst den Regressionstest an. Der Regressionstest kümmert sich in der Qualitätssicherung darum, dass Systemfunktionalitäten nach einer Systemänderung noch gleich funktionieren wie vor der Änderung.
Er prüft also für uns die unveränderte Funktionalität des Systems.
Nehmen wir also am System ein Update vor, so soll dieses in den allermeisten Fällen ja nicht jegliche Funktionalitäten im System verändern, sondern maximal gewisse Prozessabläufe ändern bzw. neue Funktionalitäten hinzufügen.
Der große Rest unseres Systems, der unverändert bleiben soll, ist im Fokus der sogenannten Regressionstests. Sie sollen sicherstellen, dass die vorgenommenen Änderungen am System nicht zu unerwünschten Verhaltensänderungen am Rest des Systems geführt haben.
Beispiel: Unser Webshop wird durch einen Produktkonfigurator erweitert. Mit Hilfe dieses Konfigurators soll es für den Kunden möglich sein, Varianten eines Produkts nach seinen Vorstellungen zu gestalten. Das Einloggen, der Bezahlvorgang, die Eingabe der Kundenstammdaten, das Kontaktformular, … bleiben von der Änderung unbeeinflusst (bzw. sollen unbeeinflusst bleiben).
Wir prüfen hier mittels Regressionstest, oder einfach gesprochen: in einem Vorher-Nachher Test, ob sich unser System in den nicht zu ändernden Bereichen weiterhin gleich verhält und keine unerwünschten Verhaltensänderungen am System auftreten.
Re-Test
Der Re-Test, oftmals mit dem Regressionstest verwechselt, hat eine komplett andere Rolle in unserer Qualitätssicherung. Er kommt erst dann ins Spiel, wenn wir schon Fehlzustände gefunden haben.
Seine Aufgabe ist es nämlich zu prüfen, ob ein im Zuge eines Testzyklus aufgetretener Fehler nach der Korrektur durch die Entwickler in einem weiteren Testdurchlauf nun behoben ist.
Beispiel: Finden wir also in unserem System einen Fehlzustand, so melden wir diesen in Form eines Fehlerreports ein. Danach wird dieser von Entwicklern behoben und ein Update auf das System gespielt, um uns einen neuerlichen Test der Funktionalität zu ermöglichen – den Re-Test.
Im Zuge dieses neuerlichen Testens prüfen wir, ob unser gefundener Fehlzustand durch die Fehlerbehebung der Entwickler korrigiert werden konnte – das ist die Aufgabe des Re-Tests.
Oftmals diskutiert wird beim Re-Test, welche Testfälle nun nach dem Auffinden eines Fehlzustandes nochmals durchgeführt werden sollen:
- Nur jener Testfall, bei dem auch der Fehlzustand entdeckt wurde?
- Testfälle, welchen den betroffenen Prozess und somit „umliegendes Gebiet“ betreffen?
- Oder greift man noch weiter, um sicher zu gehen?
Regressionstest und Re-Test mit Testautomations-Unterstützung
Diese Frage lässt sich in Zeiten der Testautomation sicher einfacher beantworten. Hier gehen wir gerne ein wenig von der klassischen Testschule ab und sagen: wenn kein Zusatzaufwand für den Tester auftritt, so ist es durchaus legitim die umgebenden Bereiche meiner gefundenen Fehlwirkung intensiv und großzügig zu testen, um damit potentielle Seitenwirkungen einer Fehlerbehebung zu prüfen.
Oftmals ist es so, dass Fehlwirkungen andere Fehler maskieren: der maskierte oder bis dahin verdeckte Fehler tritt erst auf, wenn der maskierende Fehler behoben ist.
Es kann uns aber auch passieren, dass die Behebung eines Fehlers bzw. das Coding, welches unseren Fehler behebt, an anderer Stelle ungewollt zu einem Folgeproblem, einer sogenannten Seitenwirkung, führt.
Beide dieser Fälle befinden sich oft im Umkreis der ursprünglichen Fehlfunktion, können aber durchaus auch in einem weiter gefassten Gebiet auftreten.
Einsatzgebiete Testautomation
Die klassischen Einsatzgebiete der Testautomation umfassen genau den vorhin besprochenen Regressionstest. Hier können unsere wichtigsten Prozesse mittels Testautomation mit einer Testabdeckung belegt werden und beliebig oft, zu beliebigen Zeitpunkten, das gewünschte Systemverhalten sichergestellt werden.
Fügen wir unserem System weitere Funktionalität hinzu, so werden diese neuen Funktionalitäten durch Erstellen von neuen Testfällen in unser Regressionstestfallset übernommen.
Haben Sie Interesse an unserer suxxesso Tool Suite, so nehmen Sie gerne mit uns Kontakt auf.