Testpläne und wie man sie am besten schreibt

StackOverflow https://stackoverflow.com/questions/32377

  •  09-06-2019
  •  | 
  •  

Frage

Wir versuchen herauszufinden, wie wir Tests am besten in unseren Testplan schreiben können.Insbesondere beim Schreiben eines Tests, der von jedermann, einschließlich QA-Mitarbeitern, verwendet werden soll, sollten die Schritte im Test sehr spezifisch oder umfassender sein, um dem Tester mehr Spielraum bei der Lösung der Aufgabe zu geben.Als sehr einfaches Beispiel: Wenn Sie das Öffnen eines Dokuments in einem Textverarbeitungsdokument testen, sollte der Test lauten:

  1. Öffnen Sie mit der Maus das Dateimenü
  2. Wählen Sie im Dateimenü „Datei öffnen…“.
  3. Navigieren Sie im angezeigten Dialogfeld „Datei öffnen“ zu x und doppelklicken Sie auf das Dokument mit dem Namen y

ODER

  1. Rufen Sie den Dialog zum Öffnen der Datei auf
  2. Öffnen Sie die Datei y

Jetzt ist mir klar, dass eine Antwort wahrscheinlich lauten wird: „Es hängt davon ab, was Sie testen möchten“, aber ich versuche hier, eine umfassendere Frage zu beantworten:Wenn die Testschritte zu spezifisch sind, riskieren wir, a) den Testprozess zu mühsam und langwierig zu machen und, was noch wichtiger ist, b) riskieren wir, etwas zu verpassen, weil wir einen zu spezifischen Weg zum Erreichen eines Ziels aufgeschrieben haben.Alternativ: Wenn wir es weit fassen, sind wir dann zu sehr von den Launen des jeweiligen Testers abhängig und verlieren wichtige Tests von Pfaden, die bei Kunden/Auftraggebern üblicher sind?

War es hilfreich?

Lösung

Meine erste Frage wäre: Warum schreibt Ihre Qualitätssicherungsabteilung nicht die Testpläne?Typischerweise stellen Softwareentwickler der Qualitätssicherung eine funktionale Spezifikation darüber zur Verfügung, wie die Software funktionieren soll, und die Qualitätssicherung erstellt dann darauf basierende Testpläne.

Vor diesem Hintergrund würde ich vorschlagen, die Schritte sehr genau anzugehen, da Sie detailliert beschreiben, wie die Dinge sind angeblich arbeiten.Es ist dann die Aufgabe des Testers, sicherzustellen, dass Ihre spezifischen Schritte die gewünschten Ergebnisse erzielen, und es ist auch seine Aufgabe, vom Plan abzuweichen und zu versuchen, Dinge kaputt zu machen.

Wenn es mehrere Wege gibt, ein Ziel zu erreichen, müssen Sie jeden Weg beschreiben, der dorthin führt.

Andere Tipps

Ich bin kein Tester, aber meiner Meinung nach ist es wichtig, die „UI-Route“, die der Test nehmen muss, zu dokumentieren, um Verwirrung zu vermeiden.

Ich habe an unzähligen Fehlern gearbeitet, die ich nicht reproduzieren konnte, weil ich nicht über denselben UI-Pfad wie der Tester auf die Funktion zugegriffen habe.z.B.Rechtsklick-Menü vs. Symbolleiste oder Funktionen, die aus verschiedenen Dialogen usw. ausgeführt werden können.usw.

Es hört sich so an, als wären Ihre QA-Mitarbeiter in Wirklichkeit QC (Qualitätskontrolle), wenn sie nicht für das Schreiben von Tests verantwortlich sind.Wenn sie tatsächlich für das Schreiben von Tests verantwortlich sind, werden Ihre Tests hilfreich sein, aber klare Spezifikationen wären für sie eine bessere Quelle, um die Tests selbst zu schreiben.Noch besser wäre es, sie in den Überprüfungsprozess der Spezifikationen einzubeziehen, damit sie nach Details fragen können, die es ihnen ermöglichen, Tests zu schreiben.

Wenn Sie wirklich in der Lage sind, Tests für andere Leute zu schreiben, gibt es einige Überlegungen.Sie benötigen einen schmerzhaften Detaillierungsgrad, wenn:

  • Die Personen, die die Tests durchführen, können Ihnen keine Fragen stellen
  • Die Personen, die die Tests durchführen, sind mit Ihrem Produkt nicht vertraut

Einige Angaben können Sie vermeiden, wenn diese nicht der Wahrheit entsprechen.Allerdings kommt es immer noch darauf an :)

Abgesehen davon handelt es sich bei dem, was Sie geschrieben haben, nicht um das, was allgemein als „Testplan“ angesehen wird.Ein Testplan beschreibt, welche Arten von Tests ausgeführt werden (Funktion, Regression, Sicherheit usw.), welche Funktionen getestet werden sollen, vielleicht sogar, welche Tests geschrieben werden sollen, wer die Tests durchführen wird und wann Testgruppen vorhanden sind geplante und andere Planungsaktivitäten.

Was Sie oben beschreiben, ist lediglich eine Reihe von Tests.

Das erste ist das Testen von Funktionen.Testen Sie mit detaillierten Schritten, die die UI-Route enthalten, da es möglicherweise mehr als eine Route zum Ziel gibt.Testen Sie alle Routen.Letzteres klingt eher nach Usability-Tests.Dies sollte auch durchgeführt werden, aber nicht nur von Ihren Testern, sondern auch von externen Personen.

Unterscheiden wir zwischen Testplan und Testsuiten :)

Die Test Suite besteht aus einer Reihe von Tests

Der Testplan ist [Teil der] Testsuite + verfügbare Ressourcen (Personen, Hardware, Zeit, ...).

Es ist in Ordnung, beide Varianten (detailliert und „grob“) in Ihrer Testdokumentation beschrieben zu haben. Platzieren Sie detaillierte und „grobe“ Tests einfach in verschiedenen Dokumenten und priorisieren Sie diese Dokumente.

Wenn Sie dann genügend Zeit haben, das Produkt vollständig zu testen, nehmen Sie alle Dokumente beispielsweise der Kategorie A und testen das Produkt gemäß diesen Dokumenten.Wenn Sie keine Zeit haben, aber eine schnelle Aussage über die Qualität benötigen, nehmen Sie Dokumente der Kategorie B und bestehen die dort beschriebenen Prüfungen.

Gute Seite:Sie können auswählen, wie das Produkt getestet werden soll

schlechte Seite:Sie benötigen „doppelte“ Dokumente

Es ist völlig in Ordnung, genaue, detaillierte Reproduktionsschritte zu verlangen, wenn jemand ein Problem findet.Wenn Sie Ihre Testpläne jedoch auf diese Weise schreiben, riskieren Sie die folgenden Probleme:

1) Unaufmerksamkeitsblindheit - Ich habe beobachtet, wie Leute ein detailliertes prozedurales Testskript ausführten, jeden Schritt pflichtbewusst durchgingen und akribisch aufzeichneten und den eklatanten Fehler direkt vor ihnen völlig übersahen.Weil es „nicht im Drehbuch stand“.Ihre Aufmerksamkeit war so auf all diese kniffligen Testschritte gerichtet, dass sie die vor ihnen liegenden Probleme buchstäblich nicht erkennen konnten.

2) Sie werden ALLE Fehler verpassen, die nur einen Schritt von Ihrem sehr detaillierten, sehr spezifischen Weg entfernt sind.Wenn Kunden Ihr Produkt erhalten, folgen sie nicht dem detaillierten Testplan.Sie navigieren auf unterschiedliche Weise durch Ihre App.Sie werden ihre Meinung ändern.Ihre Namen werden länger oder kürzer sein, als Sie für wahrscheinlich oder möglich gehalten haben.Sie werden eine Transaktion zur Hälfte abgeschlossen haben und sie dann abbrechen.Sie werden wandern.Sie werden nicht an einem Weg festhalten.Und jedes Mal, wenn jemand den Test wiederholt, werden ihm diese Fehler erneut entgehen.

3) Sie werden unglaublich viel Zeit damit verbringen, Testskripte zu schreiben, bei denen jeder nachvollziehen kann.Glauben Sie mir, ich habe jahrelang versucht, dies zu perfektionieren, aber es ist einfach nicht menschlich möglich.Schlimmer noch: Die Zeit, die Sie damit verschwenden, könnten Sie auf andere Weise viel gewinnbringender einsetzen, sodass Ihr Produkt schlechter dasteht.

4) Am Ende wird es eine Menge Wiederholungen geben, und es wird schwer sein, den Sinn Ihres Tests zu erkennen, ohne den gesamten Text zu lesen.Es wird nicht einfach sein, die Tests schnell durchzugehen, um herauszufinden, welche Anwendungsfälle Sie möglicherweise übersehen haben.

Halten Sie Ihre Testpläne breit gefächert und ermöglichen Sie den Personen, die die Tests durchführen, ihr Urteilsvermögen.Wenn Sie Informationen zu bestimmten Nutzungsszenarien haben, die getestet werden müssen, oder darüber, wie die Zielgruppe vorgehen möchte, dann geben Sie diese zusammen mit den Testplänen auch an die Tester weiter – vielleicht in Form von User Personas, vielleicht auch nur in Form die Form von Anwendungsfällen.Wenn Sie bestimmte Dinge abhaken müssen, ziehen Sie die Verwendung einer Checkliste in Betracht.(Weitere Informationen finden Sie in der hervorragenden Präsentation von Cem Kanerwww.kaner.com/pdfs/ValueOfChecklists.pdf).

Alternativ können Sie Ihre Testpläne auch als kurze Erkundungschartas verfassen.Sie könnten beispielsweise Anleitungen geben wie:„Callcenter-Benutzer werden Workstations ohne angeschlossene Maus verwenden.Erkunden Sie den Prozess der Erstellung eines Tickets im Namen eines Kunden und stellen Sie sicher, dass alle Aktivitäten nur mit Tastenkombinationen abgeschlossen werden können.“ Dies führt weitaus wahrscheinlicher dazu, dass Ihre Tester Fehler finden, als wenn Sie sagen: „Tab in Feld 1.“Geben Sie „Beschwerde über Leitungsqualität“ ein.Tab in Feld 2.Wählen Sie „Telefonanruf“ aus dem Dropdown-Menü.Tab in ....Feld 68.“

Es hat Vor- und Nachteile, Ihren Tester so zu behandeln, als ob er keine Kenntnisse über das System oder Computer im Allgemeinen hätte.

wenn Sie die Dinge bis ins kleinste Detail formulieren (z. B.„Wählen Sie im Dateimenü „Öffnen“ ...“), dann haben Sie den Vorteil, dass Sie Auftragnehmer verwenden können, die mit Ihrem System nicht vertraut sind. Aber Es dauert länger, so zu schreiben

Wenn Sie viele Details überspringen (z. B.„Eine Dokumentdatei öffnen...“), als dass derjenige, der Ihren Testplan verwendet, mit größerer Wahrscheinlichkeit stecken bleibt und Sie zur Klärung unterbricht. Aber es ist viel schneller zu schreiben

Es kann eine falsche Ökonomie sein, zu denken, dass es schneller geht, wenn man die flotte Version macht, wenn man am Ende nur zusätzliche Zeit damit verbringt, dem QS-Mitarbeiter das System zu erklären

Ich habe einen Artikel, in dem ich näher auf dieses Thema eingehe: Schreiben eines Systemtestplans

In diesem Artikel bevorzuge ich den detaillierteren Ansatz.Aber ich habe in letzter Zeit einen „Mittelpunkt“ zwischen diesen beiden Ansätzen entwickelt (genannt a FEATURE-Testplan), aber ich bin noch nicht so weit, dass es ausgereift genug ist, um es zu teilen

-- LM

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top