Vortrag von Adrian Zwingli, CEO SwissQ aus Anlass der Präsentation der «Swiss Testing Trends 2010» im Haus zum Rüden, Zürich.
Auf die einführende Frage «Wer würde mit seiner eigenen Software zum Mars fliegen?» antworten nur die wenigsten Zuhörer mit einem Ja…
Die hier vorgestellten Trends im Software-Testing stammen aus einer Umfrage bei 1500 Testern in der Schweiz unter Abgleich mit internationalen Experten.
Aus der Trend-Wave kann man ablesen, welche Aktivitäten erst eingeführt werden, welche wachsen, welche reif sind und welche immer weniger benutzt werden.
Was sind die Herausforderungen beim Testen von Software?
Manchmal haben IT-Betriebsorganisationen 4 Releases pro Jahr, das Management wünscht aber 12 pro Jahr. Das bedeutet, dass das Testing anders organisiert werden muss.
Agile Vorgehensweisen und stark ändernde Testfälle mit wenig Dokumentation sind weitere Erschwernisse.
Dazu kommen noch Auflagen wie Effizienzsteigerung oder Investitionsschutz neu entwickelter Lösungen.
Alles müsste besser, schneller, billiger werden…
Deshalb muss ein Business Case für das Testing zusammengestellt werden.
Alle Trends werden in die 4 Gruppen eingeteilt:
1. Organisation und Ausbildung
2. Techniken
3. Lebenszyklus und Prozesse
4. Infrastruktur und Tools
1. Organisation und Weiterbildung
Viele halten Outsourcing zwar für wichtig, die wenigsten haben aber reife Outsourcing-Prozesse.
Die meisten Firmen haben Zertifizierungen der Testprozesse durchlaufen.
Die Entwicklertests müssen bei vielen Organisationen aber noch verbessert werden.
Quality Gates sind ein bekanntes Vorgehen, viele Organisationen haben aber Probleme, diese im Betrieb zu verankern.
Eine gute Testvision und Teststrategie kann zu einer zentralisierten Testingorganisation führen.
Kommen in einem Projektteam neue Tester hinzu, so reproduzieren sie zuerst die ‹Known Issues›. Dafür ist ein Bug Tracking-Tool unabdingbar.
Per Explorativem Testing werden dann meist 70% der Fehler bereits gefunden. Die restlichen 30% (falls dies überhaupt realistisch ist) werden in strukturierten Tests gefunden. Meist ist es aber so, dass ein Teil der Fehler erst in der Produktion und durch Kunden gefunden werden.
Service Katalog
Silvio Moser, CTO SwissQ
Motivation
Mit der zunehmenden Zentralisierung von Testaufgaben wandelt sich auch das Bild der Testingorganisation.
Wo früher Prozess und Methodik im Vordergrund standen, geht es nun darum, die Testorganisation vom Kostenverursacher zum Leistungserbringer zu wandeln.
Management (Strategische Ziele), Lieferanten (Kosten) und Kunden (Nachfrage) haben alle einen Impact auf den Service Katalog.
Strukturierung
– Tool Handling
– Functional Testing
– Test Automation
– Review
– Testkonzeption
– Planung & Steuerung
– Test Case Design
– u.v.m.
Kundensicht
– Test Management
– Funktionales Testing
– Test Automation
– Performance Testing
Lieferantensicht
– Benötigte Skills, Prozesse und Werkzeuge sind ersichtlich
– Kann mit einem Preisschild versehen werden
– Make or Buy Entscheid ist möglich
Teilaufgaben
Test Stragegie, WBS, Aufwandschätzung, Review, Reporting, Tool Handling, Analysis
Fazit
Nötig sind Transparenz über Inhalt, Kosten und Service-Level der Leistungen. Eine verbesserte Kommunikation zwischen Testorganisation und Kunden ergibt ein Fundament für optmierte und effiziente Test-Services.
2. Techniken
Alle behaupten, sie machten Requirements based Testing. Dies ist gefährlich bei der Ablösung von bestehenden, undokumentierten Systemen.
Risk based Testing ist aber eine gute Ergänzung dazu.
Regressionstests sind bei vielen Unternehmen verbreitet im Einsatz mit Testautomatisierung.
Use-Case based Testing setzt gute Use-Cases voraus. Sind diese nicht mehr aktuell, treten schnell Probleme auf.
End-to-End Tests oder Verbundtests beinhalten Tests über alle Systeme hinweg.
SOA-Testing ist nicht sehr verbreitet, obwohl alle von SOA sprechen. Hier eignen sich die konventionellen Testmethoden gut genug, so dass SOA-Testing wohl kein grosses Thema werden wird.
Non-functional Tests setzen andersartige Tests voraus, z.B. Performance-Tests. Hier braucht es sehr spezialisiertes Fachwissen.
TTCN-3 hat sich im Schweizer Markt als Testnotationssprache nicht durchgesetzt. Im Telekommarkt ist es verbreitet.
Die meisten Testtechniken stammen aus den 80-er Jahren. Wirklich Revolutionäres hat sich in diesem Umfeld seither nicht getan.
3. Lebenszyklus und Prozesse
Agile Methoden wie SCRUM oder Continuous Integration bringen neue Herausforderungen: Wohin releasen SCRUM-Entwicklungsteams? In die Produktion? Was ist dann mit den Schnittstellen?
Beachtet man aber gewisse Prinzipien, ist das Testing effizient möglich.
TMAP Next ist ein interessanter Trend, der sich vorerst verstärkt in Holland durchsetzt.
TMMI: Test Maturity Model Integrated hat sich noch nicht durchgesetzt.
TPI Next: Test Process Improvement ist ein organisationsorientiertes Verbesserungsverfahren für Testing-Prozesse.
4. Infrastruktur und Tools
Bug Tracking-Tools sind sehr verbreitet.
Capture & Replay ist z.T. auch als Open Source verfügbar, andere Tools auch als SaaS.
Die Testautomatisierung müsste in vielen Projekten erhöht werden.
Wenn es das Tool zulässt, sollte man auswerten in welchem Bereich die meisten Fehler auftreten. Die Folgefrage ist dann, weshalb sie nicht gefunden wurden.
Testautomatisierung
Tjeerd Olk
Kaum jemand ist wirklich zufrieden mit seinem Automatisierungstool.
Testautomation ist nicht gleich Testautomagic!
Welche Tests eignen sich? Was kostet es? Habe ich die richtige Strategie zum Automatisieren?
Die Mitarbeiter sind ebenso wichtig wie das Tool und die Methoden und Techniken.
Früher benutzte man Record and Play Back. Heute steht man eher bei Keyword Driven Testing oder Data Driven Testing: Laufen manuelle Tests einmal, werden sie danach möglichst automatisiert.
In Zukunft wird man Integrated Testing durchführen wollen: Von Anfang an sollen automatische Prozesse integriert werden, manuelle Tests nur wo nötig.
In Organisationen läuft die Testautomatisierung meist als Nebenaktivität. Besser sind dedizierte Automatisierungsteams. Künftig soll Business Driven Test Automation zum Ziel führen.
Bei den Tools hatte man früher noch Eigenentwicklungen. Heute sind generische Tools von grossen Lieferanten im Einsatz. Diese fokussieren meist auf Systemtests. Künftig sollen integrierte Testsuites alle Testfälle ohne Medienbrüche abdecken helfen.
Fazit
– Die Abgrenzung zwischen manuellem und automatisiertem Testen verschwindet
– Testautomatisierung nicht nur durch und für Spezialisten
– Automatisierte Scripts werden generiert statt selbst codiert
– Zunehmnder Einsatz von Open Source Lösungen
– One Stop Shop
Empfohlene Vorgehensweise für das Aufsetzen von Testprozessen:
1. Stragegie
2. Analyse
3. Design
4. Pilot
5. Implementierung
Wie üblich sollte man nach der Implementierung die Strategie neu überprüfen.
Die Testautomatisierung ist stark von den Testdaten abhängig. Das Thema wird stark unterschätzt und ist in der Schweiz ein Hot Topic.
Testdaten Management
Der Testleiter möchte seinen Test effizienter gestalten, hat aber Testdaten, die nicht stabil genug sind, z.B. wegen agiler Entwicklungsmethoden. Das bedeutet auch, dass die Testautomatisierung problematisch ist.
Aus Sicht des Managements hat der Datenschutz eine hohe Priorität, siehe Swiss Banking. Daraus entstehen Imagerisiken und rechtliche Risiken. Gemäss Datenschutzgesetz DSG müssen Daten hinreichend geschützt werden.
Eine Testdatenstrategie legt fest, wie man zu tauglichen Testdaten kommt. Dabei sind die Ansprüche an die Integrität und Verfügbarkeit von Testdaten stark gestiegen.
Schnellere Entwicklungszyklen bedingen auch eine schnellere Lieferung von Testdaten, wobei der Datenschutz immer gewährleistet sein soll. Alles zu verschlüsseln ist dabei keine Lösung: Welche Daten muss ich wirklich schützen?
Das Benutzerkonzept muss gewährleisten, dass auch im Test nur die berechtigten Personen Zugriff auf Daten haben. Wenn in der Produktion alles gesichert ist, im Test aber nicht, hat man ein Problem.
Häufig werden die Daten aus der Produktion kopiert und im Test 1:1 zur Verfügung gestellt. Dies ist in Grossunternehmen ein zu langsamer Prozess und vom Datenschutz her ungenügend.
Künftig wird man wohl «synthetische» Daten für Tests extra herstellen: Die neue Software und ihre Datenbank generieren die Testdaten anhand von Datengeneratoren oder Testautomatisierung.
Damit hat man keine Datenschutzprobleme und Testdaten zeitnah zur Verfügung.
Diese Methode kann auch mit konventionellen Testdaten kombiniert werden, z.B. dort wo sensible Daten betroffen sind.
Fazit
Das Thema Datenschutz ist sehr aktuell. D.h. es müsste einfach sein, beim Sponsoren Resourcen für das Thema zu gewinnen.
Effizienzverbesserung
20% des Testaufwandes fällt an beim Test Management, 50% beim Test Design, 30% bei der Test Execution.
Wartung der Testfälle: 20% Test Management, 40% Wartung der Testfälle, 10% neue Tests, 30% Ausführung der Tests
Effizienzsteigerung sollte beim grossen Testblock «Testdesign» ansetzen. Auch die Ausführung der Tests und die Wartung sind gute Optimierungskandidaten.
Dabei ist auch die Motivation der Tester zu beachten: Diese sollten Tests nicht einfach abnicken…
Das Testing wird von inneren Faktoren bestimmt, vom näheren Umfeld (z.B. Kostensenkungsvorgaben), aber auch von der Umwelt: Was, wenn neue Technologien wie .NET oder JAVA eingeführt werden, oder «disruptive Projects» gestartet werden?
Dokumentation der TrendWave 2010.
Beitrag zum gleichen Thema von Tjeerd Olk vom Beratungsunternehmen SwissQ.
Ein Kommentar
Mit Testen sollen Fehler gefunden werden. Leider beweist Testen nicht, dass keine Fehler mehr in der Software sind. Zudem frisst eine hohe Test Coverage ganz beträchtliche Projektressourcen.
Wir sollten uns vermehrt darauf konzentrieren, weniger Fehler zu machen. Es ist bereits heute keine Zauberei mehr, 50% der Codezeilen eines Produkts zu generieren. Das hilft der Qualität in vielerlei Hinsicht.
Erstens wird ab Software-Modellen generiert; die Modellierungstätigkeit und -tools fördern die sorgfältige Analyse und die Formalisierung des des Lösungsraums, meist sogar des Problemraums; das hat meist mehr mit Engineering zu tun als mit Design und Spezifikationen in Prosa (Stichwort «Powerpoint-Architekuren»).
Zweitens müssen Generatoren nur einmal getestet werden.
Drittens muss ein konzeptioneller Fehler in Modell oder Generator nur an einem Ort behoben werden, und der Code ist danach garantiert überall nachgefahren.
Und viertens macht es mehr Spass, Modelle und Generatoren zu entwickeln als hundertmal mit copy/paste editieren dasselbe Code-Pattern zu replizieren … und dabei bestenfalls keine Fehler zu machen … und am Ende dafür noch Test-Code schreiben zu müssen.
Schau Dir mal http://www.eclipse.org/Xtext an. Damit haben wir in Projekten schon über 80% nicht-trivialen Code generiert, unsere Qualität, Effizienz und Flexibilität markant gesteigert, und erst noch mehr Spass gehabt.