Was kann ein Testengineer tun, wenn sich ein Projekt in einer frühen Phase befindet?

Ich habe immer wieder erlebt, dass in Projekten, selbst in späteren Phasen, grundlegende Annahmen entweder nicht ganz korrekt sind oder zumindest nicht verstanden und im Team infrage gestellt werden.

Viele, die erst spät in das Projekt einsteigen, machen sich entweder nicht die Mühe oder haben nicht das Vertrauen/den Mut, die grundlegenden Annahmen in den Anforderungen systematisch zu analysieren und zu hinterfragen.

Um das Testen von Anforderungen effektiver zu gestalten, könnt ihr einen Ansatz verwenden, der als heuristisches Testen oder Testen mit einer Strategie bezeichnet wird, die sich auf vergangene Daten über Wahrscheinlichkeiten stützt. Diese zielgerichtete Art des Testens ermöglicht oft eine intelligentere Untersuchung der Stellen, an denen Fehler oder Probleme auftreten können, auch beim Testen von Anforderungen.

Mit dieser Strategie lässt sich feststellen, welche Arten von Fehlern wahrscheinlich sind und wie häufig Fehler in bestimmten Teilen des Codes auftreten. Es hilft auch, die Anforderungen anhand einer gesammelten Basis von Problemen zu überprüfen. Achtet darauf, dass ihr alle diese Bereiche in Anwendung abdecken:

• Struktur (was das Produkt ist): Handelt es sich um ein einziges Programm oder um mehrere? Welche physischen Teile werden mitgeliefert? Kann ich es Modul für Modul testen?
• Funktion (was das Produkt macht): Was sind seine Funktionen? Welche Art von Fehlerbehandlung gibt es? Welche Art von Benutzeroberfläche hat es? Gibt es etwas, das für den Benutzer nicht sichtbar ist? Wie arbeitet es mit dem Betriebssystem zusammen?
• Daten (was sie verarbeitet): Welche Arten von Eingaben werden verarbeitet? Wie sieht seine Ausgabe aus? Welche Arten von Modi oder Zuständen kann es einnehmen? Wird es mit voreingestellten Daten ausgeliefert? Ist eine der Eingaben zeit- oder sequenzierungsabhängig?
• Plattform (wovon sie abhängt): Auf welchen Betriebssystemen läuft es? Muss die Umgebung auf besondere Weise konfiguriert werden? Ist sie von Komponenten Dritter abhängig?
• Betrieb (wie wird es verwendet): Wer wird es benutzen? Wo und wie wird sie genutzt? Wofür werden sie sie nutzen? Gibt es bestimmte Dinge, die die Benutzer eher tun werden? Gibt es Benutzerdaten, die die Tests realistischer machen würden?

Ihr könnt eure eigenen Heuristiken erfinden und sie sowohl auf die gesamte Anwendung als auch auf die Anforderungsanalyse anwenden.

Gute Anforderungen sollten klar und präzise sein, ohne Unklarheiten oder Mehrdeutigkeiten; sie sollten in Form von spezifischen Werten messbar sein; sie sollten prüfbar und vollständig sein; und sie sollten keine Widersprüche enthalten.

Weitere Lektüre: https://www.softwaretestinghelp.com/how-to-test-software-requirements-specification-srs/

Um meine „Vorstellung“ von QA während der Projekt-/Produktentwicklung zu verdeutlichen, habe ich den folgenden Arbeitsablauf als Beispiel aufgeschrieben:

• Anforderungen: Formalisiert sie, aktualisieren sie, verfolgt sie bei jedem Release, als Anwendungsfall oder User Story.
• Tests definieren: Definiert, wie die User Story getestet werden soll, wobei auch Randfälle berücksichtigt werden sollten.
• Werkzeuge: Findet das richtige Werkzeug/Framework/System zur Erstellung von Tests
• Tests: Die Hauptarbeit der QA besteht darin, für jede Version Tests durchzuführen oder neue Tests zu erstellen, um die meisten User Storys abzudecken. Es gibt die folgenden Testtypen:
  • Unit-Test: Code muss immer und überall auf Randfälle (Null, schlimmstes Szenario) getestet werden
  • Integrationstest: API-Integrationstest, z. B. mit einem Tool wie Postman
  • Endbenutzertest: nicht automatisierbare Tests, sollten sich um die wichtigsten Anwendungsfälle kümmern und können von Hand (oder mit der Maus) durchgeführt werden
  • Dokument & Retrospektive: Verfolgen von Releases, durchgeführten / akzeptierten / fehlgeschlagenen Tests, um Einblicke in die nächsten Schritte zu erhalten, wo das Team besser werden kann

Um meine Eingangsfrage beantworten: „Was kann ein Testengineer tun, wenn sich ein Projekt in einer frühen Phase befindet?“, ist für mich

• Hilfe in der Anforderungsphase: sie verstehen, helfen, sie zu verfolgen, und sicher sein, dass jede Anforderung einen Akzeptanztest haben sollte, im Klartext schreiben. Einen Weg zu finden, sie zu spezifizieren, zu verfolgen, zu organisieren und in einem "Test-Wiki/Dokument" auf dem neuesten Stand zu halten, ist eine große Aufgabe. Ich habe es als nützlich empfunden, nicht nur eine User Story/einen Use Case zu definieren, sondern eine „User Journey“, um Use Cases sinnvoll miteinander zu verbinden). Das gesamte Team könnte von dieser Arbeit profitieren und der QA-Ingenieur kann besser und schneller verstehen, was das System tut und warum, und die folgenden Phasen organisieren.
• für die Definition von Tests und Werkzeugen zuständig sein: Es ist wichtig zu entscheiden, was, wann und wo getestet werden soll! Auch hier sollte der QA-Ingenieur (natürlich mit Zustimmung des CTO!) die Verantwortung übernehmen. Seien Sie kritisch bei der Wahl der Werkzeuge, experimentieren Sie ruhig mit anderen Werkzeugen, denn der QA-Ingenieur muss hier verantwortlich sein
• Arbeit an Tests: die Kernaufgabe der QA hier. Sie sind dafür verantwortlich, dass jede Benutzergeschichte durch eine Reihe von Tests (Unit-/Integrations-/Endbenutzertests) mit einem Anteil von 70 % / 20 % / 10 % je Testart abgedeckt wird. Der kritische Pfad sollte für jede Version der Software manuell getestet werden.
• Dokumentation und Retrospektive: nicht vergessen! Helft dem Projekt-/Produktmanager, Verbesserungsmöglichkeiten zu erkennen, Vorschläge zu machen und Feedback zu Problemen zu geben, damit die Planung von Funktionen/Bildern einfacher wird. Zum Beispiel: Wir hatten eine Menge Probleme in diesem Bereich, sollten wir mehr in die Neugestaltung/Überarbeitung investieren?

Eine Grundlage für Qualität schaffen

Im Moment bitten wir den QA-Ingenieur, die Geschäftsanforderungen des Kunden durchzugehen und die vorhandene Funktionalität anhand dieser Anforderungen zu validieren sowie sich mit der Roadmap vertraut zu machen.

Das ist für einige Schlüsselszenarien gut. Darüber hinaus kann es jedoch zu einem Testaufbau führen, der eher einer Eistüte als einer agilen Testpyramide ähnelt, mit umfangreichen End-to-End-Selenium-Tests, die langsam und unzuverlässig sind.

Anstatt sich nur darauf zu konzentrieren, viele langsame und unzuverlässige automatisierte UI-Tests hinzuzufügen, ist dies für ein Unternehmen in der Anfangsphase eine Gelegenheit, das Fundament für Qualität zu legen. Schließlich werden Tests an sich ein Produkt von geringer Qualität nicht verbessern.
Vor allem, wenn sie von jemand anderem geschrieben wurden.

Später im Prozess.

Um die Qualität zu verbessern und Fehler in der Software zu reduzieren, sollte ihr diese im Laufe der Zeit messen und überwachen:

• Nutzung des Produkts durch die aktuellen Produktionsbenutzer
• Die Funktionen werden so genutzt, wie es sich das Unternehmen vorstellt
• Es sind Messwerte für die Nutzung durch wichtige demografische Gruppen und Geräte verfügbar
• Nutzung in Bezug auf Umsatz, Akzeptanz oder andere Maßnahmen oder KPIs
• Länge der Laufzeit von Testsuiten
• Abdeckungsgrad der Einheitstests des Anwendungscodes
• 100% sollte die allgemeine Regel sein
• Test auf Parameter, die null, fehlend, leer oder nicht vorhanden sind
• Durchschnittliche LOC-Methoden-/Klassengrößen im Anwendungscode
• Durchschnittliche Komplexität der Methoden im Anwendungscode
• Durchschnittlicher Zeitaufwand für die Behebung eines Produktionsfehlers
• Mittlere Zeit für Tickets vom Eingang bis zur Bereitstellung
• Mittlere Zeit zwischen Produktionsfehlern
• CI UI Automation Code-Fehlerrate - Zielwert N5 (00,001%)
• Anhängige Tests - Zielwert Null
• Größe des Backlogs
• Veränderung der Größe des Auftragsbestands im Laufe der Zeit - Zielwert Null
• Leistung der Anwendung

Achtet auch auf weichere und subtilere Faktoren, die schwieriger zu messen sind, wie z.B.

• Gute Benennung von Anwendungscode-Objekten
• Fragen der Benutzerfreundlichkeit in Bezug auf Schriftarten, Farben und Größen für alle Benutzer
• Bereichsspezifische Fragen der Benutzerfreundlichkeit für Systeme und Ökosysteme
• Maximierung der Zugänglichkeit, um den größten Marktanteil zu erreichen
• Maximierung der Zugänglichkeit für Benutzer mit unterschiedlichen körperlichen Fähigkeiten
• Emotionen im Zusammenhang mit Farbschemata
• UI-Konsistenz
• Verbales und interaktives Feedback von wichtigen Nutzern
• All diese verschiedenen Aspekte auszubalancieren ist der Grund, warum Qualität so schwierig ist.