Management-Zusammenfassung dieses Beitrags:
Die Begriffe Alpha, Beta und Release Candidate werden im Software-Releaseprozess verwendet, um das Entwicklungsstadium einer Softwarekomponente zu kennzeichnen.
In diesem Beitrag werden diese drei Begriffe vorgestellt und in den (übergeordneten) Softwareentwicklungsprozess eingeordnet.
Um das Entwicklungsstadium eines Softwaresystems oder einer Softwarekomponente zu charakterisieren, werden häufig die Begriffe Alpha, Beta und Release Candidate verwendet. Jedoch sollten diese in einem konkreten Projekt oder in einem Vorgehensmodell vorab beschrieben werden, um Unklarheiten bei den Beteiligten zu vermeiden.
Kurzcharakterisierung der drei Entwicklungsstadien:
- Alpha-Release: Die erste Stufe der internen Freigabe einer Software: Es können (viele) → Fehler enthalten sein. Dient zum Vortest durch interne Mitarbeiter
- Beta-Release: Die zweite Stufe der internen Freigabe einer Software: Es können Fehler enthalten sein. Dient zum Vortest durch interne Mitarbeiter und ggf. ausgewählte Kundenvertreter
- Release Candidate (Abkürzung: RC, deutsch auch: Freigabekandidat): Eine Release-Candidate-Version sollte durch den Kunden getestet werden, sodass ein → Abnahmetest erfolgen kann
In Abbildung 0.1 ist die zeitliche Abfolge der drei Entwicklungsstadien dargestellt.
Abbildung 0.1: Alpha‑, Beta- und Release-Candidate-Versionen in der zeitlichen Abfolge
1. Die zeitlichen Abstände der Entwicklungsstadien
Die Abstände zwischen den einzelnen Versionen können je nach Projekt und Organisation stark unterschiedlich sein. In Abbildung 1.1 ist eine typische 6–8‑Wochentaktung dargestellt, es ergibt sich eine Gesamtdauer von 18 bis 24 vom ersten Alpha- bis zum endgültigen Release.
Abbildung 1.1: Alpha‑, Beta- und Release-Candidate-Versionen in der zeitlichen Abfolge mit Zeitabständen
Eine typische Zeitleiste ist in Abbildung 1.2 dargestellt. Es werden neben den 3 Entwicklungsstadien (Alpha1, Beta1, RC1) auch Entwicklungsschritte verwendet; diese heißen entsprechend Alpha2, Alpha3, Beta2, Beta3, RC2 und RC3. Weitere Entwicklungsschritte können hinzugenommen werden.
Abbildung 1.2: Alpha‑, Beta- und Release-Candidate-Versionen als Zeitleiste
Wenn man die Entwicklungsstadien einsetzt, ergeben sich daraus lange Durchlaufzeiten, da jedes Entwicklungsstadium eine Minimaldauer hat.
Wichtig bei dieser Vorgehensweise ist, dass es keine Rücksprünge gibt. Ist eine Software als Beta-Version freigegeben, so kann sie nicht wieder als Alpha-Version zurückgestuft werden.
2. Die Entwicklungsstadien und das Testen
Die Entwicklungsstadien definieren auch Testarten. Je nach Art des betrachteten Systems kann es dann unterschiedliche Testarten geben. In diesem Kapitel wird der Alpha- und Beta-Test nach → ISTQB und ein Vorgehen mit den vier → Teststufen gegenübergestellt.
2.1 Alpha- und Beta-Test nach ISTQB
Das ISTQB definiert die Begriffe Alpha-Test und Beta-Test wie folgt /ISTQB-→ Glossar/:
“Alpha-Test: Eine Art Abnahmetest, der in der Testumgebung des Herstellers durch Akteure außerhalb der Herstellerorganisation durchgeführt wird.“
und
“Beta-Test: Eine Art Abnahmetest, der an einem zur Testumgebung des Entwicklers externen Standort durch Akteure außerhalb der Herstellerorganisation durchgeführt wird.”
Somit ergibt sich eine Abfolge von Tests, die in Abbildung 2.1 dargestellt ist.
Abbildung 2.1: Alpha‑, Beta- und Release-Candidate-Versionen mit Alpha- und Beta-Test
Dieses Vorgehen mit Alpha- und Beta-Tests als vorgezogene Abnahmetests findet sich bei WordPress /#WordPress-Release-Cycle/: Bei jeder neuen Hauptversion (Major Version) werden Alpha- und Beta-Tests von Testern “im Feld” durchgeführt.
2.2 Die vier Teststufen und die Entwicklungsstadien
Es ist nicht immer sinnvoll oder machbar, die Alpha- und Beta-Versionen zu einem Abnahmetest (durch den Kunden) heranzuziehen. In Abbildung 2.2 sind beispielsweise die vier Teststufen (vom Komponenten bis zum Abnahmetest) in das Alpha‑, Beta- und Release-Schema untergebracht. Der Dry Run (Trockenlauf) ist ein — meist 24-stündiger — → Zeitraum, an dem keinerlei Code-Veränderung mehr stattfinden darf, auch nicht zur Fehlerbehebung.
Abbildung 2.2: Alpha‑, Beta- und Release-Candidate-Versionen in der zeitlichen Abfolge mit Zusatzaufgaben
3. Zusammenfassung und Anmerkungen
Abbildung 3.1 zeigt eine Beschreibung der drei Begriffe / Entwicklungsstadien und des Releases in einer Übersicht.
Abbildung 3.1: Alpha‑, Beta- und Release-Candidate-Versionen in der Übersicht
Anmerkungen:
- Die hier vorgestellte Vorgehensweise mit Alpha‑, Beta- und RC-Versionen findet in der Regel nur in großen Projekten Anwendung. Bei mittleren oder kleineren Projekten sollte jedoch am prinzipiellen Vorgehen festgehalten werden, wobei die Anzahl der Entwicklungsstufen reduziert werden kann
- Bei agilem Vorgehen gibt es generell auch eine Release-Planung: Ein Release setzt sich aus mehreren Sprints zusammen, auf Alpha‑, Beta- und RC-Versionen kann häufig verzichtet werden. Hierbei sollte beachtet werden, dass die letzten Sprints vor dem eigentlichen Release nicht zu viele “gravierende” Änderungen verursachen
A. Präsentationen, Literatur und Weblinks
A.1 Meine öffentliche Präsentation
- -
A.2 Literatur
- /Ludewig23/ Jochen Ludewig, Horst Lichter: → Software Engineering. Grundlagen, Menschen, Prozesse, Techniken, dpunkt, Heidelberg 4. Auflage 2022, ISBN 978–3‑86490–598‑8
A.3 Weblinks
Folgende Weblinks werden in diesem Beitrag zitiert:
- /ISTQB-Glossar/ Das Glossar zum Softwaretest des ISTQB (Online; deutsch, andere Sprachen)
- /#Wiki-Entwicklungsstadium/ Entwicklungsstadium (Software) in der deutschen Wikipedia
- /#WordPress-Release-Cycle/ WordPress Release Cycle
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 04.07.2023 © Peterjohann Consulting, 2005–2024
