Hallo Florian, *, eine etwas längere Antwort...
Am Donnerstag, 8. Dezember 2011, 17:54:24 schrieb Florian Reisinger: > [Bugreport vereinfachen / wo Hürden?] > > 2 Hauptpunkte: > > -Sprache > -Bugzilla Hm. Ich persönlich würde ja an erster Stelle den Engpass bei so etwas wie einer "doppelten Fachkompetenz" sehen, nämlich zum einen der Kompetenz, das Problem, das man gefunden hat, präzise und verständlich/nachvollziehbar zu beschreiben, zum Anderen einer Art "QA-Kompetenz", also der Fähigkeit, den Fehler ein- und abzugrenzen und die Geduld und Zeit aufzubringen, ihn bis zur Lösung zu verfolgen/begleiten. Personen, die das beides können und dann auch noch tun, sind rar. Dagegen halte ich die Sprache selbst (wenn du damit die englische Sprache für den Bugzilla meinst) oder gar "den Bugzilla" (der ja nur das Verwaltungs- und Verfolgungstool für die zur Buglösung notwendige Infosammlung darstellt) für eher kleinere Hürden. Die Hürde "Sprache" ließe sich in meinen Augen (kurzfristig) am ehesten/besten durch ein bilinguales (de/en) QA-Team senken: Wenn nämlich von nur-deutsch- sprechenden Anwendern qualifizierte Problemberichte kommen bzw. kämen (wie viele könnten das pro Woche/Monat sein?), dann könnten/sollten diese von diesem Team in Kontakt zum Berichter nachgestellt und dann erst auf Englisch im Bugzilla erfasst werden. Dabei würde schon eine gewisse Triage stattfinden und damit wäre ein gewisses Qualitätsniveau von vornherein gesichert, auch könnte der Bug gleich bestätigt werden. Vielleicht würde das ein wenig helfen, ich glaube aber nicht, dass das Schreiben von Bugberichten zur Zeit der größte Engpass ist. Ok, aber die Idee im Hinterkopf zu behalten, schadet ja vielleicht nicht. Momentan sehe ich persönlich ein größeres Problem bei der Qualität neuer Releases. Diese sollten in meinen Augen "besser" und "schneller" getestet werden. D.h. der Engpass sind die "qualifizierten Frühtester", und vielleicht auch bessere Workflows zur Verteilung der Früherkennung. Die Entwickler haben das ja auch erkannt und mit der Beta0 eine längere Vor-Release-Testphase ermöglicht. Nur müssen die Tester diese Phase auch gut nutzen, und es muss vor allem auch mehr (qualifizierte) Tester geben. Hier ist also so etwas wie eine "effizientere (Selbst-) Organisation der Früh-QA" gefragt, oder, im Hinblick auf die Community formuliert, "eine attraktivere Früh-QA". "Attraktiv" bedeutet in meinen Augen übrigens vor allem "Fun & Quality", also hohes Qualitätsniveau verbunden mit guter Arbeitsatmosphäre. > Damals habe ich mithilfe Google Docs ein Testformular gemacht, als > Endergebnis sollte ich das mal in Silverstripe umsetzen. > > Soll ich das noch??? Gesichtspunkte: 1. Willst du deine Idee nicht erst mal "prototypisch testen"? Also die Fragen in Mailform (oder im Wiki) zur Verfügung stellen und jedem zusenden, der sich dafür interessiert? 2. Für die Bug-Erfassung selbst gibt es ja schon den von Christian erwähnten englischsprachigen Assistenten - da könnte man schauen, ob man den nicht mit geeigneten deutschsprachigen Erklärungen versehen und so die reine Sprachbarriere senken könnte. 3. Ich halte nach wie vor ein Team aus echten Menschen für am besten, um die Qualität der QA-Arbeit zu erhöhen. Wenn man gemeinsam an einer Sache arbeitet, sieht man die Schwachstellen bzw. Notwendigkeiten am deutlichsten, kann sie am schnellsten (improvisierend) ausgleichen und so die Anforderungen an verbesserte Prozesse oder Hilfstools am präzisesten formulieren. Ich würde also eher dazu raten, deine Energie für die Bildung eines deutschsprachigen/bilingualen QA-Teams (jetzt primär erst mal fürs Frühtesten) einzusetzen :-) Aber das ist nur [m]eine Meinung, du hattest ja gefragt. Gruß Nino -- Informationen zum Abmelden: E-Mail an discuss+h...@de.libreoffice.org Probleme? http://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: http://wiki.documentfoundation.org/Netiquette/de Listenarchiv: http://listarchives.libreoffice.org/de/discuss/ Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert