Kontinuierliche Integration und QA

Sich ein ständig bewegendes Ziel zu geben, ist wirklich schwierig. Wir tendieren dazu, Fixes zu verteilen, bevor wir sie für die QA bereitstellen - normalerweise für eine tägliche QA-Bereitstellung. QA nimmt die Ausgabe von dem Build über Nacht als erstes am Morgen und "wie benötigt", wenn ein wirklich kritischer Fehler eine Menge Tests blockiert.

CI ist mehr ein grundlegender Codequalitätsbenchmark (z. B. baut es auf, es besteht Unit- / Rauchtests) - habe nicht das Gefühl, dass die QA alle Builds aus CI herausnehmen muss.

Zu Beginn der Testzyklen neige ich dazu, nur neue Builds zu erstellen, wenn blockierte Fehler behoben werden. Dadurch kann mein Team den Thrash vermeiden, der durch neue Builds und überraschende Regressionen verursacht wird. Der frühe Teil einer Veröffentlichung wird häufig damit verbracht, zu verstehen, wie die Funktionalität tatsächlich implementiert wurde und ob das Produkt ein Mindestmaß an Akzeptanzkriterien erfüllt.

In der Mitte eines Testzyklus akzeptiere ich Builds öfter, um sicherzustellen, dass Fixes so viel wie möglich verfügbar sind und um nicht korrekt behobene Fehler so schnell wie möglich zu identifizieren. Dies ist normalerweise täglich außer in Umgebungen, in denen wir langfristige Stress- oder Leistungstests durchführen.

Wenn sich die Veröffentlichung nähert und ich mehr Kontrolle darüber habe, welche Bugs behoben sind (dh die aktuelle Version ist verzweigt und wir haben eine strengere Codezeilen-Richtlinie), werde ich Builds nur dann weiter machen, wenn wir Release-Blocking-Bugs finden. Zu dieser Zeit werden Builds oft als Beta oder Release-Kandidaten bezeichnet.

  

Wenn ich richtig verstanden habe, fragen Sie nach der Dauer des QA-Zyklus in einem Projekt mit einem kontinuierlichen Integrationszyklus?

Wir verwenden einen täglichen QA-Zyklus . Der Nachtaufbau ist, wenn er erfolgreich war, am nächsten Tag zum Testen verfügbar.

Fehler, die während CI-Builds gefunden werden, müssen von Entwickler-Teams behoben werden, sobald sie gefangen werden. Während QA-Teams die regulären Builds während ihrer regulären Release-Zyklen oder Patch-Zyklen erhalten, nicht durch CI-Build-Probleme.

Da der CI-Build-Autotest viele QA- und Nicht-QA-bezogene Bugs erfasst hat, führt dies direkt zu einer starken Leistungsbelastung anderer QA-Aktivitäten.

Alles hängt von den QA-Richtlinien der Firma ab, einige mögen oder einige stimmen mit meinem Punkt nicht überein :)

nitzmahones Antwort ist ein guter Ratschlag, um die häufigeren Builds, die Sie von einem CI-System erhalten, auszugleichen, da die QA ein bekanntes Testziel haben muss.

Sie können die kontinuierliche Integration nutzen, um zusätzliche Tests zusätzlich zu den Unit- / Rauchtests zu erhalten, die als Teil jedes Builds ausgeführt werden. Hier sind ein paar Dinge, die ich getan habe:

• Richten Sie einen Job in Ihrem CI-System ein, der einen geplanten Job ausführt (z. B. täglich, statt durch Quellcodeänderungen ausgelöst zu werden), um einen Leistungstest auf Ihrem System durchzuführen und die Ergebnisse zu protokollieren. Auf diese Weise können Sie die Leistung im Zeitverlauf verfolgen und Änderungen erkennen, die sich negativ auf die Leistung auswirken.
• Lassen Sie Ihren CI-Build-Job Ihr System automatisch bereitstellen, wenn die Build- und Unit-Tests erfolgreich sind, und lassen Sie einen IT-Monitor wie Nagios überprüfen bereitgestelltes System. Dies dient als schneller und schmutziger Systemtest, der häufig Fehler findet, die nicht durch die Komponententests abgefangen werden. Ich habe einen Blogbeitrag geschrieben, den Sie möglicherweise nützlich finden bin an dieser Art von Test interessiert.

  

Werden diese Korrekturen sofort nach dem Integrationstest in die QA-Umgebung implementiert oder werden sie bis zum Abschluss des aktuellen Testzyklus akkumuliert.

Es kommt darauf an. Wenn ein Problem blockiert ist und Tester nicht mehr Tests ausführen dürfen, um einen ganzen Testplan zu beenden (d. H. Um ihre Aufgabe zu erledigen), ist es offensichtlich erforderlich, den Fix sofort zu veröffentlichen. Wenn es sich bei einem Problem nicht um ein blockierendes Problem handelt, empfiehlt es sich möglicherweise, das Fix in die Warteschlange zu stellen und es in der nächsten Version verfügbar zu machen. Dies erfordert jedoch viel Verwaltungsaufwand (Protokollierung des Problems, Kommentierung des Testfalls usw.).

Wenn QA nun sehr früh während der Entwicklung auftritt (dh wenn Sie nicht einen sehr sequentiellen Entwicklungszyklus verwenden), wenn Tester eng mit Entwicklern zusammenarbeiten, dann kann es gut sein, ein Problem zu beheben, sobald es entdeckt wurde um sogar ein Inventar von Fehlern zu vermeiden (große Verschwendung).

Es hängt vom Projektentwicklungsstil ab. Angenommen, Sie sind ein agiles Team.

• Es gibt zwei Teststufen: Testen während Iteration und Iteration
• Der Zweck von CI besteht darin, Fehler während der Iteration zu finden und zu beheben. Die Art des Tests konzentriert sich auf Einheit, Funktion und Umsetzung von Stories
• Die Bugs, die Sie in solchen agilen Teams finden, sollten vor der Veröffentlichung in der QA-Umgebung behoben werden
• Die QA-Umgebung sollte zur Durchführung von Regressions- und Integrationstests verwendet werden. Der Zweck solcher Tests sollte eher die Suche nach Regression und Integration sein, als die Funktionalität von Features

Oben ist allgemeiner Ansatz., Off-Kurs, es hängt stark von der Natur Ihrer Software und Ihres Teams ab