Wer sollte den Testplan schreiben?

Ich bin im internen Entwicklungsteam meines Unternehmens und wir entwickeln die Websites unseres Unternehmens gemäß den Anforderungen des Marketingteams. Bevor wir ihnen die Website für Abnahmetests zur Verfügung stellen, wurden wir gebeten, ihnen einen Testplan zu geben, dem sie folgen sollen.

Das Entwicklungsteam ist jedoch der Ansicht, dass die Anforderungen, da sie von den Anforderern stammen, die besten Kenntnisse darüber haben, was zu testen ist, worauf zu achten ist, wie sich die Dinge verhalten sollten usw., und daher ist kein Testplan erforderlich. Wir sind immer in einem Streit darüber, und Entwickler finden es Zeitverschwendung, Dinge aufzuschreiben wie: -

1. Klicken Sie auf die Schaltfläche A .
2. Key in XYZ in das Formularfeld ein und klicken B .
3. Sie sollten Verhalten C sehen .

was wir für jede angeforderte Anforderung / Funktion wiederholen müssen. Dies ist im Grunde eine Neuformulierung dessen, was bereits im Anforderungsdokument enthalten ist.

Wir streben einen agilen Ansatz für die Verwaltung unserer Projekte an, der auch am Ende jeder Iteration angefordert wird.

Abgesehen von Unit- und Integrationstests, wer sollte derjenige sein, der den Endbenutzer-Akzeptanztestplan erstellt? Sollten es die Reqestors oder die Entwickler sein?

Vielen Dank im Voraus.

Grüße
CK

Der Testplan sollte NICHT von Entwicklern geschrieben werden. Mit dem Testplan soll unter anderem überprüft werden, ob der Entwickler die Anforderung richtig interpretiert hat. Ein Entwickler kann nicht effektiv einen Testplan für den Code schreiben, den er schreiben wird. Testpläne sollten von den Personen erstellt werden, die die Qualitätssicherung durchführen, oder von den Geschäftsanalysten. Wenn Entwickler die Pläne schreiben müssen, weisen Sie niemals jemanden zu, der den Plan für den Teil des Programms schreibt, den er schreiben wird.

Beachten Sie, dass dies anders ist als das Entwerfen von Komponententests, die vom Entwickler geschrieben werden müssen, da er den von ihm geschriebenen Code testen sollte, um festzustellen, ob er das tut, was er erwartet. Testpläne sollen jedoch testen, ob die Anwendung so funktioniert, wie es erwartet wurde, und dies muss von jemandem durchgeführt werden, der nicht weiß, wie die Anwendung technisch entwickelt wurde, um effektiv zu sein.

Das QA-Team sollte den Testplan schreiben und ausführen.

Idealerweise sollte der Testplan parallel zur Funktionsspezifikation geschrieben werden - es ist erstaunlich, wie das Nachdenken über das Testen der Funktionalität den Geist konzentriert und die Spezifikation verbessert.

Eine Scrum-Antwort: Wenn Sie die 'Definition of Done' definieren möchten, werden Sie feststellen, dass ein Testplan schnell zu einem der Elemente wird. Wie sonst können Sie die zu beschreibende Geschichte beschreiben, wenn sie nicht getestet wurde?

Wer ist dann für die Erstellung des Testplans verantwortlich? Die Mannschaft

Wer ist das Team? Jede Person, die sich für die Realisierung des Produkts einsetzt, sollte Mitglied des Teams sein.

In Ihrem Fall können Sie also die Person, die die Testpläne schreiben kann, in Ihr „Entwicklungsteam“ aufnehmen (oder einstellen). Wenn Sie zu Agile wechseln, werden Sie feststellen, dass die Erstellung eines Testplans parallel zur Entwicklung erfolgt. Beide beginnen mit derselben Geschichte und werden durch die Kommunikation synchronisiert und gleichzeitig geliefert. Sie sollten Ihre Geschichte nicht für "erledigt" erklären, bevor Sie die Testfälle bestanden haben, die die Stakeholder als kritisch ansehen.

Ich finde, dass Funktionstestpläne von Funktions- / Geschäftsanalysten geschrieben werden sollten. Sie schreiben die Funktionsanalyse (selbst wenn Sie agil arbeiten, ich gehe davon aus, dass Sie eine Analyse haben), und sie sollten daher aufschreiben, welche Pfade in der Anwendung zu Testzwecken befolgt werden sollten.

Es hängt ganz davon ab, wie Sie arbeiten, aber meiner Meinung nach sollten Entwickler keine Funktionsdokumente darüber schreiben, wie die Anwendung getestet wird, welche Daten zum Testen verwendet werden sollen usw.

Hier ist eine Idee, die beide Gruppen glücklich machen und gut zu einem agilen Ansatz passen könnte :

Automatisieren Sie Ihre Benutzerakzeptanzprüfungen und senden Sie sie per Screencast.

http://pragprog.com/magazines/2009-12/automating-screencasts

Es scheint ein Teil des Problems zu sein, dass die Testpläne, die Sie schreiben, sich sehr wiederholen und rein bestätigend sind. Um ehrlich zu sein, würde ich das, was Sie schreiben, überhaupt nicht als Test bezeichnen - wenn es nur die Anforderungen bestätigt, überprüft es . Wenn Sie dies automatisieren und per Screencast übertragen, können Sie Ihren Kunden regelmäßig eine übersichtliche Demo zusammenstellen (Sie können sie sogar täglich über einen kurzen Zeitraum senden). Sie klicken eher auf eine Demo und sehen sie sich an, als einen Testplan zu öffnen und Arbeiten Sie es durch, damit Sie hoffentlich schnelleres Feedback erhalten (sehr wichtig, wenn Sie sich für einen agileren Ansatz entscheiden). Sie können Komponenten wiederverwenden, um die Arbeitsbelastung für Sie zu verringern.

Es bietet auch eine Möglichkeit, die Anforderungen tatsächlich auszuführen. Sind Sie auf die ausführbaren Spezifikationen von Gojko Adzic gestoßen? Schauen Sie hier: http://gojko.net/2010/08/04/lets-change-the-tune/ Wenn Sie dies als eine Möglichkeit betrachten, die Anforderungen in eine ausführbare Form zu bringen, um sie Ihren Kunden vorzuführen dann scheint es plötzlich viel weniger sinnlos.

Wenn ich jetzt meinen Testerhut aufsetze, muss ich darauf hinweisen, dass Sie / Ihre Stakeholder, wenn das Screencast-Ding startet, einige ordnungsgemäße Tests durchführen können - dh Randfälle und Tests, die die App tatsächlich herausfordern , anstatt nur Anforderungen zu bestätigen. Ich würde vorschlagen, dass Sie die Screencasts zusammen mit kurzen Fragen oder Vorschlägen für Bereiche bereitstellen, zu denen Sie mehr Feedback wünschen, zum Beispiel:

1) Hier ist unser neues Anmeldeformular - sehen Sie sich diesen Screencast an, um zu sehen, wie es funktioniert!

Was wir zu Feedback wünschen: Wir haben in diesem Formular viele zusätzliche Überprüfungen hinzugefügt, um sicherzustellen, dass Kunden nicht in der Lage sind, die falschen Daten einzugeben. Wir möchten, dass Sie sich die Fehlermeldungen ansehen, die Kunden erhalten, wenn sie diese erhalten Geben Sie das Falsche ein und sagen Sie uns, ob unsere Kunden sie leicht verständlich finden.
Wir möchten auch wissen, ob wir in einigen Fällen zu streng waren - wenn Sie besonders ungewöhnliche Kundendaten haben (vielleicht einen wirklich langen oder einen wirklich kurzen Namen oder jemanden mit ungewöhnlichen Zeichen im Namen). oder etwas anderes, an das wir nicht gedacht haben, oder vielleicht hat ihre Adresse keinen Straßennamen oder so etwas Seltsames?) Dann könnten Sie vielleicht ein paar Minuten damit verbringen, diese auszuprobieren?

Das heißt, Sie präsentieren einen netten Screencast und bitten dann um Feedback, rahmen es ein, ohne zu spezifisch zu sein, und bringen sie dazu, über mögliche Probleme nachzudenken, anstatt nur zu bestätigen. Bringen Sie sie zum Nachdenken , anstatt nur blind durch einen Testplan zu klicken. Sie schreiben im Grunde eine Sondierungs-Testcharta für sie. (Wenn Sie sich die Agile Testing Quadrants ansehen , sind dies Tests in Quadrant 3).

Nehmen Sie als Beispiel die Renovierung Ihres Hauses. Würden Sie eine von Ihrem Auftragnehmer erstellte Checkliste akzeptieren, in der Sie aufgefordert werden, abzuhaken, was er für Sie getan hat? Oder würden Sie eine eigene Checkliste erstellen und prüfen, ob der Auftragnehmer das getan hat, was SIE angegeben haben?

Die Antwort ist klar: Der Antragsteller sollte prüfen, ob das, was er angefordert hat, den Spezifikationen entspricht. Er / sie sollte seine / ihre eigene Checkliste herausbringen und die App testen. gegen diese Liste.

Der Entwickler sollte jedoch eine eigene Checkliste haben und sicherstellen, dass ordnungsgemäße interne Tests durchgeführt und Fehler behoben werden, bevor die App verarbeitet wird. vorbei für UAT. Im Idealfall sollte der Entwickler die meisten dieser Tests in Form von Testskripten automatisieren. Erinnerst du dich an TDD? Im Idealfall sollten Testskripte (in diesem Fall Unit-Testfälle) zum Testen von Anwendungskomponenten geschrieben werden. Anschließend sollte eine Testsuite geschrieben werden, um diese Unit-Testfälle zu kombinieren und integrierte und anschließend Regressionstests durchzuführen.

Der Endbenutzer-Akzeptanztestplan wird normalerweise von den Kunden oder einem Geschäftspartner des Unternehmens erstellt, der den Kunden vertritt. Es soll die vom Kunden gewünschten Funktionen darstellen und ergänzt die Integrationstests von QA. Weder die Qualitätssicherung noch die Entwicklung können Benutzerakzeptanztests effektiv planen, da eines der Hauptziele der Benutzerakzeptanztests darin besteht, sicherzustellen, dass die vom Kunden gewünschten Qualitätssicherungs- und Entwicklungstests tatsächlich korrekt sind.