Hallo Liste, hallo André, ich würde nun gerne sehen, ob wir hier etwas konkreter werden können. Es mag sein, dass ich aufgrund meines fortgeschrittenen Alters in meinen Anforderungen etwas konservativ bin, und deshalb würde auch ich gerne wissen, ob dieses Produkt für mich geeignet ist. Wenn sich herausstellt, dass ich der einzige bin, der an bestimmten Dingen interessiert ist, können wir diese Schreiberei beenden und ich werde wieder mit TeX und FrameMaker arbeiten. Dieses ist für mich auch schon eine entscheidende Grundlage für einen Anforderungskatalog: Ich hätte gerne eine Kombination von beiden Programmen, zusätzlich noch Calamus, das ich allerdings das letzte Mal vor etlichen Jahren zum letzten Mal benutzt habe und Visio.
Inwieweit bestimmte Dinge in einer derartigen Liste wie dieser hier funktionieren kann ich nicht beurteilen. Vielleicht gibt es aber etwas, was auch hier funktioniert und das sollten wir versuchen. Wenn die zweite von mir vorgeschlagene Gruppe, die anwendungsbezogenen Tests nicht gemacht werden können, halte ich auch die erste Gruppe für absolut überflüssig. Ebenso müssen Funktionalität und Handhabung getestet werden. > > > > 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. Wie oben gesagt, halte ich beides für wichtig und bei meinem Vorschlag sehe ich die Trennung nicht so strikt. Die erste Sorte beinhaltet auch Anwendbarkeit. Die Anweisungen sind genau das, was in einer Anleitung steht, die den NutzerInnen verfügbar gemacht werden. Hier werden Dokumentation und Funktion miteinander verknüpft. Einen reinen Funktionstest halte ich für überflüssig bzw. das ist etwas, was ausschließlich von Entwicklern gemacht werden kann. > 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. Nicht zwingend, da die Brauchbarkeit schon mit dem ersten Test nachgewiesen worden wäre. Diesen zweiten Testfall sehe ich auch als Komforttest. > 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. Und nun? > > > .... > > 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 :-( ;-) Dieser Satz ist doch sehr kontraproduktiv im Sinne von "Es ist eh alles hoffnungslos.". Ich habe einige Dinge aufgeschrieben, die ich machen möchte. Kann das denn nicht eine Grundlage sein? Das waren nur Grobziele, aber ich denke, dass hieraus Feinziele abgeleitet werden können. Zu den drei Themen Schreiben eines Briefes besser eines Geschäftsbriefes Schreiben einer wissenschaftlichen Arbeit ohne und mit Verwendung von Globaldokumenten Erstellen eines Flyer Erstellen von Prozessdarstellungen würde ich konkret mitarbeiten, sowohl bei der Definition der Ziele als auch bei der Definition von Testszenarien. Ebenso an der Definition und Kategorisierung der Testfälle für elementare Funktionen in writer und vielleicht in draw. Tabellenkalkulation und Datenbank interessieren mich weniger. Bei Datenbanken gibt es Oracle und mySQL, es erscheint mir sinnlos etwas anderes entwickeln zu wollen, das mit guten Produkten verglichen werden muss. Sollen Definition von Anforderungen, Grob -und Feinziele, und die Zusammenstellung und (Neu-)Formulierung von Testfällen fortgeführt werden? Siegfried --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
