CIOs, IT-Führungskräfte,
Product Owner
Projektmanager,
Application Manager
Software-Architekten,
IT-Architekten
Engineering-Leader
Sie sind für das Testbudget verantwortlich. Hierbei müssen Sie sicherstellen, dass jeder Cent den höchsten Effekt auf die Fehlerrisikominderung hat.
Zusätzlich zu einem begrenzten Budget haben Sie möglicherweise auch nur eine begrenzte Zeit für das Testen eines Release Candidate vor dem Launch.
Da einige Softwaresysteme essentiell für den Geschäftsbetrieb sind, ist deren fehlerfreier Release unabdingbar.
Zusätzlich zu den automatisierten Tests gibt es daher immer eine umfangreiche Phase manueller Tests, bevor ein Release live geht.
Diese Tests werden von einem internen Team oder von einem Drittanbieter durchgeführt.
Sie verfolgen aktuell einen White-Box-Testing-Ansatz, d. h. Sie führen Testfälle aus, die mit den für einen Release-Kandidaten implementierten Anforderungen verbunden sind. Das ist kostspielig, weil Sie die gesamten Testsuiten ausführen müssen - selbst wenn hinter einigen Codeänderungen kein tatsächliches Risiko steht.
Manchmal müssen Sie aufgrund der begrenzten Testzeit einige Testfälle auslassen. Wenn Sie aber nicht in der Lage sind, das Risiko innerhalb eines Release Candidate richtig zu lokalisieren, werden Sie wahrscheinlich die falschen Testfälle überspringen und Fehler könnten übersehen werden.
Codierungsarbeiten an Funktionalität A können Nebeneffekte auf Funktionalität B haben, wenn sie denselben Code verwenden. Ohne Analysen des Codes und der Codierungsaktivitäten können Sie diese Nebeneffekte nicht erkennen und Fehler sind wahrscheinlich.
Mit KPIs, die Analysen zu Code und Codeänderungen interpretieren, wissen Sie, welche Anforderung bzw. Änderungsanforderung das größte Fehlerrisiko birgt. Sie könnten das Risiko mit weniger Testaufwand mindern.
Mit Analysen zur Codeabdeckung durch manuelle und automatisierte Tests können Sie sehen, wie gut Funktionalität X bereits durch automatisierte Tests abgesichert ist und wo die blinden Flecke sind, die noch durch manuelle Tests abgedeckt werden müssen.
Analysen können den architektonischen Code-Footprint einer Funktionalität aufzeigen und anzeigen, wie stark diese im aktuellen Release Candidate verändert wird. Auf diese Weise würden Sie sogar mögliche Nebeneffekte erfassen, die durch üblicherweise vernachlässigte Codebereinigungen verursacht werden.
August-Bebel-Str. 26-53
14482 Potsdam, Germany
hello@seerene.com
+49 (0) 331 706 234 0
Seerene GmbH
August-Bebel-Str. 26-53
14482 Potsdam, Germany
hello@seerene.com
+49 331 7062340