Vorstellungskraft und Innovation

von Olivier Renault

In einer früheren Ausgabe der Testing Experience [1] – „Die Zukunft des Testens durch den Einfluss von Open Source“ schrieb ich über die Zukunft des Testens durch die Nutzung von Open-Source-Tools and die Anwendung kollaborativer Arbeitsweisen. Aber was benötigen wir, um dort hinzukommen? Welche Fähigkeiten benötigen die Tester der Zukunft?

continuous integration

DevOps

Die Nutzung so mancher technischen Konzepte wie Agile Development, Cloud Computing, Continuous Integration und anderen hat sich inzwischen mehr und mehr verbreitet. Daraus entstand eine Bewegung, die DevOps genannt wird [2]. DevOps ist eine Antwort auf eine Gleichung, die nicht unmöglich zu lösen ist, sondern eben nur schwierig: Wie kann man die Qualität von Systemen verbessern und gleichzeitig die Softwareauslieferungen erhöhen, während in der Produktion ständig Änderungen anfallen?

Mit der Anwendung von Agile und Continuous Integration erreichen Entwickler (Development) ihr Ziel, schnell und oft auszuliefern und die Entwicklung von neuen Features zu vervielfachen.

Aber der IT-Betrieb (Operations) dagegen hat ein anderes Ziel, nämlich die Produktion am Laufen zu halten und dabei nicht zu viel mzustrukturieren, um eventuell viele Änderungen zu vermeiden.

Wie ist diese Gleichung zu lösen und wie kann man diese widersprüchlichen Ziele vereinen? Und welche Rolle spielen die Tester? Nun, sie befinden sich genau zwischen den Fronten!

Tester können die Brücke zwischen Dev und Ops sein, die sie verbindet. Sie können sicherstellen, dass Entwickler schnell und gut ausliefern, und Operations von der Qualität der neuen Softwarelieferungen überzeugen, bevor sie in die Produktion gegeben werden. Um diese Mission zu erfüllen, müssen Tester sich technische und organisatorische Fähigkeiten aneignen, die es ihnen erlauben, Trends wie diesem zu folgen.

Continuous Delivery

Ein Ziel ist es, sich mehr in Richtung Industrialisierung zu bewegen. Industrialisierung bedeutet nicht einfach nur, Testwerkzeuge wie Management-Tools, (Load und Function) Automatisierungstools und Fehlermanagement-Tools, welche heutzutage die gängigen Tools sind, anzuwenden. Für die Tester der Zukunft besteht Industrialisierung darin, über den Tellerrand der eigenen alltäglichen Arbeit hinauszuschauen und globale Testfabriken aufzubauen, die Testen und Ausliefern miteinander vereinen.

Wir, als professionelle Tester der Zukunft, müssen tiefer in die Welt der Entwicklung und der Operations einsteigen, um die Lücke, die die beiden trennt, zu füllen. Andernfalls werden sie diese Lücke ohne uns schließen.

Die Zahl derjenigen professionellen Tester, die diese Vision vertreten und anwenden, wächst ständig, und es werden immer mehr Tools kreiert, meist Open Source, um Entwicklung und Betrieb zu verbinden. Es gibt Firmen, die an diesem Trend arbeiten, wie zum Beispiel Tupilabs [3] (geführt von Bruno P. Kinoshita, dem Verfasser von unter anderem Jenkins Plugin/Testlink) mit einem neuen Tool wie Nestor oder ich selbst mit dem Jinfeng-Projekt.

Ziel ist es, ein wahrhaft kontinuierliches Lieferungssystem zu schaffen, welches drei Schritte vereint: Continuous Integration, Testautomatisierung und Continuous Deployment.

Continuous Integration

Der erste Schritt eines Continuous Delivery Systems ist die Continuous Integration. Sie benötigt spezielle Tools, wie zum Beispiel Jenkins. Dieses Tool funktioniert wie ein Orchesterdirigent, indem es die automatisierte Erstellung von Anwendungsprogrammen steuert, gewisse Schritte auslösen und verbinden kann, automatisiertes Deployment und automatisierte Tests durchführt und Berichte generiert.

Die Verantwortung für ein solches Tool liegt beim Development-Team, aber der Tester muss in der Lage sein, es einzusetzen oder Einstellungen zu ändern, um automatisierte Testphasen einzubinden oder zu managen. Des Weiteren muss er in der Lage sein, die Metriken und Berichte zu erstellen, die für die Dokumentation des Tests notwendig sind, wie zum Beispiel Modultesten, Testabdeckung und Entwicklungsstandards.

Testautomatisierung

Der zweite Schritt beinhaltet das Kerngeschäft des professionellen Testers und muss sich daran orientieren, spezifische Tools zum Testen zu meistern und einen Weg zu finden, sie anzupassen, damit sie auf die Probleme angewendet werden können, vor denen professionelle Tester tagtäglich stehen. Er schließt außerdem die Kostenreduzierung für die Software ein, was manchmal ihre Nutzung einschränkt. Dies erfordert eine Verbesserung von Open-Source-Tools und die Entwicklung einer neuen Generation von Tools. Aufgrund der Einschränkungen von Tools wie TestLink tauchen zum Beispiel Tools wie Nestor oder Squash-TM auf.

Automated Deployment

Automated Deployment ist mit Operations verbunden. Wie können wir sichergehen, dass wir, wenn wir die Häufigkeit der Entsendung von Softwarekomponenten in die Produktion erhöhen, nicht gleichzeitig auch das Fehlerrisiko steigern? Wie können wir die hohe Qualität von Produktionssystemen aufrechterhalten? Auch hier ist die Antwort Industrialisierung. Automatisiertes Deployment hilft dabei, manuelle Operations – und somit das Fehlerrisiko – einzuschränken. Es ist außerdem hilfreich, Vertrauen in die Transaktionen zu haben und diese zu prüfen. Was in der Produktion deployt wird, ist, was zuvor getestet wurde – WYDIWYT: What You’ll Deploy Is What You’ve Tested.

Ist dies alles nur Wunschdenken?

Nein, all diese Werkzeuge und Prozesse existieren bereits. Einige Aspekte müssen vielleicht noch verbessert werden, aber sie sind jetzt schon verwendbar, wie ich im folgenden Beispiel zeigen werde.

Vor kurzem arbeitete ich in einer Firma mit an der Deployment-Phase eines Systems, welches es möglich machen sollte, durch mobile Geräte (Android, iPhone/iPad, BlackBerry) Zugang zu kommerziellen Anwendungen zu erhalten. Dieses Projekt einer multinationalen Firma hatte verschiedene Teams (Devs, Ops, QA, Network etc.), die auf der ganzen Welt verteilt waren (USA, einige europäische Länder, China, Indien). Viele der Devs arbeiteten aus den USA, der Kern des QA-Teams in Indien, einige QAs in anderen Ländern verteilt, und ein Teil der Operations fand in Frankreich statt. Wir mussten die Deployments in verschiedensten Umgebungen (Testen, Staging, Produktion) mit variierender Dichte organisieren.

Wir richteten einen Jenkins-Server ein, den wir für die Continuous-Integration-Phase nutzten, und erstellten täglich einen Daily Build mit dem neuen Code des GIT-Servers des US-Teams. Dieser Daily Build wurde genutzt, um einen Tarball zu erstellen, und dieses Paket wurde wiederum in CVS gelagert und mit einem Shell-Script getaggt.

Je nachdem, von welchem GIT-Zweig aus das Paket ausgestellt wurde, wurde es entweder automatisch jeden Tag auf der Testplattform deployt oder einfach bis es von einem Menschen autorisiert wurdegelagert. Es folgte die automatisierte Deployment-Phase. QA-Teams konnten diese Version jeden Tag testen, selbst wenn das Ops-Team mit einem Brand in der Produktion beschäftigt war.

Während dieses Projektes müssen wir nach dem Deployment noch die automatisierte Testphase entwickeln, bevor manuell getestet wird. Dies wird automatisch eine Reihe grundlegender Tests bestätigen (Smoke Test), bevor die Version an Testteams geliefert wird, die sich dann auf das Testen neuer Features konzentrieren. Zusätzlich können diese Tests erneut auf Pakete angewendet werden, bevor sie in Produktion gegeben werden. Mein Plan ist es, für diese automatisierte Testphase Jinfeng zu nutzen, während Jenkins die Produktion von Paketen und das Ausführen von Tests nach einem BTDD-Vorgehen steuert (Behaviour Test Driven Development). Bei diesem Projekt setzt die Umsetzung einer solchen kontinuierlichen Auslieferungsplattform das Erlernen und Anwenden folgender Tools und Sprachen voraus: Jenkins, Python-Jython, Bladelogic, Ant, Git, CVS, Confluence, JORA, RobotFramework, Gradle und Groovy.

Dieses System ist in der Lage, automatisch E-Mails zu senden, Dokumentation in Confluence zu erstellen, JIRA-Tickets zu erstellen, um dem Prozess zu folgen, und die verschiedenen Teams zu koordinieren.

Fazit

Letztendlich kann man vielleicht sagen, dass zwei der wichtigsten Fähigkeiten, die ein zukünftiger Tester benötigt, einfach Vorstellungskraft und eine innovationsfreudige Einstellung sind.

Ein Punkt, an dem ich im Zuge des Entwicklungsprozesses im Jinfeng-Projekt noch arbeite, ist, die Möglichkeiten für das Ausführen von Jenkins in einem Raspberry Pi einzuschätzen. Raspberry Pi ist ein elementarer Computer von der Größe einer Kreditkarte, der weniger als 40 Dollar kostet. Es war mir möglich, Jenkins auf einer Linux-Distribution mit einem jdk ARM [9] auf einer 8GB-SSD-Karte laufen zu lassen. Unglücklicherweise war die Leistung selbst mit der Raspberry Pi 512 MB Version nicht gut genug. Sie hat nicht ausgereicht, um mir eine komplette Continuous Delivery und ein automatisiertes Testsystem zu erlauben. Aber ich glaube daran, dass die Tester der Zukunft die Fähigkeiten haben werden, diese Art eines komplett automatisierten Testinstruments für ein paar hundert Dollar zu erstellen, inklusive Hardware und Software. Dies wird dabei helfen, das Testen in Zukunft weiter zu verbreiten.

Quellen:

[1] Testing Experience #16 „The future of testing“
[2] https://en.wikipedia.org/wiki/DevOps
[3] http://www.tupilabs.com/
[4] http://www.sqaopen.org/
[5] http://en.wikipedia.org/wiki/Sonar_(software_quality)
[6] https://en.wikipedia.org/wiki/Test_automation
[7] http://mantis.testlink.org/view.php?id=4064
[8] https://www.raspberrypi.org/
[9] http://jdk8.java.net/fxarmpreview/

Weitere Testing-Artikel im te Mag

Eine Frage der Haltung – Lösungsfokussierung im Testing

Das ultimative Werkzeug für alle zukünftigen Anforderungen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

Recent Posts