Menü

Was der QS-Tester über den Release- und Deployment-Management-Prozess wissen sollte

  • Haupt
  • Konzepte Testen
  • Was der QS-Tester über den Release- und Deployment-Management-Prozess wissen sollte

what qa tester should know about release

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

In unserer heutigen Teambesprechung hat der Manager mit allen nachgefragt Bereitschaft zur Testdurchführung . Er erwähnte, dass der Code bis morgen früh für die Qualitätssicherung bereit sein wird. Was meinte er, als er sagte 'Code wird fertig sein', bedeutet das, dass die Entwickler den Code heute Abend in einer QS-Umgebung schreiben werden?

bester Musik-Downloader für Android-Handys

Er meinte eigentlich, dass die Bereitstellung nachts erfolgen soll und der neue Code zum Testen in der QS-Umgebung bereitgestellt wird.

Viele von Ihnen fragen sich jetzt vielleicht, was Bereitstellung ist und was sie wirklich darin tun.

Release- und Deployment-Management-Prozess für qa

Was du lernen wirst:

Gesamtprozess und Bedeutung des Release- und Deployment-Managements für das QS-Team

  • Warum pflegen wir wirklich unterschiedliche Umgebungen?
  • Wie wird der Code von einer Umgebung in eine andere migriert?

Ich werde die folgenden Themen in diesem Artikel behandeln

  1. Warum ist es für Tester wichtig, den Release- und Bereitstellungsprozess zu kennen?
  2. Unterschiedliche Umgebungen
  3. Was meinen Sie mit Build and Deployment?
  4. Geplante oder Notfallbereitstellung
  5. QA-Checkliste - Vor und nach der Bereitstellung

# 1. Warum ist es für Tester wichtig, den Bereitstellungsprozess zu kennen?

Unsere Hauptaufgabe bei der Testausführung hängt davon ab, wie erfolgreich die Bereitstellung war. Wenn das Bereitstellungsteam vor Herausforderungen stand und auf mehrere Probleme stieß und den Code nicht ordnungsgemäß bereitstellen konnte, weist dies sicher darauf hin, dass das QA-Team viele Fehler identifizieren wird, die möglicherweise mit der Umgebung oder dem Bereitstellungsprozess zusammenhängen.

  • Wenn Tester über den Bereitstellungsprozess informiert sind, wissen sie, wie wichtig es ist, ihre Aufgaben innerhalb des geplanten Zeitrahmens zu erledigen.
  • Tester erhalten eine Vorstellung davon, ob es sich bei dem Problem tatsächlich um einen Funktionsfehler handelt oder um etwas, das während der Bereitstellung verursacht wurde. Ein Tester ist zum Testen der Berichtsfunktion beauftragt. Wenn er jedoch versucht, sich auf der Website anzumelden, wird ein Fehler angezeigt, der bedeutet, dass die Umgebung nicht funktioniert Solche Probleme können nicht als funktionale Probleme, sondern als Umweltprobleme betrachtet werden. Wenn dem Tester die Bereitstellung bekannt ist, kann er das Problem als Bereitstellungsproblem bezeichnen.
  • Viele Nicht-Probleme könnten vermieden werden, wenn die Tester die Liste, die bereitgestellt wurde, wirklich kennen. Manchmal kommt es vor, dass Sie ein Problem für Bereiche testen und melden, die noch nie bereitgestellt wurden.

# 2. Unterschiedliche Umgebungen

Unterschiedliche Umgebungen

In der obigen Klassifizierung habe ich die 4 wichtigsten Umgebungen behandelt, denen die meisten Organisationen folgen. Viele Clients unterhalten jedoch viel mehr Umgebungen wie Staging, Pre-Staging usw. Außerdem kann die Namenskonvention abweichen.

  • DEV - Die Entwicklungsumgebung wird vom Entwicklungsteam zum Schreiben des Codes erstellt und verwaltet. Der Zugriff für diese Umgebung wird nur dem Entwicklungsteam gewährt. Normalerweise hat das QA-Team keinen Zugriff auf diese Umgebung. Diese Umgebung wird hauptsächlich vom Entwicklerteam für Unit-Tests verwendet.
  • QA - In der QS-Umgebung finden die Tests tatsächlich statt. Diese Umgebung gehört dem QS-Team. Das DEV-Team hat keinen Zugriff auf diese Umgebung. Nach Abschluss des Entwurfs und der Codierung wird der Code in die QS-Umgebung verschoben, damit das QA-Team die Testausführung durchführen kann.
  • UAT - Benutzerakzeptanztest ist eine Umgebung, in der die Tests von den Geschäftsbenutzern durchgeführt werden. Dies erfolgt nach Abschluss des Systemtests. Die Hauptabsicht besteht darin, das System aus geschäftlicher Sicht zu testen. Der Zugriff auf diese Umgebung wird nur den Geschäftsbenutzern gewährt. In einigen Fällen suchen sie jedoch Unterstützung bei der Qualitätssicherung. Unter diesen Umständen erhält das QS-Team vorübergehend Zugang zur Umgebung.
  • PROD - Die PROD-Umgebung ist die tatsächliche Live-Umgebung, die den realen Benutzern ausgesetzt ist, und keines der DEV- und QA-Teams hat Lese- / Schreibzugriff auf diese Umgebung. Prod-Support-Teams werden unterhalten, um Probleme im Zusammenhang mit der Produktionsumgebung zu lösen.

Lesen Sie auch=> So bereiten Sie „Prüfstand“ effektiv vor und minimieren die Fehler in der Testumgebung

#3. Was meinen Sie mit Build and Deployment?

Ein Build enthält hauptsächlich das kompilierte Paket, das die ausführbare Datei bat, exe, die Bibliotheken wie dll, lib und Archive wie zip-Dateien enthalten kann. Das Entwicklungsteam erstellt den Build und stellt ihn dem Bereitstellungsteam zur Installation zur Verfügung.

Die Kompilierung des Quellcodes wird hauptsächlich vom Entwicklungsteam durchgeführt. Nachdem der Build generiert wurde, platzieren sie ihn an einem bestimmten Ort, auf den das Bereitstellungsteam für die Bereitstellung in einer anderen Umgebung zugreifen kann.

Sobald der Build bereitgestellt ist, wird das QA-Team darüber informiert Verifikationstests erstellen (BVT) und wenn es erfolgreich ist, führt das Team den Rest der Funktionsprüfung .

In einigen Organisationen, in denen kein separates Bereitstellungsteam vorhanden ist, stellt das Entwicklungsteam den Build für die Qualitätssicherung bereit, und das QS-Team schließt die Bereitstellung selbst ab. In solchen Fällen besteht ein großes Risiko. QS-Ressourcen sollten technisch einwandfrei sein, um den gesamten Build-Bereitstellungsprozess zu verstehen, und sie sollten auch wissen, wie sie bei Auftreten eines Problems Abhilfe schaffen können.

Builds werden mit Zahlen wie 1.0.01 oder 1.0.03 verwaltet. Daher ist es möglich, dass in Build 1.0.01 die DLL v0.2 und in Build 1.0.03 die DLL v0.5 ausgeführt wird. Für das QA-Team ist es wichtig sicherzustellen, dass der richtige Build in der Umgebung bereitgestellt wird, bevor die Tests beginnen. Es ist immer eine gute Idee, die Änderungen zu verfolgen, die als Teil jedes Builds bereitgestellt werden.

Die Pflege eines separaten Bereitstellungsteams ist immer eine gute Vorgehensweise, da dies zum reibungslosen Verschieben von Code von einer Umgebung in eine andere beiträgt.

Die Bereitstellung ist ein Prozess, durch den der Code / Build von einer Umgebung in eine andere verschoben wird. Der Großteil der Organisation folgt heutzutage einem geeigneten Kanal für die Bereitstellung und unterhält ein separates Team, das sich um all dies kümmert.

Erstellen und Bereitstellen

Vor dem Tag der Bereitstellung trifft sich ein Team aus Entwickler, Entwicklungsmanager, Bereitstellungstechniker, Testleiter und anderen Geschäftsinteressenten. In der Besprechung wird der Entwickler normalerweise gebeten, seine Änderung zu beschreiben. Normalerweise müssen sie ein bestimmtes Formular mit Details zu den Änderungen und dem Rollback-Plan ausfüllen.

Falls einige Details fehlen, werden die Änderungen nicht für die Bereitstellung genehmigt. Das Team entscheidet dann, ob die Änderung Teil der Bereitstellung am nächsten Tag sein kann. Der QS-Testleiter wird um Genehmigung gebeten, um sicherzustellen, dass sich Änderungen nicht auf die vorhandenen Tests auswirken. In der Besprechung werden die endgültigen Bereitstellungselemente geplant.

Die genehmigte Liste wird am Bereitstellungstag vom Bereitstellungsteam bearbeitet. Das Team führt eine Reihe von Programmen aus, die in den einzelnen Änderungsformularen (von Entwicklern bereitgestellt) definiert sind, und sendet die Kommunikation nach Abschluss der Bereitstellung.

Die Meldung 'Bereitstellung abgeschlossen' gibt dem QA-Team einen Hinweis darauf, dass die Änderungen / der neue Code zum Testen bereit sind.

Es liegt in der Verantwortung des Bereitstellungsteams, die Änderungen von DEV auf QA zu verschieben. Nach Abschluss des QS-Tests wird der Code in UAT verschoben. Das Verschieben von PROD-Daten ist der wichtigste Teil und muss außerhalb der Geschäftszeiten erfolgen, da während der Bereitstellung die Umgebung heruntergefahren werden muss und dies mit größter Sorgfalt erfolgen muss, da dies schwerwiegende Auswirkungen auf das Geschäft haben kann.

Die meisten Prod-Bereitstellungen werden spät in der Nacht durchgeführt, wenn die Wahrscheinlichkeit geringer ist, dass Endbenutzer die Umgebung beeinträchtigen.

# 4. Geplante oder Notfallbereitstellung

Jede Organisation unterhält einen Bereitstellungskalender. Viele Kunden folgen einer wöchentlichen Bereitstellung, und viele entscheiden sich für eine zweiwöchentliche Bereitstellung. Die geplante Bereitstellung sollte nur dienstags oder dienstags und freitags erfolgen. Die Bereitstellungstage können sich ändern, wenn der geplante Bereitstellungstag auf einen Feiertag fällt.

Im obigen Abschnitt habe ich den Prozess behandelt, der für jeden befolgt wird geplanter Einsatz .

Die geplanten Bereitstellungen können ihre eigene Herausforderung haben. Stellen Sie sich einen Fall vor, in dem neuer Code in der QS-Umgebung bereitgestellt wird und das Team während des Sanity-Tests einen Blocker-Defekt feststellt und der Test abgebrochen werden muss. Wartet das Testteam eine Woche bis zur nächsten Bereitstellung?

Um solche Situationen zu bewältigen, werden Notfallkorrekturen und Bereitstellungen durchgeführt, bei denen das Bereitstellungsteam nicht bis zum geplanten Bereitstellungstag warten muss. Sie müssen die Genehmigung auch für Notfallbereitstellungen befolgen und einholen. Diese Genehmigungen erfolgen jedoch normalerweise schnell, und die neuen Änderungen können am selben Tag oder so bald wie möglich in der QS-Umgebung bereitgestellt werden.

# 5. QA-Checkliste - Vor und nach der Bereitstellung

Vor der Bereitstellung -

Das ganze Testdesignphase findet statt, bevor der Code tatsächlich in die Umgebung verschoben wird. Die Testausführung hängt von der Verfügbarkeit des Codes in der QS-Umgebung ab. Während das Bereitstellungsteam daran arbeitet, den Code in der Qualitätssicherung bereitzustellen, sollte das QA-Team sicherstellen, dass die folgenden Aktivitäten abgeschlossen sind.

  • Stellen Sie sicher, dass die Testfälle überprüft und genehmigt werden
  • Stellen Sie sicher, dass das Testteam verfügbar ist und die Ressourcenplanung abgeschlossen ist
  • Sicherstellen, dass die Testdatenbedarf werden identifiziert

Nach der Bereitstellung -

Nach dem Einsatz beginnen wir als QS-Team als erstes mit unserem Sanity-Test. Bevor wir jedoch mit unserem Gesundheitstest beginnen, sollten wir sicherstellen, dass Folgendes beachtet wurde:

  • Das QA-Team sollte vom Bereitstellungsteam eine Benachrichtigung über die erfolgreiche Bereitstellung erhalten und für die QA bereit sein.
  • Das QA-Team sollte den bereitgestellten Build verfolgen.
  • Stellen Sie sicher, dass das QA-Team die Liste der erfolgreich bereitgestellten Änderungen sowie der nicht bereitgestellten Elemente hat, selbst wenn diese geplant waren. Es kann vorkommen, dass das Bereitstellungsteam aufgrund fehlender Details usw. nicht bereitgestellt werden konnte.

Fazit

Ich hoffe, der obige Artikel hat Ihnen eine Vorstellung vom gesamten Release- und Deployment-Management-Prozess gegeben, der als Teil des gesamten Softwareentwicklungszyklus durchgeführt wurde. Dies war nur ein allgemeines Verfahren, das in den meisten Organisationen angewendet wurde, jedoch haben viele Kunden unterschiedliche Protokolle.

Autor : Dieser großartige Artikel wurde von STH-Teammitglied Priya R. geschrieben.

Fanden Sie diesen Prozess hilfreich? Teilen Sie uns den Bereitstellungsprozess mit, den Sie in Ihrer Organisation verfolgen.

Literatur-Empfehlungen

^