Re: [de-discuss] QA verbessern/Hürden senken (war: Bugreport per E-Mail)

Hallo Nino!

Die Antworten werden kürzer als die Fragen....

Am 10.12.2011 12:01, schrieb Nino Novak:
> 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.

+1

> 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.

Wenn ein "Anwender" einen Fehler findet, wird er zu 99,9875% (ihr wisst, 
was ich meine...) sich _nicht_ wo anmelden oder sich an etwas 
kompliziertes gewöhnen...

> 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?)

Schätze 3-5 pro Monat... hoffe aber auf mehr...

> , 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.

genau mein Gedanke +1
> 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".

Ein weiteres, getrennt zu betrachtendes Problem, weil
a) Das "mutige" (erfahrenere...) Anwender sind, die die beta0 herunterladen
b) Stabile Versionen von vielen benutzt werden, die sich mit Bugtracking 
bzw. Englisch sich nicht zu 100% auskennen
> "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?

DAS war GoogleDocs
> 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.

Da muss man aber einen Bugzilla Account haben, was die aktuelle Lösung 
aber nicht verlangt
> 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.
+1
>   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 :-)

Was aber schwer (zu schwer??) zu machen ist, weil die

a) Mitglieder brauchen, die sowohl Englisch als auch Deutsch als 
Muttersprache haben (und die andere Sprache jeweils [sehr] gut verstehen.
b) Eine eigene ML ( en_de@global.libreoffice.org ) brauchen
> Aber das ist nur [m]eine Meinung, du hattest ja gefragt.

Die auch sofort kommentiert wurde:
Screenshot des jetzigen Standes der Bugseite:
https://de.libreoffice.org/hilfe-kontakt/bug-melden/?stage=Stage
Screenshot:
http://www.webpagescreenshot.info/img/311903-1210201123155PM


> Gruß Nino


--
Tschüss!

LibO 3.4.4
Windows 7 SP1 64-bit


--
Informationen zum Abmelden: E-Mail an discuss+help@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