Antwort

Hintergrund:

Das Testen nicht-funktionaler Aspekte entstand, als klar wurde: Selbst die logisch funktionierende Funktionalität kann für einen Teil der Benutzer unangenehm, langsam oder unzugänglich sein. Solche Defekte sind schwer automatisch zu erkennen, daher spielen manuelle Tester eine Schlüsselrolle.

Problem:

Tester konzentrieren sich oft nur auf die Funktionalität und ignorieren Leistung, Benutzerfreundlichkeit und Zugänglichkeit. Nicht-funktionale Defekte sind schwer zu formalisieren und zu erklären, ihre Subjektivität erschwert eine eindeutige Bewertung.

Lösung:

Beim Testen sollte man bewusst Zeit für nicht-funktionale Überprüfungen einplanen. Für die Leistung messen Sie die Reaktionszeit (z. B. mit einer Stoppuhr), für die Benutzerfreundlichkeit beschreiben Sie Unannehmlichkeiten und geben Sie Beispiele an, für die Zugänglichkeit nutzen Sie Checklisten oder Werkzeuge (z. B. aktivieren Sie einen Screenreader).

Wesentliche Merkmale:

Erfordern klare Formulierung von Abnahmekriterien.
Die Bewertungsergebnisse sind häufig subjektiv, daher ist die Argumentation der Berichte wichtig.
Nicht alle solchen Defekte sind vor dem Release akzeptabel - einige sind kritisch.

Fallenfragen.

Sollte jeder nicht-funktionale Defekt von einem Tester in einem Bug-Report festgehalten werden?

Nicht immer. Wenn das Problem subjektiv ist, reicht es manchmal aus, es mit dem Team zu diskutieren und als Verbesserung festzuhalten (Feature-Request).

Sollte der Tester selbst Leistungsmetrik festlegen?

Nur wenn sie nicht in den Anforderungen oder dem Lastenheft festgelegt sind, sonst sollte man sich darauf stützen.

Ist spezielle Software oder Werkzeuge für nicht-funktionales Testen erforderlich?

Nein, grundlegende Überprüfungen sind durchaus manuell möglich (z. B. manuelle Zeitmessung, Analyse der Zugänglichkeit mit einer Checkliste).

Typische Fehler und Anti-Patterns

Ignorierung nicht-funktionaler Kriterien.
Subjektive Berichte ohne messbare Beweise.
Zu allgemeine oder verschwommene Titel und Beschreibungen von Bugs.

Beispiel aus dem Leben

Negativer Fall

Ein Tester bemerkte, dass die Katalogseite länger als 10 Sekunden lädt, aber er legte keinen Bug an, da er dachte, „das ist wahrscheinlich bei allen so".

Vorteile:

Er hat das Team nicht mit strittigen Tickets belastet.

Nachteile:

Benutzererfahrung wurde verringert, Kunden waren enttäuscht, das Management erfuhr von dem Problem nur durch Beschwerden.

Positiver Fall

Der Tester dokumentierte detailliert, dass die Katalogseite beim ersten Zugriff 12 Sekunden braucht, fügte einen Screenshot der Stoppuhr hinzu und schlug mögliche Optimierungen vor.