zusammenfassungen/Writerside/topics/04/Software Engineering/02_TestingForContinuousQuality.md

Testing for continuous Quality

Quadrant 1: Technologie-fokussierte Tests, die das Development leiten

• Developer Tests:
  • Unit tests
    • Verifizieren Funktionalität eines kleinen Subsets des Systems
    • Unit Tests sind die essenzielle Basis einer guten Test-Suite
      • Verglichen mit anderen, sind sie einfach zu erstellen und warten
      • Viele Unit-Tests :)
  • Component-/Integration Tests:
    • Verifizieren Verhalten eines größeren Teils
• Tests sind nicht für den Kunden
• Implementierung

Quadrant 2: Business-fokussierte Tests, die das Development leiten

• definiert Qualität/Features, die der Kunde möchte
• Funktionale Tests, die von User-Storys abgeleitet werden
  • bspw. GUI-Tests, Integration-Tests
  • (Mock-Up-Tests, Simulationen) → wird nicht behandelt
    • GUI-Designs mit User validieren, nicht automatisiert
• Sollten zum Großteil automatisiert als Teil der CI/CD-Pipeline laufen
  • am besten auf Production-Code
• Implementierung
  • Direkte Kommunikation zwischen Kunden/Developer
  • TDD umsetzen
    • Erst simplen Happy-Path-Test implementieren
    • Dann Code
    • Dann mehr Tests
    • mehr Code
  • Sobald ein Test ein erstes Mal erfolgreich ist, sollte er nicht mehr fehlschlagen
    • Es sei denn: Anforderungen haben sich geändert

Q2: Service Testing

• Production Code durch externe Schnittstellen testen
  • bspw: Extern sichtbare Interfaces(Klassen/Funktionen, aufgebaut nach Facade Pattern), API, Event-Gesteuerte Interfaces (Kafka, MQTT)
• Vorteile:
  • weniger fragil als UI-Tests
  • sehr günstig zu warten
• Tests bieten eine "lebende Dokumentation", wie das System sich verhält

Implementierung Service Tests

• API-level Test-Frameworks unterstützen
  • 
    • Test-Framework
      • unterstützt restliche Teile bei Test-Definition und -Ausführung
    • SystemUnderTest
      • Zeigt auf die Komponente, die durch das Interface gezeigt wird
    • Tests/Beispiele
      • Test-Szenarien, technologie-unabhängig
    • Test-Methode

Beispiel Service Testing

• Tests adressieren Endpunkte der drei Komponenten

• sollten alle automatisch ausgeführt werden

• 

  • 2 Tests:
    • happy-path
    • invalid username
  • Input wird der Test-Methode TestLogin gegeben
  • Dann weiter als Variable in den Production-Code
  • Erwartetes Ergebnis wird mit dem tatsächlichen Ergebnis verglichen
  • Wie Daten hin und zurück kommen, müssen Tester und Coder besprechen

Q2: User Interface Testing

• Production-Code durch UI testen
• Simulieren Nutzer-Verhalten
  • ist dennoch möglich zu automatisieren

Beispiel UI-Testing (mit Selenium)

• Selenium ist ein Framework für automatisierte UI-Tests
  • 
  • 
• Tests sind sehr fragil
  • Vor allem, die Teile, bei denen Elemente auf der Webseite ausgewählt werden

Quadrant 3: Business-fokussierte Tests, die das Projekt kritisieren/evaluieren

• manchmal sind Anforderungen nicht gut genug, um gewünschtes Produkt zu designen
  • Tests evaluieren, ob Software Erwartungen genügt
    • Emulation von User-Interaktionen
• Manuelles Testen, das nur ein Mensch ausführen kann
• Typen:
  • User Acceptance Testing (UAT)
    • neue Features austesten lassen
  • Usability Testing
    • Fokus-Gruppen werden studiert und interviewt, während sie die Anwendung nutzen
    • Wissen, wie die Nutzer Systeme nutzen, ist ein Vorteil, wenn man die Nutzbarkeit testet
  • Exploratory testing
    • Tester denken sich selbst neue Tests aus, die sie dann auch durchführen
      • benötigt viel Kreativität und Intuition
    • wird von einer Strategie geleitet und durch Guidelines eingegrenzt

Quadrant 4: Technologie-fokussierte Tests, die das Projekt kritisieren/evaluieren

• Tests, die Charakteristiken wie Performance, Robustheit, Sicherheit sicherstellen
• Sollten in jedem Schritt des SDLC beachtet werden

Q4: Security Testing

• Technologie fokussierte Tests von einem wichtigen, nicht-funktionalen Aspekt
• Sicherheits-Bugs sind sehr kostenintensiv, wenn sie erst spät im SDLC gefunden werden
• Security-Testing: Denken wie ein Hacker

Tools und Techniken für Security Testing in verschiedenen Stages

• Static Application Security Testing (SAST)
  • bspw. nicht-verschlüsselte Passwörter darstellen
• Software Composition Analysis (SCA)
  • Identifiziert Schwachstellen in 3rd-Party-Abhängigkeiten
  • kann in CI/CD integriert werden
• Image Scanning
  • Scannt Container-Images
  • kann in CI/CD integriert werden
• Dynamic Application Security Testing (DAST)
  • Analysiert, wie die Anwendung auf spezifisch angepasste Anfragen reagiert
  • kann in CI/CD integriert werden
    • brauchen teilweise länger in der Ausführung
• Manual exploratory testing
• Penetration (pen) -Testing
  • beinhaltet einen professionellen Security-Tester
  • sollte nah am Ende des Auslieferungs-Kreislaufs geschehen
• Runtime Application Self Protection (RASP)
  • Anwendung durchgängig auf mögliche Attacken beobachten und diese verhindern
  • bspw. durch automatische Beendung von Prozessen

Q4: Performance Testing

• Performance kann anhand verschiedener Faktoren gemessen werden
  • Antwort-Zeit
    • WebApplikationen bspw. sollten max. 3 Sekunden für eine Antwort brauchen
  • Durchsatz/Parallelität
    • Anzahl an Anfragen, die innerhalb einer Zeitspanne unterstützt werden können
  • Verfügbarkeit
• Faktoren, die Performance beeinflussen:
  • Architektur-Design
    • bspw. Caching-Mechanismen
  • Wahl des Tech-Stacks
    • Technologien sind unterschiedlich schnell
  • Code-Komplexität
  • Datenbank-Wahl und -Design
  • Netzwerk-Latenz
    • Alle Komponenten kommunizieren darüber
    • Falls schlechtes Netz → langsame Anwendung
  • Physischer Ort der Nutzer
    • Distanz spielt eine Rolle
  • Infrastruktur
    • CPU, RAM, etc.
  • 3rd Party Integrationen
    • Sind meistens außerhalb der Kontrolle
    • Sollten auch anhand von Performance-Werten ausgewählt werden

Typen von Performance Tests

• Load/Volume Tests
  • Verifizieren, dass das System den benötigten Durchsatz liefert
  • werden meist mehrfach durchgeführt → Durchschnitt
• Stress Tests
  • Womit kommt die Anwendung noch klar?
    • bspw. viele User
  • Exakte Messungen werden benötigt, um die Infrastruktur anhand der Ergebnisse zu planen
• Soak Tests
  • Wird die Performance über Zeit schlechter?
  • Hält die Anwendung durchgängig unter einem konstanten Workload

Testing Automation Pyramide

• Unit Tests
  • Verifizierung von einem kleinen Subset des Systems
• Integration Tests
  • Testen einer Gruppe von Klassen
• Contract Tests
  • API-Tests für Module, die gerade entwickelt werden
• Service Tests
  • API-Tests, die individuelle Module testen
• UI-Tests
  • Simulieren Nutzer-Verhalten für bestimmte Features
• End-to-end-Tests
  • Simulieren Nutzer-Verhalten für eine komplette Interaktion (inkl. externe Systeme)

Achtung: Nicht-Funktionale Tests werden hier nicht beachtet!