In einem vor einigen Wochen veröffentlichten Artikel haben wir über die menschlichen Herausforderungen gesprochen, denen sich Tester stellen müssen.
Die Arbeit eines Testers ist nicht nur eine menschliche, sondern es gibt auch viele Herausforderungen im Zusammenhang mit den technischen Aspekten des Testens.
Dieser Artikel stellt einige der technischen Herausforderungen vor, denen wir am häufigsten begegnen.
Software ist in ihrer Umgebung nicht isoliert. Sie kommuniziert über APIs mit anderer Software. Um ein funktionsfähiges Produkt zu haben, muss sichergestellt werden, dass es mit bestimmter umgebender Software interagieren kann. Diese Softwareinteraktionen müssen daher getestet werden.
Diese Tests können für Tester verwirrend sein, da APIs keine grafischen Schnittstellen bieten (Software benötigt sie nicht, um miteinander zu kommunizieren) und spezielle Tools erfordern.
Darüber hinaus ist es zwar einfach, die APIs unserer eigenen Software zu beherrschen, dies ist jedoch nicht unbedingt der Fall für die APIs der Software, mit der unser Produkt interagiert.
Schließlich können diese stark kodifizierten Interaktionen Architekturen erzeugen, die mehr oder weniger leicht zu verstehen sind.
Es gibt mehrere Gründe, warum Sie als Tester keine Angst vor API-Tests und APIs im Allgemeinen haben sollten, selbst wenn Sie ein Funktionstester mit wenigen „technischen“ Fähigkeiten sind:
API-Tests sind ein guter erster Schritt in die Welt der „technischen“ Tests, da man sich damit leicht vertraut machen kann, wenn man erst einmal selbst Hand angelegt hat. In einem agilen Kontext ist es für Tester ebenfalls zunehmend wichtig, in verschiedene Aspekte des Testens eingreifen zu können, und API-Tests sind eine Fähigkeit, die immer gefragter ist.
Das ist keine neue Herausforderung! Ich höre seit Beginn meiner Tätigkeit im Jahr 2011 von Testautomatisierung. Ich bin tatsächlich überzeugt, dass Tester schon seit geraumer Zeit von Automatisierung hören.
Auf den ersten Blick scheint es daher ziemlich überraschend, dass Automatisierung nicht völlig weit verbreitet ist. Tatsächlich hat sich der Anteil automatisierter Tests in den letzten Jahren eher stabilisiert als erhöht.
Der Grund dafür ist ganz einfach: Es ist nicht einfach, die Durchführung von Tests zu automatisieren. Die Tools sind zahlreich, die Anforderungen und Kontexte noch mehr!
Viele Automatisierungsprojekte scheitern, weil das Automatisierungstool ungeeignet ist, die Wartung der automatisierten Tests zu zeitaufwändig ist, die Automatisierungsziele und -strategie nicht klar definiert oder angepasst sind oder die automatisierten Tests nicht zuverlässig genug sind.
Um eine erfolgreiche Automatisierung zu erreichen, müssen Sie das richtige Tool auswählen, die an der Automatisierung beteiligten Personen schulen, den Umfang der Automatisierung identifizieren und den Umfang und die Tests an den Kontext anpassen.
Wenn Sie ein Funktionstester sind, kann die Testautomatisierung schnell unverständlich werden. Tatsächlich müssen nichttechnische Tester ihre Skripting-Fähigkeiten (um automatisierte Tests zu verstehen und zu schreiben) sowie ihre Fähigkeit, automatisierte Tests einzurichten und zu überwachen, entwickeln.
In diesem Fall empfehle ich, die Dinge Schritt für Schritt anzugehen und mit einer „einfachen“ Automatisierung zu beginnen. Dies kann mit API-Tests oder durch die Verwendung eines bereits entwickelten KDT-Frameworks (Keyword Driven Testing) erfolgen, wie es bei Tools wie Robot Framework der Fall ist, oder durch die Verwendung von Automatisierungstools, die für Funktionstester entwickelt wurden und es ihnen ermöglichen, sich mit der Automatisierung und ihren Einschränkungen vertraut zu machen. Ich denke hier an Tools wie Agilitest.
Wenn Sie keine größeren Schwierigkeiten mit der technischen Seite der Dinge haben, müssen Sie sich „nur“ der Herausforderung stellen, das System einzurichten und zu betreiben. Der Schlüssel ist:
Schließlich hören wir immer mehr über nicht-funktionale Tests. Die gängigsten sind Penetrationstests (populär gemacht durch die DSGVO), Leistungstests, Anpassungstests (insbesondere für Mobilgeräte) und Zugänglichkeitstests (populär gemacht durch die RGAA in Frankreich und WCAG im Rest der Welt).
Die Liste der nicht-funktionalen Testarten wird im Einklang mit der zukünftigen Nutzung und Standards wie der RGESN für Ökodesign weiter wachsen.
Wie Sie wissen, ist es unmöglich, all diese Tests gründlich durchzuführen, und ein Tester muss wissen, welche nicht-funktionalen Tests er durchführen muss und in welcher Tiefe.
Mein wichtigster Ratschlag hier ist, sich auf Anforderungen zu verlassen und zu „fordern“, dass es testbare nicht-funktionale Anforderungen gibt … oder einfach zu fordern, dass es für die nicht angesprochenen Punkte keine Anforderungen gibt und daher kein Testbedarf besteht!
Mir ist bewusst, dass der erste Teil in vielen Kontexten utopisch ist. Wenn die Existenz solcher Anforderungen nicht in Betracht gezogen werden kann, kann es sich lohnen, das Thema nicht-funktionale Tests direkt in der Teststrategie des Unternehmens anzugehen und Möglichkeiten zur Auswahl der zu implementierenden nicht-funktionalen Tests vorzusehen. Diese Strategie kann dann in Testpläne umgesetzt werden (Strategie auf Projekt-/Produktebene). In Ermangelung quantifizierter Anforderungen müssen Sie sich von den verschiedenen Standards (DSGVO, RGAA …) inspirieren lassen oder von dem, was Sie auf dem Markt oder in der Produktion beobachten, wenn das Produkt bereits in Produktion ist.
Man könnte argumentieren, dass Testdesign nicht technisch ist. Es stimmt, dass Sie nicht wissen müssen, wie man Code manipuliert oder liest, um gute Tests zu entwerfen. Das Entwerfen von Qualitätstests ist jedoch ein hochtechnischer Aspekt der Arbeit eines Testers.
Es gibt eine Reihe von Testdesignmethoden (die bekanntesten unter Testern sind spezifikationsbasiert), die auf Grundlage der Testbedingungen festlegen, welche Tests mit welchen Werten ausgeführt werden sollen.
Ebenso muss ein Tester wissen, wie er Prioritäten setzt und welche Elemente in welchem Umfang getestet werden sollen, je nach den Risiken und verfügbaren Ressourcen.
Zunächst einmal müssen Sie Ihre Designtechniken, ihre Stärken und Schwächen kennen und wissen, wie Sie sie umsetzen.
Technisches Wissen reicht jedoch nicht aus. Es ist wichtig, den Kontext und das zu testende Produkt zu verstehen. Dadurch können wir uns an den Kontext anpassen und einen Mix aus Techniken vorschlagen, der zu einem möglichst effizienten Testpaket führt.
Es ist auch wichtig, die Testdaten eingehend zu bearbeiten (bestimmte Designtechniken geben klare Hinweise zu den in bestimmten Fällen zu wählenden Werten), um Daten auszuwählen, die die verschiedenen potenziellen Mängel des Produkts am besten identifizieren.
Dies ist für viele Tester ein großes Problem! Testumgebungen sind nicht stabil, nicht leicht zugänglich oder nicht nah genug an der Produktion.
Die Daten sind nicht repräsentativ, nicht zahlreich genug, nicht zugänglich oder nicht anonymisiert…
Das Problem dabei ist, dass es für das korrekte Testen eines Produkts unerlässlich ist, so nah wie möglich an die Produktionsnutzung heranzukommen, um das Benutzerverhalten so getreu wie möglich zu simulieren.
Leider ist es praktisch unmöglich, eine Umgebung zu haben, die sowohl hinsichtlich des Volumens als auch der Interaktion mit Partnern so groß ist wie die Produktionsumgebung. Ebenso ist es keine Lösung, sich ausschließlich auf Produktionstests mit Verschiebungsrechten zu verlassen.
Daten- und Umgebungsprobleme sind im Allgemeinen recht komplex.
Glücklicherweise stehen uns derzeit eine Reihe von Tools zur Verfügung, die uns bei der Bewältigung dieser Probleme helfen. Ich denke dabei insbesondere an die Umgebungsvirtualisierung, mit der wir Umgebungen im Handumdrehen erstellen und so die Probleme von Umgebungen vermeiden können, die von mehreren Teams gemeinsam genutzt werden, oder von Umgebungen mit „bereits verwendeten“ Daten.
Für Daten stehen Tools zur Verfügung (von Herausgebern oder intern), mit denen Sie Daten anonymisieren und Teilmengen aus der Produktion entnehmen können, um repräsentative Stichproben zu erhalten.
Für den Partnerteil ist eine Lösung, die manchmal zwingend erforderlich ist, die Einrichtung von Plugs, da Partner nicht unbedingt gemeinsame Testumgebungen mit unserem Produkt haben oder dieses zu oft „down“ ist.
Kurz gesagt, es gibt hier keine Wunderlösung, sondern eher eine Suche nach pragmatischen Lösungen (oft werkzeugbasiert), die mit jedem Kontext verknüpft sind. Das Wichtigste ist, die problematischsten Punkte zu identifizieren und zu versuchen, sie zu lösen.
Schließlich kommt es auch vor, dass Umgebungs- und Datenprobleme durch menschliches Eingreifen in Kontexten gelöst werden können, in denen Testumgebungen und -daten nicht unter der Kontrolle der Teams stehen, die die Umgebungen und Daten verwenden.