Sowohl in meinem Scrum-Team als auch in der gesamten IT-Abteilung haben wir kein einziges angestelltes QA-Personal. Tatsächlich ist es vom oberen Management vorgeschrieben, dass wir keinen einstellen können (und ich glaube nicht, dass sich das wahrscheinlich ändern wird). Trotzdem besteht nach wie vor ein Anspruch auf qualitativ hochwertige und funktionierende Arbeit - noch bevor sie an die (internen) Benutzer zum Beta-Testen/UAT übergeben wird.
Bisher wurde dies dadurch gelöst, dass der PO auch als QA fungiert. Erwähnenswert ist jedoch die Tatsache, dass sie für jedes Projekt der Abteilung auch als PM und manchmal sogar als Sekretärin fungiert. Infolgedessen werden Stories oft erst gegen Ende eines Sprints als „erledigt“ betrachtet oder einen (oder mehrere) Sprints nach vorne verschoben, bevor sie die Zeit findet, sie zu prüfen. Offensichtlich können wir die Entwickler nicht einfach einen Monat herumsitzen lassen, damit sie aufholen kann.
So wie ich das sehe, sind die einzigen Lösungen, die mir eingefallen sind:
Ich mag keine dieser Optionen besonders; Gibt es einen besseren Weg, um unseren Prozess zu verbessern?
Wir haben in meinem Team mit dem gleichen Problem gekämpft, obwohl es im Team keinen Ersatz für eine qualitativ hochwertige Qualitätssicherung gibt, haben wir es geschafft, uns durch das Tragen mehrerer Hüte zurechtzufinden.
Das ist unser Arbeitsablauf:
Ein paar Punkte von Interesse, die dies effektiv machen.
Wir erweitern ständig unsere automatisierte Testsuite. Regressionen werden zu seltenen Bestien.
Die „QA“ ist auch der Peer-Reviewer und überprüft den Code, bevor er ihn testet.
Dies bedeutet, dass sie die Möglichkeit haben, den Code „white box“ zu testen. Da sie bereits ein gewisses Verständnis des Codes haben, ist es einfacher, Grenzfälle zu finden, die möglicherweise übersehen wurden, und allgemein seltsame Wege, um die neue Funktion zu brechen. Es bedeutet auch, dass Fehlerberichte häufig die Zeilennummer enthalten, in der sich der Fehler befindet, und einen Vorschlag, wie er behoben werden kann. (aber nie eine tatsächliche Lösung, wir wollen keinen Anreiz für Schlamperei schaffen.)
Drängen Sie aber ernsthaft auf eine Qualitätssicherung. Meiner Erfahrung nach kann nicht einmal der qualitätsbewussteste Entwickler mithalten, was eine großartige Qualitätssicherung leisten kann. Wir konnten damit klarkommen, aber nicht jeder Entwickler ist dafür geschaffen, den Kontext von „dass es funktioniert“ auf „wie kann ich es brechen“ zu ändern.
Es gibt bereits einige gute Antworten, wie die Testaufgaben durch das Team abgedeckt werden können. Ich hoffe, mit dieser Antwort etwas anderes hinzuzufügen:
Meiner Erfahrung nach ist die größte Fähigkeit, die ein QA-Ingenieur in das Team einbringt, nicht die Fähigkeit, Tests durchzuführen (wie andere Antworten behandelt haben, ist das einfach genug, um zu automatisieren oder zu delegieren). Vielmehr ist es die Perspektive, die sie aus einer Karriere mitbringen, in der sie nach Grenzfällen, Rissen im Plan usw. suchen. Wenn Sie niemanden in dieser Rolle einstellen können, empfehle ich, diese Fähigkeit bei Ihren Entwicklern oder Neueinstellungen zu suchen und zu fördern .
Ich würde auch empfehlen, sich anzusehen, wie Lean den Aufbau von Qualität empfiehlt. Bauen Sie Gewohnheiten auf, um häufige Problemquellen in Ihrem Code zu identifizieren und diese anzugehen. Der Aufbau qualitativ hochwertiger Entwicklungspraktiken ist besser als der Versuch, die Probleme jedes Mal auf dem Weg nach draußen zu erkennen.
Ich denke, Sie sollten eine Person mit QA-Hintergrund einstellen, aber nicht als jemanden, der die eigentlichen Tests durchführt, sondern als jemand, der alle anderen mit dem Testvirus infiziert . Wenn Sie keinen Tester einstellen können, stellen Sie einen Entwickler mit Testerfahrung ein oder finden Sie jemanden im Team, der sich ein wenig mehr auf das Testen spezialisieren möchte.
Ich bin fest davon überzeugt, dass ein guter Softwareentwickler auch darin besteht, ein guter Tester zu sein.
Das Testen sollte vorab und parallel zum Codieren erfolgen, nicht am Ende. Es macht also absolut Sinn, dass Leute aus dem Scrum-Team die eigentlichen Tests durchführen. Sowohl automatisiert als auch mit explorativen Testsitzungen. Lernen Sie die agilen Testquadranten kennen und finden Sie eine gute Balance zwischen den Testanstrengungen.
Empfohlene Lektüre:
Automatisierte UI-Tests
Fordern Sie die Entwickler auf, automatisierte Tests zu schreiben, die die Funktionalität der von ihnen entwickelten Funktionen beweisen. dh seleninum/TestUI/CodedUI etc
Dies erhöht die Belastung beim Schreiben von Spezifikationen und verringert die Belastung beim Testen
Testen Sie als Gruppe:
Leider haben wir keinen eigenen Tester in unserem Team, was bedeutet, dass wir auf die Testfähigkeiten aller Teammitglieder angewiesen sind. Das mag den Büchern zufolge richtig sein, aber meiner Erfahrung nach haben Entwickler nicht die gleiche Denkweise wie ein Tester. Wir versuchen, dies auszugleichen, indem wir explizite interne Testsitzungen organisieren, bei denen das gesamte Team ein fertiges Feature testet. Wir ermutigen uns gegenseitig, so viel wie möglich interne Testsitzungen zu planen. Diese internen Testsitzungen sind äußerst wertvoll.
Dann machen Sie eine Demo:
Ja; Bis Freitag haben wir normalerweise einige Funktionen bereit, um sie dem Product Owner zu zeigen. Daher muss ich mit ihm überprüfen, ob die neue Funktionalität, die wir während dieses Sprints implementieren, das tut, was erwartet wird. Wir schreiben ein kurzes Szenario, wie wir diese neue Funktionalität nutzen werden, und fügen eine Liste mit Fragen hinzu, um etwaige Unsicherheiten aus dem Weg zu räumen. Nachdem uns der Product Owner seine Antworten geschickt hat, können wir mit der Implementierung fortfahren.
und schließlich eine Kopie der Produktionsdaten in einer Testumgebung für die Generalprobe ausführen:
Am Dienstagmorgen stellt unser Technologiepartner unseren Code in der UAT-Umgebung bereit. Wenn UAT vom Produkteigentümer abgemeldet wird, wird der Code am Mittwoch in der Clones-Umgebung (einer zweiten Akzeptanzumgebung, die eine exakte Kopie der Live-Daten vom Produktionsserver enthält) bereitgestellt. In der Clones-Umgebung testen wir, um sicherzustellen, dass die Live-Daten nicht von unseren Änderungen betroffen sind, und um zu sehen, ob die hinzugefügte Funktionalität mit den tatsächlichen Daten das tut, was sie tun sollte.
Verweise
Ich unterstütze Ewans Ansatz: Selbsttestende Codes und automatisierte Tests sind der Weg, um dieses Problem zu lösen.
Selbsttest-Code – erfordert eine Überarbeitung des vorhandenen Codes, und das Zögern Ihres Teams wäre verständlich.
Automatisiertes Testen – am besten durch Einstellung eines anderen Programmierers – der dann Tests anstelle von Produkten programmiert – und das Management würde es nicht bemerken.
Oder verwenden Sie, wie Sie in Auswahl 2 vorschlagen, einfach einen Teil der Zeit der vorhandenen Programmierer, um automatisierte Tests zu schreiben.
Ein anderer Ansatz - abhängig von Ihren Produkten - wäre, ein Alpha-Programm zu starten, bei dem die Benutzer im Wesentlichen kostenlos Fehler testen und melden; keine Kosten für das Management und Sie lassen Ihr Produkt testen, während Sie es entwickeln.
Nathan Cooper