Turbo für Digitalisierungsprojekte
Software-Entwicklung durch automatisierte Tests beschleunigen
IT-Verantwortliche stehen durch den steigenden Digitalisierungszwang in Unternehmen enorm unter Druck. Um konkurrenzfähig zu bleiben, müssen sie Software schneller und zuverlässiger in die Produktionsabläufe integrieren, als die Konkurrenz. Nur mit einem hohen Automatisierungsgrad lassen sich solche Aufgaben heute noch bewältigen. Eine Strategie auf Basis von Continuous Delivery kann aus diesem Dilemma helfen. Denn für die schnelle und kontinuierliche Bereitstellung von Anwendungen sind vollständig automatisierte Unit-, Integrations- und UI-Tests unerlässlich. Sie sind notwendig, um den Weg zur Einführung eines reibungslosen Continuous-Delivery-Prozesses zu ebenen.
Ohne dedizierte Tests ist eine erfolgreiche Softwarelieferung kaum denkbar. So wird während des gesamten Entwicklungsprozesses die Anwendung auf drei Ebenen getestet.
Auf der ersten Ebene gibt es die sogenannten Unit-Tests, bei denen eine bestimmte Klasse oder Methode einzeln und isoliert von anderen Einheiten geprüft wird. Sie werden üblicherweise von Entwicklern erstellt und stellen sicher, dass ein bestimmter Code-Abschnitt sich wie erwartet verhält.
Die Konzentration auf einzelne Einheiten bedeutet aber, dass die korrekte Zusammenarbeit mehrerer Komponenten im Unit-Test nicht überprüft wird. Hierfür ist die nächste Ebene zuständig: der Integrationstest, in dem das Zusammenspiel mehrerer Bausteine im Mittelpunkt steht. Dabei werden immer mehrere Code-Module und deren Schnittstellen überprüft.
Die dritte Ebene sind sogenannte User-Interface (UI)-Tests, in denen die Benutzeroberfläche einer ganzen Anwendung mit simulierten Anwendereingaben geprüft wird. Durch die Validierung des Erscheinungsbilds und der Funktionalität wird sichergestellt, dass die vom Server gelieferten Daten auch richtig angezeigt werden, was insbesondere bei der Fehlerbehandlung eine wichtige Rolle spielt.
- Diese Branchen wurden befragt
Zehn vertikale Märkte wurden untersucht. - Strategische Bedeutung
Dass die Digitalisierung zu einem wichtigen Thema wird, wissen die meisten Unternehmen inzwischen. - Investitionen werden eingeplant
Erstaunlich viele Betriebe legen kein Geld für die digitale Transformation zur Seite. - Strategische Steuerung
Entweder die Geschäftsführungen werden tätig oder es gibt Initiativen in den Fachbereichen. - Nachholbedarf beim Change Management
Das Change Management beschränkt sich meist auf einzelne Organisationsbereiche. - Papierdokumente noch im Einsatz
Fast 30 Prozent der Befragten wickeln ihre Geschäfts- und Produktionsprozesse zu mehr als 50 Prozent auf Papier ab. - Medienbrüche bleiben ein Thema
immerhin sagt fast ein Drittel, die Zeit der Medienbrüche sei vorbei. - Mobile Business im Kommen
Mobile Arbeitsprozesse sind in zwei von drei Unternehmen ein Thema. - Das Social Web bleibt Randthema
Im Kommunikationsmix der Unternehmen spielt das Social Web eine Rolle. Sonst weniger. - Digitale Geschäftsmodelle werden wichtiger
Knapp 23 Prozent geben Vollgas in Sachen digitale Geschäftsmodelle. - ITK-Branche mit Vorsprung
Die ITK-Branche ist bei der digitalen Transformation viel weiter fortgeschritten als etwa die Logistiker.
Testautomatisierung verbessert Softwarequalität
Die Automatisierung dieser drei Testarten bekommt eine immer größere Bedeutung. Entwicklungsbegleitende, voll automatisierte Tests stellen kontinuierlich die Release-Fähigkeit der Software fest. Damit kann die Stabilität einer Anwendung viel öfter und vor allem früher im Entwicklungsprozess beurteilt werden, so dass potenzielle Fehler schneller und häufiger erkannt werden.
Allerdings sind die verschiedenen Testarten nicht gleich einfach zu automatisieren. Bei Unit-Tests ist die Automatisierung durch Frameworks wie JUnit etabliert und gilt als Standard in der Softwareentwicklung. Abhängigkeiten werden durch Mocks ersetzt. Dadurch lassen sich die Unit-Tests schnell und einfach ausführen.
Integrations- und UI-Tests dagegen benötigen eine komplexere Infrastruktur. Die Anwendung muss komplett gestartet werden und Abhängigkeiten zu anderen Systemen und Komponenten müssen simuliert werden, um aussagekräftige Ergebnisse zu liefern. Die Vorbereitung der richtigen Infrastruktur hat eine deutlich höhere Komplexität und bedeutet Aufwand. Bei der Überprüfung der Oberfläche kommt zusätzlich noch die Simulation von validen Anwendereingaben hinzu.
Viele Manager scheuen deshalb häufig die Kosten für das Einführen einer vollständigen Testautomatisierung in den Bereichen Integrations- und UI-Tests. Mit den richtigen ToolsTools bleibt aber auch diese Investition im Rahmen, so dass sich kontinuierliche, vollautomatische Tests mittel- und langfristig immer lohnen. Die Releasefähigkeit einer Anwendung kann durch Testautomatisierung kostengünstig und schnell überprüft werden und ist Voraussetzung für eine zeitgemäße Time-to-Market-Strategie. Manuelle Tests sind dann nur noch ausgewählten Fachanwendern vorbehalten, die sich vor einem Release ganz gezielt auf die neuen Funktionen einer Anwendung konzentrieren, um die Übereinstimmung mit den Anforderungen zu prüfen und fachliche Fehler auszuschließen. Alles zu Tools auf CIO.de
- Software-Entwicklung in Europa
Eine Umfrage zum Status quo in der Software-Entwicklung weist auf deutliche Unterschiede zwischen europäischen Regionen hin. Übereinstimmung herrscht indes darin, dass Individualentwicklung wichtig bleibt, Cloud-Enabling auch für Legacy-Anwendungen Pflicht wird und Entwickler zu stark von Nebensächlichkeiten abgelenkt werden. - IT-Chefs in Ländern ...
... der Regionen Benelux und DACH möchten durch gezielten IT-Einsatz vor allem die Kosten senken. Die Briten sehen darin eher ein Instrument zur Umsatzsteigerung. Und die Skandinavier wollen ihre Kunden besser bedienen. - In allen Regionen ...
... sollen sowohl bestehende Anwendungen "cloudifiziert" als auch neue Anwendungen native für die Cloud entwickelt werden. - Dramatische Unterschiede gibt es in Sachen Self-Service:
Nur in der DACH-Region haben Entwickler mehrheitlich keinen Self-Service-Zugriff auf IT-Infrastruktur. - Gefragt nach den strategischen IT-Initiativen, ...
... legen Skandinavien, die DACH-Region und die Benelux-Staaten größten Wert auf standardisierte Deployment-Architekturen und –Prozesse. Den Briten ist das nicht so wichtig. Ihnen geht es vorrangig um mehr Produktivität in der Software-Entwicklung. - Deutliche Unterschiede in der Akzeptanz von Cloud Computing:
Für ein Drittel der befragten Briten ist die Cloud "kritisch" für strategische IT-Initiativen. In allen anderen Regionen ist die Sogwirkung nicht so stark. - Jenseits der DACH-Region spielt die Public Cloud eine deutlich wichtigere Rolle.
In der deutschsprachigen Region ist die Hybrid Cloud besonders populär. - Offenbar sind die Deutschen, Österreicher und Schweizer ...
... besonders effizient, wenn es um die Auslastung ihrer Data Centers geht. - Die Briten und die Benelux-Länder haben noch reichlich Legacy-Systeme im Einsatz.
In Ländern aus Skandinavien und der DACH-Region wurde schon kräftig ausgemistet.
Testautomatisierung vereinfacht die Fehlersuche
Unternehmen sollten in Entwicklungsprojekten bereits von Anfang an eine Automatisierung vorsehen. Dabei müssen alle drei Testarten fester Bestandteil des Build-Prozesses sein, damit sie bei jeder Änderung automatisch ausgeführt werden. Bei der Einbindung in die Build-Umgebung gilt das Prinzip des Failfast-Ansatzes, bei dem ein Fehlschlag dazu führt, dass die weiteren Prozess-Schritte nicht mehr ausgeführt werden.
Die Anzahl der Tests und die Vielfalt der Varianten, die getestet werden, nehmen mit jeder Testebene von unten nach oben immer weiter ab. Basis dieser Hierarchie sind die schnell ausführbaren Unit-Tests, die sehr nah am Quellcode arbeiten und dabei viele Varianten sowie möglichst alle Entscheidungswege prüfen. Danach verschiebt sich der Fokus auf ausgewählte Tests von Komponenten und Schnittstellen. Auf der letzten Ebene wird gezielt die Anwendererfahrung ausgewertet und das Gesamtsystem kommt in den Blick.
Die sinkende Anzahl der Testvariationen in den oberen Testhierarchieebenen sorgt für eine größere Effizienz des gesamten Entwicklungsprozesses. Wegen des größeren Aufwands und der deutlich längeren Ausführungszeit der Tests im Bereich Integration und UI wird der Durchlauf auf die wesentlichen Prüfroutinen beschränkt.
Eine wichtige Randbedingung erfolgreicher Testautomatisierung ist die Organisation der Projektteams. Die Erfahrung zeigt, dass cross-funktionale Teams, die alle Bereiche wie Test, Softwareentwicklung und Releasemanagement behandeln, die beste Lösung sind. Bessere Kommunikation und Zusammenarbeit sowie eine gleichmäßigere Wissensverteilung unter den Mitarbeitern sind die Folge.
Kurze Wege und regelmäßiger Austausch vermeiden zeitintensive Kommunikationsschleifen zwischen Bug-Eröffnung, Test-Verifizierung und Bug-Behebung. Daher ist es beim Beginn des Projekts empfehlenswert, eine gemeinsame Arbeitsgrundlage mit einem einheitlichen Vorgehensmodell wie Scrum oder Kanban sowohl für die Entwicklung als auch das Testen zu finden.
- Schneller als Plan-Build-Run
Die Anforderungen an Software verändern sich im Laufe der Entwicklung oft erheblich - anders als bei einem Auto zum Beispiel. Dem tragen agile Methoden wie Scrum Rechnung. - Besseres Ineinandergreifen
Bei traditioneller Softwareentwicklung greifen Zahnräder oft nicht ineinander, sondern sie rotieren nebeneinander vor sich hin. Scrum sorgt für nahtlosere Prozesse. - Jeder spricht mit jedem
Bei vielen Softwareprojekten mangelt es an gelungener Kommunikation, bei Scrum ist regelmäßiges Feedback für alle Beteiligten Pflicht. - Mehr Qualität
Mit Hilfe von Scrum entwickelte Software ist in der Regel besser als andere, weil hier frühzeitig das Feedback der Kunden integriert wurde. - Chaos führt nicht zu Panik
Chaotisch ist Scrum insofern, als sich der damit verbundene Prozess nicht einfach mit einem Pfeil beschreiben lässt, der links auf dem Blatt Papier anfängt und irgendwo rechts aufhört. Sondern er ist mehrdimensional. Wenn sich alle an bestimmte Regeln halten, läuft trotzdem nichts aus dem Ruder. - Im Mittelpunkt: Der Mensch
Scrum heißt Gedränge. Und es bedeutet, den Menschen in den Mittelpunkt zu stellen in dem Sinne, dass ihm die Methode ermöglicht, effizient und gleichzeitig kreativ zu arbeiten. - Automatisierte Tools statt Selbstgestricktes
Oft verwendet jede Abteilung eigene Anwendungen, um Entwicklungsschritte zu dokumentieren, zum Beispiel Excel. Automatisierte, vor allem einheitliche Tools beschleunigen hier die Abläufe erheblich. - Nicht nur am Ende testen
Zeitgemäße Entwicklungsumgebungen erlauben es, auch einzelne Module zwischendurch zu testen, um immer auf dem neuesten Stand zu sein.
Sichtbarkeit der Tests im Team
Eine besonders kritische Situation im Entwicklungsprozess entsteht, wenn über Stunden oder Tage im "Continuous Build" mehrere Fehler auflaufen und sich überlagern. Dadurch kann niemand nachvollziehen, welcher Fehler zu welcher Code-Änderung gehört. Dies erschwert die Fehlerbehebung unnötig und muss unbedingt verhindert werden.
Wenn das Entwicklerteam nicht auf Stabilität achtet, gewöhnen sich rasch alle an einen fehlerhaften Build und es sinkt zunehmend die Bereitschaft, die Fehler zu beseitigen. Nach kurzer Zeit ist dann keine korrekte Aussage über die Qualität der Software mehr möglich. Dieser Zustand verhindert das Deployment oder führt zu unerkannten Fehlern im Produktivsystem.
Eine gute Lösung ist es, in der täglichen Teambesprechung Fehler im Continuous Build in Listenform zusammenzutragen und anschließend in eine Rangfolge zu bringen. Dies erhöht für das Team die Sichtbarkeit der Tests und der Zuständigkeiten für einen fehlgeschlagenen Build. Um die Qualität dauerhaft hoch zu halten, sollte die Feedback-Schleife des Builds kurzfristig alle notwendigen Daten zur Fehleranalyse liefern. Der Test-Code sollte Gegenstand eines Reviews sein, um die Einhaltung von Guidelines dauerhaft sicherzustellen.
Ein empfehlenswertes und den Gesamtablauf entlastendes Verfahren ist eine Vereinbarung im Team, vor dem Check-in des Quellcodes Unit- und ausgewählte Integrations-Tests lokal auszuführen, um offensichtliche Fehler schon vorab zu bemerken.
Continuous Deployment als nächste Stufe der Automatisierung
Die Testautomatisierung ist nur der erste Schritt einer Continuous-Delivery-Pipeline. Nach den Tests folgt das automatisierte Deployment der Anwendung zum Beispiel in Form eines Java-Web-Archivs in einem Application Server. Das Artefakt wird automatisiert durch den Build erstellt, getestet und in ein Repository zum Beispiel Maven oder Docker abgelegt.
In diesem Zusammenhang bedeutet Automatisierung, dass nach dem Commit des Entwicklers keine manuellen Aktionen notwendig sind, um das fertige Artefakt zu erhalten. Tools wie Jenkins besitzen alle notwendigen Funktionen, um eine solche Continuous Integration (CI) Pipeline aufzusetzen. Der nächste Schritt ist dann Continuous Delivery. Hier wird die CI-Pipeline um ein automatisiertes Deployment erweitert, das ein beliebiges Zielsystem mit einem Klick aktualisiert.
In diesem Kontext können verschiedene manuelle Genehmigungsschritte eingebaut sein. Denkbar ist, dass ein Testmanager Systeme für die Abnahme mit einem einzigen Klick bereitstellen kann. Für das Deployment der Produktivumgebung hingegen könnte nur ein bestimmtes Betriebsteam die Berechtigung haben. Sobald diese automatischen Prozesse fehlerfrei ablaufen und einen hohen Reifegrad erreicht haben, kann als nächster Schritt zur vollständigen Automatisierung das Continuous Deployment eingeführt werden. Der Auslöser für die Bereitstellung der Produktivumgebung ist hier entweder der Commit eines Entwicklers oder ein Zeitintervall - zum Beispiel nachts um 3 Uhr.
Nicht jeder Automatisierungsgrad ist für alle Projekte sinnvoll, organisatorische Rahmenbedingungen müssen bei der Entscheidung berücksichtigt werden. Unternehmen sollten aber auf jeden Fall ein automatisiertes Deployment anstreben. Damit kann sich das Projektteam auf die Kernaufgabe der Anwendungsentwicklung konzentrieren. Die manuelle Bereitstellung von Test- und Produktivsystemen lenkt von der Hauptsache ab, ist im Nachhinein schwer nachvollziehbar und nicht wiederholbar, meist schlecht dokumentiert und somit nicht effizient genug.
- Produkt- & Projektmanager
Ganz generell schätzen es Entwickler nicht so besonders, wenn ihnen jemand erklären will, wie sie ihren Job zu machen haben. Weil Produkt- und Projektmanager aber oft Entwickler-Teams leiten, passiert genau das. Das kann zu Unstimmigkeiten führen. <br /><br /> Dazu hat auch David Fox von devRant eine Meinung: "Letztendlich ist es in den meisten Fällen so, dass Produkt- und Projektmanager in irgendeiner Art und Weise die 'Besitzer' von Projekten und Prozessen sind, ohne dabei die täglichen Herausforderungen und Probleme der Softwareentwickler zu kennen." - Chefs
Genau wie die Produkt- und Projektmanager sind auch Development oder Engineering Manager dafür zuständig, Teams von Entwicklern zu führen und sicherzustellen, dass Projekte rechtzeitig und unter Budget fertiggestellt werden. <br /><br /> "In einigen Unternehmen können Situationen entstehen, in denen der Chef gleichzeitig Mitglied des Entwicklerteams ist. Insbesondere wenn der Chef vorher selbst Entwickler war und nach einer Beförderung zum Chef wird, ist Konfliktpotenzial gegeben", merkt Fox an. - Recruiter
Softwareentwickler müssen gar nicht selbst aktiv nach einem Job suchen, um von Recruitern und Headhuntern belästigt zu werden - dem Fachkräftemangel sei Dank. Es dürfte sehr schwer sein, einen Developer zu finden, der noch nicht in die Fänge der Recruiter geraten ist. <br /><br /> David Fox sieht insbesondere die Hartnäckigkeit der Recruiter als Problem: "Sie rufen an, sie e-mailen und sie lassen Dich einfach nicht in Ruhe - selbst dann, wenn Du gar keinen Job suchst. Und selbst wenn man eine Anstellung sucht, neigen viele Recruiter dazu, irrelevante Jobangebote zu machen oder Stellen zu empfehlen, deren Profil überhaupt nicht passt - etwa einen Job am anderen Ende des Landes, obwohl man gar nicht bereit ist, umzuziehen." - Dokumentation
Gibt es keine Dokumentation, beschweren sich die Softwareentwickler. Wenn es zuviel ist, beschweren sie sich und wenn sie die Dokumentation selbst erledigen müssen, auch. Sogar über die Art und Weise, wie andere Leute die Dokumentationsaufgabe bewältigen, beschweren sich die Entwickler. <br /><br /> An dieser Stelle seien sich auch endlich einmal alle Entwickler einig, wie Fox betont: "Softwareentwickler wollen eine ausführliche, gut geschriebene und akkurate Dokumentation - aber selber machen wollen sie es nicht." - Meetings
Meetings sind nicht nur für alle anderen ein Problem, sondern auch für Softwareentwickler. Insbesondere dann, wenn es sich um völlig unnötige, zeitraubende und stinklangweilige Zusammenkünfte handelt. Wie Fox erzählt, sind inzwischen auch Devotionalien mit der Aufschrift 'I survived another meeting that should have been an email' erhältlich. - Coworking Spaces
Mit dem Aufstieg der Agilität sind flache Hierarchien, Collaboration und Teamwork zum Alltag in Unternehmen geworden - insbesondere für Software-Development-Teams. Gerade die können ihre Arbeit in einem Großraumbüro aber meist nur schwer oder gar nicht bewältigen - sagen zumindest die Zahlen von devRant. <br /><br /> David Fox erklärt: "Es gibt einfach zuviel Ablenkung: die Kollegen unterhalten sich, Meetings werden verpasst, Telefonanrufe überhört. Es gibt auch eine Vielzahl an Beschwerden über den Kaffee im Büro und andere Annehmlichkeiten - oder eben das Gegenteil davon." - Kollegen
Selbsterklärend: Jeder hat wohl einen Kollegen oder eine Kollegin, den beziehungsweise die er ganz besonders schätzt. Nicht. <br /><br /> Im Fall der Softwareentwickler ist die Abneigung gegenüber Kollegen meist entweder in der mangelnden Qualität ihrer Arbeit oder einem völlig aus dem Leim gegangenen Ego begründet, gibt David Fox preis. - Vorstellungsgespräche
Wenn ein Softwareentwickler auf Jobsuche ist und zum Bewerbungsgespräch geladen wird, gibt es danach meist auch etwas zu meckern: <br /><br /> "Dumme Fragen oder die Lösung von völlig praxisfernen Aufgaben im Bewerbungsgespräch stoßen den Developern ebenso sauer auf, wie ein Gesprächspartner, der überhaupt nicht weiß, was ein Entwickler eigentlich genau macht", so Fox. - Fehler & Bugs
Softwareentwickler haben tagein, tagaus mit Fehlern und Bugs zu tun. Deswegen glaubt devRant-Gründer Fox, dass Entwickler in dieser Sache anders ticken: <br /><br /> "Die meisten anderen Probleme erfahren keine positive Auflösung, aber Bugs und Fehler sind behebbar und das fühlt sich gut an." - Quality Assurance
Die Quality Assurance (QA) - oder Qualitätssicherung - ist ein kritischer Teil der Softwareentwicklung. Dennoch bemängeln Softwareentwickler an QA-Experten häufig dieselben Dinge wie an Produkt- und Projektmanagern, so Fox. <br /><br /> "Die Qualitätssicherung bekommt das Produkt oder Projekt in die Hände, wenn die Entwickler es abgeschlossen haben. Deswegen verstehen sie oft nicht, welche Hürden und Workarounds die Entwickler im Entstehungsprozess bewältigen mussten. Offensichtlich kommt es auch regelmäßig vor, dass QA-Leute die Entwickler bitten, Bereiche nochmals zu überarbeiten, die sie auch selbst bewältigen könnten."
Fazit
Die vollständige Automatisierung der Unit-, Integrations- und UI-Tests ist eine Grundvoraussetzung für Continuous Delivery in der Softwareentwicklung. Die Überprüfung der Anwendungsintegration und Benutzerschnittstellen sind schwieriger zu automatisieren und benötigen spezielle Vorbereitungen bezüglich Infrastruktur und Testdaten. Durch den Einsatz spezialisierter Tools lässt sich dieser Aufwand beherrschen und die Automatisierung wird eine mächtige Waffe im Kampf gegen Bugs.
Automatisierte Tests ermöglichen schnelle und häufige Lieferungen einer Software und sind bei einem zukünftigen Refactoring wertvoll. Der erhöhte Testaufwand zahlt sich damit bei jeder Lieferung und jedem frühzeitig entdeckten Fehler doppelt aus. Schnelle Feedback-Zyklen und definierte organisatorische Zuständigkeiten sind nicht zuletzt auf dem Weg zu einem erfolgreichen Continuous-Deployment-Prozess unverzichtbar.