Test Charta

R 2.0.0

Was ist eine Test Charta?

Was ist eine Test Charta?

Die Dokumentation eines Ziels und der Agenda einer Testsitzung.

Beschreibung

Test-Chartas werden oft im explorativen Testen verwendet. Die Charta hilft dabei, die Aufgaben und Ziele des Testens festzulegen. Anhand der Charta wird in einer Testsitzung entschieden, was getestet werden soll, was das Ziel ist und was innerhalb und außerhalb des Testumfangs liegt. In manchen Fällen gibt die Charta auch an, welche Ressourcen eingesetzt werden sollen.

ALT MISSING
Abb. 1: Rahmen einer Test Charta

Eine gute Charta ist eine Aufforderung:

Sie legt Inspirationshilfen nahe ohne genaue Handlungen oder Ergebnisse festzulegen. Gute Test-Chartas sind sehr kurz, sie umfassen selten mehr als eine halbe DIN-A4-Seite.

Mit einer Charta lege ich 3 Dinge fest, um meinem Test einen Rahmen zu geben:

  1. Wo teste ich?

    • Soll eine Funktion getestet werden, eine Anforderung, eine User Story?

  2. Welche Hilfsmittel stehen mir zur Verfügung?

    • Benutze ich Werkzeuge? Brauche ich Testdaten? Konfigurationen?

  3. Welche Informationen hoffe ich zu finden?

    • Z.B. erhoffe ich mir Informationen über Qualitätsmerkmale, z.B. Sicherheit oder Zuverlässigkeit, ist das Design konsistent, werden Standards verletzt?

So besser nicht!👎

Erforschen der Änderung des Nachnamens mit dem Wert O’Malley, um festzustellen, ob die Funktion zum Ändern des Profils Namen mit Apostroph verarbeiten kann.

zu spezifisch

Es gibt nicht viel zu erforschen. Und es klingt wie ein ziemlich seltsam formulierter Testfall.

So auch nicht!👎

Erforschen der Systemsicherheit mit allen möglichen Hacking-Programmen, um alle Sicherheitslücken zu entdecken.

zu allgemein

Diese Charta ist so vage, dass diese Mission nie erfüllt werden kann. Sie fordert dazu auf, das gesamte System mit einer großen Menge undefinierter Hilfsmittel zu erforschen.

Beispiel für eine gute Charta👍

Es ist besser, mehrere Chartas zu erstellen, die sich jeweils auf einen bestimmen Bereich und/oder auf eine bestimmte Art von Sicherheitslücken beziehen, als eine allumfassende große Charta zu benutzen.

Erforschen der Eingabefelder mit Java-Script und SQL-Attacken, um Sicherheitslücken zu finden.

Erforschen der Seiten, die einen Login erfordern mit gefälschten URLs und POST-Parametern, um sicherzustellen, dass Benutzer keinen Zugang zu Inhalten erhalten können, die sie nicht bezahlt haben.

Test-Charta erstellen

Am besten sollte man eng mit den Stakeholdern zusammenarbeiten, um eine Charta zu identifizieren und zu umreißen. Durch Gespräche lässt sich häufig herausfinden, wo Risiken stecken könnten und kann sich darauf beim Testen konzentrieren.

Hier sind einige Quellen, die zur Inspiration dienen können:

Anforderungen

Anforderungsdiskussionen sind ein idealer Zeitpunkt, um eine Charta zu entwerfen → jedes Mal, wenn eine Frage während der Diskussion Unsicherheiten, Vieldeutigkeiten oder Abhängigkeiten aufdeckt.

User Story

Teste die User Story mithilfe ihrer Akzeptanzkriterien

Implizite Erwartungen

Ein Beispiel für implizierte Erwartungen sind nicht funktionale Qualitätskriterien wie Verlässlichkeit oder Performance. Auch wenn die Funktionalität funktioniert sind Antwortzeiten, die von unter einer Sekunde auf über eine Minute steigen, ein Problem, auch wenn die Antwortzeiten nicht ausdrücklich ein Teil der Anforderungen war.

Wann immer eine implizierte Erwartung erkannt wird, die es verdient, hat erforscht zu werden, sollte in einer Charta festgehalten werden.

Charta koordiniert Ziele

Werden Risiken von Stakeholdern ähnlich eingeschätzt? Das hilft, sich nicht lange mit dem Aufspüren von Informationen zu beschäftigen, die nachher niemand verwenden möchte. Solche Fragen können z.B. auch während Anforderungsdiskussionen gestellt werden.

Mögliche Fragen:

"Wenn es Probleme mit Altdaten geben sollte, würde uns das interessieren?"

"Sollten wir nach möglichen Konsequenzen für die Performance Ausschau halten?"

"Wenn wir einen - egal wie verrückten - Weg finden würden, auf dem ein Nutzer sein Konto unbrauchbar machen könnte, würden wie das beheben wollen, richtig?"

Fragen der Stakeholder

Fragen entstehen im gesamten Entwicklungszyklus. Fragen entstehen z.B. beim Überdenken von Designentscheidungen:

"Wie werden die bestehenden Einstellungen zur Privatsphäre von unserer neuen Nachrichtenfunktionalität beeinflusst?"

"Was wird passieren, wenn wir zukünftig die zehnfache Menge an Einträgen zum Katalog hinzufügen?"

Bestehende Artefakte

Sogar der Quellcode kann interessante Charta-Ideen beinhalten. Hier sollte man vielleicht noch einmal genauer nachforschen…​

// Ich weiß nicht warum, aber das funktioniert. Besser nicht anfassen!

Neue Erkenntnisse / neue Entdeckungen

Das Chartern ist ein fortlaufender Prozess. Wenn man merkt, dass man weit über die aktuelle Charta hinaus testen möchte, ist dies ein Hinweis auf weitere Chartas, den man schnell notieren sollte! So kann man sich auf seine aktuelle Charta konzentrieren und später eine neue Charta für weitere Sessions erstellen.

Das Spiel mit den Horrorschlagzeilen

Was sind die schlimmsten Schlagzeilen, die man in den Nachrichten hören könnte und die eigene Software betrifft???

Fehlerdatenbanken

Eine Fehlerdatenbank bietet wahrscheinlich eine Fülle an Erkenntnissen über Bereiche mit früheren Risiken.

Supportanfragen

Welchen Problemen waren die Nutzer bereits früher ausgesetzt?

Test-Touren

Im Internet findet man viele Beispiele für Test-Touren, die helfen den roten Faden nicht zu verlieren. Als Beispiele seien hier einige wenige genannt: Museumstour (auch alten Programmcode berücksichtigen, funktioniert das Zusammenspiel mit neuem?), Garbage Collector Tour (Müllmänner besuchen die ganze Stadt, Straße für Straße, Tonne für Tonne - kurzes Prüfen der Funktionalität), All Nighter Tour (einige Fehler treten nur auf, wenn eine Anwendung lange läuft, Speicherfreigaben).

Quellen