Hi,
Siegfried Jetzke wrote:
nun bin ich wieder im Lande und habe mir diese Liste kurz angeschaut. Mit
den Namen habe ich massive Schwierigkeiten. Die Ziele sollten in dieser
Liste mit angegeben werden.
Stimme ich dir zu. Als Checkliste beim Abarbeiten habe ich meistens
dieses Dokument genommen:
http://qa.openoffice.org/files/documents/77/2095/smoketests.stc
Das ist aber eigentlich nur eine Formalität, das Problem liegt in der
Definition der Testfälle an sich.
Gleichzeitig sollten die Tests aus meiner Sicht
etwas stärker gruppiert werden.
Unter edit_actions finden sich z.B. cmp_doc04 -vergleicht zwei Dokumente-,
edt_nav04 - öffnet und schließt den Navigator- oder fin_rep04 - sucht und
ersetzt einen Zeichenkette.
Hier schlage ich eine Gruppe : Elementare Funktionen in
writer/calc/impress/... vor.
Unterfunktionen wären z.B.: Textmanipulation, Dateibearbeitung, Import-
/Export.
Gerne.
Zu jeder Funktion In dieser Gruppe sollte es zwei Tests geben. Einen, in dem
die Anweisungen stehen, die ausgeführt werden sollen und einen ohne die
Anweisungen. Für mich ist es interessant nicht nur zu wissen, ob eine
Funktion ordnungsgemäß arbeitet sondern auch, ob sie ausgeführt werden kann.
Na ja .. damit teilst du eigentlich in rein Funktionale und
Usability-Tests auf.
Funktionale Tests können nur sicherstellen, dass einen gegebenen
Funktionalität auch tatsächlich (noch) verfügbar ist. Das ist in der
Regel das, was wir kurz vor einem Release machen und genau das Anliegen
der Smoketests.
Usability-Tests können nicht erst in der letzten Phase vor dem Release
gemacht werden .. das wäre zu einem viel zu späten Zeitpunkt.
Unbeachtet dessen, denke ich, dass wir solche Tests brauchen. Bisher
wurden die mit Testusern im wesentlichen bei Sun gemacht. Strukturierte
öffentliche Tests dieser Art gibt es bisher nicht. Ich schätze aber,
dass diese wesentlich schwieriger zu koordinieren sind, denn solange man
die Leute nciht direkt einladen kann, wird es schwierig ihenn den Sinn
der Tests zu verdeutlichen und koordiniert feedback zu bekommen.
Unmöglich ist es nicht .. nur sehr schierig.
....
Hier gibt es sicher noch weitere Fälle. Ich würde jedoch zunächst gerne
klären, ob ein derartiges Vorgehen konsensfähig ist. Auch hierzu wäre es in
einem ersten Schritt gut zu wissen, was Menschen überhaupt machen wollen.
Konsensfähig: ja.
"was Menschen überhaupt machen wollen": jeder was anderes und wiklich
machen wollen sie nie das, was Sie dir erzählen :-( ;-)
Wenn ich versuche, mich an einige der Beiträge zu erinnern, wäre es auch
hilfreich zu definieren, ob vorausgesetzt werden soll, dass NutzerInnen
wissen müssen, was eine Funktion, ein relationales Datenbanksystem oder nur
der Unterschied zwischen Tabellen einer Tabellenkalkulation und denen einer
Datenbank sind oder ob alles stets immer wieder erklärt werden soll.
Für einen funktionalen Test, gehe ich davon aus, dass die Tester
einigermassen qualifiziert sind und entsprechenden Wissen mitbringen
(zumindest in einingen gebieten).
Für einen Usability-Test muss man davon ausgehen, dass die Anwender eben
genau dieses Wissen nicht haben.
Wie gesagt .. ich würde diese beiden Sachen weitgehend unabhängig
voneinander betrachten, denn sie haben verschiedene Ziele, es werden
verschiedene Arten von Testern benötigt und auch der Zeitrahmen für die
Abarbeitung der Tests ist vollkommen verschieden.
Im moment würde ich mich auf die Funktionalen Tests konzentrieren, weil:
- wir schon eine basis haben, die aber umgestaltet werden muss
- wir schon Tester haben die auf dieser Basis gearbeitet haben
- wir diese Kategorie von Tests regelmässig brauchen und auch die
Testergebnisse verhältnismässig schnell verarbeiten (d.h. es gibt
relativ schnelle REaktionen auf einen Test, sofern nötig).
Dass wir einige Kritik geerntet haben, weil wir offenbar die
Usability-Tests vernachlässigen ist mir bewusst, nur können wir nicht
alles auf einmal machen .. und diese zu entwickeln braucht wesentlich
mehr Zeit.
André
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
