Qualitätssicherung

Diese Seite erklärt, wie man sowohl als offizielles Mitglied als auch als neuer Mitarbeiter im UBports QA-Team hilft. Bitte für ein besseres Verständnis der Arbeitsweise auch die Anleitungen Problemverfolgung und Fehler melden lesen.

Rauchtest

Um die Kernfunktionalität des Betriebssystems zu testen, haben wir eine Liste standardisierter Tests. Führe diese Tests auf Deinem Gerät aus, um Bugs und Rückfälle zu finden und zu melden. Normalerweise werden sie vor einem neuen Release auf allen Geräten durchgeführt, um sicherzustellen, dass keine neuen Probleme dazugekommen sind.

Fehlerberichte bestätigen

Unconfirmed bugreports are labeled needs confirmation to enable global filtering. Browse through the list, read the bugreports and try to reproduce the issues that are described. If necessary, add missing information or logs, or improve the quality of the report by other means. Leave a comment stating your device, channel, build number and whether or not you were able to reproduce the issue.

Wenn Sie Schreibzugriff auf das Repository haben, können Sie das Label needs confirmation durch bug (um es als bestätigt zu markieren) oder invalid ersetzen (wenn das Problem definitiv nicht reproduzierbar ist). In diesem Fall sollte es geschlossen werden.

Falls man auf zwei Fehlerberichte stößt, die das selbe Problem beschreiben, hinterlässt man einen Kommentar und versucht die Unterschiede zu ermitteln. Sind beide faktisch identisch, schließt man den neueren und markiert ihn als duplicate.

Korrekturen testen

Pull-Requests können mit den QA-Skripten getestet werden. Führen Sie ubports-qa -h für Nutzungsinformationen aus.

Sobald ein Entwickler die Arbeit an einem Problem beendet hat, wird es in die Qualitätssicherungsspalte des GitHub-Projekts verschoben. Nun prüft man, ob das Problem im neuesten Stand des Entwicklungskanals gelöst ist und versucht weitere Probleme zu erkennen, die möglicherweise in Folge auftreten. Es ist darauf zu achten, ob der Entwickler bestimmte Dinge benannt hat, auf die während der Tests zu achten ist und dass man einen detaillierten Kommentar mit den eigenen Erfahrungen hinterlässt. Hat man Schreibrechte in dem Repository, kann der Fehlerbericht zurück in In Development oder weiter zu Release Candidate verschoben werden, entsprechend der Anleitungen zur Problemverfolgung.

Initiale Sichtung von Fehlerberichten

Die initiale Sichtung von Fehlerberichten erfolgt durch QA-Teammitglieder mit Schreibrechten im Repository. Falls ein neuer Fehlerbericht eingeht, liest man diesen und fügt die korrekten Markierungen entsprechend der Anleitungen zur Problemverfolgung. Der Fehlerbericht kann gegebenenfalls auch direkt bestätigt werden.

Wurde das Problem bereits gemeldet, markiert man es als duplicate und schließt es.