So schreiben Sie eine QS-Dokumentation, die tatsächlich funktioniert

Ein Softwareprodukt ist wie ein Flugzeug: Es muss vor dem Start einer technischen Prüfung unterzogen werden.

Die Qualitätssicherung ist ein notwendiger Schritt zur Einführung eines erfolgreichen Softwareprodukts. Es ist nur ein kleiner Teil der gesamten Projektarbeit, aber niemand hat gesagt, dass es einfach wäre.

Es gibt so viele Arten von Softwaretests - automatisierte und manuelle, explorative und funktionale, Kompatibilitäts-, UI / UX-, Regressions-, Einheiten-, API- und Leistungstests. Viel Glück beim Umwickeln aller!

Allen diesen Typen ist jedoch gemeinsam, dass Sie jeweils eine gründliche Dokumentation zu QS-Tests erstellen müssen. Die Qualität der Testdokumente bestimmt, ob sich Ihre Arbeit als nützlich oder vergeblich erweist.

Ich habe diesen Artikel geschrieben, um Ihnen das Leben ein bisschen zu erleichtern. Hier ist Ihre ultimative Anleitung zum Schreiben von Software-QS-Dokumentation, die funktioniert.

Erstellen Sie einen Testplan und einen Testfortschrittsbericht

Der Testplan ist ein Leitfaden, der das Gesamtbild des QS-Prozesses umreißt und eine Aufgabenliste, Strategie, Ressourcen und einen Zeitplan enthält.

Fragen Sie sich vor dem Erstellen eines QS-Planungsdokuments: „Was ist der Zweck der Softwarelösung?“ und "Welche Funktionen müssen getestet werden?". Testen Sie nicht jeden einzelnen Teil Ihrer Software. Sie müssen entscheiden, welche Methoden, Technologien und Tools Sie verwenden möchten.

Der Testplan hilft Ihnen dabei, Folgendes zu verstehen:

  • Was sind die Akzeptanzkriterien?
  • Welche Ressourcen benötigen Sie? Welche Betriebssysteme, wie viele Kopien und mit welcher Lizenz? Benötigen Sie technische Berater?
  • Sind Ihre Rollen und Verantwortlichkeiten gut definiert?
  • Was sind Testzeiträume?

Der Testfortschrittsbericht ist ein weiterer Teil der QS-Dokumentation, der dem Testplan ähnelt, jedoch zusätzliche Daten zum aktuellen Fortschritt enthält. Mit diesem Dokument können Sie und Ihr Entwicklungsteam den Projektfortschritt überwachen und gegebenenfalls organisatorische Probleme identifizieren.

Testplan & Bericht

Testfälle erstellen

Nachdem Sie die Funktionen geklärt haben, die in Ihrem Testplan getestet werden müssen, müssen Sie für jeden Teil Ihrer Software einen Testfall erstellen.

Testfälle sind ziemlich einfach - diese QS-Dokumentation besteht aus 7 Abschnitten: ID, Testfall, Testschritte, erwartetes Ergebnis, Status, tatsächliches Ergebnis und Kommentare.

  1. ID ist eine eindeutige Nummer, die Ihrem Testfall zugewiesen wird.
  2. Im Testfall Abschnitt, zeigen Sie die Anforderung aus (e) Sie einen Link , um es in den Spezifikationen Dokument zu testen und bereitstellen werden.
  3. In dem Prüfschritte Abschnitt, listen Sie alle Aktionen erforderlich , einen Testfall abzuschließen.
  4. Im Abschnitt Erwartetes Ergebnis fassen Sie das Ergebnis eines bestimmten Tests zusammen, wenn dieser erfolgreich ist.
  5. Im Abschnitt Status geben Sie an, ob ein bestimmter Schritt den Test bestanden hat oder nicht.
  6. Im Abschnitt Tatsächliches Ergebnis erläutern Sie das Ergebnis eines fehlgeschlagenen Tests.
  7. Der Abschnitt " Kommentare " ist nicht obligatorisch, aber Sie können ihn hinzufügen, um einige zusätzliche Notizen zu hinterlassen.
Testfall

Schreiben Sie einen Fehlerbericht

Der Fehlerbericht ist ein wichtiges Element der QS-Dokumentation. Es registriert alle unerwünschten Probleme mit Ihrem Programm. Es ist ein entscheidendes Element der Projektdokumentation, das Sie zu einer fehlerfreien Softwarelösung führt.

Klingt einfach, oder? Ja, aber nur bis Sie mit der Dokumentation beginnen. Hier sehen Sie ein Beispiel für einen typischen Fehlerbericht:

Fehlerbericht

Der Fehlerbericht besteht aus den folgenden Abschnitten: Kennung, Zusammenfassung, Beschreibung, Reproduktionsschritte, Reproduzierbarkeit, Schweregrad, Priorität, Umgebung und Anhänge.

  1. Jedem bestimmten Softwareproblem wird eine eindeutige Nummer zugewiesen - die Kennung . Es optimiert die Navigation durch QS-Dokumente und erleichtert die Kommunikation zwischen Entwicklern, Testern und PMs.
  2. In der Zusammenfassung geben Sie eine kurze Antwort auf drei einfache Fragen: Was ist passiert, wo und unter welchen Umständen?
  3. In der Beschreibung Abschnitt , beschreiben Sie den Fehler im Detail. Sie sollten über die tatsächlichen und die erwarteten Ergebnisse berichten. Es ist nützlich, einen Link zu Ihren Softwareanforderungen bereitzustellen.
  4. Anschließend schreiben Sie über die zu reproduzierenden Schritte (STR) . Dies zeigt Entwicklern genau, wie das Problem reproduziert werden kann. Verpassen Sie keinen Schritt, sonst kehrt Ihr Bericht möglicherweise zu Ihnen zurück.
  5. Im Abschnitt zur Reproduzierbarkeit klären Sie, ob der Fehler jedes Mal auftritt, wenn Sie der STR folgen. Sie sollten Zahlen verwenden, um ungefähre Chancen anzuzeigen, z. B. 7 von 10.
  6. Im Abschnitt zum Schweregrad erklären Sie, wie viel Schaden der Fehler dem Projekt zufügen kann. Mit anderen Worten, es zeigt den technologischen Grad des Einflusses des Defekts auf das gesamte System. Selbst ein kleines Problem kann die gesamte Anwendung stark beeinträchtigen.
  7. Die Priorität zeigt, wie wichtig ein bestimmter Fehlerbericht ist. Die Priorität kann mit Hilfe von Buchstaben angegeben werden - "A" für die dringendsten und "Z" für die am wenigsten dringenden, Zahlen - "1" für die dringendsten und "9" für die am wenigsten dringenden oder einfach Wörter wie "hoch" ”,“ Mittel ”oder“ niedrig ”.
  8. Im Abschnitt Umgebung sollten Sie definieren, welche Betriebssysteme oder Browserversionen betroffen waren.
  9. Schließlich enthalten die Anhänge die Liste der Videos, Screenshots oder Konsolenprotokolldateien, die dem Fehlerbericht hinzugefügt wurden.

Beachten Sie diese nützlichen Tipps zum Schreiben von Fehlerberichten

  1. Schreiben Sie eine ausreichende und angemessene Zusammenfassung. Es spielt keine Rolle, ob es lang oder kurz ist. Was zählt ist, dass es klar sein sollte.
  2. Schauen Sie sich die Zusammenfassung und die Beschreibung an. Sehen sie ziemlich gleich aus? Sie müssen vergessen haben, erwartete und tatsächliche Ergebnisse in der Beschreibung zu skizzieren und den Link zu den Anforderungen hinzuzufügen.
  3. Erfassen Sie das Problem mithilfe eines Screenshots. Dies kann Ihnen und dem Entwicklungsteam viel Zeit sparen. Manchmal reicht ein Blick auf das Bild gerade aus, um die Situation zu verstehen.
  4. Versuchen Sie, das Problem mindestens dreimal zu reproduzieren, bevor Sie es melden, um sicherzustellen, dass es vorhanden ist.
  5. Melden Sie das Problem so schnell wie möglich und benachrichtigen Sie Ihren Projektmanager oder Produktbesitzer, wenn das Problem schwerwiegend ist.
  6. Überprüfen Sie Ihre QS-Dokumentation auf Grammatikfehler, damit Sie nicht von der Grammatikpolizei entfernt werden.
  7. So komisch es auch klingen mag, stellen Sie sicher, dass das Problem keine Funktion ist - lesen Sie die Dokumentation erneut!
  8. Verpassen Sie keine wichtigen Informationen in Ihren Schritten zur Reproduktion.

Senden Sie einen Fehlerbericht

Fehlerberichte durchlaufen einen Lebenszyklus - vom Moment, in dem Sie ein Problem melden, bis zum Moment, in dem das Problem geschlossen wird.

Lebenszyklus von Fehlerberichten

Der erste Schritt besteht darin, den Fehlerbericht zu erstellen und einzureichen . An diesem Punkt entscheidet der Projektmanager oder ein technischer Projektleiter , ob zu vergeben , es zu einem Entwickler oder sinken sie auf dem Gelände der Insuffizienz oder Unzulänglichkeit.

Nachdem der zugewiesene Entwickler den Fehler behoben hat , müssen Sie als Qualitätssicherung überprüfen, ob er behoben wurde. Wenn ja, können Sie in der Nähe des Defekts Bericht. Die beste Vorgehensweise ist, es in ein oder zwei Wochen zu schließen.

Wenn der Fehler nicht behoben ist, öffnen Sie den Fehlerbericht erneut und senden ihn an den zugewiesenen Entwickler zurück. Der Fehlerbehebungsprozess kann langwierig sein, aber Sie müssen stark bleiben, bis alle Fehlerberichte endgültig geschlossen sind.

Einwickeln

Qualitätssicherung ist ein Prozess, den Sie einfach nicht vermeiden können. Jedes Flugzeug wird vor dem Abflug einer technischen Prüfung unterzogen. Wenn es ein Problem gibt, wird das Flugzeug geerdet, bis das Problem behoben ist.

Ebenso muss jedes Softwareprodukt vor dem Start überprüft werden. Sie können es sich nicht leisten, fehlerhafte Software bereitzustellen, da Benutzer Ihrer App keine zweite Chance geben.

Müssen Sie die Qualität Ihrer Software verbessern?

Meine Firma KeenEthics bietet solide Entwicklungs- und Qualitätssicherungsdienste. Wenn Sie einen Kostenvoranschlag für ein ähnliches Projekt benötigen, können Sie sich gerne an uns wenden .

Wenn Ihnen der Artikel gefallen hat, sollten Sie mit Was ist Prototyping und warum brauchen wir es und minimal lebensfähiges Produkt: Zwischen einer Idee und dem Produkt fortfahren.

PS

Den Originalartikel im KeenEthics-Blog finden Sie hier: Wie schreibe ich eine QS-Dokumentation, die funktioniert?