Sollten Tester Releases genehmigen oder nur über Tests berichten?

20

Ist es sinnvoll, den Testern die Berechtigung zum Abmelden zu erteilen? Sollte ein Testteam

Testen Sie einfach Funktionen, Probleme usw., und melden Sie sie auf der Basis von Bestanden / Nicht Bestanden, und überlassen Sie es anderen, anhand dieser Ergebnisse zu handeln
Haben Sie die Befugnis, auf der Grundlage dieser Ergebnisse selbst Veröffentlichungen aufzuhalten?

Mit anderen Worten, sollten Tester aufgefordert werden, sich bei Releases tatsächlich abzumelden? Das Testteam, mit dem ich zusammenarbeite, ist der Meinung, dass dies der Fall ist, und wir haben ein Problem damit, weil sich der Testumfang verschlechtert. Die Ablehnung der Freigabe basiert manchmal auf Problemen, die in der betreffenden Version ausdrücklich nicht behandelt werden.

testing release-management process

— Ernest Friedman-Hill
quelle

2

Bitte formulieren Sie Ihre Frage neu, damit es sich nicht um eine Umfrage handelt. Welches Problem möchten Sie lösen?

— M. Dudley

5

"sollte" hängt weitgehend von der Organisationsstruktur des Unternehmens ab. Wenn sie an Fehlern gemessen werden, die in der Produktion gefunden wurden, ist es ein wesentliches Werkzeug, eine fehlerhafte Version zu halten.

Ausgezeichneter Punkt, @MichaelT. In meiner Organisation ist das Testen eher eine Rolle als eine Stellenbeschreibung, und die Bewertung erfolgt eher ad-hoc und überhaupt nicht quantitativ. Erfolgreiche Bereitstellungen würden zu positiven Überprüfungen führen, Fehler in der Produktion wären jedoch keine besonderen Nachteile, ebenso wenig wie für andere Mitglieder des Teams.

— Ernest Friedman-Hill

5

Wenn Sie das Problem haben, dass Tester die Freigabe von Releases aufgrund von Problemen ablehnen, deren Behebung nicht geplant ist, dann haben Sie Kommunikationsprobleme (sie wissen nicht, dass die Probleme nicht geplant sind) oder Personenprobleme (sie machen sich selbst wichtig; ob Die Freigabe ist letztendlich eine Geschäftsentscheidung.

— Jan Hudec

27

Die meisten Orte, an denen ich gearbeitet habe, haben die QA-Mitarbeiter eine Art Abmeldeschritt, haben jedoch keine endgültige Berechtigung, ob die Veröffentlichung fortgesetzt wird oder nicht. Ihre Freigabe bedeutet, dass sie die vom Release-Plan erwarteten Tests abgeschlossen haben und nicht, dass das Release fehlerfrei ist.

Letztendlich müssen QA! = Das Unternehmen und das Unternehmen entscheiden, ob sie mit der Bereitstellung des Codes im aktuellen Zustand einverstanden sind oder ob der Nutzen den Nachteil oder was auch immer überwiegt. Dies wird häufig von Kunden oder Stakeholdern unmittelbar vor der Bereitstellung durchgeführt und wird häufig als Benutzerakzeptanz bezeichnet.

Wenn Ihre Qualitätssicherung auch Ihre Benutzerakzeptanzgruppe ist, besteht die Möglichkeit, dass sie befugt ist, Ihren Release-Kandidaten als inakzeptabel zu definieren. Wenn Sie dies jedoch über Probleme hinwegbekommen, die nicht in den Geltungsbereich von Bugfix / Iteration / Sprint / Änderung fallen Anfrage / Was auch immer Sie sich Zeit nehmen, der Projektmanager oder die Stakeholder des Geschäftsbereichs müssen sich mit dem QA-Team zu Jesus treffen.

Es ist in Ordnung, über bereits vorhandene Mängel oder unbeabsichtigte Ergebnisse neuer Anforderungen zu berichten, aber wenn dies außerhalb des Geltungsbereichs liegt und keine Katastrophe darstellt, ist es im Allgemeinen nicht akzeptabel, das Problem als Blockierungsproblem zu kennzeichnen. Es geht in den Rückstand für den Product Owner, wie alles andere Prioritäten zu setzen.

— Rechnung
quelle

Wer entscheidet, ob Sie den Kunden einladen, einen Abnahmetest für Build 1234 durchzuführen, oder ob dieser nicht für Abnahmetests ausreicht?

— Bart van Ingen Schenau

3

@BartvanIngenSchenau: Der Product Owner / Projektmanager muss das letzte Wort dazu haben. Denn selbst die Akzeptanztests nehmen bei Bedarf häufig zu (möchten Sie Feature X jetzt, obwohl wir Y nicht dazu bringen können, damit zu arbeiten, oder möchten Sie noch zwei Monate warten, bis wir es reparieren?) Und den Product Owner verhandelt das.

— Jan Hudec

Zusätzlich zu dem, was Jan sagte, würde es in vielen Methoden einen Zeitplan oder eine Kadenz geben. Einige Leute stellen jeden Kandidaten, der den anfänglichen Rauch-Test überlebt, für UAT bereit, andere stellen automatisch alles bereit, was in den Kandidaten-Zweig eingecheckt wurde, andere alles, was in main eingecheckt wurde. Im Idealfall haben Sie die Fortschritte der Stakeholder gezeigt, so dass es am Ende keine große Überraschung geben sollte. In einigen dieser Fälle zeigen Sie den Stakeholdern, worauf die QA-Mitarbeiter Sie aufmerksam gemacht haben, und sie sagen nur "wen kümmert das", und es ist vorbei.

— Bill

In modernen SaaS-Umgebungen mit kontinuierlicher Bereitstellung kann der Code-Bereitstellungszyklus (Service-Bereitstellungszyklus) vom Feature-Release-Zyklus (Business-Release-Zyklus) getrennt sein. Dieser Feature-Release-Zyklus kann mithilfe von Feature-Flags oder Umschaltern implementiert werden, z. B. von Alpha (intern) über Beta (Opt-In) bis hin zur allgemeinen Verfügbarkeit. Dies ist eine Möglichkeit, eine formellere Geschäftsfreigabe unabhängig von der Bereitstellungsfähigkeit bestimmter Codes oder Dienste zu ermöglichen. Die umgekehrte Verknüpfung von Feature-Releases mit Service-Bereitstellungen führt zu einer Kopplung und einem Risiko im Prozess, die mit der Feature-Flag-Technik vermieden werden können.

— Will

@will Ich bin nicht anderer Meinung, aber es wird immer noch eine Entscheidung getroffen, ob diese verborgenen Funktionen verborgen genug sind, um von anderen Benutzern als dem Beta-Team bei der Erstbereitstellung und letztendlich überall dort, wo ich diesen Ansatz verwendet habe, bemerkt zu werden mehr oder weniger gleich aus, aber mit unterschiedlichen Beschriftungen an den beweglichen Teilen und dem Risiko etwas verschoben. Ich bevorzuge die Situation, die Sie beschreiben, aber das QA-Team, das etwas vorgefunden hat, oder der Produktmanager, der sich dafür entscheidet, trotzdem fortzufahren, ist in diesem Modell genauso eine Sache wie in jeder anderen meiner Erfahrungen.

— Bill

6

Jemand braucht diese Autorität . Ob es sich um einen Tester, das Testerteam, den Leiter des Testerteams oder den Leiter der Entwicklungsorganisation handelt, spielt keine Rolle. Oder genauer gesagt, es hängt von der Organisation ab.

Letztendlich ist die Entscheidung, Software freizugeben, eine Geschäftsfunktion. Das Unternehmen muss entscheiden, ob die Qualität angemessen ist. Der Leiter der Qualitätssicherung sollte diese Entscheidung treffen oder sie der entsprechenden Geschäftseinheit übermitteln. Das hängt alles von der Größe des Unternehmens, der relativen Bedeutung der Qualität usw. ab.

Abgesehen davon beginnen die Informationen, die für die Entscheidung herangezogen wurden, mit dem Tester . Unabhängig davon, ob sie die Möglichkeit haben, eine Veröffentlichung zu stoppen oder nicht, sollten sie sich verpflichtet fühlen, die Entscheidungsträger zu informieren, wenn sie etwas sehen, von dem sie glauben, dass es eine Verzögerung bei der Veröffentlichung hervorruft.

— Bryan Oakley
quelle

6

Es ist genauso sinnvoll, den Testern die Autorisierung zum Abmelden (dh ein Vetorecht) für Veröffentlichungen zu erteilen, wie den Entwicklern dieses Recht zu erteilen: keines.

Tester und Entwickler sind in erster Linie Techniker, daher werden sie ihre Entscheidungen wahrscheinlich hauptsächlich aus technischen Gründen treffen. Die Bedenken, die bei der Erstellung eines Releases abgewogen werden müssen, sind jedoch sowohl technische als auch geschäftliche Bedenken. Offensichtlich ist der Kunde nicht zufrieden, wenn Sie ein fehlerhaftes Produkt ausliefern, aber der Kunde ist gleichermaßen unzufrieden, wenn Sie eine Veröffentlichung immer wieder verschieben, da noch offene Probleme mit dem Produkt bestehen.

Jemand muss die richtige Balance zwischen einem guten Produkt und der Einhaltung des Zeitplans finden, der dem Kunden versprochen wurde. Zu diesem Zweck sollten Sie nicht in einer rein technischen, sondern in einer eher geschäftsorientierten Rolle wie dem Projektmanager oder dem Product Owner am Projekt beteiligt sein und Ihre Meinung von den Testern und Entwicklern einholen.

— Bart van Ingen Schenau
quelle

1

Ich habe das abgelehnt, weil ich mit einigen Punkten und Annahmen, die Sie machen, grundsätzlich nicht einverstanden bin. Ich bin nicht einverstanden, dass die Qualitätssicherung keine Befugnis haben sollte, ein Veto gegen eine Freigabe einzulegen, da viele Qualitätssicherungsgruppen auch in einer Benutzerakzeptanzrolle tätig sind. Außerdem stimme ich der Annahme nicht zu, dass Tester technische Leute sind. Nicht immer ist dies der Fall, und nicht jede Gruppe, die Software veröffentlicht, kann sich ein vollständiges QA-Team leisten, sodass die Rolle von Business-Analysten übernommen werden kann, die möglicherweise überhaupt keine technischen Kenntnisse besitzen.

— maple_shaft

1

zusätzlich zu maple_shafts punkt sehe ich oft den letzten aufruf auf dieser seite an jeden, der in der rolle des kunden ist, es sei denn, es wurde etwas schreckliches identifiziert. Dies ist letztendlich ihre Leistung und sie haben höchstwahrscheinlich den richtigen Standpunkt zum Risiko, vorausgesetzt, Sie liefern ihnen genaue Informationen.

— Bill

5

Die Entscheidung, "freizugeben" oder "nicht freizugeben", ist letztendlich eine Geschäftsentscheidung, bei der eine strenge Risiko- / Ertragsanalyse durchgeführt werden muss.

Es ist verrückt, wenn eine Organisation das Testteam auffordert, diese Verantwortung zu übernehmen, oder wenn das Testteam dieser Verantwortung zustimmt.

Die Rolle des Testteams besteht darin, eine Analyse der Qualität der Software, ihrer Freigabebereitschaft und aller Risiken bereitzustellen, die als Einfluss auf die Geschäftsentscheidung zur Freigabe oder Nichtfreigabe identifiziert wurden.

Wie andere angemerkt haben, braucht _ jemand _ (und ich glaube, es ist eine Einzelperson) die Autorität, um die 'Freigabe'- oder' Nichtfreigabe'-Entscheidung zu treffen. Dieselbe Person kann diese Entscheidung unter bestimmten Bedingungen delegiert haben (dh keine P1- oder P2-Bugs)

— Jordan
quelle

3

Ich habe mit der gleichen Situation gearbeitet, in der Tester immer kreativere Methoden entwickelt haben, um ein System zu durchbrechen, die bei einer Risikobeurteilung in der Produktion kaum jemals vorkommen werden.

Obwohl ich das Testteam verstehe und empfehle, dass es keine unvollständige Freigabe senden möchte, ist eine starke Produktbeteiligung erforderlich, um zu definieren, was ein "akzeptables Risiko" ist.

Meiner Erfahrung nach sollte das Testteam ein Veto gegen die Freigabe von Software erhalten, dieses Veto sollte jedoch vom Produktbesitzer außer Kraft gesetzt werden, jedoch nur nach Absprache mit den führenden Testern.

Software wird niemals perfekt sein, wenn Sie unter Testkriechen leiden, werden Sie niemals etwas veröffentlichen, bis es ein großes Produktionsproblem gibt (das nicht korrekt getestet wird) und es schnell erledigt.

— Michael
quelle

1

Das ist ein echtes Problem, aber ich bin mir nicht sicher, ob das notwendigerweise das Problem des OP ist. Meine Interpretation ist, dass die Tester irgendwie neue Anforderungen interpretieren, die ursprünglich nicht definiert wurden.

— maple_shaft

2

Meine Erfahrung mit Testteams hat mich auf die andere Seite geführt. Für mich sollte die Qualitätssicherung keine Erwartung haben, eine Bereitstellung blockieren zu können, ohne den Rest des Teams davon zu überzeugen oder den Eigentümer dazu zu bringen, das Team außer Kraft zu setzen.

— Bill

1

Es stimmt - ich war wahrscheinlich nicht explizit genug, die gleichen Probleme treten auf, wenn Tester Fehler ansprechen, und ich zitiere "in the spirt of the story", was zu den gleichen Problemen führt - nichts wird jemals veröffentlicht.

— Michael

In meinem Fall ist es eher die Interpretation von @maple_shaft; Sie müssen nicht so sehr nach Wegen suchen, um die Software zu beschädigen, sondern müssen Fehler melden, die ausdrücklich nicht unterstützte Fälle betreffen.

— Ernest Friedman-Hill

1

@ ErnestFriedman-Hill Es hört sich so an, als würden Sie negative Anforderungen beschreiben, und diese fehlen in Ihren funktionalen Anforderungsdokumenten. Eine negative Anforderung ist eine explizite Aussage darüber, was ein System NICHT tut, und kann genauso akzeptabel sein wie normale Anforderungen. Wenn diese deklariert sind, sind ihre Testfälle gegen Negative Anforderungen nicht gültig.

— maple_shaft