Was ist die richtige Teststrategie in Agile Scrum / Kanban-Teams?

Das Problem ist:

Das Team, in dem ich arbeite, hat ein Verhältnis von 10 Entwicklern zu 2 Testern, was bedeutet, dass wir Code schneller ausgeben als "Test".

Welcher Ansatz sollte laut agilen Experten der richtige Ansatz sein, um Aktivitäten in solchen Szenarien zu verfolgen?

Ich befürchte, dass bald der Tag kommen wird, an dem es eine Menge Dinge gibt, die in früheren Sprints als "Fertig" bezeichnet wurden (ohne dass Tests durchgeführt wurden), aber wenn es tatsächlich um Tests geht, könnte es einige potenzielle Fehler geben.

Wie kann ich die Bemühungen nahtlos verfolgen? Sollte das Testen Teil von "Done Definition" sein? Was sind die Fallstricke, wenn dies nicht der Fall ist?

Für mich ist es eine Art "Wasserfall", da Sie Geschichten "Fertig" nennen, bevor sie tatsächlich auf Funktion getestet werden.

Ja, das Testen sollte unbedingt Teil der Definition von "Fertig" sein. Ohne Frage.

Aus rein agiler Sicht ist es für jeden im Team der richtige Ansatz, zum Schreiben von Tests beizutragen. Der Tester ist derjenige, der die Bemühungen koordiniert, aber es liegt in der Verantwortung des gesamten Teams, sicherzustellen, dass die Software ordnungsgemäß getestet wird.

Erstens ist ein Verhältnis von 10: 2 schlecht. Erfahrungsgemäß funktioniert ein Verhältnis von 3: 1 oder 4: 1 Entwicklern zu Testern gut. Sie werden daher wahrscheinlich mindestens einen weiteren Tester benötigen, da sonst der Teststau wächst und entweder nie gelöscht wird oder Sie irgendwo Abstriche machen.

Wenn Sie Aufgaben im nächsten Sprint testen, implementieren Sie Mini-Wasserfall oder "Scrumfall", während Sie das Testen von der Entwicklung trennen. Sie haben Recht damit, dass Tests unbedingt Teil der erledigten Definition sein sollten. Wenn eine Aufgabe nicht getestet wurde, wie kann sie als "erledigt" deklariert werden?

Der richtige Ansatz wäre daher:

1. Fügen Sie dem Team nach Möglichkeit einen Tester hinzu, andernfalls lassen Sie die Entwickler einige Tests durchführen (obwohl sie wahrscheinlich nicht so gute Arbeit leisten wie ein professioneller Tester).
2. Ändern Sie Ihr Scrum / Kanban-Board so, dass es die Spalten "Testbereit" und "In Test" enthält, und stimmen Sie dem Team zu, dass ein Teil des Workflows darin bestehen muss, dass alle Aufgaben diese Spuren durchlaufen.
3. Aufgaben gelangen nur dann in die Spalte "Fertig", wenn sie durch Tests akzeptiert wurden.

Dies ist ziemlich häufig, wenn nicht typisch. Um einige Fragen zu beantworten:

• Was sollte der richtige Ansatz sein, um Aktivitäten in solchen Szenarien zu verfolgen?
• Werden Funktionen ohne Qualitätssicherung, aber mit Fehlern ausgeführt?
• Wie kann ich die Bemühungen nahtlos verfolgen?
• Sollte das Testen Teil von "Done Definition" sein?
• Was sind die Fallstricke, wenn dies nicht der Fall ist?

Ich würde einen Gesamtansatz verfolgen, der:

• ermöglicht es den Testern, Mehrwert zu schaffen
• gibt ihnen Autorität
• maximiert ihren Wert
• ermutigt QS-Leute, Entwickler auszubilden

und um das zu tun (und Ihre Fragen zu beantworten) würde ich:

• Stellen Sie sicher, dass sie Fehler in einem benutzerfreundlichen Fehlerverfolgungssystem eingeben können, das auch Funktionen wie Jira, Trello, Pivotal Tracker usw. enthält.

• Stellen Sie sicher, dass sie darin geschult sind, gute Fehlerberichte zu erstellen, die Folgendes beschreiben:

  • Schritte zum Reproduzieren
  • Anfangs- / Einrichtungswerte
  • eingegebene Werte
  • Screenshots, falls zutreffend
  • Serverprotokolle, falls zutreffend
• Stellen Sie sicher, dass Fehler zugewiesen, bearbeitet und abgeschlossen werden.
• schulen Sie sie in Best Practices und senden Sie sie an Konferenzen.
• Trainieren Sie sie in der Programmierung und Verwendung eines Test-Frameworks.
• Ermöglichen Sie ihnen, Programmierern gute Ansätze und Denkweisen zum Testen beizubringen.

Ja, einige Funktionen können auch ohne Qualitätssicherung, aber mit Fehlern ausgeführt werden. Ich finde oft, dass QS ein zweiter Satz Augen ist. Manchmal kann diese Rolle von einem anderen Entwickler besetzt werden. Persönlich finde ich, dass dies einige Fehler findet, aber nicht alle, die eine andere QS-Denkweise finden könnte.

Das Testen sollte Teil der Durchführung sein, dies bedeutet jedoch nicht, dass die QS-Person die Prüfung durchführen muss. Angesichts der Ressourcenknappheit und einer agilen Umgebung, in der die von der Qualitätssicherung festgelegten Spezifikationen vermieden werden, muss die Qualitätssicherung in das Erlernen der Benutzerdomäne, das Entwerfen von Besprechungen, Besprechungen zur Punktpflege, Stand-ups, Rückblicke usw. einbezogen werden.

Verwenden Sie für die große Frage der Teststrategie die agilen Testquadranten, um sich zu orientieren:

                   |
      Integrated   |     Performance
_________________________________________
                   |     
           Unit    |     Exploratory

Die Entwickler führen möglicherweise bereits Unit-Tests durch. Ein wichtiger Bereich, den die Qualitätssicherung durch die Abdeckung steigern kann, ist das integrierte Testen und die Verwendung der UI-Automatisierung. Gute Erkundungstests sind ebenfalls sehr wertvoll - es geht nicht nur darum, auf jeden Link auf der Seite zu klicken, sondern auch darum, die Domäne der Endbenutzer kennenzulernen und zu erfahren, was die Verwendung der Anwendung für sie bedeutet.

Berücksichtigen Sie für das Verhältnis von Qualitätssicherung zu Testern auch das Testdreieck:

    Exploratory
  Integrated Tests
Individual Unit Tests

wobei ein explorativer oder integrierter Test Dutzende, wenn nicht Hunderte von Komponententests darstellen kann, indem der gesamte "Stapel" ausgeübt wird.

Denken Sie auch daran, dass es wie in agilen Teams im Allgemeinen einen Ansatz geben sollte, bei dem jeder codieren und testen kann. Der Schlüssel ist natürlich, den Leuten die Anleitung und Struktur zu geben, damit sie das tun können, was benötigt wird, und ihnen Schulungen für den anderen Bereich zu geben.

In Bezug auf das tatsächliche Verhältnis bin ich nicht einverstanden mit der Genauigkeit von Davids Antwort von 3: 1 oder 4: 1. In einigen Organisationen, in denen Entwickler gute Unit- und integrierte Tests schreiben, ist es möglicherweise in Ordnung, 7: 1 in einer Organisation mit sehr wenig zu sein Von Entwicklern durchgeführte Tests müssen möglicherweise 1: 1 durchgeführt werden. Dies hängt wirklich von der Organisation, Struktur, dem Wissen, der Branche usw. ab.

Als wir mit der Entwicklung unseres Produkts begannen, implementierten wir auch Kanban und damit eine vollständige Testautomatisierungsstrategie. Aus diesem Grund haben wir heute keine Tester in unserem Team. Stattdessen müssen Entwickler Testfälle schreiben und diese automatisieren, wenn sie an User Storys, Verbesserungen oder Fehlern arbeiten. Unsere Definition von Dev Complete umfasst Unit-Tests und Funktionsautomatisierung.

Nach Abschluss der Entwicklung befindet sich noch eine "Validierungsphase", in der alle neuen Entwicklungsarbeiten (Funktionen, Fehlerbehebungen) auf einem Staging-Server bereitgestellt werden und jemand - jeder, der über funktionale Kenntnisse der Funktion verfügt - diese validieren muss. Wir verwenden Mitarbeiter unseres Dokumentationsteams sowie des Produktmanagements - und manchmal auch leitende Angestellte / Architekten von Sr. Engg - zur Validierung. Jede Version muss mindestens 1 Woche im Staging verbleiben, bevor sie in der Produktion bereitgestellt wird.

Hier ist eine Momentaufnahme unseres Kanban-Boards -

Der Prozess und Kanban haben für uns gearbeitet. Wir haben eine nahezu 100% ige Testautomatisierung, eine Trittfrequenz von 3-4 Wochen und das Beste ist, dass die meisten Teammitglieder die Flexibilität haben, an so ziemlich den meisten Teilen unseres Produkts zu arbeiten!

Auch wenn dies möglicherweise nicht Ihren kurzfristigen Zielen entspricht, möchten Sie auf jeden Fall prüfen, wie Sie Ihr Team langfristig umstrukturieren können. Wenn dies noch nicht geschehen ist, sollten Sie sich Strategien zur Testautomatisierung ansehen, die Ihrem Team definitiv helfen würden, mehr zu erreichen Qualität in kürzeren Abständen.