Erkunden von Shift-Left-Tests
Tests im Anwendungslebenszyklus-Management sind unerlässlich, um die Codequalität zu maximieren und das Betriebsrisiko zu minimieren, das mit der Bereitstellung und Aktualisierung von Software verbunden ist. Der Begriff Shift-Left steht in diesem Zusammenhang für die Idee, die Testaktivitäten so früh wie möglich in die Entwicklungsphase zu verlegen. Die Organisation in unserem Beispielszenario sollte erwägen, diesen Ansatz in die DevOps-Strategie einzubeziehen, um die aktuellen Sicherheits- und Stabilitätsprobleme zu minimieren. Überprüfen Sie in dieser Einheit verschiedene Arten von Tests, die auf diese Weise implementiert werden können, und überprüfen Sie dann ihre Implementierungsmethoden.
Welche Tests sollten Bestandteil von Shift-Left-Tests sein?
Softwareentwicklung umfasst eine Vielzahl von Testtypen, aber insbesondere die, die für uns von Interesse sind:
Komponententests: Diese Tests konzentrieren sich auf die kleinsten testbaren Teile eines Anwendungscodes, z. B. einzelne Funktionen oder Methoden. Ziel ist es, festzustellen, ob jede Codeeinheit den vorgesehenen Vorgang isoliert vom Rest der Codebasis und externen Abhängigkeiten ausführen kann. Solche Tests sollten vollständig automatisiert, schnell (innerhalb von 30 Sekunden abgeschlossen) und eine vollständige Codeabdeckung bereitstellen (was im Grunde bedeutet, dass alle Komponententests die gesamte Codebasis gemeinsam testen sollten). Komponententests eignen sich für den Shift-Left-Ansatz. Wir empfehlen, ihn so früh wie möglich auf den gesamten Code anzuwenden, vorzugsweise zu Beginn der Programmierungsphase.
Rauchtests: Diese Tests sollen die Kernfunktionalität einer Anwendung in einer Testumgebung bewerten. Während sie die tatsächliche Anwendung testen (anstatt einzelner, isolierter Komponenten, wie es bei Komponententests der Fall ist), besteht ihr Zweck darin, zu bestimmen, ob die erstellte Anwendung oder die Bereitstellung ausreichend stabil ist, um eingehendere Tests zu rechtfertigen. Sie überprüfen jedoch nicht die Interoperabilität zwischen Apps. Wie bei Komponententests sollten sie vollständig automatisiert und relativ schnell sein (Benutzerinteraktionen können mithilfe von Browserautomatisierungstools und Benutzeroberflächenautomatisierungs-Frameworks simuliert werden). Der Begriff Rauchtest soll die Idee vermitteln, dass Rauch ein großes Problem (Feuer) darstellt, das möglichst schnell behandelt werden sollte. Rauchtests sollten auch frühzeitig im Entwicklungszyklus implementiert werden, vorzugsweise sobald eine Version der Software verfügbar ist, die ihre Kernfunktionen bereitstellt. Dies gilt sowohl für die Anwendungsbuild- als auch für die Bereitstellungsphase.
Integrationstests: Diese Tests überprüfen die Interaktion zwischen verschiedenen Anwendungskomponenten. Im Gegensatz zu Komponententests können sie viel Zeit in Anspruch nehmen. Die erweiterte Dauer dieser Tests wird häufig als Argument für die frühe Ausführung des Softwareentwicklungslebenszyklus verwendet. Im Allgemeinen sollten Sie Integrationstests in Szenarien in Betracht ziehen, für die Komponenten- oder Buildakzeptanztests nicht geeignet sind. Allerdings wird empfohlen, sie in regelmäßigen Intervallen durchzuführen. Dieser Ansatz bietet einen angemessenen Kompromiss zwischen einer potenziellen Verzögerung bei der Erkennung von Integrationsproblemen und einer zusätzlichen Wartezeit, die erforderlich ist, um sie abzuschließen.
Akzeptanztests: Diese Tests bestimmen, ob ein Softwareprodukt die Geschäftsanforderungen erfüllt und bereit für eine Lieferung an seine Verbraucher ist. Akzeptanztests eignen sich nicht für die Shift-Left-Strategie, aber es kann möglich sein, einige seiner Elemente frühzeitig in den Softwareentwicklungslebenszyklus zu integrieren. Beispielsweise sollten Akzeptanzkriterien und Benutzergeschichten, die wesentliche Komponenten von Akzeptanztests sind, frühzeitig im Entwicklungsprozess eingeführt werden. Dies erleichtert die Zusammenarbeit zwischen Entwicklungsteams, Produktbesitzern und Projektbeteiligten. Darüber hinaus sollten Softwareanwender und Projektbeteiligte in den früheren Testphasen einbezogen werden, um ihr Feedback zu teilen. Dies kann die Verwendung von Methoden wie Alpha- oder Betatests, Benutzerfreundlichkeitstests oder frühen Versionen voraus der formalen Akzeptanztests umfassen.