Was ist ein Software-Testplan?
Ein Testplan beschreibt, wie Ihr QS-Team das Testen eines bestimmten Teils des Softwareprodukts angehen wird. Ein Testplan umfasst Ziele, Zeitplan, Ergebnisse und Ressourcen, die zum Erreichen dieser Ziele erforderlich sind. Ein qualitativ hochwertiger Testplan ist die Investition von Zeit wert, da ein sorgfältiger Ansatz zu einer guten Fehlererkennung führt und die mit der Qualitätssicherung verbundenen zeitlichen und finanziellen Risiken mindert.
Das Gute von Testplänen liegt in ihrer praktisch unternehmensweiten Reichweite. Nur wenige Komponenten des Testplans sind besonders technisch. Das Dokument ist meist für alle Beteiligten zugänglich und vermittelt ein Bild der Qualitätssicherung, das bei allen im Projekt ankommt. Tester verbringen in der Regel weniger Zeit mit ihren nicht aus der Technik kommenden Kollegen, als mit Entwicklern, so dass ein Einblick in die Arbeit der QS ebenfalls von Vorteil ist.
Testplan und Teststrategie: Sind sie dasselbe?
Während einige die Begriffe synonym verwenden, schreit dies geradezu nach bewusster oder unbewusster Missachtung von Nuancen. Testpläne decken einen eher engen Bereich ab — sie helfen sicherzustellen, dass bestimmte Teile der Software den Standards entsprechen. Beim Prozess der Testplanung geht es, wie der Name schon sagt, viel mehr um die zu liefernden Ergebnisse und den Weg dorthin. Es ist die Teststrategie, die das große Bild liefert und warum Ihre QS-Spezialisten all dies tun.
Um den Unterschied zu Testplänen besser zu verdeutlichen, wird hier erläutert, was eine Teststrategie beinhalten könnte:
- Die im Projekt verwendete Technologie und ihre Auswirkungen auf die QS
- Projektweite technische Risiken
- Teststufen (es sei denn, Sie setzen voll auf Agilität, natürlich)
- Arten von Prüfungen
- Allgemeiner Zeitplan in Übereinstimmung mit dem Zeitplan für die Produktentwicklung
Holen Sie sich eine Vorlage für eine Teststrategie, die es uns ermöglicht, Software 2 Mal so schnell zu veröffentlichen
Was sind die Anforderungen an den Testplan?
Wie ich bereits erwähnt habe, können sowohl die Notwendigkeit von Testplänen als auch die Pläne selbst ziemlich fließend sein. Dennoch gibt es einige Kriterien, die bei der Erstellung eines Testplans zu beachten sind.
- Prägnanz. Vermeiden Sie nach Möglichkeit lange Sätze. Einleitende Sätze sollten nach Möglichkeit weggelassen werden. Ein Testplan ist (im Gegensatz zu diesem Artikel) kein Stück Prosa: Er ist ein tägliches Handbuch, in dem Floskeln schnell veraltern
- Struktur. Wenn Sie einen Testplan erstellen, nehmen Sie sich die Zeit, den Inhalt übersichtlich zu organisieren. Ein gutes Inhaltsverzeichnis ist sehr hilfreich, vor allem für häufige Nutzer, die sich nicht immer im Kontext stehen (z. B. Programmierer)
- Lesbarkeit. Wie bereits erwähnt, sollte Ihr Testplan für alle Beteiligten von Nutzen sein. Vermeiden Sie den QS-spezifischen Jargon, wenn Sie können. Wenn Sie derjenige sind, der den Testplan schreibt, holen Sie sich Feedback von nicht-technischen Kollegen, um zu sehen, ob sie stolpern, wo sie nicht stolpern sollten
- Anpassungsfähigkeit. Dinge können schief gehen, und nicht unbedingt auf der Seite der QS. Ein Rückschlag bei den Produkt-, Design- oder Entwicklungsteams bedeutet auch einen Rückschlag für Sie. Berücksichtigen Sie solche Risiken, um den Plan relevant zu halten
- Genauigkeit. Nicht jeder wird den Plan auf einer täglichen Basis konsultieren, besonders wenn ihre Arbeit das nicht erfordert. Eine falsche Aussage kann einigen Teammitgliedern falsche Ideen geben, die monatelang bei ihnen bleiben
Schritte zur Entwicklung des Testplans
Schritt 0: Analyse des Produkts
Dieser Schritt ist vielleicht nicht so wichtig, wenn Sie schon eine Weile an dem Projekt gearbeitet haben. Andererseits bedeutet die Entwicklung eines Testplans für ein neues Projekt immer, dass Sie Ihre Hausaufgaben machen müssen. Dies gilt umso mehr, wenn das Team ein automatisiertes Softwaretestwerkzeug verwendet. Je besser Sie verstehen, wie die Software tickt, desto mehr Möglichkeiten zur Automatisierung werden Sie sehen.
Nicht nur andere QS-Spezialisten sollten Ihnen helfen, das Produkt zu verstehen. Fragen Sie den Produktbesitzer nach der Markteinführung und den Funktionen mit hoher Priorität, da die Qualität möglicherweise zugunsten der Geschwindigkeit geopfert wurde. Sprechen Sie mit dem Projektmanager, um zu sehen, ob er mit wiederkehrenden Problemen konfrontiert war. Fragen Sie Entwickler, wo technische Schulden zu einem Misserfolgspunkt werden könnten.
Schritt 1: Definieren Sie den Umfang
Testpläne sind in der Tat nicht dazu gedacht, alles über Ihr Produkt abzudecken. Sie konzentrieren sich in der Regel auf die Teststufe (z. B. Geräte- oder Systemtest) und können sich zusätzlich auf die Testarten einschränken. Die Differenzierung zwischen funktionalem und nicht-funktionalem Testen ist oft schon eine Unterscheidung an sich.
Sehen wir uns die Tests von Bankensoftware als Beispiel an. Ihre Bank hat möglicherweise einen Lifestyle-Bereich eingeführt, in dem Kunden eine Konzertkarte kaufen oder einen Tisch in einem Restaurant reservieren können. Ihre Bank vergibt auch Treuepunkte für alle Transaktionen, einschließlich Lifestyle-Käufe. Wenn die Aufgabe darin besteht, sicherzustellen, dass die Treuepunkte für diese neuen Lifestyle-Käufe korrekt vergeben werden, betrifft Ihr Testplan Integrationstests.
Schritt 2: Listung Sie die Prüfkriterien auf
Sobald Sie wissen, worauf Sie achten müssen, ist es nur logisch zu definieren, was Erfolg und Misserfolg der QS ausmacht. Fühlen Sie sich frei, Benchmarks einzuführen, die für den Umfang relevant sind. Einige Beispiele sind die prozentuale Fehlerquote, die Erfolgsquote von Testfällen und der Schwellenwert schwerer offene Defekte.
Weitere Testkriterien finden Sie in unserem Artikel über die Beendigung von Tests.
Schritt 3: Zeichnen Sie die Umgebung auf
Da wir nun sowohl den Umfang als auch die Kriterien kennen, ist es an der Zeit zu entscheiden, wie Sie vorgehen wollen. Schreiben Sie alle Tools auf, die Ihr Team für Softwaretests verwendet. Beurteilen Sie, ob diese Suite für den Umfang ausreichend ist. Recherchieren Sie und fügen Sie bei Bedarf neue Lösungen hinzu.
Besonders bei einem neuen Projekt ist besondere Sorgfalt bei der Vorbereitung des QS-Teams auf die Testautomatisierung erforderlich. Führen Sie die QS-Spezialisten durch die Automatisierungsideen, die Sie während der Analysephase gesammelt haben. Stellen Sie sicher, dass sie die notwendigen Automatisierungstools beherrschen, um diese Vision umzusetzen. Die Ressourcenplanung kann sehr wohl Teil dieses Schritts sein, auch ohne Automatisierung.
Schritt 4: Erstellen Sie einen Zeitplan
Der nächste Schritt besteht darin, einen Zeitplan der Aktivitäten zu erstellen, um den Umfang zu erfüllen. Den Zeitplan der Produkt- und Entwicklerteams zu kennen, ist 90 % der Erstellung Ihres eigenen Zeitplans. Achten Sie darauf, mögliche versäumte Fristen sowohl für Sie als auch für deren Ende zu berücksichtigen.
Die Testautomatisierung kann den Planungsaufwand erheblich erleichtern. Wenn einzelne Module während der Entwicklung geprüft werden, verbringen Ihre QS-Spezialisten weniger Zeit damit, darauf zu warten, dass die Entwickler ihnen den nächsten Build schicken. Diese Zeit kann besser für Erkundungstests und gegebenenfalls für das Nachholen von verpassten Terminen genutzt werden.
Schritt 5: Schreiben Sie die Leistungen auf
Jetzt bleibt nur noch, die erwartete Ausgabe zu formalisieren. Der Testplan, den Sie möglicherweise gerade schreiben, ist ebenfalls ein Ergebnis. So sind die neuen Testfälle, die Ihr Team machen wird, sowie alle Früchte der Automatisierungsarbeit.
Testergebnisse sind wohl die ultimativen Ergebnisse, da sie künftige QS- und potenzielle Fehlerbehebungsmaßnahmen beeinflussen. Sie können auch eine Möglichkeit finden, Ihre Arbeit bei einem bestimmten Meilenstein oder am Ende des Sprints den Kollegen zu präsentieren, die nicht zur Qualitätssicherung gehören.
Schlussfolgerung
Der Testplan ist ein nützliches Werkzeug mit Vorteilen, die über den QS-Aufwand hinausgehen. Es formalisiert Softwaretests, öffnet sie für andere Stakeholder und hilft bei der Bewältigung potenzieller Herausforderungen innerhalb und außerhalb des QS-Teams. Große Vorbereitung liefert großartige Ergebnisse, und Software-Qualitätssicherung ist keine Ausnahme.
