# Testing for continuous Quality
![image_556.png](image_556.png)

## 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**](01_ImplementingForMaintainability.md)

## Quadrant 2: Business-fokussierte Tests, die das Development leiten
- definiert Qualität/Features, die der Kunde möchte
- Funktionale Tests, die von [User-Storys](RequirementsAnalysis.md#user-stories) 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
  - ![image_794.png](image_794.png)
    - 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
![image_793.png](image_793.png)
- Tests adressieren Endpunkte der drei Komponenten
- sollten alle automatisch ausgeführt werden

- ![image_795.png](image_795.png)
  - 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
  - ![image_796.png](image_796.png)
  - ![image_797.png](image_797.png)
- 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](IntroductionOOAD.md#requirements-in-software-engineering)
- 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
![image_798.png](image_798.png)
![image_799.png](image_799.png)

- 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!**