Codierung und Test im selben Sprint

Wie wird das Testen im selben Sprint wie das Codieren gehandhabt, wenn die gesamte oder die meisten Codierungen erst am Ende des Sprints durchgeführt werden? (Ich beziehe mich auf die "Suppe-zu-Nuss" -Entwicklung und das Testen eines einzelnen PBI innerhalb eines Sprints.)

Die meisten Antworten, die ich online gesehen habe, beziehen sich auf die Automatisierung der Qualitätssicherung, aber selbst das ist nicht möglich, da Sie im Allgemeinen eine funktionierende Benutzeroberfläche benötigen, um automatisierte Tests aufzuzeichnen oder daraus zu erstellen. Ich habe nur Storyboards, die sich ständig weiterentwickeln, wenn ich Features entwickle und neue Anforderungen entdecke.

In meinem Fall entwickle ich eine neue Desktop-Anwendung. Desktop-Apps eignen sich im Allgemeinen nicht für automatisierte Tests. Ich habe einige automatisierte Komponententests, aber es handelt sich nicht um manuelle Funktions- / Integrationstests, die ein QS-Fachmann durchführen würde.

Im Moment ist mein Sprint also morgen zu Ende, ich muss noch programmieren und meine QA-Mitarbeiter haben noch nichts zu testen und keine Ahnung, wie ich alles testen kann, was ich ihnen geben würde, ohne dass ich ihre Hände halte.

Ich bin mir sicher, dass ich nicht die erste Person bin, die dieses Dilemma hat.

In der Vergangenheit habe ich eine Pipeline erstellt: Im aktuellen Sprint testet das Testteam die Funktionen, die während des vorherigen Sprints implementiert wurden. In meinem jetzigen Job bezeichnet der Premier diesen Ansatz als "Wasserfall" und als solchen inakzeptabel.

Wenn Sie keine User Story (US) testen und sicherstellen, dass die Akzeptanzkriterien erfüllt sind, wird diese Story nicht ausgeführt. Wenn dies nicht der Fall ist, gehen die USA natürlich zum nächsten Sprint. Und wenn sich alle US-Amerikaner in diesem Zustand befinden, wurde der Sprint beendet, ohne dass dem Projekt ein Mehrwert hinzugefügt wurde. Aus Sicht des Kunden kann ich dies nicht von dem gesamten Entwicklungsteam unterscheiden, das in den Urlaub fährt.

Eines der Lean-Prinzipien (Agile endet nicht mit Scrum) lautet "Qualität ist eingebaut". Etwas wird nur getan, wenn es die von Ihnen definierten Qualitätskriterien erfüllt. Dies ist für einen wirklich agilen Prozess von entscheidender Bedeutung. Das Beenden des Frühlings mit dem Wert Null oder das separate Testen von der Entwicklung sind Symptome eines großen Problems.

Es gibt viele Dinge, die Sie tun können:

• Automatisierung ist der Schlüssel zum Erfolg. Zumindest auf Unit-Test-Ebene und einige andere Praktiken wie CI sind ebenfalls wichtig. Dies ist nicht genug, aber wenn diese Tests gut durchgeführt werden, führen sie zu wenigen oder gar keinen Fehlern, die beim manuellen Testen entdeckt wurden (normalerweise kleinere UI-Dinge). Wenn Sie engagierte QS-Mitarbeiter haben, können diese die Abnahmetests automatisieren. Einige dieser Automatisierungen können bereits vor dem Ende eines Sprints beginnen.

• Sehen Sie sich die Größe Ihrer User Stories an. Wenn Sie einen US-Amerikaner haben, der an den ersten beiden Tagen des Sprints am dritten Tag fertig ist, kann eine QS-Person ihn testen. Meiner Meinung nach ist es eines der wichtigsten Dinge für den Erfolg einer agilen Entwicklung, kleine (SMART) Benutzerhistorien zu haben, und viele Leute scheinen dies nicht zu bemerken.

• Die Zusammenarbeit zwischen Testern und Entwicklern ist ein weiterer Schlüssel zum Erfolg. In meinem vorherigen Projekt hat eine QA-Person, die von einem Entwickler in den USA fertig gestellt wurde, einen "Paartest" mit dem Entwickler durchgeführt (dies kann manuell sein, über das Starten einiger automatisierter oder besser beider), dies funktioniert ziemlich gut.

Das wesentliche Problem ist, dass Sie Programmierer haben, die codieren, aber nicht testen, und Tester, die testen, aber nicht codieren.

Lösen Sie dieses Problem und Sie werden dieses Problem nicht haben und ein wohl effizienteres Team.

Eine Möglichkeit, die in der Vergangenheit für mich funktioniert hat, bestand darin, Programmierer und Tester vorzuschlagen, die Geschichten mit der expliziten Aufgabe zu kombinieren, eine vollständig getestete Geschichte zu liefern. Zusammen damit habe ich alle Formen des "dev complete" -Denkens gelöscht: keine "dev complete" -Spalten auf dem Scrum / Kanban / Trello-Board, keine "dev done" -Einstellung von Programmierern.

Was passiert ist, war:

• Paare waren für die Übermittlung von Geschichten verantwortlich und würden beide scheitern, wenn eine Geschichte nicht fertiggestellt wäre. Sie wurden als verantwortliche Fachkräfte für die Bereitstellung von Software behandelt, und in den meisten Fällen auch.

• Es wurden viel weniger Tests durchgeführt, da die Tester Unit- und Integrationstests ausgesetzt waren, sodass sie denselben Test nicht manuell wiederholten.

• Einige Tests wurden automatisiert, als die Entwickler besser verstanden, was die Tester benötigten.

• Einige Leute waren verärgert.

• Geschichten wurden im Durchschnitt schneller geliefert, weil der Code-Commit-Pull-Test-Zyklus fast augenblicklich wurde

Natürlich ist dies nur meine anekdotische Erfahrung, aber vielleicht möchten Sie es selbst versuchen, wenn Sie können.

In Ihrem Fall erscheint mir die Botschaft angesichts Ihrer Bemerkung, dass Tester und Entwickler in Ihrem Unternehmen maßgeblich voneinander getrennt sind, klar. Es gibt eine offensichtliche Barriere für Kommunikation und Zusammenarbeit, die durch Unternehmensregeln festgelegt wird.

Dies ist ein Kommunikationsproblem , kein agiles Problem. Die Einführung einer agilen Methodik macht dies nur deutlich. Silo'd-Teams sind ein bekanntes Anti-Pattern für das Management. Deshalb sollten Sie die mangelnde Anpassungsfähigkeit von Agile in diesem Fall in Kauf nehmen !

Die eigentliche Rolle Ihrer Qualitätssicherung liegt in der Nähe von Abnahmetests. Ich würde mir vorstellen, dass dies von einem separaten Team durchgeführt wird, das eher als Produktbesitzer fungiert als als Teil des Entwicklungsteams.

Beispiel: Während eines Sprints müssen Sie eine Funktion hinzufügen, mit der Suchergebnisse nach verschiedenen Kriterien gefiltert werden können. Sie haben Ihren Suchmechanismus bereits implementiert, aber die Ergebnisse sind alphabetisch sortiert.

• Während des Sprints:

  1. Das Team entwirft das Design der neuen Funktion und die Auswirkungen auf die tatsächliche Codebasis.

  2. Entwickler schreiben Unit-Tests, die sicherstellen, dass die Bestellung wie erwartet funktioniert, und schreiben gleichzeitig den eigentlichen Code.

  3. Die neue Funktion wurde sorgfältig getestet, um sicherzustellen, dass nichts kaputt geht (Regressionstests) und dass sie wie erwartet funktioniert (Komponententests).

  4. Wenn möglich und angemessen , was in den meisten Projekten nicht der Fall ist , kann ein Product Owner (und damit Ihr QA-Team) die neue Funktion ständig evaluieren, um zu verhindern, dass das Team in die falsche Richtung geht. Dies erfordert eine kontinuierliche Integration in Dutzende von Builds pro Tag.

• Nach dem Sprint wertet der Product Owner das neue Feature aus, um sicherzustellen, dass es den Anforderungen des Kunden entspricht. Ihr QA-Team ist tatsächlich hier, nachdem der Sprint beendet wurde.

Ich glaube, Ihre aktuellen Probleme sind die folgenden:

• Geltungsbereich . Ein Sprint betrifft Ihr Team und nur Ihr Team, nicht Ihre eigentliche Qualitätssicherung, die eher als Product Owner fungiert.

• Testen . Die Tatsache, dass Sie ein QA-Team haben, bedeutet nicht, dass Sie nur Code schreiben müssen. Die Aufgabe Ihres Teams ist es, eine Funktion bereitzustellen, die wie erwartet funktioniert, und keinen Code für die anderen zum Testen herauszugeben. Wenn Sie sich darauf verlassen, dass das QA-Team die Tests für Sie durchführt, erhöhen sich die Gesamtkosten, da Fehler ein bis zwei Wochen später behoben werden, anstatt sie fast sofort zu beheben.

Wenn die gesamte oder die meisten Codierungen erst am Ende des Sprints durchgeführt werden?

Warum ist es nicht früher fertig? Diese wichtige Einschränkung ist die Ursache Ihrer Probleme, und ich habe gesehen, dass zwei Ansätze erfolgreich sind. Einer passt gut in den agilen Ansatz (aber nicht in andere gängige Praktiken) und der andere ist ein bisschen agil (aber häufiger).

Das erste ist, dass Sie erst am Ende des Sprints codieren. Tatsächlich ist das Schreiben von Code ein relativ kleiner Teil der Entwicklung. Wenn Sie nach etwa der Hälfte des Sprints fertig sind, bleibt genügend Zeit für die Qualitätssicherung, um ihre Arbeit zu erledigen. Außerdem bleibt Ihnen viel Zeit, um Dokumentationen zu schreiben, technische Schulden zu beseitigen, Rückstände zu entwerfen ... all die anderen Dinge, die Sie für ein Qualitätsprodukt tun müssen. Der Nachteil, den ich gesehen habe, ist, dass es fast unmöglich ist, die Funktionalität und die Komponententests so schnell durchzuführen. Persönlich denke ich, dass es völlig in Ordnung ist, Komponententests durchzuführen, nachdem die Qualitätssicherung begonnen hat, einen Blick auf die Funktionalität zu werfen, aber die Befürworter von TDD (und andere) werden dem nicht zustimmen.

Die zweite Möglichkeit besteht darin, dass die Qualitätssicherung einen Sprint hinter den Entwicklungsmitarbeitern durchführt, wie es Ihre PM hasst. Ich neige auch dazu, dies nicht zu mögen. Es beseitigt das Konzept des "freisetzbaren Produkts" am Ende des Sprints, auch wenn Sie einen Eskalationsprozess für Ihre Veröffentlichungen haben. Schlimmer noch, Entwickler werden sich auf "neue" Dinge konzentrieren, wenn QA mit Fragen oder Fehlern aus dem Testen zu ihnen kommt. Es ist auch unwahrscheinlicher, dass Entwickler Fehler in dieser Anordnung beheben. Aber ich habe gesehen, dass es pünktlich Qualitätssoftware produziert.

Der Scrum-Leitfaden verlangt, dass Teams funktionsübergreifend sind. Alle Teammitglieder gelten unabhängig von ihrer Spezialisierung als Entwickler. Silo-Benutzer (Programmierer, Tester, QA, UX usw.) sind in Scrum nicht hilfreich. Die Teammitglieder helfen sich gegenseitig, wo immer sie können. Es gibt kein Konzept für die Weitergabe des Elements an qa.

In Ihrer Situation scheint es, als hätten Sie ein Schätzproblem. Bei der Schätzung von Product Backlog-Elementen müssen Sie alle Aktivitäten berücksichtigen , z. B .: Codierung, Testen, Peer Review, Bereitstellung, Integration - unabhängig von Ihrer Definition der erledigten Anforderungen.

Als grobe Faustregel sollten Sie damit rechnen, zwischen 5 und 15 Artikelrückstände in einen Sprint zu bringen. Auf diese Weise erhalten Sie eine Vorstellung davon, wie groß die einzelnen Product Backlog-Elemente sein sollten. Es gibt Ihnen auch eine hervorragende Chance, die Arbeit im Sprint zu erledigen.

Schließlich besteht die Aufgabe des Teams darin, ein Produktrückstandselement auf "erledigt" und dann auf das nächste Element zu verschieben. Manchmal bedeutet dies, dass die Leute sich gegenseitig auf die Zehen treten, und es ist daher sinnvoll, mehr als einen Produktstau gleichzeitig aufzubauen. Ihre Richtlinie sollte jedoch darin bestehen, Ihre in Bearbeitung befindlichen Arbeiten (WIP) zu reduzieren und Produktrückstände zu erledigen.

Testen und Codieren gehen Hand in Hand. Sie können es Modul für Modul planen. Sobald das Modul fertig ist, können Sie es Testern zur Verfügung stellen. Dieses gesamte Szenario hängt auch von der Testphase ab, an der Sie arbeiten. Spiral-SDLC-Modell sieht gut aus. Das gleichzeitige Testen und Codieren ist dabei bequem. Ein anderer Ansatz könnte das V-Modell sein .

Meine Antwort, die auf den ersten Blick wahrscheinlich recht seltsam ist, lautet: Sie haben keine Zeit zum Testen, da Sie der Meinung sind, dass die Nebeneffekte von Code getestet werden müssen . Und mit Nebeneffekt meine ich den Informatikbegriff :

Eine Funktion (...) hat einen Nebeneffekt, wenn sie nicht nur einen Wert zurückgibt, sondern auch (...) eine beobachtbare Wechselwirkung mit (...) der Außenwelt hat.

Ich habe das Zitat vorgebracht, um den Teil "Interaktion mit der Außenwelt" hervorzuheben: Sie möchten, dass das Testen auf der Benutzeroberfläche so erfolgt, wie es auf dem Bildschirm gedruckt wird ("[um mit dem Testen zu beginnen] ist nicht wirklich möglich, da Sie im Allgemeinen eine Funktion benötigen Benutzeroberfläche zum Aufzeichnen oder Erstellen automatisierter Tests von ").

Andere Antworten haben Sie angewiesen, diese "Abnahmeprüfung" zu automatisieren, damit dies schnell geschehen kann. Dies ist richtig, behebt aber Ihr ursprüngliches Problem nicht vollständig: Was ist, wenn nicht genügend Zeit vorhanden ist, um diese Abnahmetests zu schreiben?

Sie müssen Ihre Sicht auf das Testen aufgeben, wenn der Code mit der Außenwelt interagiert hat, dh etwas ausgedruckt hat und Eingaben erwartet. Das Problem mit den Nebenwirkungen ist, dass sie praktisch nicht testbar sind. Dies wurde mir klar, als ich ein Interview mit Guido van Rossum las, in dem er sagte, dass eine Aussage, die den Computer ausschaltet, nur durch Ausführung bewiesen werden kann, dass sie funktioniert.

Die Lösung für diese "Untestabilität" besteht darin, zu verstehen, dass Sie, wenn Sie einmal bewiesen haben, dass die Anweisung funktioniert, sie überall verwenden und sich darauf verlassen können, dass sie ihre Arbeit erledigt. Isoliere es in eine Funktion und teste alles andere .

Wenn Sie dieses Beispiel näher an Ihre Frage bringen, handelt es sich bei der Funktion jetzt wahrscheinlich um eine ganze Bibliothek oder ein ganzes Framework. Statt den Computer herunterzufahren, wird etwas gedruckt: eine Benutzeroberfläche. Halten Sie die Anrufe so stumm und stabil wie möglich , denn sobald Sie diesen Teil Ihrer Anwendung eingegeben haben, können Sie nur noch teure Abnahmetests durchführen, dh eine Art externe Beobachtung.

Die Benutzeroberfläche als "fremdes Territorium" zu betrachten, ist eigentlich eine korrekte Sichtweise, da Sie die Logik einer Bibliothek, die nicht von Ihnen bereitgestellt wird, nicht testen müssen, und es ist vielleicht überraschenderweise eine realistische Sichtweise: Wirklich? Erwarten Sie, dass Sie diesen Aufruf jemals testen, z MyWidget.draw().

Dies soll nicht heißen, dass Abnahmetests nicht wichtig sind oder dass sie übersprungen werden können. Es ist da, um zu bleiben, und die Automatisierung hat, wie andere Antworten vermuten lassen, enorme Vorteile. Wenn Sie jedoch Zeit zum Testen und Codieren im selben Sprint finden möchten, versuchen Sie, den Code so nebenwirkungsfrei wie möglich zu halten.