Methodik und Architektur
entscheiden über den Erfolg
UTAA® adressiert «by Design» die fünf häufigsten Ursachen des Scheiterns von Testautomatisierung.
UTAA wurde als Antwort auf die immer wiederkehrenden Herausforderungen der Testautomatisierung in grossen Projekten entwickelt. Projektverantwortliche kennen die Herausforderung: Fehlendes Vertrauen in die Testautomatisierung infolge schlechter Ergebnisse. Dies ist jedoch kein Naturgesetz. Mit einer bewährten Methodik und sichtbaren Ergebnissen kann das Vertrauen aller Projektbeteiligten und des Managements gewonnen werden.
UTAA® adressiert die 5 wesentlichen Probleme der Testautomatisierung:
1. Fehlende Teststrategie
Automatisiert wird, was manuell am meisten Zeit kostet oder was naheliegend scheint. Typischerweise sind das GUI-Tests. Es entsteht eine invertierte Testpyramide: viele langsame, brüchige End-to-End-Tests, wenig schnelle, stabile Komponenten- und API-Tests.
2. Tool-Fixierung
Proprietäre Testtools kosten schnell 50.000 bis 500.000 Franken oder Euro pro Jahr. «Testen ohne Programmierung» klingt gut in der Demo. Bei 10.000 Tests in einer Delivery-Pipeline trägt es nicht. Irgendwann beginnt die Programmierung um das Tool herum. Und jedes neue Tool schafft neue Abhängigkeiten.
3. Instabile Tests
Zufällig fehlschlagende Tests erodieren das Vertrauen in die gesamte Suite. Schon ab 1% unzuverlässiger Tests sinkt das Vertrauen signifikant. Die Folge: Testergebnisse werden ignoriert, tatsächliche Defekte bleiben unentdeckt.
4. Testautomatisierung wird nicht als Softwareentwicklung betrachtet
Kein Code Review für den Test-Code, keine Modularisierung, keine Versionierung. Test-Schulden wachsen schneller als der Nutzen. Der Capgemini World Quality Report 2023/24 zeigt: Nur 3% der Organisationen haben ihre Regressionstest-Suites vollständig in Delivery-Pipelines integriert.
5. QA als Silo
Qualitätssicherung als separate Abteilung bedeutet: späte Fehlererkennung, lange Feedback-Zyklen. Elite-Teams laut DORA deployen 973-mal häufiger als Low-Performer. Der Unterschied: Testing ist Teil der Entwicklung, nicht daneben.
Die Lösung
UTAA® steht für Universal Test Automation Architecture. Keine Software zum Kaufen, kein Framework zum Installieren. UTAA® besteht aus Prinzipien, Prozessen und Mustern, die Testautomatisierung als Teil der Softwareentwicklung verankern.
Testautomatisierung ist Softwareentwicklung
Test-Code verdient dieselbe Sorgfalt wie Produktionscode. Modularität. Code Review. Versionierung in Git. CI/CD-Integration. Wer das akzeptiert, bricht den Kreislauf aus steigendem Wartungsaufwand.
Keyword-Driven Testing, modern gedacht
Konsequente Trennung fachlicher Testszenarien von den wiederverwendbaren Keyword-Libraries. Der ISO/IEC/IEEE 29119-5:2024-Standard formalisiert diesen Ansatz. Robot Framework setzt ihn nativ um.
Lesbare Tests als Dokumentation
Tests in Plain Text können Fachbereich, Compliance-Verantwortliche und Auditoren lesen und prüfen. In FINMA-, DORA- und GxP-regulierten Umgebungen ist das eine Grundanforderung. Versioniert in Git ergibt sich der Audit-Trail ohne Zusatzaufwand.
Wiederverwendbarkeit auf allen Teststufen
Keywords werden einmal implementiert. Verwendet für Komponententests, Schnittstellentests, Integrationstests, E2E-Tests. Der Geschwindigkeits-Booster für die Testerstellung in jedem Projekt.
Synthetische Testdaten
Compliance by Design: Testdaten werden synthetisch generiert. Keine Produktionsdaten in Testumgebungen, keine versehentlichen Datenschutzverletzungen.
Offenheit
Robot Framework ist Python-basiert, aktiv gepflegt, open source und seit über 20 Jahren in Produktiveinsatz. Das einzige Framework, welches mit ausreichender Flexibilität natürliche Sprache für Tests ermöglicht. Keine Lizenzkosten. Keine Hersteller-Abhängigkeiten.
Thin Layer Architecture
Robot Framework als domänenspezifische Sprache auf der Testfallebene, Python als effiziente Engine für Keywords und Libraries. Tests beschreiben das Verhalten, Keywords implementieren es.
API-First, GUI nur wo nötig
GUI-Tests sind wartungsintensiv und langsam. UTAA® setzt auf API-Tests als Default. Schneller, stabiler, günstiger. GUI-Tests kommen dort zum Einsatz, wo sie wirklich gebraucht werden. Beide Varianten sind beliebig kombinierbar.
Bereit für KI-Komponenten
ML-Modelle und LLMs verändern, was getestet werden muss: Modell-Drift, Robustness, Halluzinationen. UTAA®-Keywords lassen sich um ML-Metriken (Accuracy, F1) und Drift-Checks erweitern — eine Suite für klassische und KI-Tests, ausgerichtet an ISO 25010 und ISO 25059.
Die Prozesse
Eine saubere technische Grundlage entfaltet ihren Wert erst mit den passenden Prozessen. UTAA® denkt beides zusammen.
Code Review für Testcode
Jede Änderung wird geprüft, wie bei Produktionscode. Das verhindert, dass Test-Schulden unbemerkt wachsen.
Git als Single Source of Truth
Branching, Merge Requests, nachvollziehbare Historie. Kein separates Testdokument das veraltet.
Continuous Testing
Tests laufen bei jedem Commit. Nicht erst am Ende eines Sprints, nicht erst vor dem Release. Fehler tauchen auf, wenn sie noch günstig zu beheben sind.
Strukturierter Keyword-Library-Aufbau
Wiederverwendbare Bausteine entstehen nicht zufällig. Sie werden systematisch entwickelt, dokumentiert und gepflegt — bevor Testfälle geschrieben werden.
Whole Team Quality
Testing ist Teamverantwortung, kein QA-Silo. Entwickler, Fachtester und Business-Analysten arbeiten mit denselben Testressourcen.
Perfekt für regulierte Umgebungen
UTAA® wurde in regulierten Umgebungen entwickelt und eingesetzt: BAFIN, FINMA, DORA. Lesbare Tests, Versionierung, konsistentes Reporting und stabile Strukturen erfüllen die Anforderungen an Nachvollziehbarkeit und Auditierbarkeit durch Design.