02 [L] Testen während des SDLC

1. Evaluieren von Arbeitsergeabnissen wie Anforderungen, User Storys, Entwürfe und Code

2. Auslösen von Fehlerwirkungen und Finden von Fehlerzuständen

3. Sicherstellen der erforderlichen Überdeckung eines Testobjekts

4. Verringern des Risikos einer unzureichenden Softwarequalität

5. Verifizieren, ob spezifizierte Anforderungen erfüllt wurden

6. Verifizieren, ob ein Testobjekt den vertraglichen, rechtlichen und regulatorischen Anforderungen entspricht

7. Bereitstellen von Informationen für die Stakeholder, damit diese fundierte Entscheidungen treffen können

8. Aufbauen von Vertrauen in die Qualität des Testobjekts

9. Validieren, ob das Testobjekt vollständig ist und aus Sicht der Stakeholder wie erwartet funktioniert.

1. Das zu testende Arbeitsergebnis

2. Die Teststufe

3. Risiken

4. Der Softwareentwicklungslebenszyklus

5. Faktoren im Zusammenhang mit dem geschäftlichen Kontext, z.B.

   1. die Unternehmensstruktur

   2. Wettbewerbserwägungen

   3. die Zeit bis zur Markteinführung.

Dynamisch:

• Fehlerwirkungen, die durch Fehlerzustände in der Software verursacht werden

Statisch

•  Direkt Fehlerzustände im Testobjekt finden

Ziel: Die Ursachen für die Fehlerwirkung (die Fehlerzustände) zu finden, diese zu analysieren und zu beseitigen. Schritte_

1. Reproduzieren einer Fehlerwirkung

2. Diagnose (Finden der Grundursache)

3. Behebung der Ursache

4. Fehlernachtests, Regressionstests

Ziel: Beseitigen des Fehlerzustands.Beim Debugging-Prozess fallen die Reproduktion und Diagnose heraus. Folglich reduziert sich der Prozess auf:

1. Behebung

2. Fehlernachtests, Regressionstests

1. Kosteneffizientes Mittel zur Erkennung von Fehlerzuständen

2. Höhere Qualität der Testobjekte (wenn Fehlerzustände behoben werden)

3. Direkte Bewertung der Qualität des Testobjekts

4. Beitrag zu Entscheidungen

5. Indirekte Repräsentation von Benutzern im Projekt

6. Kann erforderlich sein (vertraglich, gesetzlich, regulatorisch)

1. Umfang und Zeitpunkt der Testaktivitäten (z. B. Teststufen und Testarten)

2. Detaillierungsgrad der Testdokumentation

3. Wahl der Testverfahren und des Testansatzes

4. Umfang der Testautomatisierung

5. Rolle und Aufgaben eines Testers

1. Für jede Softwareentwicklungsaktivität gibt es eine entsprechende Testaktivität

   • Somit unterliegen alle Entwicklungsaktivitäten der Qualitätssteuerung

2. Unterschiedliche Teststufen haben spezifische und unterschiedliche Testziele

   • So wird sichergestellt dass der jeweilige Test angemessen und entsprechend umfassend ist und Redundanzen vermieden werden.

3. Die Testanalyse und der Testentwurf für eine bestimmte Teststufe beginnen bereits in der entsprechenden Entwicklungsphase des SDLC

   • So wird der Grundsatz des frühen Testens eingehalten

4. Tester werden in das Review von Arbeitsergebnissen einbezogen, sobald Entwürfe dieser Dokumentation verfügbar sind

   • So kann frühes Testen und frühe Fehlerentdeckung den Shift-Left-Ansatz unterstützen

1. Test-First Ansätze:

1. Test-Driven-Development (TDD)

2. Abnahmetestgetriebene Entwicklung (ATDD)

3. Verhaltensgetriebene Entwicklung (Behavior-Driven Development, BDD)

2. Besonderer Zweck des Testens: Tests werden vor dem Code geschrieben und dienen so als Mittel zur Lenkung der Entwicklung3. Jeder dieser Ansätze setzt das Prinzip des frühen Testens um4. Es wird dabei dem Shift-Left-Ansatz gefolgt da die Tests definiert werden, bevor der Code geschrieben wird.5. Sie unterstützen ein iteratives Entwicklungsmodell

TDD = Test-Driven Development

• Codierung wird durch Tests gelenkt, da Testfälle zuerst geschrieben werden

• Einzelne Iterationen von wenigen Minuten (Red, Green, Refactor)

  1. Komponententest schreiben, der fehlschlägt (Red)

  2. Code anpassen, dass der Test durchgeht (Green)

  3. Code aufpolieren (Refactor)

ATDD = Abnahmetestgetriebene Entwicklung

1. Tests werden aus Abnahmekriterien als Teil des Systementwurfs entwickelt

2. Abnahemtests werden geschrieben, ehe der Teil der Anwendung entwickelt wird, der die Tests erfüllen soll

Verhaltensgetriebene Entwicklung (Behavior-Driven Development, BDD):

1. Drückt das gewünschte Verhalten einer Anwendung mit Testfällen aus, die in einer einfachen, natürlichsprachlichen Form geschrieben und die von Stakeholdern leicht zu verstehen sind

2. Üblicherweise unter Verwendung des Gegeben/Wenn/Dann- (Given/When/Then-) Formats

3. Die Testfälle werden dann automatisch in ausführbare Tests übersetzt

Dev = Development. Entwicklung der Software.

Ops = Operations. Prozesse für Betrieb der ausgelieferten Software.

CI = Continuous Integration. Codeänderungen werden häufig (mind. täglich) in zentrales Repository gepushed in mit eine bereits integrierten Versionsstand hinzugefügt. Das produziert einen neuen Build. Es werden also nicht wahllos unintegrierte Teile zusammen in einen neuen Build zusammengeworfen, sondern es wird stückweise vorgegangen.

CD = Continuous Delivery. Techniken, Prozesse und Werkzeuge um CI automatisiert auszuführen.

CI/CD = Der kombinierte Prozess aus CI und CD.

Weil sofort nach dem Einchecken des Codes alle im CI/CD-Prozess konfigurierten Tests automatisiert ausgeführt werden.

1. Zuverlässigkeit der Anwendung

2. Auslastung

3. Performance

4. Nutzung bereitgestellter Funktionen

DevOps ist ein organisatorischer Ansatz, der darauf abzielt, Synergien zu schaffen, indem Entwicklung (Dev) (einschließlich Testen) und Betrieb (Ops) zusammenarbeiten

Um die Kluft zwischen Entwicklung (einschließlich Testen) und Betrieb zu überbrücken

DevOps fördert

1. Teamautonomie

2. schnelle Rückmeldungen

3. integrierte Werkzeugketten

4. technische Praktiken wie CI/CD

Dies ermöglicht es den Teamsqualitativ hochwertigen Code über eine DevOps-Auslieferungskette (Delivery Pipeline) schneller zu erstellen, zu testen und freizugeben (Kim 2016).

1. Schnelle Rückmeldung über die Codequalität und ob sich Änderungen nachteilig auf den bestehenden Code auswirken.

2. CI fördert einen Shift-Left-Ansatz beim Testen, indem Entwickler dazu angehalten werden, qualitativ hochwertigen Code zusammen mit Komponententests und statischer Analyse bereitzustellen.

3. Förderung von automatisierten Prozessen wie CI/CD, die den Aufbau stabiler Testumgebungen erleichtern.

4. Steigert den Blick auf nicht-funktionale Qualitätsmerkmale (z. B. Performanz, Zuverlässigkeit).

5. Automatisierung durch eine Auslieferungskette reduziert den Bedarf an sich wiederholenden manuellen Tests.

6. Das Risiko einer zu aufwendigen Regression wird durch den Umfang und die Bandbreite der automatisierten Regressionstests minimiert

1. Die DevOps-Auslieferungskette muss definiert und etabliert werden.

2. CI/CD-Werkzeuge müssen eingeführt und gewartet werden.

3. Die Testautomatisierung erfordert zusätzliche Ressourcen und kann schwierig einzurichten und zu warten sein.

Shift-Left = Prinzip frühen Testens

• Bedeutet idR dass das Testen frühestmöglich beginnen sollte z. B. nicht erst, wenn der Code implementiert oder die Komponenten integriert sind

• Allerdings soll das Testen auch später im SDLC nicht vernachlässigt werden

1. Review der Spezifikation aus der Sicht des Testens -> Finden oft potenzielle Fehlerzustände, wie Mehrdeutigkeiten, Unvollständigkeit und Inkonsistenzen.

2. Schreiben von Testfällen, bevor der Code geschrieben wird

3. Ausführen des Codes in einem Testrahmen während der Coderealisierung.

4. Statische Analyse des Quellcodes vor dem dynamischen Testen oder als Teil eines automatisierten Prozesses.

5. Durchführung von nicht-funktionalen Tests frühzeitig (wenn möglich beginnend auf der Ebene der Komponententests).

6. Verwendung von CI/CD, da dadurch schnelle Rückmeldung

7. Automatisierte Komponententests, die Teil des normalen Repositories sind

1. Retrospektiven sind Sitzungen bei denen gemeinschaftlich Rückschau über einen vergangenen Projektabschnitt gehalten wird.

2. Sie finden bspw. statt bei

1.  Ende eines Projekts

2. Ende einer Iteration

3. Erreichen von Releasemeilenstein

4. Bei Bedarf

3. Der Zeitpunkt und die Organisation hängt vom SDLC ab

4. Alle Projektbeteilitgten nehmen Teil (also nicht nur Tester, sondern z. B. auch Entwickler, Architekten, Product Owner, Businessanalysten):

1. Was war erfolgreich und sollte beibehalten werden?

2. Was war nicht erfolgreich und könnte verbessert werden?

3. Wie können die Verbesserungen eingearbeitet und die Erfolge in Zukunft beibehalten werden?

Sie sind normalerweise Teil des Testabschlussberichts

Retrospektiven sind entscheidend für die erfolgreiche Umsetzung der kontinuierlichen Verbesserung, und es ist wichtig, dass die empfohlenen Verbesserungen weiterverfolgt werden.

1. Erhöhte Effektivität/Effizienz des Testens

   • z. B. durch die Umsetzung von Vorschlägen zur Prozessverbesserung

2. Höhere Qualität der Testmittel

   • z. B. durch gemeinsames Review der Testprozesse

3. Teamzusammenhalt und Lernen

   • z. B. durch die Möglichkeit, Probleme anzusprechen und Verbesserungspunkte vorzuschlagen

4. Verbesserte Qualität der Testbasis

   • z. B. weil Mängel im Umfang und in der Qualität der Anforderungen angesprochen und behoben werden konnten

5. Bessere Zusammenarbeit zwischen Entwicklung und Test

   • z. B. weil die Zusammenarbeit regelmäßig überprüft und optimiert wird

Teststufen beschreiben Abschnitte des Testprozesses, bei denen Software in einem bestimmten Entwicklungs-/Integrations- oder Abstraktionsstadium getestet wird.

Folgende 5 Stufen gibt es (Abstraktion / Integration zunehmend):

1. Komponententest

2. Komponentenintegrationstest

3. Systemtest

4. Systemintegrationstest

5. Abnahmetest

Der Komponententest (auch Unittest genannt) konzentriert sich auf das Testen von isolierten Komponenten. 

Dies erfordert oft spezifische Unterstützung, wie Testrahmen oder Unittest-Frameworks. 

Komponententests werden normalerweise von Entwicklern in ihrer Entwicklungsumgebung durchgeführt.

Der Komponentenintegrationstest konzentriert sich auf das Testen der Schnittstellen und Interaktionen zwischen Komponenten.

1. Der Systemtest konzentriert sich auf das Gesamtverhalten und die Leistungsfähigkeiten eines gesamten Systems oder Produkts.

2. Sie umfassen häufig funktionale Tests von End-To-End-Aufgaben und nicht-funktionale Tests von Qualitätsmerkmalen. 

3. Die Verwendung von Simulationen von Teilsystemen ist ebenfalls möglich. 

4. Der Systemtest kann von einem unabhängigen Testteam durchgeführt werden und bezieht sich auf Anforderungsspezifikationen für das System.

Der Systemintegrationstest konzentriert sich auf das Testen der Schnittstellen zwischen dem System unter Test und anderen Systemen und externen Diensten. Für Systemintegrationstests sind geeignete Testumgebungen erforderlich, die vorzugsweise der Betriebsumgebung entsprechen.

1. Der Abnahmetest konzentriert sich auf die Validierung und den Nachweis der Einsatzfähigkeit, d. h., dass das System die Geschäftsanforderungen des Benutzers erfüllt. 

2. Idealerweise sollten Abnahmetests von den vorgesehenen Benutzern durchgeführt werden. 

3. Die wichtigsten Formen des Abnahmetests sind: 

1. der Benutzerabnahmetest (user acceptance testing, UAT), 

2. der betriebliche Abnahmetest, 

3. der vertragliche und regulatorische Abnahmetest, 

4. der Alpha-Test und der Beta-Test.

Ein Abnahmetest, bei dem die Installation und Konfiguration des Sytems geprüft wird.

Ein Feldtest ist ein Abnahmetest, bei dem das Produkt stichprobenartig in einer realistischen Umgebung verwendet wird.Das ist v.A. empfehlenswert, wenn man es später mit vielen, unvorhersehbaren Einsatzumgebungen zu tun haben wird (bspw. ein Home-Router).

Hier wird das System von den Benutzern selbst validiert.Das ist besonders wichtig, wenn Auftraggeber und Benutzer später verschiedene Gruppen sind (bspw. wenn ein Onlineportal für Bürger entwickelt wird, was eine Behörde beauftragt hat).

Beides sind eine Art von Abnahmetest, bei denen Vorabversionen durch repräsentative Kunden getestet werden (ähnlich zum Feldtest).Alpha = Wird beim Entwickler ausgeführtBeta = Wird beim Kunden ausgeführt

• Funktionaler Test

• Nicht-funktionaler Test

• Black-Box-Test

• White-Box-Test

Beim funktionalen Test werden die Funktionen bewertet, die eine Komponente oder ein System erfüllen soll. 

Die Funktionen sind, „was" das Testobjekt tun soll.

Das Hauptziel der funktionalen Tests ist die Überprüfung 

1. der funktionalen Vollständigkeit

2. der funktionalen Korrektheit

3. der funktionalen Angemessenheit

Beim nicht-funktionalen Test werden andere als die funktionalen Eigenschaften einer Komponente oder eines Systems bewertet. Beim nicht-funktionalen Test wird geprüft, "wie gut sich das System verhält". Das Hauptziel des nicht-funktionalen Tests ist die Überprüfung der nicht-funktionalen Qualitätsmerkmale der Software.

1. Performanz

2. Kompatibilität

3. Gebrauchstauglichkeit

4. Zuverlässigkeit

5. IT-Sicherheit

6. Wartbarkeit

7. Übertragbarkeit

Im Rahmen von Reviews, Komponententest oder Systemtest

Weil sie einen Testrahmen bieten aber speziell prüfen, ob eine nicht-funktionale Bedingung erfüllt ist (z. B. die Prüfung, ob eine Funktion innerhalb einer bestimmten Zeit ausgeführt wird oder ob eine Funktion auf eine neue Plattform portiert werden kann).

Der Black-Box-Test basiert auf Spezifikationen und leitet die Tests aus der Dokumentation außerhalb des Testobjekts ab. 

Das Hauptziel des Black-Box-Tests besteht darin, das Verhalten des Systems gegen seine Spezifikationen zu überprüfen. 

Der White-Box-Test ist strukturbasiert und leitet Tests aus der Implementierung oder der internen Struktur des Systems ab (z. B. Code, Architektur, Arbeitsabläufe und Datenflüsse). 

Das Hauptziel des White-Box-Tests besteht darin, die zugrunde liegende Struktur durch die Tests bis zu einer akzeptablen Stufe zu überdecken. 

Alle vier genannten Testarten können auf allen Teststufen angewandt werden, auch wenn der Schwerpunkt auf jeder Stufe anders ist. 

Für alle genannten Testarten können unterschiedliche Testverfahren zur Ableitung von Testbedingungen und Testfällen verwendet werden.

Der Fehlernachtest bestätigt, dass ein ursprünglicher Fehlerzustand erfolgreich behoben wurde. 

Je nach Risiko kann man die behobene Version der Software auf verschiedene Arten testen, z. B:

1. Ausführen aller Testfälle, die zuvor aufgrund des Fehlerzustands fehlgeschlagen sind, oder auch durch

2. Hinzufügen neuer Testfälle, um alle Änderungen zu überdecken, die zur Behebung des Fehlerzustands erforderlich waren.

In dem Fall können sich Fehlernachtests darauf beschränken, lediglich die Testschritte auszuführen, die die durch den Fehlerzustand verursachte Fehlerwirkung produziert haben, und zu prüfen, ob die Fehlerwirkung nicht mehr auftritt.

Als Regressionstest bezeichnet man die wiederholte Ausführung bestehender Testfälle.

Sein Ziel ist zu zeigen dass eine Änderung (die ggf. bereits per Fehlernachtest geprüft wurde) keine nachteiligen Folgen hat.

Die nachteiligen Folgen könnten 

1. die Komponente betreffen, an der die Änderung vorgenommen wurde

2. andere Komponenten desselben Systems

3. andere verbundene Systeme

betreffen.

Nein, er kann sich auch auf die Umgebung beziehen.

Es ist ratsam, zunächst eine Auswirkungsanalyse durchzuführen, um den Umfang der Regressionstests zu optimieren. 

Die Auswirkungsanalyse zeigt, welche Teile der Software betroffen sein könnten.

1. Regressionstestsuiten werden viele Male durchlaufen,

2. Im Allgemeinen nimmt die Anzahl der Testfälle mit jeder Iteration oder jedem Release zu

3. Daher eignen sich Regressionstests sehr gut für eine Automatisierung eignen (bspw. über CI/CD)

Der Wartungstest beschreibt Tests, welche nach der Auslieferung und Inbetriebnahme der Software ausgeführt werden.

Der Test sollte nicht mit dem Wartbarkeitstest verwechselt werden.

1. Korrigierend (Bugfix)

2. Anpassung an neue Umgebung (bspw. neue OS-Version)

3. Neue oder verbesserte Features

4. Verbesserung der Wartbarkeit

Nein, es kann auch ungeplante umfassen (Hotfixes)

Eine Auswirkungsanalyse (d.h., welche System-/Code-Teile sind davon betroffen). Diese kann helfen Risiken vs. Vorteile besser abzuwügen.

1. dem Grad des Risikos der Änderung

2. der Größe des bestehenden Systems

3. dem Umfang der Änderung

1. Änderungen, wie z. B. geplante Erweiterungen (d. h. release-basiert), korrigierende Änderungen oder Hotfixes.

2. Upgrades oder Migrationen der Betriebsumgebung, z. B. 

   • bei Wechsel von einer Plattform auf eine andere, was Tests der neuen Umgebung erfordern kann

   • Tests der Datenkonvertierung, wenn Daten aus einer anderen Anwendung in das zu wartende System migriert werden

3. Außerbetriebnahme, z. B. wenn eine Anwendung das Ende ihres Lebens erreicht. 

   • Tests der Datenarchivierung erfordern

   • Testen von Wiederherstellungsverfahren