Mit Erwartungen f\u00e4ngt alles an. Was erwarte ich von der Software, was erwarte ich von diesem Blog-Beitrag, und was hat das mit dem \u201eAfsluitdijk\u201c zu tun? <\/p>\n\n\n\n
Der Afsluitdijk ist ein 32 Kilometer langer Damm in den Niederlanden und trennt das Ijsselmeer von der Nordsee. Sein Bau wurde beschlossen, um Amsterdam und weitere Gebiete vor Hochwasser und Sturmfluten zu sch\u00fctzen und erm\u00f6glichte Landgewinnung \u2013 seit 1986 gibt es die 12. Niederl\u00e4ndische Provinz Flevoland. Es gibt zwei Tiedesperrwerke, welche den Ablauf des S\u00fc\u00dfwassers sowie den Schiffsverkehr steuern. Diesen kommt insbesondere bei Sturmfluten eine besondere Bedeutung zu. Ich habe fr\u00fcher bei einem Unternehmen gearbeitet, welche die Software f\u00fcr diese Schleusen entwickelt hat. Wie viele Bugs w\u00fcrden wir dieser Software zugestehen?<\/p>\n\n\n\n
Bevor Software entwickelt und getestet wird, sollten wir uns \u00fcberlegen, welches Qualit\u00e4tslevel wir erwarten. Wird hiermit ein unternehmenskritischer Prozess abgedeckt, der jederzeit verf\u00fcgbar sein muss, oder ist es verkraftbar, wenn die Software mehrere Tage ausf\u00e4llt? Handelt es sich einen zentralen Dienst unseres Cloudangebotes, auf den alle Anwender:innen angewiesen sind, oder ist eine projektspezifische Entwicklung f\u00fcr 15 Mitarbeitende einer eigenst\u00e4ndigen Abteilung?<\/p>\n\n\n\n
Wichtige Meilensteine des strukturierten Testprozesses<\/h3>\n\n\n\n
Beim Entwickeln und Testen von Software verfolgt d.velop einen risikobasierten Ansatz. Je h\u00f6her die negative Auswirkung eines Fehlers ist, je gr\u00f6\u00dfer die Wahrscheinlichkeit, dass es zu einem Fehler kommt, desto besser muss getestet werden. Dies wirkt sich nat\u00fcrlich auf die Kosten aus. Daher spielt die Wirtschaftlichkeit hierbei eine gro\u00dfe Rolle \u2013 fehlerfreie Software ist praktisch unbezahlbar.<\/p>\n\n\n\n
Zur\u00fcck zu Erwartungen \u2013 hierzu geh\u00f6rt auch, dass alle sie kennen und verstehen. Die gew\u00fcnschten Funktionen der Software m\u00fcssen dokumentiert sein, sonst kann sie nicht gut entwickelt und getestet werden. Im Projektgesch\u00e4ft werden Anforderungen oft in Lasten- und Pflichtenheften festgehalten, in agilen Projekten und in der agilen Softwareentwicklung sind \u201eUser Stories\u201c \u00fcblich. Hierin werden \u00fcberschaubare, in sich gekapselte Anforderungen beschrieben. Dabei hat sich, nicht nur bei d.velop, folgender Aufbau etabliert:<\/p>\n\n\n\n
- \n
- Titel<\/strong>: Als <Rolle> m\u00f6chte ich <Funktionalit\u00e4t>, damit ich <Grund><\/li>\n\n\n\n
- Beschreibung<\/strong>: (wenn der Titel nicht schon sprechend genug)<\/li>\n\n\n\n
- Akzeptanzkriterien<\/strong>: Niedergeschriebene, fachliche Anforderung, welche zum Zeitpunkt der Abnahme erf\u00fcllt sein muss<\/li>\n\n\n\n
- Aufwandssch\u00e4tzung:<\/strong> $$$<\/li>\n<\/ul>\n\n\n\n
<\/span>Effektives Projektmanagement in der Softwareentwicklung: Warum kurze Zyklen entscheidend sind<\/span><\/h2>\n\n\n\n
Zeit hat man nie genug, schon gar nicht zum Testen. Wer kennt nicht die folgenden Aussagen? \u201eDie Entwicklung hat sich verz\u00f6gert, es blieb keine Zeit zum Testen\u201c oder \u201eDas n\u00e4chste Projekt startet bereist, bevor das aktuelle fertig war\u201c. Dazu f\u00e4llt mir immer eines meiner Lieblingsaussagen aus dem Projektmanagement ein: \u201eSag mir, wie Dein Projekt startet, und sich sage Dir, wie es endet!\u201c Planung ist also alles! <\/p>\n\n\n\n
Klassischerweise gibt es in der Softwareentwicklung die Schritte Spezifikation, Entwicklung, Test und zum Abschluss das Release bzw. Deployment oder Produktivsetzung. Die Praxis zeigt aber, dass es hier mehrere Konfliktstellen gibt: Was kommt nach Entwicklung? Nein, nicht Test, sondern noch mehr Entwicklung \u2013 die Zeit f\u00fcrs Testen schrumpft. <\/p>\n\n\n\n
Endlich kann getestet werden, der Plan sieht danach die Produktivsetzung vor \u2013 nicht aber, dass auch Fehler gefunden werden. Also zur\u00fcck zur Entwicklung, vielleicht auch mehrmals, bis die Tests endlich das gew\u00fcnschte Ergebnis bringen. Jetzt aber Produktivsetzung, Release oder Deployment, FERTIG! Wirklich fertig? Leider nein. Der Echtbetrieb ist immer anders als die Simulation, die Anwender:innen finden Abweichungen zum Wunschzustand, also: Zur\u00fcck zur Entwicklung.<\/p>\n\n\n\n
Ist Planung also wirklich alles? Pl\u00e4ne sind immer schwierig, besonders, wenn sie die Zukunft betreffen. Daher hat sich bereits seit vielen Jahren die Lieferung von Entwicklungsergebnissen in m\u00f6glichst kleinen H\u00e4ppchen etabliert \u2013 auch im Projektgesch\u00e4ft. Je kleiner die Inkremente, desto genauer kann verstanden werden, was sich \u00e4ndert, und je eher und genauer erhalte ich Feedback. So werden in d.velop Projekten Teilergebnisse oft w\u00f6chentlich vorgestellt, und die d.velop Cloud erf\u00e4hrt oft mehrere Updates t\u00e4glich. Planung bleibt wichtig, kurze Zyklen sind aber wichtiger!<\/p>\n\n\n\n
<\/span>Qualit\u00e4tssicherung bei Software: Testen in der Praxis<\/span><\/h2>\n\n\n\n
Wenn strukturiert getestet wird, kommen wir zwangsl\u00e4ufig an den folgenden Stationen vorbei:<\/p>\n\n\n\n
- \n
- Testplanung \/ Analyse:<\/strong> Was ist zu testen?<\/li>\n\n\n\n
- Testentwurf \/ Testrealisierung:<\/strong> Wie wird getestet und ist jetzt alles f\u00fcr den Test bereit?<\/li>\n\n\n\n
- Testdurchf\u00fchrung:<\/strong> Regression Ausf\u00fchrung<\/li>\n\n\n\n
- Testabschluss:<\/strong> Testergebnisse sammeln<\/li>\n\n\n\n
- Test\u00fcberwachung & -steuerung:<\/strong> \u00dcbergreifendes Testmanagement<\/li>\n<\/ul>\n\n\n\n
Bei kleineren Vorhaben oder Projekten ist dies vielleicht zu viel des Guten. Es lohnt sich aber immer, einen Plan zu haben und die Testergebnisse festzuhalten. Im einfachsten Fall ist dies ein und dasselbe Dokument, z.B. eine Excel-Tabelle mit den folgenden Spalten:<\/p>\n\n\n\n
- \n
- Testnummer<\/li>\n\n\n\n
- Ablaufbeschreibung<\/li>\n\n\n\n
- Erwartetes Ergebnis<\/li>\n\n\n\n
- Testdatum<\/li>\n\n\n\n
- Tester<\/li>\n\n\n\n
- Testergebnis<\/li>\n\n\n\n
- Bemerkungen<\/li>\n<\/ul>\n\n\n\n
So bleibt nachvollziehbar, was getestet wurde und der Projektleiter oder die Projektleiterin hat etwas in der Hand, wof\u00fcr er oder sie Geld verlangen kann. Wenn ich wei\u00df, was ich testen soll, stellt sich immer noch die Frage nach dem Wie. Die:Der geneigte Endanwender:in nimmt sich die Maus und klickt alle Funktionen durch, doch es gibt noch viele andere Wege.<\/p>\n\n\n\n
Bei einmaligen oder seltenen Vorhaben ist der manuelle Test \u00fcber die Benutzeroberfl\u00e4che der richte Weg. Wird Software jedoch komplexer und stetig weiterentwickelt, ist es auf Dauer zu aufw\u00e4ndig, t\u00e4glich alle neuen Funktionen aufs Neue durchzuklicken. Hier k\u00f6nnen die automatisierten Tests Linderung schaffen. Bei der Darstellung der verschiedenen Testarten wird h\u00e4ufig eine Pyramide genutzt:<\/p>\n\n\n\n
![\"Infografik](\"https:\/\/www.d-velop.de\/blog\/wp-content\/uploads\/2024\/06\/pyramide-testarten.jpg\")
<\/figure>\n\n\n\nIn der Standard-Softwareentwicklung haben sich Unit-Tests etabliert. Zu jeder programmierten Funktion wird auch eine Testfunktion geschrieben. Wird bei der Weiterentwicklung die Funktion gest\u00f6rt, schl\u00e4gt die Testfunktion fehl und die Entwicklerin oder der Entwickler kann unmittelbar eingreifen.<\/p>\n\n\n\n
Um die Zusammenarbeit von mehreren Funktionen, Microservices oder Applikationen zu testen, reichen Unit-Tests nicht aus. Hier greifen automatisierte Integrations- und API-Tests. Noch weiter oben in der Pyramide befinden sich UI (User Interface), End-to-End und Akzeptanz-Tests.<\/p>\n\n\n\n
Testpyramiden und Teststrategien: Die Balance zwischen Aufwand und Aussagekraft<\/h3>\n\n\n\n
Je weiter oben in der Pyramide, desto aufw\u00e4ndiger und damit teurer ist ein Testdurchlauf. Daf\u00fcr sind die Tests aussagekr\u00e4ftiger, da das Gesamtverhalten mit allen Abh\u00e4ngigkeiten getestet wird. Um aus beiden Welten die Vorteile zu ziehen, hat sich in der agilen Softwareentwicklung die aufrecht stehende Pyramide etabliert. Dies ist aber nicht der einzige richtige Weg! Je nach Anwendung und Anwendungszweck kann auch die umgekehrte Pyramide richtig sein, oder ganz andere geometrische Figuren wie hexagonal, hourglass, trophy oder house of testing. Hilfreich ist aber, dies nicht dem Zufall zu \u00fcberlassen, sondern eine Teststrategie zu entwickeln und f\u00fcr den individuellen Anwendungsfall die optimale Testabdeckung der Codes zu erreichen.<\/p>\n\n\n\n
Ist die Testautomatisierung der heilige Gral und manuelles Testen ein Relikt aus der Vergangenheit? Sicher nicht! Automatisierung lohnt sich, je h\u00e4ufiger getestet werden muss und je h\u00e4ufiger sich eine Anwendung \u00e4ndert. Aber Testautomatisierung hat nicht nur Fix-, sondern auch laufende Kosten! Tests m\u00fcssen nicht nur erstellt, sondern auch gepflegt werden. Dieser Aufwand wird oft untersch\u00e4tzt. Eine Untersuchung (Forrester Analytics Business Technographics Develeoper Survey, 2023, Base: 2,177 Developers) hat ergeben, dass nur zwischen 20% und 25% der Tests automatisiert sind \u2013 da sind wir bei d.velop deutlich besser.<\/p>\n\n\n\n
Shift Left und Shift Right: Strategien f\u00fcr effektives Testen und Fehlerbehebung<\/h3>\n\n\n\n
Neben dem Wie stellt sich auch die Frage nach dem Wann. Unter \u201eShift Left\u201c versteht man den Ansatz, so fr\u00fch wie m\u00f6glich im Entwicklungsprozess zu testen \u2013 je eher ein Fehler gefunden wird, desto g\u00fcnstiger kann er behoben werden. Das hei\u00dft: Fehler vermeiden oder fr\u00fch erkennen, so fr\u00fch und so umfangreich wie m\u00f6glich testen.<\/p>\n\n\n\n
\nDer Begriff Shift Left<\/strong> beschreibt die Strategie, Tests so fr\u00fch wie m\u00f6glich im Entwicklungsprozess durchzuf\u00fchren. Je fr\u00fcher ein Fehler entdeckt wird, desto kosteng\u00fcnstiger ist seine Behebung.<\/p>\n\n\n\n
Im Gegensatz dazu verfolgt Shift Right<\/strong> den Ansatz, die Produktion kontinuierlich zu \u00fcberwachen. Ziel ist es, Fehler so schnell wie m\u00f6glich zu erkennen und \u2013 noch wichtiger \u2013 diese umgehend zu beheben.<\/p>\n<\/div><\/div>\n\n\n\n
Die Praxis \u2013 erst recht beim Betrieb von komplexen Cloud-L\u00f6sungen \u2013 hat jedoch gezeigt, dass auch mit maximalen Anstrengungen nicht alle Fehler vor dem produktiven Betrieb gefunden werden k\u00f6nnen. Unter \u201eShift Right\u201c gibt es daher den Ansatz, die Produktion so gut wie m\u00f6glich im Auge zu behalten. Fehler sollen so schnell wie m\u00f6glich entdeckt, und \u2013 was noch wichtiger ist \u2013 so schnell wie m\u00f6glich behoben werden. Das bedeutet, dass eine Code\u00e4nderung bestenfalls innerhalb weniger Minuten getestet und produktiv genommen werden kann. Ist ein Problem durch eine neue Version entstanden, sollte ein Rollback auf die noch funktionierenden Vorg\u00e4ngerversion innerhalb von Sekunden m\u00f6glich sein. Ist das Kind ganz tief in den Brunnen gefallen und z.B. Dateninkonsistenzen aufgetreten, muss jederzeit klar sein, wie ein Desaster Recovery m\u00f6glich ist.<\/p>\n\n\n\n
Qualit\u00e4tssicherung von Software bei d.velop<\/h3>\n\n\n\n
Von der Theorie zur Praxis: Wie sieht die Qualit\u00e4tssicherung bei der d.velop Produktentwicklung aus? Software entsteht bei uns in rund 30 Entwicklungsteams, in jedem von diesen gibt es eine Person, die sich hauptverantwortlich f\u00fcr die Softwarequalit\u00e4t zeigt. Dabei ist das nicht in allen Teams ein Vollzeit-Job, oft ist es eine Rolle neben z.B. der Entwicklert\u00e4tigkeit. Bei d.velop sind es aber 18 Personen, die sich ausschlie\u00dflich um Qualit\u00e4tssicherung k\u00fcmmern.<\/p>\n\n\n\n
\u00dcber 200 Applikationen wollen bei d.velop getestet werden, hierum k\u00fcmmern sich unter anderem rund 80.000 Tests, die n\u00e4chtlich automatisiert ausgef\u00fchrt werden. Beim Testen kommt unserer d.velop Cloud eine besondere Rolle zu: Da hier oft mehrmals t\u00e4glich \u00c4nderungen live genommen werden, muss engmaschig getestet werden, damit zwei parallele Updates miteinander kompatibel bleiben. Hierf\u00fcr werden st\u00fcndlich \u00fcber 60 Tests zur Absicherung von gegenseitigen Abh\u00e4ngigkeiten durchgef\u00fchrt.<\/p>\n\n\n\n
Wie beschrieben, hat bei d.velop die Testautomatisierung einen hohen Stellenwert. Hierbei kommen f\u00fcr sehr unterschiedliche Einsatzzwecke verschiedene spezialisierte Werkzeuge zum Einsatz, das folgende Bild fasst die wesentlichen zusammen.<\/p>\n\n\n\n
![\"Infografik](\"https:\/\/www.d-velop.de\/blog\/wp-content\/uploads\/2024\/06\/werkzeuge-testautomatisierung.jpg\")
<\/figure>\n\n\n\nSicherheitsprozesse und statische Codeanalyse: Grundlagen der Qualit\u00e4tssicherung<\/h3>\n\n\n\n
Die statische Codeanalyse spielt insbesondere f\u00fcr die Sicherheit unserer Software eine entscheidende Rolle.<\/p>\n\n\n\n
- Testentwurf \/ Testrealisierung:<\/strong> Wie wird getestet und ist jetzt alles f\u00fcr den Test bereit?<\/li>\n\n\n\n
- Beschreibung<\/strong>: (wenn der Titel nicht schon sprechend genug)<\/li>\n\n\n\n
![\"Infografik](\"https:\/\/www.d-velop.de\/blog\/wp-content\/uploads\/2024\/06\/software-you-can-trust.jpg\")
<\/figure>\n\n\n\n![\"Infografik](\"https:\/\/www.d-velop.de\/blog\/wp-content\/uploads\/2024\/06\/softwareentwicklung-ki.jpg\")