Hi,
Gibt es überhaupt klare Richtlinien, was OOo können soll, muß usw.?
Und auch entsprechende Prüflisten? Wenn ja, wo sind die zu finden?
Ja, es gibt welche .. hatte ich schon erwähnt .. ich nenne sie nochmal
zu den drei kategorien, die du benannt hast.
Ich denke mir das so ähnlich wie Checklisten vor dem Start eines
Airbus. Nur mal ein paar grobe Überlegungen dazu, um vielleicht die
Diskussion in eine anwendbare Richtung zu lenken.
Es könnte mit 3 Gruppen gearbeitet werden:
1. Was muß/soll OOo können und warum?
Z.B. als Gesamtprogramm (z.B. Netzwerkfähigkeit) aber auch in den
einzelnen Modulen (Writer, Draw etc.),
Das kommt noch den manuellen Release- oder Lokalisierungs tests am nächsten.
Release-Tests sollen sicherstellen, dass keine wesentliche Funktion
verlorengeht bzw. unbenutzbar wird.
Lokalisierungstests sollen sicherstellen, dass nciht nur die
Funktionalität vorhanden ist, sondern dass sie auch in unterschiedlichen
Lokalisierungen funktioniert, sauber übersetzt wird ... (das geht über
eine Übersetzungen hinaus, z.B. müssen auch komplexes Schriftlayout oder
unzerschiedliche Zahlen / Währungsformate geprüft werden).
Releasetests sind im wesentlichen hier beschrieben:
http://qa.openoffice.org/testcase/index.html
Mit dem Problem, dass diese zum Teil überflüssig sind .. siehe Pkt. 3,
zum anderen beziehen sie sich noch auf OOo 1.1. Und .. ja, sie sind zu
"technisch" d.h. zu wenig anwenderorientiert. DEshalb müssen sie ja
überarbeitet werden
Lokalisierungstests werden in einem eigenen Portal verwaltet. Sie sind
etws umfangreicher als die o.g. Tests, und ein wenig mehr
anwendungsorientiert.
Im Moment werden die Releasetests immer kurz vor einem Release
durchgeführt, eben um festzustellen, ob die Version freigegeben werden
kann.
Die Lokalisierungstests laufen in längeren Abständen (da sie auch
zeitauwendiger sind).
2. Welche von den Usern geschätzten Funktionen (anderer Programme oder
neue Ideen) sind für OOo brauchbar und sinnvoll?
Hier haben wir das eigentlich Problem. Das wurde bisher in der Community
nicht strukturiert gemacht. Es ist auch relativ schwierig, das zu
machen, was nicht heisst, dass es unmöglich ist. Es braucht schlicht
jemanden, der es anpackt.
3. Eine Liste für die Prüfung sämtlicher Funktionen in OOo erstellen.
Das ließe sich evtl. wie ein Flow-Chart anlegen, indem man sich
vielleicht an den vorhandenen Funktionen der Symbolleisten orientiert.
Z.B.: Einfügen -> Textmarke -> läßt sie sich setzen in .sdw, .odt,
.rtf usw.; läßt sie sich setzen in Writer, Draw, Calc etc.; ginge es
einfacher/besser etc.?
Es gibt Testskripte, die nahezu alle Funktionen hinsichtlich ihrer
Spezifikation testen. Die werden automatisiert abgearbeitet. Das hat den
Vorteil, dass man (wenn die Skripte einmal geschrieben sind) relativ
schnell prüfen kann, ob Funktionalitäten verloren gehen.
Bitte macht euch aber klar, was relativ heisst. Die volle Testsuite
läuft *mehrere Tage*. Die Automatisierung ist dabei schneller, als jeder
Mensch so etwas durchtesten könnte und geht sehr stupide vor.
Alternative Wege, geht es einfacher / schneller wird da natürlichnicht
gefragt.
Nur .. wenn man das mit realem Bedienern machen würde, würde es Monate
dauern, einen kompletten Test durchzuziehen.
Wie gesagt, es ist nicht unmöglich, so etwas zu tun, aber es ist
definitiv nicht vor jedem Release möglich.
Dann bräuchte im Prinzip jeder einzelne Prüfpunkt (im obigen Beispiel
"Textmarke") nur auf Helfer verteilt zu werden. Und wenn etwas nicht
stimmt, kommt die Rückmeldung.
Anhand der Themen (z.B. "Textmarke") wäre zu sehen, ob alle Aspekte
des Programmes gecheckt sind oder noch was fehlt.
Ja, so in etwa arbeiten wir auch bei den Release- oder
Lokalisierungstests, müssen uns aber auf eine Teilmenge der Funktionen
beschränken, weil das Thema einfach zu komplex ist.
Ich weiß, das ist jetzt absolut simpel gedacht. Aber vielleicht ist
damit ein Anfang zu machen.
Ansonsten, canceln.
Wenn da ernsthaft an Tests etc. rangegangen wird, wäre ich bereit, ab
2006 mit einzusteigen. Allerdings mit dem Manko, daß ich nicht der
große Experte bin.
Nein, darum geht es beim abarbeiten der auch Tests nicht. Für "nicht
Experten" gibt es zwei Ansätze:
- entweder es gibt konkrete Testbeschreibungen, bei denen sehr genau
dokumentiert ist, was bei der Durchführung des Tests zu beachten ist und
was das erwartete Ergebnis ist
- ein Usability-Test, der nur ein grobes Ziel und einen groben Weg
vorgibt, um herauszufinden, ob der Anwender die Aufgabe erledigen kann.
Ich hoffe immer noch, dass sich für letztere jemand findet, der sie
schreibt und später auch auswerten kann, denn genau das fehlt uns. (Und
nein .. im Moment kann ich das nicht, da mir dazu zwar einige Ideen im
Kopf rumgeistern, ich aber die Sicherstellung der Basisifunktionalität
im Moment wichtiger finde und mich nicht clonen kann).
André
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
