Ein kleiner Exkurs. Diesmal zu Testverfahren. Ich war gerade im Gespräch mit einem Kollegen über verschiedene Testverfahren. Dabei kam die Frage auf, wie man verschiedene Testfälle angehen kann. Hier nun also das Resultat.
Komponententest
Klassische Unit-Tests. Im Minimalmodell müssen hier vor allem die Schnittstellen zwischen den Systemen abgetestet werden. Die meisten Qualitätsverfahren gehen davon aus, dass die meisten Fehler genau an den Schnittstellen passieren, da der Entwickler sein eigenes Modul gut kennt und die Fehler ehr durch unerwartete Parameter entstehen können.
Im Fall von O365 ist JavaScript wahrscheinlich die häufigste Oberfläche. Daher würde ich die Unit-Tests auch auf dieser Ebene ansiedeln und jede Kommunikation zwischen der Oberfläche und dem Backend abtesten. So wissen wir, welche Funktionen wir aufrufen und bei welchen Parametern wir welche Ergebnisse erwarten. Genau diese würde ich hier testen. So kann man bei jedem Aufruf einmal den Positivfall und die eingebauten Fehlerfälle abtesten.
Ein Beispiel:
GetYearOfDate(„2007-12-12“) assert „2007“
GetYearOfDate(„2. Feb. 2017“) assert „2017“
GetYearOfDate(„30.02.2002“) assert InvalidDateException
Integrationstest
Integrationstests sind Testfälle die zu Testszenarien verbunden sind. Ich habe das zum Beispiel immer gemacht, indem ich mir eine UserStory/UseCase/Requirement des Kunden geschnappt habe. Das war mein Testszenario. Dann habe ich für jedes von mir identifizierte Akzeptanzkriterium einen Testfall geschrieben um es abzuprüfen.
Diese würde ich üblicherweise im VSO Test Manager schreiben. Der Vorteil ist, dass wir diese Testfälle über unseren SSO-Login und den Web-Client auch bei Kunden in ihrem eigenen System nutzen können. Für ausgeführte Testfälle erhalten wir dann nämlich auch ein sehr detailliertes Testprotokoll.
Idealerweise werden Integrationstests auf einer expliziten Testumgebung (der INT-Stage) ausgeführt. Diese Testfälle sind bei mir immer durch einen Tester auf Entwicklerseite ausgeführt worden. Nicht jedoch durch den Entwickler, der das Modul geschrieben hat. Gerne aber durch einen anderen Entwickler, der daran nicht beteiligt war.
Ein Beispiel:
Anforderung:
Ein Nutzer möchte eine Übersicht aller seiner aktiven Projekte aus der Projektliste auf der Startseite.
Implizite Akzeptanztests (zur Abnahme beim Kunden):
- Es muss möglich sein, dass auf der Startseite ein Anzeigemodul (z.B. Webpart) platziert wird, dass eine Liste von Projekten anzeigen kann
- Die Liste auf einen speziellen Nutzer gefiltert werden
- Projekte anderer Nutzer sollen nicht angezeigt werden
- Es sollen nur aktive Projekte aus der Liste ermittelt werden.
- Inaktive oder beendete Projekte sollen nicht angezeigt werden.
In diesem Fall schreiben wir ein Testszenario „Aktuelle Projektübersicht eines Nutzers“ und haben darin 5 Testfälle, die jeweils ein Akzeptanzkriterium enthalten.
Systemtest
Der Systemtest ist die Gesamtheit aller Testszenarien die hier im Zusammenspiel getestet werden. Es sollte also eine Testumgebung geben (normalerweise der QA-Stage), auf der kurz vor der Abnahme einmal alle Komponenten installiert werden. Hier testet ein Test-Team, welches wieder vom Entwicklungsteam gestellt werden kann.
Bei mir war es oft so, dass zu diesem Zeitpunkt bereits einige Key-User auf der Plattform unterwegs waren und über Exploratory Testing – also freies Testen nach Gefühl – unterstützt haben, um somit Fehler zu finden, die mehr Fachwissen benötigen.
Auch gibt es als Output ein Testprotokoll.
Abnahmetest
Dieser kann als einziger Test nicht durch den Zulieferer erfolgen. Er wird auch User Acceptance Test (UAT) genannt und lässt die späteren Nutzer – oder eine Teilmenge davon – auf die Umgebung. Im Idealfall kann dieser Test bereits auf der späteren Produktivumgebung stattfinden, damit sichergestellt ist, dass alles richtig eingerichtet wurde. Sollte dies nicht möglich sein, findet der Test auf der QA-Umgebung statt, welche per Definition identisch mit der Produktivumgebung ist.
Zusammenfassung
Komponententest dienen der Abprüfung der Applikationsschnittstellen über Unit-Tests um die Konsistenz der Applikation zu gewährleisten. Liefergegenstand ist das Protokoll der Unit-Tests.
Die Integrationstests entsprechen dem Schreiben von Testszenarien anhand der Requirements und von Testfällen anhand abgenommener Akzeptanzkriterien. Ausführung erfolgt bei Fertigstellung einzelner Module auf der Integrationsumgebung. Liefergegenstand ist das Testprotokoll der Integrationsumgebung.
Als Systemtest versteht man die Ausführung aller Testszenarien der Integrationstests. Ausführung erfolgt auf der QA-Umgebung bei Abschluss der Implementierungsphase. Liefergegenstand ist das Testprotokoll der QA-Umgebung.
Und der Abnahmetests beschreibt die Ausführung aller Testszenarien oder eigener Tests auf der QA- oder Produktivumgebung durch die Fachabteilung. Wir sind hier lediglich beratend tätig und halten Ressourcen für die Fehlerbehebung bereit.
ALM Tech Blog 