HINWEIS: Dieser Beitrag ist Teil der Blogserie "Die brutale Wahrheit zum Testing", in der Sixsentix Experten ihr Wissen und teils schmerzhafte Erfahrungen zusammengetragen haben.
Software als entscheidender Erfolgsfaktor: Geschwindigkeit zählt
In den letzten Jahren hat der Markt große Anstrengungen unternommen, um Lösungen so schnell wie möglich zu liefern. Die Software hat sich von einer unterstützenden Rolle im Geschäft zu einem elementaren Teil des Geschäftsmodells selbst entwickelt. Beispielsweise ermöglichen E-Banking-Plattformen den Kunden, die Aufträge selbst abzuwickeln. Für viele Unternehmen bedeutete dies, dass die Software Architektur mit zusätzlichen Applikationsschichten ergänzt werden.
Der Grund dafür? Erstens versuchen sie, sich mit schnelleren und flexibleren Lösungen von der Konkurrenz abzuheben. Zweitens wollen sie den Markt mit neuen innovativen Lösungen aufmischen. Um auf das Beispiel der Banken zurückzukommen: Viele Finanzinstitute schaffen zusätzliche Marken (Unternehmen, Anwendungen, Dienstleistungen usw.), um neue Marktsegmente anzusprechen oder sogar neue Nischenmärkte zu kreieren.
Das Problem: Totaler Fokus auf die Innovation (und Vernachlässigung aller anderen Systeme)
Es ist auf jeden Fall eine Herausforderung, neue Dienste auf den bestehenden Backend-Systemen aufzusetzen und in kurzer Zeit einen anständigen Produkt-Release zu ermöglichen. Beispielsweise können die datenspeichernden Systeme durch gesetzliche Vorschriften oder die Verwendung veralteter Softwarearchitektur stark beeinträchtigt sein.
Dann haben Unternehmen die Agile Delivery Frameworks eingeführt, welche auf Innovationsprozesse zugeschnitten sind, in der Erwartung, das gleiche Ergebnis zu erzielen. Aber ist das wirklich möglich? Sind alle Unternehmen in der Lage, das nächste Spotify zu werden? Unserer Erfahrung nach ist das nicht so einfach. Es gibt einige ernsthafte Herausforderungen, die überwunden werden müssen:
- Die Systeme existieren nebeneinander, aber einige unserer Kunden bemerken das nicht einmal.
- Das Agile-Delivery-Framework passt nicht zu allen Systemen, nicht einmal im selben Unternehmen oder in derselben Organisation.
Quelle: Envato
Die Lösung: Orchestrierung von Tests zwischen allen Systemen
Andererseits kann eine neue App innerhalb der Systeminnovation über Nacht fertiggestellt werden. Daher sind der Zeitdruck und das Ausmaß der Abhängigkeiten entscheidende Attribute für eine schnellere Freigabe zwischen den drei Systemklassifizierungen.
Was sollen wir also tun? Sollten wir die Innovation verlangsamen, um die Systeme der Differenzierung und der Aufzeichnung in unser Modell einzubinden? Definitiv nicht!
Der Ansatz von Sixsentix besteht darin, die Qualitätssicherung und insbesondere die Disziplin der Testarchitektur als Orchestrator zwischen den Systemen einzusetzen. Der Hauptzweck der Testarchitektur besteht darin, die Systeme der Differenzierung und der Aufzeichnung darauf vorzubereiten, mit dem Tempo des Systems der Innovation Schritt zu halten oder es sogar zu erhöhen!
Unser Kundenportfolio besteht aus mittelgroßen und großen Unternehmen aus verschiedenen Geschäftsbereichen, die eines gemeinsam haben - die meisten von ihnen haben sehr schnell neue Systeme zur Differenzierung und Innovation entwickelt. Hier sind einige der entscheidenden Lektionen, die wir bisher gelernt haben:
- Risikobasiertes Testen bringt zwei wesentliche Vorteile beim Testen von Anwendungen innerhalb des Systems of Record. Auf der einen Seite spielt es die Rolle des Qualitätshüters für das System of Record. Auf der anderen Seite hilft es dem Innovationssystem, schneller Beweise zu erhalten und folglich frühzeitig zu entscheiden, ob es in die Produktion gehen soll oder nicht.
- Jedes System benötigt eine andere Art von Teststrategie, und jede Teststrategie muss die Koexistenz mit den anderen Systemen berücksichtigen. Eine Teststrategie (d.h. ein Ansatz, eine Infrastruktur, ein Tool) passt nicht zu allen Systemen.
Quelle: Sixsentix's Adaption von Gartner's Pace-Layered Application Strategy
Der Sixsentix-Weg: Der Einsatz der Testarchitektur zur Überbrückung der Lücken
Zur weiteren Veranschaulichung dieser Ideen betrachten wir die Situation bei einem unserer Kundenunternehmen, bei dem wir viele Abhängigkeiten zwischen dem System der Innovation (d.h. den mobilen Apps) und dem System der Aufzeichnung (d.h. dem CRM des Kerngeschäfts) feststellten.
Bevor wir unseren Testarchitektur-Service implementierten, stellten wir die folgenden Symptome fest:
- Überlastung der Lieferrückstände
- Abhängigkeiten zwischen agilen Teams verbrauchten fast die gesamte Entwicklungskapazität
- Die Lieferziele (Markteinführungszeit) konnten nicht erreicht werden
- Entdeckung von Nebeneffekten in der Produktionsumgebung
- Enormer Aufwand für die Konsolidierung von Testnachweisen für auditrelevante Systeme
Doch nach der Implementierung des Dienstes konnten wir eine Reihe von Verbesserungen feststellen:
- Die Qualitätssicherung unterstützt schnellere Releases mit risikobasierten Tests
- Der Grad der Testautomatisierung wurde massiv verbessert und ermöglicht Continuous Testing
- Prüfungsrelevante Testnachweise werden dank der methodischen Testabdeckung effizient geliefert
- Beim geschäftsrelevanten Testen werden die Abhängigkeiten besser verstanden und daher die Backlogs aller drei Systeme besser aufeinander abgestimmt und priorisiert
- Auf organisatorischer Ebene wurde die Linksverschiebung ermöglicht.
Quelle: Envato
Diese Perspektive auf häufige SDLC-Herausforderungen ist das Ergebnis der Erfahrung von Sixsentix bei der Beratung und Operationalisierung von QA-Lösungen in großen Unternehmen. Der Artikel ist auch im Rahmen der Werbeaktivitäten unseres Unternehmens auf der EuroSTAR-Konferenz entstanden. Wenn Sie mehr über unseren Testarchitektur-Service erfahren möchten, besuchen Sie diesen Link oder kommen Sie an unserem Stand auf der EuroSTAR-Konferenz in Antwerpen vom 13. bis 16. Juni 2023.