Wie gehen Sie als Softwaretester/QA damit um, wenn Stakeholder (z. B. Projektmanager und Entwickler) unterschiedliche Vorstellungen von Projektanforderungen haben? Mir ist bekannt, dass diese Kommunikationsstörung den Release- und QA-Zeitplan für das Projekt beeinflusst.
Kann jemand vorschlagen, was der nächste Schritt des Testers/der QA hier wäre?
Schätzen Sie Ihren freundlichen Vorschlag. Danke!
Das ist eine großartige Frage. Vor einigen Jahren habe ich die in einem Team gemeldeten Fehler analysiert und festgestellt, dass mehr als die Hälfte davon auf ein Missverständnis der Anforderungen zurückzuführen sind.
Einige Dinge, die helfen können, dieses Problem zu reduzieren, sind:
Wenn es zwei Beteiligte gibt, die die Anforderung unterschiedlich verstehen, dann können es mehr sein. Wie interpretieren Sie die Anforderung aus Sicht eines Testers? Oder wie sieht es mit dem Kunden aus? Oder sogar die Endverbraucher des Produkts? Wenn die Anforderung bis zu dem Punkt zweideutig ist, an dem zwei Personen, die (zumindest theoretisch) eng zusammenarbeiten, um das Produkt zu liefern, unterschiedliche Interpretationen haben, würde ich es für wahrscheinlich halten, dass es andere Interpretationen gibt.
Ich würde erwarten, dass das QA-Team darauf achtet, indem es an jedem Schritt des Prozesses beteiligt ist. Qualitätssicherung als Tests nach der Entwicklung zu betrachten, reicht nicht aus, um ein Qualitätsprodukt zu liefern. Die Anforderungen als weiteres Augenpaar zu betrachten, um Unklarheiten zu finden, oder Fragen dazu zu stellen, wie die Anforderung früh im Entwicklungsprozess getestet werden kann, ist wichtig, um das Team auf langfristigen Erfolg vorzubereiten.
Wenn Sie bereits an dem Punkt angelangt sind, an dem die Arbeit zur Integration und zum Testen bereit ist, es jedoch Meinungsverschiedenheiten über die Anforderung gibt, besteht der erste Schritt darin, herauszufinden, was die Anforderung wirklich ist. Jemand muss die endgültige Entscheidung treffen. Eine Möglichkeit wäre, dass sich jemand an den Kunden oder einen Endverbraucher wendet und sich abklären lässt, was tatsächlich benötigt wird. In einigen Fällen kann der Projektmanager oder Product Owner befugt sein, die Entscheidung zu treffen und dem Kunden die Stimme zu geben, in diesem Fall ist sein Wort die wahre Voraussetzung. Sobald Sie die wahre Anforderung haben, werden die Tests erstellt, um das System innerhalb der Grenzen der Anforderung zu testen und zu zeigen, dass es die Anforderung erfüllt.
Abhängig davon, was die wahre Anforderung ist und wie weit das Design und die Implementierung von dieser Anforderung entfernt sind, werden die folgenden Schritte bestimmt.
Willkommen bei PMSE!
Es ist ganz normal, dass Menschen eine Anforderung unterschiedlich verstehen, aber interessant ist, dass Sie die Person, deren Meinung am wichtigsten ist, nicht erwähnt haben: den Kunden. Der Weg, mit Ihrer Situation umzugehen, besteht darin, eng und häufig mit Ihrem Kunden (Sponsor / Produkteigentümer / Endbenutzer) zusammenzuarbeiten, regelmäßig und oft Ergebnisse zu liefern, das Feedback des Kunden einzuholen und darauf zu reagieren.
QA sollte immer vom Beginn einer Arbeit bis zu ihrem Ende laufen. Es ist kontraproduktiv, die Qualitätssicherung in einen begrenzten Zeitrahmen zu packen. Entscheidend ist, wie schnell das Team als Ganzes (Analyse, Entwicklung, QA und Kunde) jedes Inkrement des Produkts liefern kann.
Ich werde diese Frage allgemeiner beantworten, da die Konfliktlösung für Stakeholder-Themen keine unterschiedlichen Methoden erfordern sollte, je nachdem, wer die Stakeholder sind oder was die Aufgaben sind. Unterschiedliche Meinungen, Interpretationen und Wahrnehmungen sind bei jedem komplexen Projekt selbstverständlich, daher sollte das Team über einen Prozess verfügen, durch den diese Probleme eskaliert, untersucht und analysiert werden und bei dem sich das Team auf eine Lösung einigt. Wenn zwei oder mehr Beteiligte ein Problem nicht auf einer niedrigeren, informelleren Ebene lösen können, dann würden ein oder mehrere Beteiligte es durch diesen Prozess formell eskalieren, damit das breitere Team es entsprechend behandeln kann.
Dieser Prozess sollte es beiden gegnerischen Stakeholdern ermöglichen, ihren Standpunkt zu äußern, die Vorzüge zu argumentieren und ihre Lösung anzubieten. Das Eskalationsteam würde sich beide Argumente anhören und dann eine Lösung anhand der vorgegebenen Methode auswählen, unabhängig davon, ob es sich um eine Person mit der entsprechenden Autorität, Mehrheitsentscheidung oder einer anderen Form des Konsenses handelt.
In Bezug auf QA bereiten Sie Ihre Testfälle vor, wenn eine Anforderung eingefroren ist, und präsentieren Sie sie dem Team. Jeder wird sehen, was er bauen und/oder erhalten wird, und Fragen und Änderungswünsche stellen, bevor Sie mit dem Testen beginnen.
Jeder mit einem scheinbar anderen Verständnis von Projektanforderungen muss sowohl an den ursprünglichen, spezifischen Wortlaut als auch an die übliche Interpretation in branchenüblicher Gepflogenheit und Praxis erinnert werden.
Wenn es Leute gibt, die das nicht akzeptieren können oder wollen, müssen sie entweder an einer Art Gruppendenken-Seminar teilnehmen, um ihre Meinung richtig zu machen, oder sie haben Recht und die Projektbeschreibung muss neu geschrieben werden.
Nick012000