Lebensfähigkeit eines Entwicklungsteams ohne * dedizierte * Testerrolle [geschlossen]

Ich habe in letzter Zeit viel darüber nachgedacht, wie man ein schlankes Entwicklungsteam aufbaut. Letztendlich möchte ich mit einer kleinen Anzahl von Gleichgesinnten mein eigenes kleines Softwarehaus eröffnen. Das Ziel wird nicht sein, reich zu werden, sondern ein gesundes Arbeitsumfeld zu haben.

Bisher definiere ich ein schlankes Team wie folgt:

• Klein;
• Selbstorganisierend;
• Alle Mitglieder müssen die Qualitätssicherung berücksichtigen.
• Mitglieder müssen in der Lage sein, mehrere Rollen auszuführen

Der letzte Punkt ist, wo ich mir ein bisschen Sorgen mache, weil, wie das Mantra sagt ...

Entwickler machen schlechte Tester.

Obwohl ich verstehe, dass Entwickler häufig "zu nah" an ihrem Code oder dem Code ihres Kollegen sind, um Qualitätsbewertungen auf höherer Ebene vorzunehmen, bin ich nicht davon überzeugt, dass sie de facto schlechte Tester sind. Im Gegenteil, ich bin der Meinung, dass sich die Eigenschaften eines guten Entwicklers stark mit den Eigenschaften eines guten Testers überschneiden.

Unter der Annahme, dass dies richtig ist, habe ich über verschiedene Möglichkeiten nachgedacht, um das Entwickler- / Testerproblem zu umgehen, und ich glaube, ich habe ein tragfähiges Modell entwickelt.

Mein Modell erfordert:

• Ein kleines Softwarehaus mit 2+ Projekten
• Ein agiler (iterativer) Ansatz für Entwicklung und Bereitstellung
• 1 Team pro Projekt
• Alle Teammitglieder sind Softwareentwickler
  • In ihrer Stellenbeschreibung werden Entwicklung , Qualitätssicherung , Prüfung und Lieferung eindeutig als Verantwortlichkeiten angegeben

Wenn alle diese Voraussetzungen erfüllt sind, können die Projekte folgendermaßen organisiert werden (dieses Beispiel bezieht sich auf zwei Projekte, A und B ):

• Jedes Teammitglied wechselt zwischen der Entwickler- und der Testerrolle
• Wenn ein Teammitglied ein Entwickler in Projekt A ist , ist es ein Tester in Projekt B.
  • Die Mitglieder arbeiten jeweils nur an einem Projekt und werden daher voraussichtlich entweder als Entwickler oder als Tester fungieren .
• Ein Rollenzyklus besteht aus 3 Iterationen als Entwickler und 2 Iterationen als Tester (wiederum in zwei verschiedenen Projekten).
• Die Projektteams hätten jederzeit 3 ​​Entwickler und 2 Tester.
• Mitgliedsrollenzyklen sollten um 1 Iteration phasenverschoben sein.
  • Dies minimiert die Abruptheit der Teamänderungen. Für jede Iteration bleiben 2 Entwickler und 1 Tester gleich wie bei der vorherigen Iteration.

Vor diesem Hintergrund sehe ich die folgenden Vor- und Nachteile:

Vorteile

• Verteilt das Projektwissen im gesamten Unternehmen.
• Stellt sicher, dass die Teammitglieder den Code, den sie geschrieben haben, nicht testen.
• Außerphasige Rollenzyklen bedeuten, dass kein Projekt jemals einen 100% -Mitgliedswechsel hat.
• Wechselnde Rollen brechen die Monotonie langweiliger Projekte.

Nachteile

• Die Iterationen beider Projekte sind eng miteinander verbunden. Wenn ein Projekt eine Iteration zur Hälfte abbrechen und erneut starten würde, wären die beiden Projekte nicht synchron. Dies würde die Verwaltung des Rollenzyklus erschweren.
• Scharniere bei der Einstellung von Entwicklern, die auch als Tester arbeiten.

Ich habe gemischte Kritiken erhalten, als ich diesen Ansatz mit Freunden und Kollegen besprochen habe. Einige glauben, dass nur wenige Entwickler jemals solche Rollen wechseln möchten, während andere mir sagen, dass sie es persönlich gerne ausprobieren würden.

Meine Frage lautet also: Könnte ein solches Modell in der Praxis funktionieren? Wenn nicht, könnte es in ein funktionierendes Modell umgewandelt werden?

Hinweis: Der Kürze halber habe ich mich nur auf die Rollen Dev und Tester konzentriert. Ich werde bei Bedarf auf andere Rollen eingehen.

Ich stimme nicht zu

Entwickler machen schlechte Tester

Die meisten Teams, in denen ich in meiner Karriere gearbeitet habe, hatten keine QS-Unterstützung. Dies schließt einige große, globale Unternehmen ein, die Produkte wie ihr globales Anmelde- und Registrierungssystem einbeziehen. In einem anderen Fall flossen 30% des Umsatzes des Unternehmens über eine Box auf meinem Schreibtisch. (Diese Praktiken werden übrigens nicht empfohlen;)) Diese Unternehmen waren auf die Ingenieure angewiesen, um sicherzustellen, dass ihr Code korrekt funktioniert. Und wir, die detailorientiert, etwas zwanghaft und stolz auf unsere Arbeit sind, würden große Anstrengungen unternehmen, um sicherzustellen, dass unsere Software korrekt funktioniert.

Außerdem mache ich als Entwickler viel mehr Tests als die Tester. Ich teste meinen Code routinemäßig zu 90% oder zu 100%, wenn ich nicht mit Java arbeite.

Ich arbeite gerne mit Testern, weil sie es aus einer anderen Perspektive betrachten und Dinge erfassen, an die ich nicht gedacht habe. Aber ich zähle wirklich nicht darauf, dass sie mehr als 30-50% Testabdeckung bieten, während ich mich für 100% verantwortlich mache. (Übrigens, das ist kein Knaller auf sie - sie sind normalerweise dünn über Projekte verteilt.)

Anstatt die Ingenieure in Interviews zu fragen, ob sie eine Qualitätssicherung durchführen möchten, fragen Sie: Wenn ein Fehler in der Produktion auftritt, wer ist dafür verantwortlich? Wenn ich einen Fehler einführe und ein Kunde ihn erlebt, fühle ich mich schlecht und übernehme Verantwortung. Ich beschuldige die QS-Leute nicht. IMHO Das ist die Art von Ingenieur, die Sie einstellen möchten (und mit der Sie arbeiten möchten).

Meine Methode zur Qualitätssicherung ist a) superaggressives Testen von Einheiten (obwohl ich mich nicht dazu bringen kann, eine vollständige testgesteuerte Entwicklung durchzuführen), b) ein starker Codeüberprüfungsprozess hilft wirklich und c) die Integration einer Intoleranz und Ungeduld mit Mängel in der Teamkultur.

Es ist mir immer aufgefallen, dass die ältesten Leute diejenigen waren, die selbst bei kleineren Problemen am fleißigsten und aufmerksamsten waren, weil sie auf ein größeres Problem hinweisen konnten. Aber hauptsächlich waren sie am ehesten bereit, die Zeit zu verbringen, um es richtig zu machen.

Aber die meisten Teams, in denen ich gearbeitet habe, insbesondere für kleine Unternehmen, hatten keine formelle QS-Komponente.

Ich stimme der Antwort von @Rob Y zu und möchte einige Punkte hinzufügen:

• In agilen, engagierten Testern innerhalb eines Teams sind sie ein Anti-Pattern, da sie Teams dazu zwingen, Pipeline-Arbeit zu leisten und von Natur aus ineffizient zu sein. Sie erhalten ständig Geschichten, die "dev done", aber nicht getestet sind. Engagierte Tester sind in Ordnung, wenn sie außerhalb des Teams (oder eines separaten Teams) arbeiten.

• Entwickler machen schlechte Tester ... und Tester machen schlechte Tester. QA ist schwer. In der Tat ist es sehr schwer. Ihr Problem sind möglicherweise nicht Personen und Rollen. Ihr Problem könnte sein, dass Ihre Software überstürzt ist. Auch hier liegt es in der Verantwortung Ihres Teams, vor der Produktion zu testen (ob es eine dedizierte Qualitätssicherung hat oder nicht).

• Die Qualitätssicherung ist Teil der Entwicklung, wie z. B. Refactoring, Architektur usw. Es liegt in der Verantwortung eines Entwicklungsteams, Software nach einem bestimmten, vereinbarten und realistischen Standard zu erstellen. QAs werden diesen Standard nicht verbessern. Bessere Entwickler werden es wahrscheinlich tun.

• Provokation: Wer sagt, dass QAs bei QA-ing besser sind als Entwickler? Es ist etwas, was die Leute sagen, aber ... [Zitat benötigt]. Die notwendige "Hacker" -Mentalität der Qualitätssicherung ist eine Entwicklermentalität. Tatsächlich sind oder waren im Grunde alle Hacker Entwickler, nicht QS ...

• Provokation 2: 99% der QS-Arbeit kann (und sollte , sollte ich sagen ) über Skripte automatisiert werden. Ein gutes Team wird dies tun, und um dies richtig zu tun, brauchen Sie ... Entwickler.

Bei einem früheren Job hatten wir nur Entwickler und keine QS-Mitarbeiter. Infolgedessen war niemand anderes schuld, wenn ein Problem die Produktion erreichte. Wir haben unsere QS-Verantwortung sehr ernst genommen und uns stark auf automatisierte Testsuiten verlassen. Da das Schreiben automatisierter Tests immer noch codiert, war es keine große Sache, Entwickler dazu zu bringen, dies zu tun.

Das Wichtigste ist, dass es Teil der Kultur des Teams und Teil jedes Projekts ist. Wir haben Testpläne erstellt (nur kurze Listen von Tests, die wir für ein Projekt schreiben wollten), und andere Entwickler haben Fälle und Szenarien, die wir verpasst hatten, überprüft und vorgeschlagen.

Wenn Sie streng sind, kann es sehr gut funktionieren. Das hat es für uns getan - wir hatten eine hervorragende Verfügbarkeit und geringe Fehler in einem ständig verfügbaren E-Commerce-Webdienst.

Zunächst eine Einschränkung - Ich habe sowohl als QS-Ingenieur als auch als Software-Ingenieur professionell gearbeitet.

Könnte ein solches Modell in der Praxis funktionieren?

Alles ist möglich.

Obwohl ich verstehe, dass Entwickler häufig "zu nah" an ihrem Code oder dem Code ihres Kollegen sind, um Qualitätsbewertungen auf höherer Ebene vorzunehmen, bin ich nicht davon überzeugt, dass sie de facto schlechte Tester sind. Im Gegenteil, ich bin der Meinung, dass sich die Eigenschaften eines guten Entwicklers stark mit den Eigenschaften eines guten Testers überschneiden.

Es hängt davon ab, welche Art von Tests Sie benötigen. Wenn Sie gedankenbetäubende, monotone, sich wiederholende manuelle Tests benötigen, um sicherzustellen, dass jeder einzelne Bildschirm oder jedes einzelne Element wirklich ins Elbonische übersetzt wurde, werden Sie Probleme haben.

Und meiner Erfahrung nach erfordert jedes Projekt zumindest ein wenig von dieser Art von Tests (auch wenn nicht jedes Projekt diese Art von Tests durchgeführt hat). Das Problem ist, dass Sie diese Art von Tests nicht von Personen erhalten, die mit den Best Practices für die Qualitätssicherung nicht vertraut sind. Zur Hölle, Sie bekommen es nicht einmal von Leuten, die Best Practices kennen, sondern den Entwicklern "vertrauen".

Als Tester können Sie den Entwicklern nicht vertrauen. Ich habe die Anzahl der Fehler verloren, bei denen festgestellt wurde, dass "diese Änderung möglicherweise nicht verursacht wurde" oder "auf meiner Entwicklungsbox einwandfrei funktioniert".

Selbst wenn Sie Entwickler finden, die es tolerieren können , 2 von 5 Wochen nicht das zu tun, was sie gerne tun, werden Sie auf diesen zentralen Widerspruch stoßen. Schlimmer noch, Sie verbringen Zeit und Energie damit, Menschen darin zu schulen, in zwei Jobs gut zu sein, anstatt in einem. Unternehmen haben es schwer genug, Menschen zu finden und auszubilden, die gut in einem einzigen Job sind, geschweige denn zwei.

Vielleicht bist du irgendwie großartig, was ich noch nicht erlebt habe - aber ich bezweifle es.

Ich denke, es könnte funktionieren, aber es gibt ein paar Dinge, die ich sicherstellen würde, dass Sie es tun.

1. Seien Sie sehr offen über die Doppelrollen der Kandidaten. Es ist aus vielen Gründen nicht jedermanns Sache. Wenn Sie zu viele Leute haben, die es nicht mögen, haben Sie Misserfolg und Umsatz.
2. Haben Sie einen Plan, in dem Sie bewerten können, wie Sie dies am besten in das Team integrieren können. Obwohl ich mich immer auf eine Aufgabe / ein Projekt konzentrieren möchte, bin ich mir nicht sicher, ob ich nicht über einen sehr langen Zeitraum programmieren möchte. Vielleicht ist das Testen ein schöner Urlaub abseits des Programmierens. Nicht, dass es einfacher wäre, zur Abwechslung nur einige verschiedene Gehirnzellen zu verwenden. Seien Sie bereit, es auf verschiedene Arten zu versuchen, bevor Sie sich für das Beste entscheiden.

Das Synchronisieren von Projekten scheint keine praktische Lösung zu sein. Wenn jemand ein Tester für ein Projekt ist, ist er möglicherweise der beste Kandidat, um einen Programmierer zu ersetzen und umgekehrt.

Dieser Plan lässt die Teams nicht genug selbst organisieren. Eine Strategie passt wahrscheinlich nicht zu allen Teams und Projekten.