Ad-hoc-Tests: Wie man Fehler ohne einen formalen Testprozess findet

Der Begriff Ad-hoc bedeutet, dass es an Struktur fehlt oder dass etwas nicht methodisch ist. Wenn man von Ad-hoc-Tests spricht, bedeutet das, dass es sich um eine Form von Blackbox- oder Verhaltenstests handelt, die ohne einen formalen Prozess durchgeführt werden.

Der formale Prozess bedeutet hier, dass es eine Dokumentation wie Anforderungsdokumente, Testpläne, Testfälle und eine angemessene Testplanung in Bezug auf den Zeitplan und die Reihenfolge der durchgeführten Tests gibt.

Diese werden hauptsächlich mit dem Ziel durchgeführt, Defekte oder Fehler aufzudecken, die nicht durch traditionelle oder formale Prozesse während des Testzyklus erfasst werden können.

Wie wir bereits verstanden haben, liegt das Wesen dieses Testens darin, dass es keine formale oder strukturierte Art des Testens gibt. Wenn diese Art von Zufallstests durchgeführt wird, ist es offensichtlich, dass die Tester dies ohne einen bestimmten Anwendungsfall im Hinterkopf tun, mit dem Ziel, das System zu zerstören.

Daher ist es definitiv noch offensichtlicher, dass eine solche intuitive oder kreative Testmethodik erfordert, dass der Tester extrem qualifiziert und fähig ist und über tiefgreifendes Wissen über das System verfügt. Ad-hoc-Tests stellen sicher, dass die durchgeführten Tests vollständig sind, und sind besonders nützlich, um die Effektivität des Testeimers zu bestimmen.

Leseempfehlung => Exploratory Testing – How to Think Beyond Traditional Testing Boundaries?

Beginnen wir mit einem Beispiel für Ad-hoc-Tests

Hier ist ein Beispiel dafür, wie wir diese Tests durchführen können, wenn es um einen UI-Assistenten geht.

Angenommen, Sie müssen einen Plan oder eine Vorlage für eine Aufgabe erstellen, die mit diesem UI-Assistenten durchgeführt werden soll. Der Assistent besteht aus einer Reihe von Bereichen, die Benutzereingaben wie Name, Beschreibung usw. enthalten.

Während der Assistent fortschreitet, müssen beispielsweise in einem der Bereiche Benutzerdaten eingegeben werden, woraufhin der UI-Assistent ein Kontext-Popup-Fenster ausgibt, das die zugehörigen Daten hinzufügt, um den Assistenten zu vervollständigen und den Assistenten einzusetzen/zu aktivieren.

Um dies zu testen, führt der Tester seine regulären Tests durch, wie z. B.:

• Schließen Sie den Assistenten erfolgreich mit allen gültigen Daten ab und erstellen Sie den Plan.
• Brechen Sie den Assistenten auf halbem Weg ab.
• Einen erstellten Plan mit dem Assistenten bearbeiten.
• Den erstellten Plan löschen und sehen, dass es keine Rückstände davon gibt.
• Einen negativen Wert in den Assistenten eingeben und sehen, dass die entsprechenden Fehlermeldungen angezeigt werden.

Nun, für das obige Beispiel sind hier einige Testfälle für Ad-hoc-Tests, die durchgeführt werden könnten, um so viele Fehler wie möglich aufzudecken:

• Während Sie versuchen, negative Daten hinzuzufügen, fügen Sie bestimmte Sonderzeichen hinzu, die nicht eingeschränkt sind, um zu sehen, ob sie richtig behandelt werden. Zum Beispiel schränken Assistenten manchmal {oder [ Klammern nicht ein, aber in bestimmten Situationen kann dies zu Konflikten mit Code führen, der auf der Sprache basiert, in der er geschrieben ist, und ein sehr unzuverlässiges Verhalten verursachen.
• Ein weiterer Test bezieht sich speziell auf Pop-ups. Ein Benutzer kann ein Popup-Fenster starten und dann versuchen, die Rücktaste auf der Tastatur zu drücken. Ich habe oft beobachtet, dass dies dazu führt, dass der Assistent im Hintergrund komplett verschwindet und die gesamten Benutzerdaten, die bis zum Start des Pop-ups eingegeben wurden, verloren gehen!

Charakteristika von Ad-hoc-Tests:

Wenn Sie sich die obigen Szenarien ansehen, werden Sie einige sehr ausgeprägte Charakteristika dieser Art von Tests erkennen.

Sie sind:

• Sie stehen immer im Einklang mit dem Testziel. Es handelt sich jedoch um bestimmte drastische Tests, die mit der Absicht durchgeführt werden, das System zu zerstören.
• Der Tester muss das zu testende System vollständig kennen und verstehen. Das Ergebnis dieses Tests findet Fehler, die versuchen, die Lücken des Testprozesses aufzuzeigen.
• Betrachtet man auch die beiden oben genannten Tests, so wäre die natürliche Reaktion darauf, dass – diese Art von Test nur einmal durchgeführt werden kann, da ein erneuter Test nicht möglich ist, es sei denn, es liegt ein Fehler vor.

Wann führen wir Ad-hoc-Tests durch?

Das ist in der Tat eine Millionen-Dollar-Frage!

Meistens sind die Testteams immer mit zu vielen Funktionen belastet, die sie innerhalb einer begrenzten Zeitspanne testen müssen. In dieser begrenzten Zeitspanne gibt es viele Testaktivitäten, die aus dem formalen Prozess abgeleitet sind und ebenfalls abgeschlossen werden müssen. In solchen Situationen finden Ad-hoc-Tests nur wenig Eingang in die Tests.

Aus meiner Erfahrung kann jedoch eine Runde Ad-hoc-Testing Wunder für die Produktqualität bewirken und viele Designfragen aufwerfen.

Da es sich bei Ad-hoc-Tests eher um eine „wilde“ Testtechnik handelt, die nicht strukturiert sein muss, lautet die allgemeine Empfehlung, dass sie nach der Ausführung des aktuellen Testeimers durchgeführt werden sollten. Ein anderer Gesichtspunkt ist, dass sie durchgeführt werden können, wenn detaillierte Tests aus Zeitgründen nicht durchgeführt werden können.

Meiner Meinung nach können Ad-hoc-Tests fast jederzeit durchgeführt werden – am Anfang, in der Mitte und am Ende! Es findet einfach zu jedem Zeitpunkt seinen Platz. Wann jedoch Ad-hoc-Tests durchgeführt werden müssen, um den größtmöglichen Nutzen zu erzielen, ist am besten von einem erfahrenen Tester zu beurteilen, der über fundierte Kenntnisse des zu testenden Systems verfügt.

Wann nicht durchführen?

Wenn die vorherige Frage eine Million Dollar wert war, sollte diese eine Milliarde wert sein!

Während wir festgestellt haben, wie effektiv und fruchtbar Ad-hoc-Tests sein können, müssen wir als erfahrener und fähiger Tester auch herausfinden, wann wir nicht in diese Art von Tests investieren sollten. Obwohl es im Ermessen des Testers liegt, hier einige Empfehlungen/Beispiele, wann es nicht notwendig sein könnte.

• Vermeiden Sie diese Tests, wenn es einen Testfall gibt, für den ein Fehler existiert. In einer solchen Situation ist es notwendig, den Fehlerpunkt des Testfalls zu dokumentieren und dann den Fehler zu verifizieren/wieder zu testen, wenn er behoben ist. Daher ist es hier nicht anwendbar.
• Es kann auch bestimmte Szenarien geben, in denen Kunden oder Klienten eingeladen werden, die Beta-Version der Software zu testen. In solchen Fällen sollten diese Tests nicht durchgeführt werden.
• Ein anderes Szenario ist, wenn ein sehr einfacher UI-Bildschirm hinzugefügt wird. Herkömmliche Positiv- und Negativtests sollten hier ausreichen, um ein Maximum an Fehlern herauszufinden.

Arten von Ad-hoc-Tests

Ad-hoc-Tests können in die folgenden drei Kategorien eingeteilt werden:

#1) Buddy Testing

Bei dieser Form des Testens gibt es ein Testmitglied und ein Entwicklungsmitglied, die ausgewählt werden, um an demselben Modul zu arbeiten. Nachdem der Entwickler das Unit Testing abgeschlossen hat, setzen sich Tester und Entwickler zusammen und arbeiten an dem Modul. Diese Art des Testens ermöglicht es beiden Parteien, die Funktion in einem breiteren Rahmen zu betrachten.

Der Entwickler erhält einen Einblick in all die verschiedenen Tests, die der Tester durchführt, und der Tester erhält einen Einblick in das inhärente Design, was ihm hilft, ungültige Szenarien zu vermeiden und dadurch ungültige Fehler zu verhindern. Es hilft dem einen, wie der andere zu denken.

#2) Pair Testing

Bei diesem Test arbeiten zwei Tester gemeinsam an einem Modul, wobei sie sich den gleichen Testaufbau teilen. Die Idee hinter dieser Form des Testens ist, dass die beiden Tester Ideen und Methoden entwickeln, um eine Anzahl von Fehlern zu finden. Beide können sich die Arbeit des Testens teilen und die notwendige Dokumentation aller gemachten Beobachtungen erstellen.

#3) Monkey Testing

Dieses Testen wird hauptsächlich auf der Ebene des Unit Testing durchgeführt. Der Tester analysiert Daten oder Tests auf völlig zufällige Art und Weise, um sicherzustellen, dass das System in der Lage ist, etwaigen Abstürzen standzuhalten. Dieses Testen kann in zwei Kategorien eingeteilt werden:

Vorteile des Ad-hoc-Testens

Dieses Testen gewährleistet, dass der Tester so kreativ wie nötig sein kann.

Das erhöht die Testqualität und -effizienz wie folgt:

• Der größte Vorteil ist, dass ein Tester aufgrund der verschiedenen innovativen Methoden, die er zum Testen der Software anwenden kann, mehr Fehler finden kann als beim traditionellen Testen.
• Diese Form des Testens kann überall im SDLC angewendet werden; sie ist nicht nur auf das Testteam beschränkt. Auch die Entwickler können diese Tests durchführen, was ihnen helfen würde, besser zu kodieren und auch vorherzusagen, welche Probleme auftreten könnten.
• Sie können mit anderen Tests gekoppelt werden, um die besten Ergebnisse zu erzielen, was manchmal die für die regulären Tests benötigte Zeit verkürzen kann. Dies würde es ermöglichen, qualitativ bessere Testfälle zu generieren und die Qualität des Produkts insgesamt zu verbessern.
• Es muss keine Dokumentation erstellt werden, was eine zusätzliche Belastung des Testers verhindert. Ein Tester kann sich darauf konzentrieren, die zugrundeliegende Architektur zu verstehen.
• In Fällen, in denen nicht viel Zeit zum Testen zur Verfügung steht, kann sich dies als sehr wertvoll in Bezug auf die Testabdeckung und die Qualität erweisen.

Nachteile von Ad-hoc-Tests

Ad-hoc-Tests haben auch einige Nachteile. Schauen wir uns einige der Nachteile an:

Da es nicht sehr organisiert ist und keine Dokumentation vorgeschrieben ist, besteht das offensichtlichste Problem darin, dass der Tester sich an alle Details der Ad-hoc-Szenarien erinnern und diese auswendig lernen muss. Dies kann vor allem in Szenarien, in denen es viele Interaktionen zwischen verschiedenen Komponenten gibt, eine noch größere Herausforderung darstellen.

• Aus dem ersten Punkt folgt, dass dies auch dazu führen würde, dass Fehler in den nachfolgenden Versuchen nicht wiederhergestellt werden können, wenn nach Informationen gefragt wird.
• Eine weitere sehr wichtige Frage, die sich hier stellt, ist die der Verantwortlichkeit für den Aufwand. Da dies nicht geplant/strukturiert ist, gibt es keine Möglichkeit, die Zeit und den Aufwand, der in diese Art des Testens investiert wird, abzurechnen.
• Ad-hoc-Tests sollten nur von einem sehr sachkundigen und erfahrenen Tester im Team durchgeführt werden, da sie proaktives Handeln und Intuition in Bezug auf das Vorhersehen potenzieller fehlerbehafteter Bereiche erfordern.

Best Practices To Make This Testing More Effective

Wir haben ausführlich über die Stärken und Schwächen dieser Tests gesprochen.

Im Grunde genommen sollten Ad-hoc-Tests ihren Platz im SDLC finden, doch wenn sie nicht auf angemessene Weise durchgeführt werden, können sie sich als kostspielig und als Verschwendung wertvoller Testzeit erweisen. Im Folgenden finden Sie einige Hinweise, wie Sie Ad-hoc-Tests effektiv gestalten können:

#1) Identifizieren Sie fehleranfällige Bereiche:

Wenn Sie ein bestimmtes Stück Software gut im Griff haben, werden Sie zustimmen, dass es bestimmte Funktionen gibt, die anfälliger für Fehler sind als andere. Wenn Sie das System noch nicht kennen, sollten Sie die Funktionen im Vergleich zu den geöffneten Fehlern überprüfen.

Die Anzahl der Fehler in einer bestimmten Funktion zeigt Ihnen, dass diese empfindlich ist, und Sie sollten genau diesen Bereich für die Durchführung von Ad-hoc-Tests auswählen. Dies erweist sich als eine sehr zeitsparende Methode, um einige schwerwiegende Fehler aufzudecken.

#2) Aufbau von Fachwissen:

Ein Tester, der mehr Erfahrung hat, ist zweifellos intuitiver und kann erahnen, wo die Fehler liegen könnten, im Vergleich zu jemandem, der nicht viel Erfahrung hat. Ich würde sagen, ob erfahren oder nicht, es liegt an der Person, den Sprung zu wagen und sich Fachwissen über das zu testende System anzueignen.

Ja, erfahrene Tester sind im Vorteil, da ihre im Laufe der Jahre erworbenen Fähigkeiten nützlich sind, aber die neuen Tester sollten dies als Plattform nutzen, um so viel Wissen wie möglich zu erwerben, um bessere Ad-hoc-Szenarien zu entwerfen.

#3) Erstellen Sie Testkategorien:

Wenn Sie die Liste der zu testenden Funktionen kennen, nehmen Sie sich ein paar Minuten Zeit, um zu entscheiden, wie Sie diese Funktionen kategorisieren und testen wollen. Zum Beispiel sollten Sie entscheiden, die Funktionen, die am sichtbarsten sind und am häufigsten vom Benutzer verwendet werden, vor allen anderen zu testen, da diese für den Erfolg der Software entscheidend sind.

Dann können Sie sie nach Funktionalität/Priorität kategorisieren und Segment für Segment testen.

Ein weiteres Beispiel, bei dem dies besonders wichtig ist, ist die Integration zwischen Komponenten oder Modulen. In diesen Fällen kann es eine Menge von Anomalien geben, die auftreten können. Die Verwendung einer Kategorisierung würde dabei helfen, diese Art von Test zumindest ein- oder zweimal zu berühren.

#4) Haben Sie einen groben Plan:

Ja, dieser Punkt mag Sie vielleicht ein wenig verwirren, da wir Ad-hoc-Tests als Tests beschrieben haben, die keine Planung oder Dokumentation haben sollten. Hier geht es darum, sich an das Wesen der Ad-hoc-Tests zu halten, aber dennoch einige grobe Anhaltspunkte zu notieren, wie man zu testen gedenkt.

Ein sehr einfaches Beispiel ist, dass man sich manchmal nicht an alle Tests erinnern kann, die man durchführen will. Wenn man sie also aufschreibt, kann man sicher sein, dass man nichts übersieht.

#5) Werkzeuge:

Nehmen wir ein Beispiel, mit dem wir alle sehr häufig konfrontiert werden. In vielen Fällen ist das Testen der Funktionalität an sich erfolgreich, ohne dass eine Abweichung im Verhalten festgestellt wird. Die Protokolle hinter den Kulissen könnten jedoch einige Ausnahmen melden, die von den Testern übersehen werden könnten, da sie das Testziel in keiner Weise beeinträchtigen.

Diese Ausnahmen könnten sogar sehr schwerwiegend sein. Daher ist es sehr wichtig, dass wir lernen, wie man solche Fehler sofort erkennt.

#6) Dokumentieren für mehr Fehler:

Auch hier verstehe ich, dass dies wieder einige Augenbrauen hochziehen kann. Die Dokumentation muss nicht detailliert sein, sondern nur eine kleine Notiz für Ihre eigene Referenz aller verschiedenen abgedeckten Szenarien, Abweichungen in den Schritten, die involviert sind, und halten Sie diese Fehler für die jeweilige Testmerkmalkategorie fest.

Dies wird Ihnen helfen, den gesamten Testeimer zu verbessern, wobei Sie entscheiden können, wie Sie bestehende Testfälle verbessern oder weitere hinzufügen können, falls erforderlich.

Fazit

Wir haben ausführlich über Ad-hoc-Testtechniken gesprochen – ihre Stärken, Schwächen, Situationen, in denen sie von Vorteil sind und in denen sie nicht von Vorteil sind.

Dies ist eine Testtechnik, die garantiert die Kreativität eines Testers maximal befriedigt. In meiner gesamten Testkarriere habe ich die größte Befriedigung aus Ad-hoc-Tests gezogen, da der Innovation keine Grenzen gesetzt sind und man am Ende nur mehr Wissen hat.

Das Wichtigste, was man aus all den oben genannten Informationen mitnehmen kann, ist zu bestimmen, wie man die Stärken von Ad-hoc-Tests nutzen kann, um einen Mehrwert für den gesamten Testprozess und die Produktqualität zu schaffen.

Über den Autor: Dies ist ein Gastartikel von Sneha Nadig. Sie arbeitet als Testleiterin mit über 7 Jahren Erfahrung in manuellen und automatisierten Testprojekten.

Führen Sie Ad-hoc-Tests in Ihrem Projekt durch? Was sind Ihre Vorschläge, um Ad-hoc-Tests erfolgreich zu machen?