Hallo zusammen, hallo André,
On Jun 22, 2009, at 8:32 PM, André Schnabel wrote:
Herbert Duerr schrieb:
On Jun 22, 2009, at 2:51 PM, Joost Andrae wrote:
Einfluss auf die Fehlerbehebung eines Issues, welches noch nicht
von einem Entwickler angenommen wurde, kann man auch nehmen, indem
man selber Entwickler-Resourcen bereitstellt, um dieses Problem zu
beheben.
Dabei müssen nicht mal Entwickler-Resourcen bereitgestellt werden.
Auch ein ganz normaler Anwender kann die Fehlerbehebung wesentlich
beschleunigen, indem er Issues leichter verdaulich macht. Z.B.
durch das Heraus-Isolieren des konkreten Problems (http://wiki.services.openoffice.org/wiki/AquaBuild#Contribute_by_finding.2C_isolating.2C_debugging_or_solving_issues
):
So die Theorie - jeder, der sich schon länger für QA bei OOo
engagiert dürfte diese kennen.
Ist das wirklich die von allen geteilte Theorie? Z.B. habe ich in
diesem Thread schon gelesen, daß das Lösen von Bugs nicht die Aufgabe
des Testing sein sollte. Dabei ist meiner Meinung nach das
Herausisolieren des konkreten Problems ein ganz wesentlicher Teil der
Arbeit. Bevor das gemacht ist, kann die Wichtigkeit eines Problems
normalerweise auch nicht richtig eingeschätzt werden.
[...]
...Warum hängen so viele Issues in einem so schlechten Zustand rum?
Ganz einfach: weil es in der Regel Stunden, bei komplexeren
Problemen Tage dauert, eine gute Beschreibung zu liefern.
Genau. Es ist einfach eine Menge Arbeit, das Kernproblem aus dem
Startproblem heraus zu isolieren. Jeder mag viel lieber anderen sagen,
was sie tun sollen (z.B. durch das Setzen von Bug-Prioritäten) als
diese Arbeit selbst zu leisten. Das ergibt dann leider den Effekt "zu
viele Häuptlinge, zu wenige Indianer".
Die Motivation, eine solche zu liefern ist natürlich vorhanden (z.B.
weil man ein schwieriges Problem löst, oderdem Entwickler hilft).
Der wichtigste Motivationsfaktor ist aber, dass der Fehler
korrigiert wird. Im Moment ist die Chance für einen "freien QAler"
sehr gering, gerade einen Issue zu bearbeiten, der dann demnächst
auch wirklich gefixed wird.
Fast alle Entwickler, lösen gerne Issues "en passant" mit: Ist ein
Problem herausisoliert, der Fix nicht allzu aufwendig, die Risiken
sind vernachläßigbar und der Aufwand zur Verifikation und anderen
Tests ist überschaubar, dann werden sie in der Regel schnell gefixt.
Wenn es sich nach dem aufwendigen Herausisolieren des Problems aber
herausstellt, daß die anderen Bedingungen für einen schnellen Fix
nicht gegeben sind, dann kommt der Issue in die Resourcen-
Warteschlange, wo er nach Wichtigkeit abgearbeitet wird.
Falls aber ein Issue noch in einem nicht-herausisolierten Zustand ist
und er auch sonst nicht dringend erscheint, dann gammelt er leider rum.
Für potenzielle Stopper stehen diese noch relativ gut. Für alles,
was nicht Stopper ist sind die Chancen recht gering. Irgendwann
stellt sich die Frage, in wieviele Issues man noch Stunden an Arbeit
steckt, ohne dass diese nachher korrigiert werden.
Jemand muß diese Arbeit aber tun, wenn der Issue wirklich gefixt
werden soll.
Wir sollten uns überlegen, wer das Heraus-Isolieren erledigen kann/soll:
1. der Issue-Reporter mit einer helfenden Hand von QA?
2. automatisches Testing?
3. manuelles Testing?
4. Entwickler?
Es wäre schön, wenn ein Konsens darüber zustande kommt, daß das Heraus-
Isolieren des Kernproblems ein wesentlicher Teil der Behebung eines
Fehlers ist. Meiner Meinung nach gilt der Satz "QA ist dafür nicht
zuständig" also nicht.
---
Herbert Duerr
du...@sun.com
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551
Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org
For additional commands, e-mail: dev-h...@de.openoffice.org