Softwaretests (QA)

Entwickler testen, was sie gebaut haben, nicht was Nutzer tun

Ein Entwickler prüft, ob das Feature wie geplant funktioniert. Ein Nutzer fügt eine Telefonnummer mit Leerzeichen ein, drückt mitten in der Zahlung auf Zurück, öffnet die Website auf einem drei Jahre alten Android-Handy oder hat zwei Tabs gleichzeitig offen. Das sind die Fälle, die Support-Tickets erzeugen, und sie stehen selten in einem Entwicklertest.

Unsere Tester gehen zuerst den erwarteten Pfad durch und versuchen dann bewusst das Unerwartete. Jeder Fehler wird so dokumentiert, dass ein Entwickler ihn in Minuten reproduzieren kann: das Gerät, der Browser, die genauen Schritte, was hätte passieren sollen und was passiert ist. Ein Screenshot oder eine Aufnahme liegt bei.

Der Schweregrad entscheidet, was zuerst behoben wird

Eine lange Liste von Bugs ohne Priorität ist fast so nutzlos wie keine Liste. Teams beheben zuerst die einfachen, und der Bug, der Menschen am Bezahlen hindert, wartet hinter einem verschobenen Icon. Wir bewerten jeden Bug nach seiner Wirkung auf Nutzer und Geschäft.

Kritische Probleme blockieren eine wichtige User Journey oder verlieren Daten. Schwere machen eine Journey schwierig oder betreffen viele Nutzer. Geringfügige sind kosmetisch oder selten. Der Zusammenfassungsbericht endet mit einer klaren Empfehlung: bereit zur Veröffentlichung, Veröffentlichung mit bekannten Problemen oder nicht bereit.

Für Teams, die häufig veröffentlichen, müssen dieselben Abläufe jedes Mal getestet werden. Das größte Paket automatisiert die wichtigsten mit Playwright oder Cypress, damit sie bei jedem Deployment laufen und Regressionen vor den Nutzern abfangen.

• Kritisch: blockiert Zahlung, Anmeldung oder eine andere wichtige Journey
• Schwerwiegend: eine Journey funktioniert, ist aber mühsam, oder viele Nutzer sind betroffen
• Gering: kosmetisch oder selten, bei Gelegenheit behoben
• Release-Empfehlung in klaren Worten