Warum sagt der Scrum-Guide keine Tester?

Ich habe den Scrum Guide von scrum.org gelesen und dort steht:

Entwicklungsteams enthalten keine Unterteams, die bestimmten Bereichen wie Tests oder Geschäftsanalysen gewidmet sind.

In seiner wörtlichen Übersetzung bedeutet dies, dass es keine Tester gibt, was verwirrend ist. Wie können sie das vorschlagen?

Es bedeutet, dass entweder:

1. Tester sind in das Entwicklungsteam integriert - Tools, mit denen Entwickler sowohl testen als auch testen können.

   oder:

2. Das Team übt Test Driven Development aus, dh es schreibt automatisierte Tests, die das System testen.

Beides bedeutet, dass kein separates Testteam erforderlich ist.

In seiner wörtlichen Übersetzung bedeutet dies, dass es keine Tester gibt, was verwirrend ist ... Wie können sie dies vorschlagen?

Ja, genau das schlagen sie vor. Mit anderen Worten - die Entwickler sind die Tester und die Tester sind die Entwickler.

Die Idee ist, die Eigentümerschaft und Qualität von Code zu fördern .

Dies bedeutet nicht, dass der Code nicht getestet wird, sondern dass die am Schreiben beteiligten Personen am Testen beteiligt sind - es gibt keine Trennung der Verantwortlichkeiten.

Das Problem, das mit diesem Ansatz angegangen werden soll, ist die allzu häufige Trennung zwischen Entwicklern und Testern, bei der Entwickler Code schreiben und "über die Wand werfen", und das dann hin und her, wodurch das Projekt und die Produktion verzögert werden Sub-Standard-Software.

Der grundlegende Teil dazu ist, dass der Codierer dafür verantwortlich ist, Code zu erstellen, der funktioniert und die Anforderung erfüllt. Dies erfordert eine bestimmte Denkweise: "Der Code, den ich schreibe, macht das, was er tun soll."

Um die Verantwortlichkeiten des Kodierers zu mischen, muss der Kodierer nun andere Einstellungen für andere Aktivitäten eingeben. Als Kodierer ist es jedoch schwierig, sich vollständig von dieser Einstellung zu trennen.

Der Tester ist dafür verantwortlich, Fehler und Stellen zu finden, an denen die Funktionalität von der erforderlichen Funktionalität abweicht. Dies erforderte die Einstellung von "Der Code ist kaputt und ich werde herausfinden, wie."

Ebenso versucht ein Business Analyst, die Anforderungen zu identifizieren, nach denen der Kunde tatsächlich fragt. Dies setzt eine andere Denkweise voraus: "Die Anwendung funktioniert nicht so, sollte es aber."

Damit ein Codierer in einer dieser anderen Funktionen arbeiten kann, besteht eine angemessene Wahrscheinlichkeit, dass die Einstellungen in Konflikt geraten und der Codierer unter folgenden Bedingungen arbeitet:

• Coder / QA - "Der Code funktioniert einwandfrei, und ich habe bereits codiert, um alle erdenklichen Probleme zu lösen."
• Coder / BA - "Der Code sollte so funktionieren, wie ich es möchte, und dies wären nette Dinge, die der Kunde nicht gedacht hat.

Dies soll nicht heißen, dass jeder Codierer für diese Probleme anfällig ist (ich habe einige sehr begabte Codierer- / QA-Typen getroffen ... allerdings nicht für Code, den sie geschrieben haben).

Dies gilt auch für das Entwicklungsteam. Das Mischen der Verantwortlichkeiten und der damit verbundenen Denkweisen dieser Verantwortlichkeiten für ein Entwicklungsteam gefährdet das Endprodukt (den Code).

Es sagt , dass es nicht ist Unter -Team zu testen gewidmet ist . Das bedeutet nicht, dass überhaupt keine Tests durchgeführt werden. Dies bedeutet nur, dass die Teammitglieder ihre eigenen Tests durchführen und häufig den Code / die Funktionen anderer testen. Ich bin mit der Scrum-Methodik nicht so vertraut, aber ich werde mich auf die Probe stellen und sagen, dass der Kunde möglicherweise auch an den Tests beteiligt ist.

Ich denke, dies bedeutet teilweise, dass Sie Tests für Ihren eigenen Code schreiben müssen, damit Sie wissen, dass er funktioniert (wenn nicht, haben Sie ihn noch nicht wirklich fertiggestellt), und teilweise, dass Sie manchmal als Tester für den Code anderer erwartet werden .

Anstatt zuzulassen, dass die Leute den Softwarequalitätsjob auf eine andere Person übertragen und ihn ignorieren, muss jeder die ganze Zeit über den Code nachdenken, den er schreibt, und das ist eine gute Idee.

Diese Aussage versucht grundsätzlich, ein albernes Arbeiten zu vermeiden. Ein Teil der Lösung hierfür sind Methoden wie - Testgesteuerte Entwicklung - Paarprogrammierung - Pull-Anforderungen - Testautomatisierung und dergleichen, bei denen das Testen ein wesentlicher Bestandteil des Entwicklungsprozesses ist und nicht isoliert entweder auf der Seite oder auf der Seite ausgeführt wird 'nach'.

Darüber hinaus wird im Scrum-Handbuch nur in sehr begrenztem Umfang über Rollen gesprochen. Tatsächlich sprechen sie über das Entwicklungsteam. Was sie bedeuten ist, dass Sie ein starkes funktionsübergreifendes Team wollen. Dies bedeutet, dass Sie abhängig von den Anforderungen Ihrer Projekte eine Reihe von Fähigkeiten benötigen, z. B. UX, BA, QA / Tester, Ops, Coder usw. usw. Es spielt jedoch keine Rolle, ob dies eine oder mehrere Personen sind, die diese Anforderungen erfüllen.

Die Teams, mit denen ich zusammenarbeite, haben mit Sicherheit eine Rolle in der Qualitätssicherung, genauso wie wir DevOps-Mitarbeiter. Aber sie sind alle auch Entwickler, nur mit Spezialisierung auf diesen Gebieten. Der Trick ist wirklich, nicht in Silos zu fallen und isoliert zu arbeiten.

Das bedeutet nicht unbedingt, dass es keine Tester gibt. Es kann sein, dass ein Scrum-Team engagierte Tester hat oder nicht.

Diese Aussage zu Scrum bedeutet für mich, dass Sie die gesamte Lieferpipeline als ein einziges Team betrachten sollten. Ein Teil desselben Teams zu sein, schlägt einige Dinge vor:

1. Es gibt eine einzige Schätzung für eine Geschichte / einen Fehler / eine Aufgabe. Es gibt keine Entwickler- und Testschätzung.
2. Das Team schätzt eine Geschichte nicht und verpflichtet sich dazu, ohne dass der Tester anwesend ist.
3. Wenn etwas schief geht, ist es nicht mehr die Schuld des Testers als die Schuld des Entwicklers. Es ist die Schuld des Teams .
4. Das Team muss niemals Tester ausleihen, anfordern oder nach ihnen fragen.
5. Testen ist Teil der Definition von erledigt. Ungetestete Arbeit ist unvollständige Arbeit.
6. Entwickler sollten die Testbarkeit beim Entwerfen ihres Codes berücksichtigen.

Wenn sie in einem Team zusammenarbeiten, hat das Team gemeinsam Erfolg und scheitert gemeinsam. Ich war in einem sehr erfolgreichen Scrum-Team mit mehreren Testern. Die Tester waren bei allen Stand-ups, Pflege-Sessions, Planungen usw. anwesend. Wenn nicht klar wäre, wie eine Story getestet werden soll, würde sich das Team nicht dazu verpflichten. Bei der Schätzung haben wir immer mit unseren Testern gesprochen.

Mögliche Anzeichen, dass Sie Tester nicht wirklich als Teil des Bereitstellungsteams behandeln, selbst wenn Sie glauben, dass Sie Folgendes tun:

1. Tester haben einen "QA-Standup" (yup, ich habe es gesehen).
2. Tester haben eine separate Managementstruktur.
3. Sie haben einen QA-Lead.
4. Sie verlassen sich stark auf End-to-End-Tests.
5. Tests werden im folgenden Sprint geschrieben.
6. Die meisten Tests finden am letzten Tag des Sprints statt.

Diese sind subjektiv und nicht unbedingt falsch. Meiner Meinung nach sind sie jedoch rote Fahnen.

Trotzdem ist es durchaus möglich, ein Scrum-Team zu haben, ohne dass jemand eine bestimmte Rolle als Tester spielt. Das kann auch gut funktionieren. Vor allem, wenn Sie das Testen automatisieren. TDD hilft auch.