QA/Mitmachen
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Spende
Einstieg
Was ist QA?
QA steht für "Quality Assurance", zu deutsch Qualitätssicherung. QA identifiziert Probleme in unserer Software, bestätigt Probleme, die von Kunden gemeldet werden und überprüft vorgeschlagene Korrekturen und Erweiterungen, so dass jede neue Version verlässlicher und robuster ist und unsere Nutzer ein befriedigendes Tool bietet. Wir praktizieren QA auf verschiedenen Wegen während der ganzen Entwicklung einer neuen Version.
Unser erstes Ziel ist es, die nervigsten und dringendsten Fehler zu finden und zu bestätigen und sie an die Entwickler zu übergeben, damit sie sich darum kümmern. Dafür sind wir eine Brücke zwischen Nutzer und Entwickler und versuchen, jeden Fehlerbericht seiner ordentlichen Lösung zuzuführen mit dem Ziel einer überprüften Nutzererfahrung. Wir versuchen, Fehler zu reproduzieren, ihnen die richtige Priorität zuzuordnen, Dubletten zu finden, vorgeschlagene Korrekturen zu überprüfen usw.
Schnellstart Handbuch für Anfänger
Anfänger wollen sich nicht durch Berge von technischen Dokumentationen wühlen. Anfänger wollen sofort anfangen. Auf geht's.
- Lade die letzte stabile Version Version vom LibreOffice herunter und installiere sie (auf der leeren Wiese).
- Lade einen aktuellen master build von LibreOffice herunter und installiere ihn.
- Melde Dich bei The Document Foundation Bugzilla, dem Bug Tracker, an.
- Öffne diese Abfrage der unbestätigten Fehler des letzten Monats (Erweiterungsanforderungen sind mit Absicht ausgeblendet, einige andere Dinge ebenfalls).
- Picke Dir einen interessanten Fehler heraus.
- Suche nach Duplikaten.
- Wenn der Fehler kein Duplikat ist, aber eine konfuse Beschreibung hat oder wichtige Informationen fehlen, setze den Status auf NEEDINFO.
- Nach dem Versuch einer Reproduktion sowohl in der stabilen Version als auch im master build, setze entweder den Fehler auf NEW oder lasse ihn UNCONFIRMED.
Diese Schritte beschreiben eigentlich eine unvollständige Sichtung, weil Anfänger nicht überfordert werden sollen von den Myriaden Details, die in Betracht gezogen werden sollten für ein "perfektes" Sichtungsergebnis. Nachdem ein Anfänger sich mit dieser einfachen Routine auskennt, sollte er mit einer kompletteren Sichtung beginnen. Es wäre nicht sehr effizient, die vollständige Sichtung anderen zu überlasen.
Fahrplan zum persönlichen Wachstum in der QA
Jeder hat seinen seinen eigenen Weg zur QA. Einige sind eher motiviert von einem klaren Rahmen, was zu tun ist. Hier präsentiern wir einen Vorschlag für eine QA Karriere Entwicklung:
- Bearbeite die einfache Sichtung aus dem Schnellstart Handbuch für ~ 50 unbestätigte Fehler.
- Teste nochmal ~ 50 seit über einem Jahr unbearbeitete. mit einem täglichen Master Build von LibreOffice.
- Lerne dkie wichtigsten Schlüsselwörter und verwende sie: accessibility, bibisectRequest, dataLoss, filter:x, needUITest, perf, regression, text:x, wantBacktrace.
- installiere ein paar alte Versionen und mache zurückliegende Tests für 100 unbestätigte Fehler.
- lerne über Priorität und Schwere und erbitte Zugang zur Gruppe der Mitarbeiter von einem Bugzilla Admin.
- lerne, verschiedene Spuren zu erhalten und wende an, was Du über Berichte mit wantBacktrace oder perf keywords (ohne existierende angehängte Spuren) gelernt hast.
- Installiere ein anderes Betriebssystem auf einer virtuellen Maschine. Damit hast Du eine größere Bandbreite an Test und Untersuchen.
- Starte kritisch die Entwicklung von Erweiterungsanforderungen, die Du an das Design Team mit needsUXEval keyword weitergibst.
- Starte bibisecten. Bearbeite zuerst das tutorial und arbeite Dich durch die Berichten mit den bibisectRequest Schlüsselworten.
- Lerne Python und beginne mit UI Tests.
- Erstelle Python unit tests.
- Lerne C++ und erstelle cppunit Tests.
Bestätigung
finde bestätigte Berichte
- nach Betriebssystem:
- nach der Zeit:
Unbestätigte Berichte ohne Kommentare
Um die Sichtung der unbestätigten Berichte zu beschleunigen bezeichnen wir sie mit QA:needsComment auf der Tafel, wenn der Bericht diese Bedingungen erfüllt:
- Inaktiv seit mehr als 2 Wochen
- Keine Kommentare von einer dritten Person
Versuch, den Fehler zu reproduzieren
Da einige Fehler betriebssystemspezifisch sind, ist es immer eine gute Idee, gegen das selbe Betriebssystem zu testen. Aber wenn das nicht möglich ist, dann teste es auf Deinem aktuellen Betriebssystem. Die meisten Fehler sind nicht betriebssystemspezifisch.
Im folgenden findest Du Textbausteine für einige Szenarien. Für weitere Vorschläge, wie die Berichte und die Browser Tools zu formulieren sind um sie effizienter zu machen, siehe unsere vorformulierten Antworten.
- Wenn der Fehler reproduziert werden kann, dann setze den Fehler Status auf NEW und ergänze folgenden Kommentar:
Thank you for reporting the bug. I can confirm that the bug is present in [die LibreOffice Version mit der Du getestet hast (kann aus dem ▸ Dialog entnommen werden).]
- Wenn der Fehler nicht reproduziert werden kann, dann lasse den Status auf UNCONFIRMED und ergänze folgenden Kommentar:
Thank you for reporting the bug. I can not reproduce the bug in [die LibreOffice Version mit der Du getestet hast (kann aus dem ▸ Dialog entnommen werden).]
- Wenn der Fehlerbericht zu schwierig zu verstehen ist, dann setze den Fehlerstatus auf NEEDINFO und ergänze folgenden Kommentar:
Thank you for reporting the bug. Unfortunately without clear steps to reproduce it, we cannot track down the origin of the problem. Please provide a clearer set of step-by-step instructions on how to reproduce the problem. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested information is provided.
- Wenn ein Dokument benötigt wird, um den Fehler zu bestätigen, dann setze den Status auf NEEDINFO und ergänze folgenden Kommentar:
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Note that the attachment will be public, remove any sensitive information before attaching it. See <https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F> for further detail.)
weitere Schritte
- Wenn die Fehler Summary nicht klar genug ist, aktualisiere sie, so dass das angesprochene Hauptproblem besser erklärt und es leichter macht, Dubletten zu finden.
- Das Feld Component kann auch aktualisiert werden, um besser zu beschreiben, in welcher Komponente das Problem selbst liegt oder seinen Ursprung hat.
- Erweiterungsanforderungen, die neue Funktionen erfordern, müssen erst vom UX-Tem abgesegnet werden. Also ergänze hier einfach ‘needsUXEval’ zum Keywords Feld und setze libreoffice-ux-advise
lists.freedesktop.org auf CC.
- Erweiterungsanforderungen, die neue Funktionen erfordern, müssen erst vom UX-Tem abgesegnet werden. Also ergänze hier einfach ‘needsUXEval’ zum Keywords Feld und setze libreoffice-ux-advise
- Kontrolliere, ob der Fehler eine Verschlimmerung ist.
Folge der aktuellen Entwicklung der unbestätigten Fehler und beachte die detaillierten Fehlersichtungs Anweisungen für genauere Angaben.
teste tägliche builds
- Lade den letzten daily build herunter (mit dem aktuellen Datum)
- Installiere ihn
- Teste ihn. Lies die Release Notes, um zu sehen, was es hier Neues gibt.
- Wenn Du einen Fehler findest, berichte ihn bitte hier und gib alle verfügbaren Informationen dazu an (Schritte zur Reproduktion, das betroffene Dokument, genaue Beschreibung, Betriebssystem,...)
Hinweis: Für Hilfe tritt bitte #libreoffice-qa IRC:// bei.
teste Vorabversionen
- Lade die letzte Vorab-Version herunter
- Installiere sie
- Teste sie. Lies die Release Notes, um zu sehen, was es hier Neues gibt.
- Wenn Du einen Fehler findest, berichte ihn bitte an hier und gib alle verfügbaren Informationen dazu an (Schritte zur Reproduktion, das betroffene Dokument, genaue Beschreibung, Betriebssystem,...)
Hinweis: Für Hilfe tritt bitte #libreoffice-qa IRC:// bei.
Teste nochmal
Jeden Tag stupsen wir unbearbeitete Fehler für über ein Jahr an, um festzustellen, ob sie mitlerweile korrigiert wurden. Mehr Informationen finden sich im Artikel zu automatisierten Aufgaben.
Fehler zum erneuten Test
- heute angestupste Fehler:
- Fehler aus der letzten Woche:
- Fehler aus dem letzten Monat:
- Fehler aus den letzten drei Monaten:
- Fehler aus dem letzten halben Jahr:
Versuch, den Fehler zu reproduzieren
Wenn der Fehler in der aktuellen Version von LibreOffice immer noch existiert, ergänze den folgenden Kommentar mit der LibreOffice Version, gegen die Du getestet hast (kann aus dem ▸ Dialog entnommen werden).
This bug is still present in [Die LibreOffice Version, gegen die Du getestet hast (kann aus dem ▸ Dialog entnommen werden).]
Wenn Du den Fehler in einer früheren Version reproduzieren kannst, aber in der aktuellen Version nicht mehr vorhanden ist, ändere den Status auf RESOLVED WORKSFORME und ergänze den folgenden Kommentar:
This bug is no longer reproducible in [die LibreOffice Version mit der Du getestet hast (kann aus dem ▸ Dialog entnommen werden).] Changing status to RESOLVED WORKSFORME
Bitte niemals...
- ... das Versionsfeld aktualisieren
- ... über eMail antworten. Stattdessen immer im Bug Tracker antworten.
- ... das Statusfeld auf RESOLVED - FIXED ändern, weil dieser Status nur verwendet wird, wenn ein spezielles Verfahren das Problem gelöst hat.
weitere Schritte
- Kontrolliere, ob der Fehler eine Verschlimmerung ist.
Kontakt
Jede Hilfe ist höchst willkommen. Du kannst jederzeit in Verbindung treten
- über IRC #libreoffice-qa IRC://
- über die QA Mailing Lliste