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

Wisst ihr, dass "70 bis 85 % der Fehler in Software auf unvollständige oder ungenaue funktionale Anforderungen zurückzuführen sind?"

"Es hat keinen Sinn, präzise zu sein, wenn man nicht einmal weiß, wovon man spricht." -John von Neumann

Kommen wir zur Frage, die ich in der Headline gestellt habe:

Wie kann die Zeit eines QA-Engineers am besten genutzt werden, wenn sich das Projekt noch in einem frühen Stadium befindet?

Testet die Anforderungen selbst, nicht das Produkt. Indem ihr die richtigen Fragen stellt, um implizite Annahmen in den Anforderungen aufzudecken und zu hinterfragen.

Dies könnte sich in dieser Phase am meisten auszahlen.

Ich denke auch, dass der Unterschied zwischen einem QA-Engineer und einem Testing-Engineer darin besteht, dass ein QA-Engineer Fehler von vornherein verhindert, während ein Testing-Engineer sie erst im Nachhinein findet.

Ich habe immer wieder erlebt, dass in Projekten, auch 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 gezielte Art des Testens ermöglicht oft eine intelligentere Untersuchung, wo 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 eurer Anwendung abdeckt:

• 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 tut): 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 Workflow als Beispiel aufgeschrieben:

• Anforderungen: formalisieren, aktualisieren, bei jedem Release als Use Case oder User Story festhalten.
• 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: Kern der QA-Arbeit hier, für jedes Release Tests durchführen oder neue Tests erstellen, um die meisten User Stories 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 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 eure Frage genauer zu beantworten: "Was kann ein QA-Ingenieur 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 die Use Cases auf sinnvolle Weise 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-Engineer (natürlich mit Zustimmung des CTO!) die Verantwortung übernehmen. Seit kritisch bei der Wahl der Tools, experimentiert ruhig mit anderen Tools, denn der QA-Engineer muss hier verantwortlich sein.
  • Arbeit an Tests: die Kernaufgabe der QA hier. Ihr seid dafür verantwortlich, dass jede User Story durch eine Reihe von Tests (Unit-/Integrations-/Endbenutzertests) abgedeckt wird, und zwar in einem Verhältnis von 70 % / 20 % / 10 % je Testart. Der kritische Pfad sollte für jede Version der Software manuell getestet werden.
  • Dokument 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 viele Probleme in diesem Bereich, sollten wir mehr in die Neugestaltung/Überarbeitung investieren?