Ist es richtig, Fehler zu beheben, ohne neue Funktionen hinzuzufügen, wenn Software für Systemtests freigegeben wird?

Diese Frage richtet sich an erfahrene Tester oder Testleiter. Dies ist ein Szenario aus einem Softwareprojekt:

Angenommen, das Entwicklerteam hat die erste Iteration von 10 Funktionen abgeschlossen und für Systemtests freigegeben. Das Testteam hat Testfälle für diese 10 Funktionen erstellt und 5 Testtage veranschlagt. Das Entwicklerteam kann natürlich nicht 5 Tage im Leerlauf sitzen und beginnt mit der Erstellung von 10 neuen Funktionen für die nächste Iteration. Während dieser Zeit fand das Testteam Fehler und brachte einige Fehler hervor. Die Fehler werden priorisiert und einige müssen vor der nächsten Iteration behoben werden. Der Haken ist, dass sie die neue Version mit neuen Funktionen oder Änderungen an vorhandenen Funktionen erst akzeptieren würden, wenn alle diese Fehler behoben sind. Das Testteam sagt, dass wir auf diese Weise eine stabile Testversion garantieren können, wenn wir neben der Fehlerbehebung auch neue Funktionen einführen. Sie können auch nicht bei jeder Iteration Regressionstests für alle Testfälle durchführen.

Dies bedeutet, dass das Entwicklerteam einen Codezweig ausschließlich zur Fehlerbehebung und einen weiteren Zweig erstellen muss, in dem die Entwicklung fortgesetzt wird. Insbesondere durch Refactoring und architektonische Änderungen wird mehr Aufwand für das Zusammenführen verursacht.

Können Sie zustimmen, ob dies ein gängiges Testprinzip ist? Ist das Anliegen des Testteams gültig? Haben Sie dies in Ihrem Projekt in der Praxis erlebt?

Ich würde stattdessen sagen, dass sich jede Version neuer Funktionen in einem separaten Zweig befinden sollte. Dadurch können Entwicklung und Releases entkoppelt werden.

Wie funktioniert Ihre Freigabe für Endbenutzer in diesem Prozess? Ihr Systemtestteam sollte sich weniger mit dem Entwicklungsplan befassen und sich stattdessen auf den Zeitplan für die Kundenfreigabe konzentrieren.

Es macht wenig Sinn, zu versuchen, neue Funktionen während der Entwicklung formell zu testen, da die Chancen gut stehen, dass Ihre nächsten 10 Funktionen dieselbe Funktionalität berühren und diese Bereiche erneut testen müssen.

Sie können interne Zwischenversionen während der Entwicklung weiterhin informell testen und ihr Testdesign ausarbeiten (hoffentlich werden die meisten Fehler in diesen neuen Funktionen behoben). Am Ende der Entwicklung benötigen sie jedoch einen zusätzlichen Zeitraum, um neue Funktionen und Regressionen formal zu testen testen.

Wenn sie schätzen, dass 5 Tage zum Testen Ihrer 10 neuen Funktionen erforderlich sind, sollten sie berücksichtigen, dass sie am Ende des Entwicklungszyklus vor der Freigabe an Kunden 5 Tage benötigen, um die neuen Funktionen zu validieren (und wahrscheinlich mehr Zeit für die Iteration) wenn Fehler gefunden werden). Während dieser Zeit kann die Kundenversion zum Testen abgezweigt werden, und die Entwicklung neuer Funktionen kann für die nächste Version fortgesetzt werden.

Wir verwenden einen hybriden Ansatz. Für die Kundenfreigabe haben wir definitiv eine eigene Niederlassung, die ausschließlich für kritische Fehlerkorrekturen vorgesehen ist.

Die regelmäßige Entwicklung mehrerer Softwareversionen wird fortgesetzt. Angenommen, die neueste stabile Release-Version ist 2.0. Alle riskanten Funktionen werden dem 3.0-Zweig hinzugefügt. Nur Fehlerkorrekturen gehen in 2.0-Zweige. Die Tests durch ein engagiertes QS-Team werden nur an stabilen Niederlassungen durchgeführt. Kundenfreigaben erfolgen natürlich aus einer anderen Niederlassung basierend auf 2.0. Lang laufende Funktionen wie die Plattformentwicklung der nächsten Generation werden in 4.0 und nicht einmal in 3.0 ausgeführt.

Auf dem Papier sieht das alles gut aus. Wenn ein Kunde jedoch eine bestimmte Funktion wünscht, muss diese zur 2.0-Filiale selbst hinzugefügt werden, da 3.0 nicht stabil genug ist, um für Kunden freigegeben zu werden. Dies bedeutet, dass das QA-Team die gesamte Regressionssuite erneut ausführen muss.

Eine Sache, die wir tun, ist die Codeabdeckung jedes Regressionstestfalls. Es werden nur die Regressionstestfälle ausgeführt, die von den Codeänderungen für die Funktion betroffen sind. Für eine Kundenversion wird natürlich die vollständige Regressionssuite ausgeführt.

Das hängt wirklich davon ab, wie eng die neuen Funktionen mit den Teilen gekoppelt sind, für die Fehlerbehebungen erforderlich sind. Wenn Sie beispielsweise einem kleinen Teil der Benutzeroberfläche eine neue Drag & Drop-Funktion hinzufügen, sollte dies keinen Einfluss auf den Fehler haben, der mit dem Parsen der vom Benutzer geladenen Datei zusammenhängt.

Trotzdem ist es für Tester verständlich (nicht unbedingt gerechtfertigt), die Fixes 'Ceteris paribus' testen zu wollen (alle 'anderen' Dinge sind gleich).

Es gibt möglicherweise andere Bedenken hinsichtlich der Art der Veröffentlichung und der Erwartungen der Endbenutzer. Beispielsweise müssen Sie möglicherweise erst nach einer Iteration von Fehlerkorrekturen + Testen und einer weiteren neuen Funktion + Testen freigeben, da Benutzer NUR eine Neuinstallation oder ein Upgrade wünschen, wenn neue Funktionen vorhanden sind. Einige verlangen möglicherweise so schnell wie möglich Korrekturen als oberste Priorität.

Sie können dieses (häufige) Problem lösen, indem Sie beide Teams zusammenführen.

Tester innerhalb des Entwicklungsteams, die testen, wie Features erstellt werden, können den meisten Teams helfen, die Qualität der Ausgabe zu verbessern.

Ich empfehle Ihnen, diesen ausgezeichneten Blog-Beitrag von Henrik Kniberg zu lesen , der Kaban erklärt . Im Scrum-Prozess finden Sie viele Ideen (ein kostenloses Buch auch von Henrik Kniberg ).

Er schrieb auch einen ausgezeichneten Kanban VS Scrum Artikel in seinem Blog.

Genießen.

Das Testteam hat definitiv ein berechtigtes Anliegen, aber ich würde die Notwendigkeit mehrerer Testiterationen für jede Version in Frage stellen. Warum eine ganze Testrunde mit einer Codeversion durchlaufen, die Benutzer nie sehen werden?

Wenn die Tester versuchen, einem Kunden eine definierte Version zukommen zu lassen, die die neuen Funktionen nicht erwartet, ist ihre Anfrage vernünftig, gerechtfertigt und Sie sollten sich nach hinten beugen, um sie zu liefern.

Wenn dies nur dazu dient, ihre "Prozesse" während der normalen Entwicklungsphasen zu unterstützen und sicherzustellen, dass die Fehlerliste nicht außer Kontrolle gerät, fragen Sie den Testleiter, ob diese Einschränkung ein wenig gelockert werden kann, ohne ein Problem damit zu machen Wir nähern uns dem Release-Punkt.

Ziehen Sie in Betracht, Ihr Versionsverwaltungssystem auf ein verteiltes Produkt umzustellen. Dies erleichtert die Bereitstellung einer solchen Version erheblich.

"Können Sie zustimmen, ob dies ein allgemeines Testprinzip ist?

Yes

Ist das Anliegen des Testteams gültig?

Yes

Haben Sie dies in der Praxis in Ihrem Projekt erlebt? "

Yes

::

and Yes Merging is the downside of it 

Sie haben nicht gefragt, wer dafür verantwortlich ist, aber es liegt in der Verantwortung des Konfigurationsmanagers. Diese Stream-Strategie sollte in seinem CMP enthalten sein. Ansonsten feuere ihn / sie. Ich denke, die Resonanz von Pierre 303 ist auch sehr gut, aber natürlich, wenn möglich technisch (z. B. wenn man an eine Siebel-Veröffentlichung denkt ...) und organisatorisch.

Das Problem ist, dass sie, wenn sie die Fehler in einem Zweig testen, sie erneut testen und im Trunk-Modus auf dem Trunk testen müssen, sobald sie wieder zusammengeführt wurden (es sei denn, sie vertrauen sehr darauf, welche guten Tester selten sind). Dies bedeutet nicht nur mehr Arbeit für die Entwickler, sondern auch mehr Arbeit für die Tester.

Hier gibt es keine richtige Antwort, aber ein paar Dinge, die Sie beachten sollten:

• Könnten diese Fehlerversionen (ohne die neue Funktionalität) jemals an die Benutzer gehen? Wenn ja, dann muss es verzweigt und getestet werden, und jeder muss dies als Overhead akzeptieren.

• Ist es möglich, die neue Funktionalität so aufzuteilen, dass sie in völlig getrennten Bereichen der Anwendung zu den vorherigen Blöcken existiert, an denen gearbeitet wurde? Wenn ja, haben Sie Optionen - die Tester können die Fehler-Retests und Regressionstest-Teile der Anwendung durchführen. Es ist nicht ideal, aber es ist ein Kompromiss, der funktionieren und ihnen etwas geben könnte, was sie wollen.

• Wie viel Arbeit ist es wirklich, ihnen eine Veröffentlichung zu geben? Im Allgemeinen ist es ein Schmerz, aber der tatsächliche Arbeitsaufwand ist normalerweise nicht so groß. Natürlich müssten sie bestätigen, dass es nicht nur mehr Arbeit für sie ist (siehe das allererste, was ich sage), aber ich habe Orte gesehen, an denen diese Arbeit funktioniert.

• Gibt es hier eine bessere Möglichkeit, die Versionskontrolle zu verwenden? Etwas wie Mercurial (siehe http://hginit.com/ - lesen Sie es, es ist gut) oder ein anderes verteiltes Versionskontrollsystem verzweigt und verschmilzt auf andere Weise und ermöglicht es Ihnen möglicherweise, das Problem zu umgehen. Schauen Sie es sich wirklich an, denn ich denke, es könnte die Antwort auf Ihr Problem sein.

Aber viel Glück, es ist ein Schmerz. Denken Sie vor allem daran, dass der beste Weg in die Zukunft sehr stark von Ihrem Unternehmen, Ihrem Produkt und Ihrer Situation abhängt. Denken Sie also darüber nach und ziehen Sie nicht einfach etwas aus dem Regal und glauben Sie, dass Sie sich zu 100% daran halten müssen.

Wenn es sich bei den von Ihnen beschriebenen Fehlern um tatsächliche Fehler und nicht um Entwurfsoptimierungen handelt , sollten Sie diese unbedingt beheben, bevor Sie mit der Arbeit an neuen Funktionen beginnen.

Wenn Sie neue Funktionen auf bekannten Fehlern aufbauen, erstellen Sie ein Kartenhaus. Möglicherweise entwickeln Sie spröde, unvorhersehbare Software. Abhängig von der Isolationsstufe zwischen dem Buggy-Code und Ihren neuen Funktionen können sich die Fehler auch auf Ihre neuen Funktionen auswirken. Wenn ja, wie würden Sie wissen, ob Ihre neuen Funktionen ordnungsgemäß funktionieren?

Wenn Sie Ihre Fehler zuerst beheben, haben Sie eine stärkere Grundlage für alle neuen Funktionen, die Sie hinzufügen.

Sicherlich gibt es Zeiten, in denen externe Kräfte Sie unter Druck setzen, gegen Ihr besseres Urteilsvermögen vorzugehen. Versuchen Sie, Entscheidungsträgern zu helfen, eine fundierte Entscheidung zu treffen, bei der sie sich der Konsequenzen beider Vorgehensweisen bewusst sind (dh ungelöste Mängel im Vergleich zu versäumten Lieferterminen), und ermöglichen Sie ihnen, ihr Urteilsvermögen zu üben. Es gibt manchmal rechtliche und finanzielle Gründe, aus denen eine Vorgehensweise notwendig ist, obwohl sie nicht vorzuziehen ist.

Versuchen Sie immer, Fehler zu beheben, bevor Sie neue Funktionen hinzufügen!

Wo ich arbeite, behandeln wir dieses Szenario, in dem jede beabsichtigte Freigabe für die Produktion einen eigenen Zweig hat. Nehmen wir zum Beispiel an, dass es für eine Sekunde eine Veröffentlichung Ende Juni und eine weitere Ende Juli geben wird. Die Juni-Version würde eine eigene Niederlassung erhalten, und alle Funktionen würden dort hinzugefügt und an die Qualitätssicherung gesendet. An diesem Punkt würden wir mit der Arbeit an Julys Veröffentlichung beginnen und von der Juni-Niederlassung abzweigen. Wenn die Qualitätssicherung Fehler findet, beheben wir diese in der Juni-Filiale. Sobald die Korrekturen an die Qualitätssicherung gesendet wurden, werden sie in die Release-Filiale von Juli integriert. Dies erhöht zwar den Aufwand für diese Zusammenführungen, ist jedoch in der Regel recht schmerzlos. Hin und wieder ist es ein großer Schmerz, wenn Sie wissen, was, aber das tritt nur auf, wenn umfassende Änderungen vorgenommen werden, und diese sollten nicht während des QS-Zyklus auftreten (aber sie passieren, mehr als ich zugeben möchte). Mit einer guten Reihe von Tests (Einheit und Integration), Codeabdeckung und allen anderen TDD-Schlagworten werden die Risiken jedoch ein wenig gemindert. Um zu helfen, haben wir normalerweise eine Person, die Zusammenführungen für jedes Projekt verwaltet.