Externe Projekte → SAVE → Checklisten Shareware Qualität

Checkliste Test

• Über diese Checkliste
  • Zweck
    Die Checkliste enthält Prüfkriterien für den Test von Sharewareprodukten vor der Veröffentlichung.
• Testumgebung
  • Betriebssystem: Windows 32-bit
    Unterstützt das Produkt alle 32-bit Windows Plattformen dann sollte mindestens unter diesen Konfigurationen getestet werden: Windows 95 Minimalinstallation (allererste Ausgabe ohne Updates etc.), Windows NT 4 mit aktuellem SP, Windows 2000, XP Home, XP Pro
  • Zum Testen unter verschiedenen OS auf einem Rechner hat sich neben Multiboot Konfigurationen die Software VMware bewährt.
  • Ein einfaches Wechseln zwischen den Betriebssystemen lässt sich auch mit einem Programm wie Norton Ghost sehr gut erreichen.
  • Sprachen / Gebietsschemata
    Unter allen unterstützten Sprachen ist zu testen. Insbesondere auch unter Verwendung unterschiedlicher Gebietsschemata für die gleiche Sprache (z.B. Schweiz).
  • Außerdem auf Datumsformate achten, wenn diese intern gespeichert werden!
  • Hardware
    Unterstützt die Software bestimmte Hardware, so muss mit den entsprechenden Geräten getestet werden. Z.B. bestimmte Eingabe- oder Ausgabegeräte, wie Wheelmäuse, Scanner, Drucker...
  • Performance
    Oft hat der Anwender nicht so performante Systeme wie der Entwickler. Also auch auf gering ausgestatteten Systemen testen. Stress-Utilities einsetzen, um eine hohe Systembelastung zu simulieren.
  • Alte Computer bekommt man meist günstig über eBay.
  • Bildschirmeinstellungen
    Geringe Auflösungen (640x350), minimale Farbtiefe und Verwendung von grösseren und kleineren Systemschriften enthüllen die meisten Fehler. Auch exotische Farbschemata und die Umstellung der Bildschirmeinstellungen (Auflösung, Farbtiefe, Farben, Schriften) während das Programm läuft sind zu testen.
  • Sharewareversion
    Das Produkt ist in der Shareware- und in der Vollversion zu testen.
  • Benutzerrechte
    Das Produkt muss, wenn nicht anders dokumentiert, unter allen erdenklichen Benutzerrechten (Extremfall: Windows 2000 Gast-User) funktionieren.
  • Korrekter Umgang mit belegten Ressourcen
    Es kann immer vorkommen, dass z.B. die Soundkarte, auf der eine lebenswichtige Ausgabe getätigt werden soll, von einem anderen Programm gerade blockiert wird. Diese Fehler sind korrekt abzufangen und dem Benutzer anzuzeigen.
• Testpersonen
  • Entwickler
    Der Entwickler testet die einzelnen Funktionen meist im Zuge der Implementierung. Für umfassendere Tests eignen sich andere Personengruppen meist besser.
  • Oft auch Menschen, welche nicht so viel am PC arbeiten. Somit werden auch Dinge versucht, welche ein Entwickler nie testen würde!
  • Tester
    Der typische Testingenieur hat weniger Kenntnis von der technischen Umsetzung der Software als eher Verständnis für die Belange der Anwender und testet das Produkt "aus Anwendersicht". Anhand eines Funktions- und Testkatalogs (bzw. des Lastenhefts, falls vorhanden) testet er idealerweise jede Funktion in jeder erdenklichen Form, mit allen erdenklichen Eingabewerten etc.
  • Betatester aus Anwenderkreis
    Kunden sind (leider oft unfreiwillig) die häufigsten Tester. Allerdings müssen die Kunden beim Test entsprechend angeleitet (z.B. Testszenarien, Checklisten) und betreut werden, sonst ist der Rücklauf erfahrungsgemäß gleich null. Der typische Anwender konfiguriert das Produkt einmal und berichtet dann über Probleme im Dauerbetrieb, findet aber wenig versteckte Fehler da er das Produkt nicht direkt "angreift". Trotzdem typisch: der öffentliche Betatest nach dem Motto "die Masse machts" - Nutzen umstritten, Rufschädigung dafür inbegriffen.
  • Viele bereits registrierte Anwender freuen sich auch, wenn Sie eine neue Beta-Version (die als solche gekennzeichnet sein sollte!) aus dem Netz laden können. Wichtig dabei ist natürlich, dass die vorherige Nicht-BETA-Vollversion weiterhin verfügbar bleibt, bis die neue Version endgültig freigegeben wird.
  • Reihenfolge
    Eigentlich logisch, erst testet man im Haus, erst dann wirft man das Produkt der Masse zum Test vor. Leider wird das selten so gemacht. 90% der Fehler, die von Betatestern gefunden werden hätten schon im Haus festgestellt werden müssen.
• Testzeitpunkt
  • Inkrementelle Tests während der Entwicklung
    Typischerweise testet der Entwickler jede Funktion im Rahmen der Implementierung.
  • Abnahmetest für ein Release
    Vor jedem Release (auch beim kleinsten Update) sollte ein Abnahmetest erfolgen. Die Vorgehensweise ist am besten standardisiert und dokumentiert. Kein Byte verlässt das Haus ohne Abnahmetest!
• Vorgehensweisen
  • Funktionsbezogener Test
    Jede Funktion wird darauf überprüft, ob sie so funktioniert, wie in der Dokumentation beschrieben. Die Funktion wird mit unterschiedlichen, auch ungültigen Eingabewerten "angegriffen".
  • Testszenarien
    Typische Abläufe werden "nachgespielt", somit wird die gemeinsame Operabilität der einzelnen Funktionen getestet. Die Szenarien werden am besten dokumentiert um sie später wieder durchzuspielen. Ein Szenario kann unter verschiedenen Rahmenbedingungen geprobt werden.
  • Installation/Update/Deinstallation
    Die Installation ist auf einem System zu testen, auf dem das Produkt noch nie installiert war. Die Installation von Updates oder das "Drüberinstallieren" ist zu erproben. Die Deinstallation ist zu testen und das System daraufhin auf Reste zu untersuchen.
  • Test der Dokumentation
    Auch die Dokumentation (Onlinehilfe etc.) muss getestet werden.
  • Dokumentation der Tests
    Die Tests sind zu dokumentieren, z.B. Build - Rahmenbedingungen - Was getestet - Wie getestet - Funktioniert ja/nein - Fehlerbeschreibung. Damit können Tests später wiederholt werden; bei Fehlern kann der Entwickler das Problem reproduzieren.