Welche Rolle würde ein Tester / eine Person zur Qualitätssicherung spielen, wenn ein BDD-Projekt mit einer 100% igen Abdeckung von User Stories mit automatisierten Abnahmetests durchgeführt wird?
Ich nehme an, ich bilde mir ein, dass Entwickler die Abnahmetests in Zusammenarbeit mit dem Produktbesitzer schreiben würden. Lassen Sie mich wissen, ob dies eine dumme Annahme ist.
Antworten:
Vielleicht bin ich zu altmodisch, aber selbst die modernsten Entwicklungs- oder Prozesstechniken können ein anderes Augenpaar, frische Augen, nicht ersetzen, bevor Sie ein Produkt für Ihren Kunden freigeben.
Selbst wenn Ihr Produkt nur eine API für einen anderen Entwickler ist, können Sie mithilfe der Qualitätssicherung als API-Benutzer denken und Test- / Verwendungsszenarien bereitstellen, die Sie oder Ihr Kunde nicht im Voraus gedacht haben.
Wenn Ihr Produkt stark auf der Benutzeroberfläche basiert, möchten Sie auf jeden Fall, dass eine andere Person (nicht Sie oder jemand aus Ihrem Team) das Endergebnis sieht, bevor Sie es an den Kunden sendet.
Wie jedes andere Schlagwort in unserer Branche ist BDD - auch bei 100% iger Abdeckung - keine Wunderwaffe .
100% Deckung ist nicht dasselbe wie 100% getestet.
Ich würde eine QS-Person in einem ATDD-Projekt als jemanden sehen, der beim Schreiben der Tests und bei der Durchführung der anderen noch vorhandenen Testarten hilft. Dh UI-Tests, Zerstörungstests und Last- / Stresstests.
Aber ich habe noch nie ein ATDD-Projekt ausgearbeitet.
Die Aufgabe von QA ist es, die Anwendung zu brechen, die Aufgabe von Devs ist es, sie nicht zu brechen. Deshalb schreiben sie ihre Tests aus einer anderen Perspektive. Zum Beispiel schreibt der Entwickler Tests, um festzustellen, ob das erwartete Verhalten vorliegt, und schreibt QA-Tests, um festzustellen, was passiert, wenn der Benutzer etwas tut, was der Entwickler niemals in Betracht ziehen würde. Darüber hinaus interpretieren Entwickler die Anforderungen häufig falsch und die QS-Tests erkennen, wenn sich ihre Interpretation von der des Entwicklers unterscheidet, und setzen sich dann mit den Projektbeteiligten zusammen, um die richtige Interpretation zu ermitteln. Tests, die von Entwicklern geschrieben wurden, die den Code geschrieben haben, haben oft große blinde Flecken, weil der Entwickler einen großen blinden Fleck hatte. Zum Beispiel könnte es testen, was 97% der Zeit passiert, aber nicht die Randfälle.
Bei einem früheren Arbeitgeber bestand die Rolle der Qualitätssicherung darin, das Produkt nicht zu testen, sondern sicherzustellen, dass die Entwickler im Wesentlichen das taten, was sie im Hinblick auf die zuvor definierten Abnahmetests, die von der Qualitätssicherung festgelegt wurden, angekündigt hatten.
Der Product Owner hatte dagegen absolut nichts mit dem Testen zu tun. Umgang mit Tests auf jeder Ebene IMHO ist nicht die Rolle des Produktbesitzers.
Irgendwann muss man Vertrauen in seine Mitarbeiter haben. Checks and Balances sind gut, aber Sie sollten keine Lösung innerhalb des Entwicklungszyklus erzwingen müssen, die in Wirklichkeit nur einen kleinen Teil der Arbeitsethik der Mitarbeiter anspricht.
In einer perfekten Welt sehe ich die Zusammenarbeit mit dem Entwickler und der Qualitätssicherung darin, die Abnahmetests gemeinsam zu verfassen. Die Qualitätssicherung sollte einen anderen Aspekt auf den Tisch bringen als das Entwicklungsteam. Die Qualitätssicherung sollte bereits in den Kinderschuhen des Produkts Hand in Hand gehen und während des gesamten Zyklus beschäftigt bleiben. Andererseits sollte der Produktbesitzer die Qualitätssicherung beauftragen, um zu verstehen, wie der aktuelle Zustand des Produkts, die Risiken usw. sind, und sich ganzheitlich auf das Produkt konzentrieren. nicht die spezifischen Nuancen, aus denen das Produkt besteht.
Aus meiner Erfahrung: Wir haben Unit-Test verwendet, um mehr als 90% des Codes abzudecken. Es gab auch Integrationstests und stündliche Builds. jHaben Sie Tests für BDD.
QA-Rolle: - Übernehmen von User Stories zum Testen - Schreiben von Code hinter Schritten - Erkundungstests mit dem RestClient-Plug-in für IDEA (daher haben wir einige schwerwiegende Fehler gefunden)
Ein Teil von BDD wendet den 3 Amigos-Ansatz an, bei dem die Stakeholder zusammenarbeiten, um die Akzeptanzkriterien zu erstellen. QA / Dev kann den Schrittcode schreiben, damit Szenarien als Abnahmetests ausgeführt werden. Wo ist der Wert von QA, um dieselben Abnahmetests manuell auszuführen, die ein BDD-Tool automatisch ausführt? Der Mehrwert der Qualitätssicherung besteht darin, diese Abnahmetests zu validieren und manuelle Sondierungsprüfungen außerhalb der schriftlichen Abnahmetests durchzuführen. Die Vervielfältigung führt normalerweise zum gleichen Ergebnis.
Entwickler schreiben Anforderungen und Spezifikationen nicht um, QA schreibt App-Code nicht um ... Es ist möglich, dass QA nicht dieselben Skript-Tests durchführen muss, die Entwickler als Abnahmetests ausführen. Es ist Zeit für Entwickler, einen Teil des QA-Hutes zu tragen!