Der beste Weg, um Entwicklung und Tests synchron zu halten

Ein Ansatz, den Sie ausprobieren könnten, besteht darin, die QA vor den Entwicklern arbeiten zu lassen.

Es würde ungefähr so ​​funktionieren:

• Back-End-Entwickler schreiben verkürzte API-Aufrufe, die das Verhalten der fertigen Funktionalität nachahmen
• UI-Entwickler erstellen ein Boilerplate-Front-End, das die API aufruft (Ergebnisse werden von den Stubs zurückgegeben).
• In diesem Stadium gibt es keinen geschriebenen Implementierungscode, nur Rahmencode
• Das sollte schnell gehen
• Die QA beginnt mit der Arbeit am Schreiben ihrer End-to-End- und Integrationstests unter Verwendung des Boilerplate-Front-Ends und der Stubbed-API
• Die Entwickler machten sich an die eigentliche Implementierung
• QA beendet ihre Tests, bevor die Entwickler fertig sind
• Die Entwickler sind jetzt nicht mehr von der QA abhängig – sie können die vorhandenen Tests verwenden, um zu bestätigen, dass ihr Code wie erwartet funktioniert

Dies erfordert einige Koordination und Sie müssen die Dinge sorgfältig planen. Tatsächlich handelt es sich um eine testgetriebene Entwicklung, die auf Funktionsebene durchgeführt wird.

TLDR: Optimieren Sie den Durchsatz und Ihre Mitarbeiter werden T-förmig .

Zunächst einmal sollte ich ansprechen

Ist das der richtige Ansatz?

Darauf lautet meine Antwort: "Fragen Sie keine Fremden im Internet. Probieren Sie es aus und sehen Sie." Agile beinhaltet zwei Konzepte, die hier relevant sind:

1. Versuchen-prüfen-wiederholen Zyklen
2. Selbstverwaltende Teams

In Bezug auf das erste ... versuchen Sie es und sehen Sie. Stellen Sie sicher, dass Sie über eine messbare Grundlinie verfügen, z. B. den Durchsatz (die Zeit, die benötigt wird, um ein einzelnes Ticket von „In Bearbeitung“ auf „Fertig“ zu bringen). Dann versuchen Sie Ihre vorgeschlagene Änderung für ein oder drei Wochen. Dann nochmal messen und prüfen.

Aufgrund des zweiten würde ich jedoch dringend davon abraten, dies einfach dem Team aufzuzwingen. Der „Try-and-see“-Ansatz sollte dabei etwas helfen, aber Sie müssen sich dennoch um ihre Bedenken kümmern. Was mich zu ...

Entwickler müssen ihren Code frühestens in den Entwicklungszweig gemergt haben, damit ihr nächstes Feature [...]

Mein Vorschlag wäre ... Springen Sie nicht sofort zum nächsten Feature. Das Feature, das Sie gerade "fertiggestellt" haben, ist vielleicht fertig, aber es ist noch nicht fertig! Anstatt zu etwas Neuem zu springen und weitere laufende Arbeiten zu büffeln, konzentrieren Sie sich darauf, dieses eine Ticket zuerst bis zum Ende zu bringen.

Nun, ja, die Nicht-QA-Entwickler haben keine Erfahrung damit

Microservice-Integration und e2e-Tests

aber so? Sie können lernen. Einer von ihnen kann mit der Qualitätssicherung zusammenarbeiten, während ein anderer alleine recherchiert und der dritte an einem nicht verwandten Lieblingsprojekt arbeiten kann (zum Beispiel). Indem Sie Schlupfzeiten einbeziehen ( eher auf Durchsatz als auf Auslastung optimieren ) , konzentrieren Sie sich darauf , einzelne Tickets zu erledigen , während Ihre Teammitglieder ihre Sägen schärfen können . Auf diese Weise erwerben Ihre Entwickler im Laufe der Zeit neue Fähigkeiten (werden T-förmig) und können möglicherweise einige der QA-Aufgaben selbst übernehmen, wodurch das Team Tickets so schnell wie möglich von „In Bearbeitung“ zu „Fertig“ bringen kann.

Was du am Ende willst, oder?

Eine mögliche technische Lösung könnte hier darin bestehen, sie zu bitten, einen zweiten Zweig zur Versionskontrolle zu erstellen . Wenn die Entwickler glauben, dass sie ihre Arbeit beendet haben, wechseln sie in einen Zweig „ausstehende QA-Tests“. Endgültige Zusammenführungen in die Produktion finden nur von diesem Zweig aus statt.

Hier ist eine Strategie, die für mich als Projektmanager, der auch eine sehr lange Geschichte in der reinen Softwareentwicklung hat, sehr gut funktioniert: „Dass es zwei unterschiedliche Ausprägungen der Idee des ‚Softwaretestens‘ gibt.“ Auch wenn der identische Begriff verwendet wird , sie sind tatsächlich disjunkte Aktivitäten. Jeder wird zu einem anderen Zeitpunkt für einen gleichermaßen legitimen Zweck angewendet.

(1) „Testgetriebene Entwicklung“ bezieht sich auf die Vorstellung, dass der einzelne Softwareentwickler nicht „das Ticket schließen“ und „seine Änderung akzeptieren lassen“ kann, bis er sowohl die Quellcodeänderung als auch einen Test bereitstellt, der nicht nur das beweist seine Änderung funktionierte, aber es hat nichts kaputt gemacht. (Diese Tests sollen Teil einer ständig wachsenden Bibliothek von Tests werden, die vom „Build-Prozess“ automatisch und kontinuierlich angewendet werden können.) Dies findet die meiste Zeit auf einer „ziemlich mikroskopischen“ Ebene statt.

(2) „Klassische ‚QA‘“ (in Ermangelung eines besseren Begriffs …) ist eine unabhängige und eher geschäftsorientierte Tätigkeit – ebenfalls häufig automatisiert, aber auf andere Weise – die von einem völlig separaten Team durchgeführt werden sollte . Diese sucht insbesondere nach kundensichtbaren und geschäftsrelevanten Themen, „die per se nichts mit ‚dem Quellcode‘ oder ‚der letzten Änderung‘ zu tun haben“.

Und es gibt – und soll es geben – eine synergetische Beziehung zwischen den beiden. Wenn Sie möchten, "konzentriert sich einer auf das 'Wie', während der andere sich auf das 'Was' konzentriert." Wenn dieser Fehlerfisch "in den Fluss hinauskommt und Ärger macht", muss er durch zwei verschiedene Fischernetze!