Ein solider und effizienter Testplan braucht vor allem eins: viele Informationen. Diese lassen sich erfahrungsgemäß nur dann gewinnen, wenn mit allen Projektbeteiligten noch vor den ersten Testdurchläufen gesprochen wird. Unternehmen sollten daher Programmierer und Tester in einem Team arbeiten lassen, wie dies heute Firmen erfolgreich machen, die von der Softwareentwicklung leben. Ist dies nicht möglich, sollte zumindest ein Tester bei jedem Treffen der Entwickler und des Projektverantwortlichen (Application Sponsor) dabei sein. So können die Tester über die reinen Spezifikationen hinaus ein besseres Verständnis für die Anwendung und die Vorstellungen des Sponsors gewinnen sowie eine engere Beziehung zu den anderen Projektmitgliedern aufbauen. Dies hilft die passenden Testfälle auszuwählen, noch bevor Testskripts verfasst werden.
Das müssen Sie fragen
Allgemeine Informationen:
• Wann ist die Live-Schaltung der Web-Anwendung und soll sie schrittweise erfolgen?
• Wie lautet die URL/IP-Adresse der zu testenden Site?
• Wann gilt ein Test als fehlgeschlagen? (Welche Server-Auslastung und Antwortzeiten sind noch zulässig?)
• Wie viele Web-Seiten ruft ein durchschnittlicher Benutzer auf, wenn er eingeloggt ist oder nur die Website browst?
• Ändern sich die dynamischen Seiten sehr schnell?
• Wird die Website täglich modifiziert?
• Wie oft werden Seiten hinzugefügt oder geändert?
• Gibt es bereits Anwender?
• Wird die Site auch außerhalb der Arbeitszeiten benötigt?
• Falls die Site schon live ist, wann herrscht viel oder wenig Traffic?
Testarten
• Wurden Funktionstests mit der Website vorgenommen?
• Sind im Test E-Mail-Accounts involviert? Wenn ja, sollen Benachrichtigungen während des Tests übermittelt werden, und gibt es dafür Test-Accounts?
Kapazitätenplanung
• Welche Bandbreite ist für das Testen der Website verfügbar?
• Wie viel Bandbreite benötigt durchschnittlich ein Anwender?
• Gibt es viele statische Elemente (Bilder)?
• Welcher Durchsatz wird erwartet?
• Wie viele "Zugriffe pro Sekunde" sollen möglich sein?
• Wie viele gleichzeitige Nutzer sind vorgesehen?
• Welchen prozentualen Anteil werden voraussichtlich angemeldete und nicht angemeldete Clients auf der Site haben?
Login-Information
• Können viele Benutzer dieselben Login-Daten verwenden und die Site dennoch so unter Last bringen, als wenn jeder eigene Zugangsdaten hätte?
• Gibt es Benutzernamen und Passwörter für Stresstests?
• Können Probleme in den Transaktionen auftreten, wenn viele Anwender dieselben Anmeldendaten verwenden?
• Gibt es Einkaufsfunktionen und ist eine Kreditkartennummer für die Tests verfügbar?
• Können mehrere Anwender eine IP-Adresse haben und sich dennoch gleichzeitig anmelden?
Benutzerverhalten
• Wie schnell klickt sich ein echter Benutzer durch die Website?
• Erhalten Benutzer viel Content, oder besuchen sie Site nur kurz?
• Welche Seiten werden am häufigsten aufgerufen, wenn Benutzer angemeldet/nicht angemeldet sind?
• Führen Transaktionen dazu, dass sich dynamische Seiten für andere Benutzer ändern, wenn diese sich mit denselben Daten anmelden?
• Gibt es weitere Merkmale, einen echter Benutzer zu definieren?
• Wie viele Szenarien müssen gleichzeitig geprüft werden, um die Site realistisch zu simulieren?
• Welche Szenarien sind das?
• Kann der Benutzer den Browser-Cache nutzen?
Technische Details
• Ruft die Site Java Applets, Java auf dem Client, Streaming Media oder spezielle Plugins auf?
• Welches ist der Media-Server und was unterstützen die Clients (Javascript, VB Script, Active X etc.)?
• Wie geht man mit dem Zustand zwischen Seitenwechseln (session state) um.
www.computerwoche.de/go/
*78619: Anforderungs-Management;
*72680: Softwareentwicklung produktiver machen.
Nicht locker lassen
Tester sollten diese Treffen auch nutzen, um ihre spezifischen Fragen zu stellen (siehe Kasten "Das müssen Sie fragen"). Ist eine Zusammenkunft aller Beteiligten nicht möglich, ist es ratsam, individuelle Termine mit den Entwicklern und dem Sponsor zu vereinbaren. Neben den Details zur Anwendung sind bei diesen Gelegenheiten vor allem das typische Benutzerverhalten einschließlich des Einloggens, sowie die geschätzte Systemlast zu erörtern.
Im nächsten Schritt sind die Ressourcen zu planen. Dabei ist zu überlegen, ob sich benötigte Hard- und Software wie Testwerkzeuge auch leasen lässt und ob im Haus schon einschlägige Produkte existieren. Das Mengengerüst für einen Lasttest bestimmt sich letztlich nach der Anzahl der Benutzer, die zu einem bestimmten Zeitpunkt auf die Web-Anwendung zugreifen sollen.
Genaue Ressourcenplanung
Die erste Aufgabe ist es daher, herauszufinden, wie viele Benutzer die vorhandene Hardware unterstützt. Die Werte für Clients und Server lassen sich mit Testwerkzeugen für Web-Anwendungen ermitteln. Falls man zu dem Schluss kommt, die Tests besser separat in einem Rechenzentrum vorzunehmen, ist ausreichend Zeit für die Konfiguration der Testumgebung einzuplanen. Dieser Aufwand gehört wie die dadurch entstehenden Zusatzkosten im Testplan vermerkt. Zudem benötigen die Tester die Unterstützung des IT-Leiters im Rechenzentrum, um technische Probleme während der Tests schnell zu beheben.
Das Testteam sollte auch das Wissen der Leute in der IT und im Fachbereich nutzen, die mit den Web-Anwendungen zu tun haben. So gibt es eventuell versierte Mitarbeiter, die beim Profiling der Besucher der Website helfen. Andere könnten die Server, das Netzwerk (Bandbreite) und die Datenbank während der Tests überwachen. Sie sind zu kontaktieren, falls bei den Tests die Systeme der Website abstürzen. Ebenso ist eine Kopie des Netzwerkdiagramms zu erfragen, die alle Geräte, Betriebsysteme, Web-, Applikations- und Datenbank-Server, Load Balancer, Router etc. darstellen muss. Auch ist zu klären, was mit Daten geschieht, die bei den Testdurchläufen anfallen. Darf der Tester sie löschen oder eine bestimmte Person im Unternehmen?
Zum Testplan gehört ein genaues und realistisches Zeit-Management, da Mitarbeiter beispielsweise Urlaub haben oder aus anderen Gründen nicht verfügbar sind. Zudem ist die Kommunikation im Team wichtig. Hierzu bieten sich regel- mäßige Treffen, Telefonkonferenzen, Instant Messaging und Chat-Räume an. Visuelle Werkzeuge, die den Projektstatus und -fahrplan darstellen, sind ebenfalls hilfreich für alle Beteiligten. Schließlich brauchen die Tester die Unterstützung durch das Management. Wenn dieses von Beginn an eine klare Vorstellung von den Tests hat, stehen die Chancen gut, dass es dem Projekt auch im Fortgang beisteht. Es ist daher wichtig, der Firmenleitung genau zu sagen, welche Hilfe man braucht, welcher Projektablauf geplant ist und was die Beteiligten tun. Später sollte man sie regelmäßig über den aktuellen Status informieren, mit ihm die Teamerfolge teilen, es aber auch an den Risiken teilhaben lassen. Gelingt dies, können Tests und das Qualitäts-Management von Anwendungen eine führende Rolle in der Unternehmensstrategie gewinnen. (as)