CBIS - CARE BED INFORMATION SYSTEM

Transkript

1 CBIS - CARE BED INFORMATION SYSTEM Test Plan Dokumentänderungen Version # Datum Ersteller Beschreibung V Anna Bruseva Erste Version

2 Inhaltsverzeichnis 1 INTRODUCTION TESTKOMPONENTEN FEATURES WIRD GETESTET WIRD NICHT GETESTET TEST DELIVERABLES TEST SPEZIFIKATION TEST SCHEDULE TESTPROTOKOLLIERUNG TESTBERICHTE BUG REPORT TEST TASKS RESSOURCEN UND UMGEBUNG TESTING TOOLS TEST UMGEBUNG Hardware Software BUG STRENGE UND PRIORITÄTEN Strenge-Lists Prioritäten VERANTWORTLICHKEITEN TESTER ENTWICKLER PERSONAL- UND SKILLSBEDARF RISIKEN...6 1

3 1 Introduction Im vorliegenden Dokument sind die Testmaßnahmen für CBIS dokumentiert. Festgelegt sind sowohl die Vorgehensweisen bei der Organisation und Planung, als auch die Art und Weise der Testdurchführung. Der Dokument ist eine Beschreibung des folgendes: welche Komponenten getestet werden; welche Features getestet werden und welche nicht; die Ausfall- sowie Durchkommenkriterien für die verschiedene Test-Einheiten; Test Delivarebles; Teststasks; notwendige Umgebung; Verantwortlichkeiten; Personal- und Trainingbedarf; Risiken. 2 Testkomponenten Folgende Komponenten werden getestet: Item vor allem werden die Haupteigenschaften eines Items, also ob die Erstellung, Änderung und Löschen eines Items richtig funktionieren InventoryUpdate da wird getestet, ob ein Item, nach einem Verkauf gelöscht wird, ob zur richtigen Zeitpunkt die Aktualisierung der InventoryUpdate durchgeführt wird etc. ItemPrice es wird überprüft ob der richtige Preis übernomen wird (im Fall einer Änderung des Preises) Configuration wird getestet, ob eine von einem User erzeugte Konfiguration richtig gespeichert wurde Order es wird getestet, ob eine Bestellung die richtige Items beinhaltet, ob die Zeitpunkt der Erstellung dieser Bestellung richtiggespecihert wurde RentalOrder sollte getestet werden ob die Start- bzw Endzeitpunkt einer Verleihbestellung richtig gespeichert wird und die richtige Einheiten beinhaltet Invoice es wird überprüft ob eine Rechnung zu der richtigen Bestellung dazugehört und nach dem richtigen Person gesendet wird User es wird getestet ob ein User (und seine Eigenschaften) richtig erstellt, geändert bzw gelöscht werden könnte Role und Privileges wird überprüft ob beim Einloggen die Rechte eines Users tatsächlich gelten, also ob ein Admin alle notwendige Rechte hat und ein Benutzer nur die durch den Projektauftrag bestimmte Rechte hat 2

4 Message wird getestet ob der Ersteller einer Message und die Message selbst richtig gespeichert werden sowie ob diese Message zu der richtigen Order gehört Attachment das Hinzufügen eines Attechments wird getestet sowie die richtige Zuordnung zu einer Message 3 Features 3.1 Wird getestet Es wird jeder beschriebene technische Anwendungsfall als ein zu testendes Feature behandelt. Wo nötig, werden Anwendungsfälle weiter unterteilt um den Test feiner zu granulieren. Außerdem sollten noch nicht funktionale Anforderungen getestet werden, wie zb Performance und Benutzerfreundlichkeit. 3.2 Wird nicht getestet Darüber hinaus, was nicht als einen Anwendungsfall definiert ist,wird allerdings nicht getestet. Außerdem wird auch das Hashing der Passwörter nicht getestet sowie keine Security-Aspekte dieser Web-Anwendung. Da es sich um einer Web-Applikation handelt sollte noch erwähnt sein, dass keine Accessability-Tests durchgeführt werden und dadurch keine Garantie für die Einhaltung der Guidelines des W3C gegeben werden könnte. 4 Test Deliverables 4.1 Test Spezifikation In einem Test Spezifikation Dokument werden alle zu testende Anwendugsfälle beschrieben. Jeder Anwendungsfall wird mit einem eindeutigen Nummer gekennzeichnet, hat einen Name sowie kurze Beschreibung wie genau das Test durhzuführen ist. Der Anwednugsfall hat dazu noch 3 Eigneschften, wobei 1 davon ist optional: NF Normal Fall Verhalten, FF Fehler Fall Verhalten und möglicherweise SF Sonder Fall Verhalten. In diesem Dokument werden Ausfall- und Durchkommenkriterien definiert. 4.2 Test Schedule Es wird einen Testzeitplan erstellt. Er enthält die genaue zeitliche Planung für die Durchführung aller Tests (Testvorbereitung, Testdurchführung, Testdokumentation). Folgende Dokumente werden vom Testteam bei der Durchführung des Systemtests erzeugt: 3

5 4.3 Testprotokollierung In einem schriftlichen Protokoll (Excel) werden die Ergebnisse der Tests dokumentiert und als Arbeitsergebnis geliefert. Je nach Anforderung werden Testprotokolle auch als Zwischenergebnisse bereits vor Ende der gesamten Tests erstellt. 4.4 Testberichte Der Testbericht beinhaltet den Namen des Testers (eine Abkürzung: AB,CP, IB, AM, MP, KF) und Datum des Tests sowie ein Protokoll der Testdurchführung (Anzahl und Identifikation der Durchgeführten Testfälle und Beschreibung des Gesamteindrucks). 4.5 Bug Report Der Bug Report beinhaltet alle Fehler des Systems, die während eines Tests entdeckt werden, mit einer eindeutigen Nomerierung, Datum, Name des Testers, Name des verantwortlichen Entwicklers sowie kurze Beschreinung vom Verhalten des Systems beim Fehlerauftritt, damit der Entwickler auch den Fehler nachvollziehen könnte. Es sollten noch die Strenge sowie die Priorität des Bugs gegeben sein (siehe 6.3). 5 Test Tasks Task Vorgänger Spezialle Kenntnisse Verantwortlichkeit 1. Testplan Vorbereiten 2. Testspezifikation vorbereiten 3. Vorbereitung des Testsystems 4. Durchführung der Tests 5. Gefundene Fehler beheben 6. (4) und (5) wiederholen bis alle Tests erfolgreich abschliessen 7. Alle notwendige Reports und Dokumente schreiben Alle notwendige Designdokumente - Testmanager Task 1 - Testmanager Task 2 Kenntniss des Systems Entwickler Task 3 Kenntniss des Systems Tester Task 4 Kenntniss des Systems Entwickler - Kenntniss des Systems Tester Task 6 - Tester 6 Ressourcen und Umgebung 4

6 6.1 Testing Tools Es werden sowohl automatische Tests implementiert als auch manuel getestet wird. Für das manuelle Testen werden am Anfang keine Tools benutzt, da der Umfang des Projekts nicht so groß ist. Eventuell, bei Bedarf, wird Selenium für die Automatisierung der manuellen Tests eingesetzt. Für die automatisierte Tests wird Rspec benutzt. 6.2 Test Umgebung Hardware Harwarespezifisch sind im allgemein keine Einschränkungen festgelegt Software Für die Erstellung sowie die Durchführung aller Tests sind follgende notwendig: Windows XP, Vista, 7 oder Linux NetBeans oder Eclipse als Implementationsumgebung Internet Explorer 8 oder Mozilla Firefox im Fall Selenium tatsächlich benutzt wird 6.3 Bug Strenge und Prioritäten Strenge-Lists Der Tester, der ein Bug registriert ist auch für diese Strenge-Zuordnung verantwortlich. Strenge ID Strenge Strenge Beschreibung 1 kritisch Level Ein Modul oder das ganze System ist abgestürtzt Systemcrashes, Datenbankausfall, Gefahr von Datenverlust, etc. 2 hoch Durch eine falsche Funktionalität oder Failure wird eine wichtige Komponente nicht mehr brauchbar. 3 mittel Falsche Funktionalität einer Komponente oder eines Prozess. 4 gering Dokumentationsfehler Prioritäten Priority Priority Level Priority Description ID 5 Muss gefixt sein Der Bug muss gefixt sein, das System kann nicht mit dem Fehler weiter arbeiten. 4 Sollte gefixt sein Wichtige Bugs, die gefixt sein müssen, sind jedoch nicht katastrophal. 3 Fix, wenn Zeit vorhanden Es wäre gut gefixt zu sein aber wenn wichtigere Tasks zu erledigen sind, kann man den Bug erst danach fixen. 2 Geringe Priorität Es ist nicht so wichtig solche Bugs gefixt zu werden. Die warden behandelt erst nachdem alle andere gefixt sind. 1 Trivial Erweiterungen gut zu haben aber außerhalb des Umfangs. 5

7 7 Verantwortlichkeiten Folgende Gruppen sind für Teilbereiche dieses Testplans verantwortlich: 7.1 Tester Dieser Person ist für die Planung und Durchführung der Tests verantwortlich und erstellt auch alle notwendigen Reports und Dokumente. Prinzipiel ist jeder Entwickler für seinen eigenen Code verantwortlich d.h. jeder sollte die Anwendungsfälle, die er implementiert hat selber testen. Im Fälle, wenn jemand die Anwendungsfälle eines anderen Entwicklers testet, dann sind eventuell gefundene Fehler an die Entwickler weitergeleitet zu werden. 7.2 Entwickler Die Entwickler des CBIS sind dafür zuständig gefundene Fehler und Abweichungen von den Spezifikationen auszubessern oder zu rechtfertigen. In letzterem Fall muss allerdings die Spezifikation aktualisiert werden. 8 Personal- und Skillsbedarf Da eingentlich jeder Entwickler selbst seinen Code testen wird und die tatsächliche Anzahl der Entwickler ist 6, wäre das heißen dass auch 6 Tester zur Verfügung stehen, wobei einer davon auch Testmanager ist. Irgendwelche ganz spezifische Skills für das Testen des Systems sind in dem Fall nicht von einer Bedeutung. Da der Projekt mittels Ruby on Rails realisiert wird, ist es auch notwendig die entsprechende Testmöglichkeiten der Sprache bekannt zu sein.im Fall von Benutzung des Tools Selenium wäre notwendig mindestens eine der Selenium-unterstützten Programmiersprachen auch bekannt zu sein. 9 Risiken Folgende Risiken werden zur Zeit beachtet: Durch das Selber-Testen entsteht das Risiko, dass ein Entwickler unabsichtlich seine eigene Fehler außer Acht läßt. Sollten Teile des Systems, die unabhängig voneinander entwickelt werden, nicht rechtzeitig fertig werden, kann ein Großteil der Tests nicht durchgeführt werden. Sollte sich während der Tests zeigen, dass ein Teil des Systems einen schweren Fehler enthält, muss eventuell ein größerer Teil der Entwickler sich mit Debugging beschäftigen und dadurch keine Zeit für Testen haben. 6