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

9

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.

MetaFight
quelle
Zwar gibt es Überschneidungen hinsichtlich der Frage, ob Entwickler Tester sein können oder sollten, aber ich denke, der Kern dieser Frage liegt in den nicht in Phase 2 befindlichen Rollen in 2 Projektmodellen.
MetaFight
2
FWIW meine persönliche Meinung ist, dass Sie mit einem solchen Ansatz ziemlich viel riskieren. Ich bin ein Ex-Tester (und nicht der schlechteste) und als ich einmal in einem Projekt gelandet bin, in dem ich zwei Rollen "verschachteln" konnte, dachte ich zuerst, wow, eine Chance, herauszufinden, wie man das richtig macht. Nach ungefähr einem halben Jahr habe ich es mir anders überlegt und möchte es nie wieder versuchen. Beide Rollen (Entwickler und Qualitätssicherung) erfordern einen 100% igen Fokus, um es richtig zu machen, aber wenn Sie sich verflechten, lenken Sie ab und verlieren entweder an Qualität oder Produktivität oder an beiden. Übrigens, ein engagierter Tester in diesem Projekt zu werden, brachte den beeindruckendsten ROI, den ich je gesehen habe
Mücke
2
@gnat, aber Sie haben nicht erklärt, warum ein Entwickler die Tester-Rolle nicht erfüllen konnte . Zugegeben, die betreffende Person müsste es als Vollzeitstelle ernst nehmen, weshalb ich vorgeschlagen habe, dass sie Projekte abwechseln und jeweils nur an einem Projekt arbeiten. Ich erwarte nicht, dass ein Entwickler dazu in der Lage ist ... nur diejenigen, die gute Tester abgeben würden, wenn sie diesen Weg gewählt hätten.
MetaFight
2
Um es mit anderen Worten zu sagen: "Ich möchte eine medizinische Praxis eröffnen, anstatt ein paar Anästhesisten einzustellen, werde ich genügend Chirurgen einstellen und sie gründlich um diese Rolle drehen." Ihr Vorschlag zeigt einen (typischen) Mangel an Verständnis dafür, was ein professioneller Tester einem Team bietet. Sie könnten es tun, viele tun es, einige bringen es zum Laufen. Was Sie nie erfahren werden, ist, was Sie verpassen und was Sie besser machen könnten. Übrigens - Testen ist keine Qualitätssicherung - nur eine Lektion, die Ihnen ein professioneller Tester beibringt.
Mattnz

Antworten:

8

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.

rauben
quelle
6

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.

Sklivvz
quelle
Kommentar zu Provocation 2: Testautomatisierung kann von Entwicklern durchgeführt werden, muss aber nicht. Tester, die wissen, wie man programmiert (aber nicht auf der Ebene eines professionellen Entwicklers), können ausreichend gute Skripte schreiben.
Kumpel Mrše
4

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.

Rory Hunter
quelle
Dieser Beitrag ist ziemlich schwer zu lesen (Textwand). Hätten Sie etwas dagegen bearbeiten sie in eine bessere Form ing?
Mücke
2
Entschuldigung, morgendlicher Brain-Dump. Ich habe es jetzt aufgelöst.
Rory Hunter
2

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.

Telastyn
quelle
Möglicherweise benötigt mein Modell eine Sr-QS-Rolle, um die vorgeschlagenen Ansätze meiner Entwicklertester zu überprüfen und Best-Practice-Ansätze zu empfehlen. Oh, und die meisten Leute finden mich nicht großartig, aber meine Mutter tut es :) und das ist gut genug für mich!
MetaFight
Ich verwandle einige unserer QS-Rollen in Product Owners. Es hört sich so an, als hätten Sie keine Akzeptanz von User Stories oder Sprint-Bewertungen durch den Produktbesitzer. Beides wird viele Probleme aufwerfen, die das Entwicklungsteam möglicherweise übersehen hat. Vorher müssen Sie jedoch verschiedene Entwickler finden, wenn Sie den Entwicklern nicht vertrauen können, dass sie Qualität produzieren. Das ist meine Schlussfolgerung - meiner Erfahrung nach kann man aus einem schlechten Entwickler keine schlechte Qualität trainieren. Ich habe mit vielen "Get the Job Doed" -Entwicklern zusammengearbeitet, und dies ist die Ausgabe, die Sie von ihnen erhalten. Ein gutes Scrum-Team erfordert gute Entwickler.
David Anderson
0

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.

JeffO
quelle
Die Tester-Rolle in diesem Fall würde wahrscheinlich manuelle und automatisierte Tests beinhalten. Ich würde erwarten, dass Entwickler Unit- und Integrationstests schreiben, aber die Tester würden das auch tun. Die genaue Aufteilung des codierten Testschreibens wäre hoffentlich ein natürliches Gleichgewicht, das nach einigen Iterationen erreicht wird.
MetaFight
Es sollte wirklich nicht einmal darum gehen, ob Kandidaten bereit sind, Doppelrollen zu spielen oder nicht. Wenn Sie ein erfolgreiches Unternehmen führen möchten, sollten Sie Menschen dort einsetzen, wo sie sich auszeichnen. Warum sollte der Typ testen, wer selbst 2 zuverlässige Systeme entwerfen und codieren kann, bei denen ein Team von 4 oder 5 Personen gleichzeitig ein einzelnes System erstellen muss? Ebenso hat das Testen seine eigenen Fähigkeiten, um es gut zu machen. Die größten Fortschritte in der menschlichen Zivilisation wurden erzielt, als sich die Menschen spezialisierten. Warum sollte es anders sein, ein Softwareunternehmen zu führen, als Mutter Natur bereits bewiesen hat, dass es am besten funktioniert?
Dunk