Hallo,
Joost Andrae schrieb:
...
In der ganzen Präsentation fehlen Hinweise, wie das QA Team
Einfluss auf die Fehlerbehebung nehmen kann - es wird auch
nicht als Aufgabe erwähnt.
ich finde es schade, daß diese inhaltliche Diskussion nicht in der für
das QA-Projekt vorhandenen Mailingliste d...@qa.oo.o stattfindet, auch
wenn dies englische Sprache voraussetzt.
Hmm .. wir sollten zumindest die Erkenntnisse (sofern wir denn welche
gewinnen) zusammenfassen und nach d...@qa tragen.
Kannst Du bitte mal ein Beispiel nennen, bei dem man sich nicht an das
Verifizieren von behobenen Fehlern beteiligen kann ?
Darum ging es im zitierten Absatz überhaupt nicht ;) ... Gerade die
Möglichkeit des Verifizierens hat sich in den letzten Monaten und Jahren
deutlich verbessert. (Wobei man auch da natürlich noch einiges
verbessern kann ;) )
...Theoretisch sollte man sich auch via Buildbot einen CWS durchbauen
können, wie es auch schon mal auf einem der letzten QA-Wochenenden in
Essen gemacht wurde.
Ja, natürlich - aber damit hat man nur darauf Einfluss, wie mit einem
(hoffentlich) gefixten Bug umgegangen wird - nicht, wecher Bug (oder in
welchem Bereich) Bugs gefixed werden.
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.
Also ein bisschen Arbeitsteilung halte ich dann schon noch für sinnvoll.
Softwareentwicklung ist nicht Aufgabe der Qualitätssicherung - so wie es
nicht aufgabe der Entwickler ist, ihren Code bis ins Details in
verschiedensten Szenarien auf die diversen Aspekte der Softwarequalität
hin abzuprüfen.
Ob ein Fehler behoben werden kann, oder auch nicht, ist abhängig von
der Komplexität eines Fehlers. Manche Bugs können nicht mal so eben
behoben werden. Teilweise werden die Problemlösungen auch gar nicht
separat als Bugfix integriert, sondern es ist teilweise einfacher, den
kompletten Bereich, in dem dieses Problem auftaucht, neu zu
implementieren. Dies bedarf u.A. eine Kosten-/Nutzenanalyse. Außerdem
kann es sein, daß die beteiligten Entwickler (also nicht nur die von
Sun) zeitliche Prioritäten gesetzt bekommen, bezüglich der zu
verplanenden Zeit für Bugfixing/Features.
Das ist mir vollkommen klar. Und was fehlt ist eben genau diese
(sichtbare) Zusammenarbeit zwischen Entwicklung und QA -Komplexitäten
einschätzen, Aufwände ermitteln, Abwägung fix gegen Neuimplementierung.
Diese Zusammenarbeit funktioniert bei Neuimplemntierungen - aber eben
nicht bei "Aufräumarbeiten".
Gruß,
André
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org
For additional commands, e-mail: dev-h...@de.openoffice.org
