Was es ist
Eine Zeile pro Build (1.0.0, 1.1.0, 1.1.1-hotfix). Erfasst Version, Veröffentlichungsdatum, Changelog, bekannte Bugs, QA-Status (ausstehend / in Arbeit / bestanden / fehlgeschlagen / übersprungen) und Zielplattformen.
Wann du es nutzen solltest
- Den Build protokollieren, der letzten Freitag an QA ging, damit das Team weiß, dass er existiert.
- Verfolgen, welche Builds die Zertifizierung nicht bestanden haben und warum.
- Eine „aktueller Build“-Referenz für Playtest-Sitzungen anpinnen.
- Bekannte Bugs festhalten, die in einem Hotfix ausgeliefert werden, weil die Alternative schlimmer war.
Wie du es nutzt
- 1Auf „+ Neuer Build“ klicken — Version, Name, Zielplattformen.
- 2Den Changelog schreiben (oder aus den Release Notes deiner Engine einfügen).
- 3Den QA-Status mit dem Testfortschritt aktualisieren.
- 4Bekannte Bugs notieren, die das Release überleben.
Tipps, die du kennen solltest
- →Build-Tracker ist die QA-seitige Ansicht; Build Log ist der nutzerseitige Changelog. Sie sind absichtlich getrennt.
- →Das Plattformfeld ist eine Mehrfachauswahl — ein Build mit Ziel „PC + Mac“ erscheint in beiden Filtern.
- →Der QA-Statusablauf ist einseitig (ausstehend → bestanden/fehlgeschlagen) — durch Anlegen eines neuen Build-Eintrags erneut testen.
- →Risiken zu Builds querverlinken — „dieser Build mindert Risiko X“ ist ein Audit-Trail, der sich lohnt.