%!TEX root = ../Abnahmetestspezifikation.tex

\chapter{Testplan}

Der Testplan ist das zentrale Dokument der Qualitätssicherung und wird daher
frühzeitig erstellt. Hier wird Umfang und Vorgehensweise der Qualitätssicherung
beschrieben. Außerdem werden Testgegenstände und deren zu testenden
Eigenschaften bzw. Funktionen identifiziert. Ferner werden die
durchzuführenden Maßnahmen und die dafür verantwortlichen Personen definiert.
Falls erforderlich, sollte hier auch auf allgemeine Risiken eingegangen werden.

\section{Zu testende Komponenten}

Hier sind sämtliche zu testenden Objekte einschließlich der Versionsnummer aufzuführen.
Ebenso ist anzugeben, auf welchem Medium die Software vorliegt, ob dies einen Einfluss auf Hardwareanforderungen hat
und ob die Software vor Testbeginn in irgendeiner Weise transformiert werden muss. Außerdem wird auf zum
Objekt gehörende Dokumentation der Komponente (Lasten-, Pflichtenheft, später auch Technischer Entwurf) referenziert.


\textbf{Anmerkung:}\\
Dieses Dokument wird am Ende noch einmal zusammen mit den Testprotokollen in der Testspezifikation abgegeben.
Da vorher im Technischen Entwurf die Komponenten benannt und nummeriert wurden, sollten diese für die zweite Abgabe erweitert werden,
so dass eine Verbindung zwischen dem Technischen Entwurf und diesem Dokument entsteht.


\section{Zu testende Funktionen/Merkmale}

Dieser Punkt beinhaltet alle Eigenschaften bzw. Funktionen und deren
Kombinationen, die zu testen sind.

Sämtliche Funktionalitäten, die getestet werden sollen, werden hier aufgeführt.
Dabei sind auf die vorangegangenen Dokumentationen zu referenzieren
(Pflichtenheft) und die dortigen Funktions-IDs zu verwenden!

Beispiel:
\begin{itemize}
\item \textbf{F20}
\item \textbf{Q10}
\end{itemize}
 

\section{Nicht zu testende Funktionen}

(optional; auszufüllen, falls es Funktionen gibt, die nicht getestet werden
sollen)\\

Hier werden alle Eigenschaften bzw. Funktionen und Funktionskombinationen
aufgelistet, die nicht getestet werden.
\textbf{ Es sollte begründet werden, warum diese nicht getestet werden.} Es
versteht sich von selbst, dass alle Muss-Funktionalitäten des Pflichtenheftes getestet werden müssen.

\section{Vorgehen}

Die allgemeinen Vorgehensweisen für die einzelnen zu testenden Funktionen und
Funktionskombinationen werden hier beschrieben. Die Beschreibung sollte
detailliert genug sein, um die Hauptaktivitäten und deren Zeitbedarf abschätzen
zu können.

Es ist zu beachten, dass für alle wichtigen Funktionalitäten das Verfahren
angegeben wird. Dies gewährleistet, dass diese Funktionalitäten adäquat
getestet werden.

Es ist zu dokumentieren, welche Aktivitäten, Techniken und Werkzeuge benötigt
werden, damit die Funktionalitäten getestet werden können.

Beispiel für Vorgehen (unvollständige Liste):\\
a) Abnahme- und Funktionstests\\
Die Anwendungsfälle aus der Anforderungsspezifikation werden über das
Web-Interface geprüft. Mindestanforderung hierfür ist es, jeden Fall einmal auf
seine korrekte Funktionalität zu testen.\\
b) Komponenten- und Integrationstests\\
Klassen werden mit JUnit-Testfällen geprüft. Vor Beginn der Implementierung
werden bereits Blackbox-Testfälle erstellt, die dann begleitend zur
Implementierung genutzt werden ("`Test first"'). Nach Abschluss der
Implementierung einer Komponente wird diese dann durch Whitebox-Tests
geprüft.\\
Der Integrationstest der Klassen und Komponenten erfolgt nach dem
Bottom-Up-Prinzip. Anfangs muss die Integration der Datenbankanbindung und den
entsprechenden Data-Access-Objects (DAO) geprüft werden, da das Mapping der
Datenbank auf Objekte die unterste Schicht des Projektes bildet. Dieser
Testabschnitt wird durch die Schnittstellentests abgedeckt.
Die Komponenten werden damit unter Berücksichtigung ihrer Abhängigkeiten
konkret in folgender Reihenfolge integriert: \ldots\\
(Hier kommt das konkrete Vorgehen bei der Integration: Welche Klassen werden
zusammen getestet, welche kommen dann dazu etc. Das kann man z.B. auch schön in
Form eines Baumes aufzeigen.)\\
c) \ldots

Das Kapitel wird im Laufe des Projekt ergänzt. In der ersten Iteration ist vor allem auf die Abnahmetests einzugehen.

\section{Testumgebung}

Die genutzte Testumgebung(en) bitte hier angeben und kurz beschreiben.\\
Beispiel: JUnit Testsuite, lokal installierter Web Application Server, \ldots

Bei Abnahmetest sollte die Testumgebung der Produktumgebung entsprechen.
