Lesezeit: 4 Minuten
Demokratisierung von Softwaretests
Herkömmliche Tests von Software-Systemen sind häufig sehr technisch und detailliert, was die Beteiligung von nichttechnischen Stakeholdern und Product Managern ausschließt. Dies führt dazu, dass die Tests auf die QA oder die Entwicklungsabteilung konzentriert bleiben. Das Ergebnis ist eine eingeschränkte Perspektive auf Probleme und Lösungen. Im Folgenden wollen wir die Schwierigkeiten und Konsequenzen dieses herkömmlichen Ansatzes genauer beleuchten.
Schwierigkeiten des traditionellen Testens
Das Begrenzen der Testaktivitäten auf Entwickler oder spezialisierte Tester kann zu einer Reihe von Problemen führen:
- Eingeschränkte Perspektive: Entwickler und Tester haben oft eine technisch orientierte Sichtweise. Dies kann dazu führen, dass wichtige Aspekte der Benutzererfahrung oder Geschäftsziele übersehen werden, die von anderen Stakeholdern wie Marketing, Vertrieb oder sogar Endkunden besser verstanden würden. Diese eingeschränkte Perspektive kann die Zufriedenheit der Nutzer beeinträchtigen und den wirtschaftlichen Erfolg des Produkts mindern.
- Verzögerte Fehlererkennung: Wenn Tests nur von einer kleinen Gruppe durchgeführt werden, bleiben Fehler oft unentdeckt, bis sie in späteren Phasen teurer und zeitaufwendiger zu beheben sind. Das kann zum Beispiel den Produktstart verzögern und die Entwicklungskosten in die Höhe treiben.
- Kommunikationsschwierigkeiten: Das Fehlen einer gemeinsamen Sprache zwischen technischen und nichttechnischen Teammitgliedern kann zu Missverständnissen führen. Diese Kommunikationslücken können die Zusammenarbeit erschweren und die Effizienz des Projekts beeinträchtigen.
- Isolierung und fehlende Zusammenarbeit: Durch das isolierte Arbeiten der Entwickler und Tester kann sich eine Kluft zwischen den verschiedenen Abteilungen des Teams bilden. Diese Trennung erschwert die Zusammenarbeit und kann verhindern, dass das Team eine ganzheitliche Betrachtung des Produkts erreicht. Der Mangel an Interaktion zwischen den verschiedenen Rollen führt oft zu Reibungen und Missverständnissen, die den gesamten Entwicklungsprozess behindern können.
- Qualitätsverlust: Die Beschränkung des Testens auf eine kleine Gruppe von Spezialisten kann zu einer niedrigeren Gesamtqualität des Endprodukts führen. Nicht alle Aspekte wie Benutzerfreundlichkeit, Kompatibilität oder Performance können gleichermaßen berücksichtigt werden. Dies kann zu einem Produkt führen, das zwar technisch funktioniert, aber in anderen wichtigen Bereichen Mängel aufweist.
Diese Probleme zeigen deutlich, dass eine Änderung der traditionellen Testmethoden notwendig ist, um eine qualitativ hochwertige und zeit- und kosteneffiziente Softwareentwicklung zu ermöglichen.
Hier können Testtools wie Cypress und Cucumber eine entscheidende Rolle spielen. Indem sie eine Brücke zwischen technischen und nichttechnischen Teammitgliedern bauen und das Schreiben von Tests in einer Sprache ermöglichen, die von allen verstanden werden kann, fördern sie die Zusammenarbeit im Testprozess. Die damit einhergehende größere Perspektiven- und Kompetenzenvielfalt ermöglicht schlussendlich ein Produkt, das besser, billiger und inklusiver ist.
Cypress
Cypress ist ein Testing Tool, welches die Automatisierung von Unit-, Integrations- und E2E-Tests im Frontend ermöglicht. Die Lernkurve, um Cypress Tests zu schreiben, ist flach und durch die BDD-Syntax (Behavior Driven Development) leicht verständlich.
Cypress Tests werden in Spec Files hinterlegt und folgen einer ähnlichen Struktur und Syntax anderer Testframeworks. Mit 'describe' können Tests gruppiert werden. Der einzelne Testfall wird in 'it' Blöcken festgehalten. 'beforeEach' und 'afterEach' werden verwendet, um die Konfiguration für die Testfälle vorzubereiten und nach Ausführung dieser aufzuräumen.
Kommandos wie cy.visit und cy.click ermöglichen die Steuerung des Browser wie das Aufrufen einer Seite oder Klicken eines Buttons. Diese sind besonders bei End-to-End Tests von hoher Relevanz.
Am Ende der Tests stehen die Assertions, die in Cypress so aussehen 'expect(Ergebnis).to.equal(Erwartung)' oder '.should(‚equal‘. Erwartung)'. Die Assertions können mit weiteren Schlüsselwörtern detailliert geschrieben und angepasst werden, um die fachliche Richtigkeit der Umsetzung zu beschreiben.
Neben der intuitiven Möglichkeit der Verwendung des Tools und Stabilität der Tests, bietet Cypress unter anderem Features wie Time Travel oder automatisiertes Warten, weshalb es momentan ein beliebtes und weit verbreitetes Testwerkzeug für JavaScript ist.
Wie bereits erwähnt, ist Cypress ein Testframework, mit welchem man jegliche Art von Tests in JavaScript schreiben kann, jedoch sind meistens die E2E-Tests im Kontext mit Cucumber gemeint.
Cucumber
Cucumber ist ein Tool, welches BDD unterstützt und die Kommunikation zwischen dem technischen und nicht-technischen Team verbessert. Die Tests werden in Gherkin geschrieben und haben eine durch Schlüsselwörter (Given-When-Then) vorgegebene Struktur und stellen das fachliche Verhalten eines Software-Features dar. Die Bedeutung der Wörter ist wie folgt:
- Feature: sollte eine grobe Beschreibung des Features beinhalten
- Example/Scenario: ist ein konkretes Beispiel, welches den Geschäftsfall definiert
- Given: hier wird die Vorbedingung des Tests beschrieben
- When: beschreibt die Aktion, die ausgeführt wird
- Then: definiert das erwartete Resultat
- And, But: um besser lesbare Tests zu erhalten, können die Vorbedingungen und Resultate aufgelistet werden
Darüber hinaus gibt es weitere primäre Schlüsselwörter wie Background, Rule, Scenario Outline, mit denen die Tests weiter vereinheitlicht und spezifiziert werden können.
Sekundäre Schlüsselwörter wie '#', '@', '"""' oder '|' werden für Kommentare, Tags, Dokumentation und tabellarische Darstellung verwendet.
Diese Beschreibungen werden in sogenannten Gherkin Feature Files abgelegt, welche zugleich auch eine Gruppierung der Tests darstellen. Die Tests werden in der Sprache der Anwender geschrieben, da Übersetzungen vermieden werden sollen. Aus diesem Grund sind die Gherkin Schlüsselwörter in bis zu 70 Sprachen vorhanden.
Natürlich ist es möglich, für jede Eingabe einen Test zu schreiben. Dies führt jedoch dazu, dass viele redundante Testbeschreibungen existieren. Um dies zu vermeiden, werden Datentabellen für das Testen von verschiedenen Datensätzen verwendet. Im vorherigen Beispiel sollen für den Titel des Tasks verschiedene Eingaben gemacht und deren Resultate überprüft werden. Dafür wird das Feature File folgendermaßen umgeschrieben:
Wir haben nun gesehen, dass beide Werkzeuge intuitiv zu verwenden sind. Jedoch bleibt die Frage offen, wie man aus einem Gherkin Feature File einen lauffähigen Cypress Test erhält?
Für eine Umwandlung werden sowohl ein Preprocessor, welcher die Feature Files in Cypress Tests umwandelt, als auch die Step Definitions benötigt. Zum Preprocessor ist noch anzumerken, dass verschiedene Implementierungen existieren, diese sich jedoch nur im Detail unterscheiden.
Zu den einzelnen Schritten in den Feature Files müssen noch Step Definitions in Cypress definiert/geschrieben werden. Dabei werden nur die Schritte definiert, die für einen erfolgreichen Testlauf von Bedeutung sind, d.h. Schritte wie Funktionalität, ein Kommentar oder Szenario werden nicht in die Step Definitions aufgenommen, da sie nur von informativer Natur sind.
Abgeleitet aus dem Feature Files Beispiel mit der Datentabelle werden also folgende Schritte in eine Step Definition Datei übernommen:
Im Feature File wird eine Datentabelle für die Beschreibung Wenn und Dann benutzt. Entsprechend sind die Schritte in den Step Definitions zu parametrisieren.
Fazit
Cypress und Cucumber bilden ein starkes Team, das die Teststrategie verbessern und vielleicht sogar revolutionieren kann. Die Tests können jedoch nicht von Beginn eines Projektes alleine von nicht-technischen Stakeholdern umgesetzt werden. Es bedarf noch Entwickler bzw. technische Mitglieder eines Teams, die sowohl das Projekt entsprechend vorbereiten als auch die Step Definitions implementieren.
Die Umsetzung der Step Definitions wird am Anfang des Projektes noch aufwendig sein, aber nach und nach können bestimmte Schritte, wie beispielsweise die Navigation zu einer Seite, wiederverwendet werden. Somit kann ein nicht-technischer Stakeholder im Laufe des Entwicklungsprozesses immer selbstständiger Tests implementieren und dadurch die technischen Stakeholder beim Testen unterstützen. Kein Testing-Tool ersetzt jedoch klare Testgrenzen, eine gute Organisation und eine saubere Implementierung. Bei der anfänglichen Einbindung in eine Test-Infrastruktur können auch andere Hürden auftreten, die jedoch mit guter Planung überwunden werden können.
Mögliche Widerstände und Schwierigkeiten, die berücksichtigt werden sollten, sind unter anderem:
Fehlender Wille: Ein Mangel an Engagement oder Verständnis für die Vorteile dieser Tools kann die Einführung behindern.
Konservative Einschätzungen: In einigen Organisationen könnte es eine Neigung geben, an bewährten Methoden festzuhalten, was die Einführung neuer Tools verlangsamen würde.
Verschiebungen des Aufwands: Obwohl die Einführung dieser Tools langfristig Vorteile hat, könnte sie zunächst zusätzliche Ressourcen in Form von Schulung, Anpassung und Integration erfordern. Ebenso sollten die Konsequenzen bedacht werden, die der Mehraufwand zum Beispiel auf Seiten des Product Owners mit sich bringt und ob dieser überhaupt die Zeit dafür aufbringen kann.
Technische Hürden: Die Integration in bestehende Systeme könnte technisch anspruchsvoll sein und spezialisiertes Wissen erfordern.
Darüber hinaus sollte man sich immer schon vor dem eigentlichen Testen im Klaren darüber sein, welchen Umfang die Tests haben sollen, was genau abgetestet werden soll und wann und wo die Tests laufen. Alle diese Faktoren sollten sorgfältig geplant und abgewogen werden, um sicherzustellen, dass die Einführung von Cypress und Cucumber reibungslos verläuft. Wenn man das alles bedenkt, ist der Weg für eine neue und grandiose Testerfahrung geebnet und kann mit Freude begangen werden, trotz der möglichen Herausforderungen, die überwunden werden müssen.
