Nachhaltigkeit in der IT beginnt beim Software-Testing und bedeutet dort zweierlei: die Software selbst auf Nachhaltigkeit prüfen und den Testprozess nachhaltiger gestalten. Bestehende Qualitätskriterien der ISO 25010, etwa Leistungseffizienz, Wartbarkeit und Benutzbarkeit, decken Nachhaltigkeitsaspekte bereits ab, ohne sie explizit so zu benennen. Ressourcenschonende Testautomatisierung, bewusste Tool-Auswahl und das Vermeiden redundanter Testfälle sind konkrete Ansatzpunkte für Teams.
Das Wichtigste in Kürze
- Nachhaltigkeit taucht in der ISO 25010 nicht als eigenes Qualitätskriterium auf, steckt aber verteilt in Kriterien wie Leistungseffizienz, Benutzbarkeit, Zuverlässigkeit und Kompatibilität.
- Nachhaltige Software und wirtschaftliche Software sind dasselbe: wer Leistung einspart, spart Geld, und wer Wartbarkeit erhöht, verlängert den Lebenszyklus und vermeidet teure Neuentwicklungen.
- Redundante Testautomatisierung verbraucht Rechenkapazität ohne Mehrwert: denselben Testfall an drei Stellen laufen zu lassen kostet dreifache Ressourcen, ohne zusätzliche Fehler zu finden.
- Wann die Testautomatisierung läuft, ist eine Nachhaltigkeitsentscheidung: tagsüber oder am Wochenende, wenn Solarenergie im Netz ist, ist ressourcenschonender als nachts mit importiertem Strom.
Nachhaltigkeit fehlt in der ISO 25010, steckt aber schon drin
Nachhaltigkeit taucht in der ISO 25010 nicht als eigenes Qualitätskriterium auf. Es gibt keinen Punkt, der “Nachhaltigkeit” heißt, und keinen, der “Greenability” oder Schutz vor Umweltverschmutzung benennt. Wer in der Norm danach sucht, findet ihn nicht unter diesem Namen.
Trotzdem ist das Thema präsent, nur verteilt. Viele der bestehenden Qualitätskriterien enthalten Aspekte von Nachhaltigkeit, ohne dass sie so etikettiert sind. Die Leistungseffizienz ist das deutlichste Beispiel: Wer weniger Leistung verbraucht, verringert den CO2-Fußabdruck einer Anwendung.
Was fehlt, ist die Transparenz. Die Norm macht nicht sichtbar, welche ihrer Kriterien auf Nachhaltigkeit einzahlen. Genau dieses Mapping müsste jemand einmal sauber erstellen und bereitstellen, damit es nicht jedes Team neu erfinden muss.
Welche Qualitätskriterien auf Nachhaltigkeit einzahlen
Nachhaltigkeit hat mehrere Dimensionen, nicht nur die ökologische. Neben dem Umweltaspekt zählen soziale Faktoren und die Lebensdauer eines Produkts dazu. Therese Kuhfuß ordnet mehrere bestehende Kriterien der ISO 25010 diesen Dimensionen zu.
Die Leistungseffizienz wirkt auf den ökologischen Faktor, weil geringerer Ressourcenverbrauch direkt den CO2-Fußabdruck senkt. Das ist der naheliegendste Zusammenhang.
Die Benutzbarkeit deckt gleich zwei Ebenen ab. Über Barrierefreiheit und höhere Benutzerakzeptanz macht sie eine Software mehr Personengruppen zugänglich, das ist der soziale Aspekt. Gleichzeitig verlängert gute Usability den Lebenszyklus eines Produkts, weil es länger genutzt wird.
Die Zuverlässigkeit arbeitet in dieselbe Richtung. Je zuverlässiger eine Software läuft, desto länger bleibt sie am Markt bestehen, und ein langer Lebenszyklus ist selbst eine Form von Nachhaltigkeit.
Auch die Kompatibilität reduziert Verbrauch. Je kompatibler ein Produkt für sich ist, desto weniger Adapter- oder Schnittstellenprodukte braucht es drumherum. Das spart Abhängigkeiten und Ressourcen.
Die Wartbarkeit gehört in dieselbe Logik. Eine sauber designte Software lässt sich um neue Anforderungen erweitern, ohne dass man jedes Mal von vorn beginnt. Gerade im regulatorischen Umfeld, wo Anforderungen ständig vom Regulator vorgegeben werden, entscheidet Wartbarkeit darüber, ob Änderungen tragbar bleiben.
Nachhaltigkeit testen ist nicht dasselbe wie nachhaltig testen
Es gibt zwei verschiedene Fragen, die oft vermischt werden. Nachhaltigkeit testen heißt, zu prüfen, ob die Software selbst nachhaltig ist. Nachhaltig testen heißt, den eigenen Testprozess ressourcenschonender zu gestalten.
Die Qualitätskriterien gehören zur ersten Frage. Mit ihnen lässt sich der Nachhaltigkeit eine Gewichtung geben, also festlegen, wie wichtig sie im konkreten Projekt ist. Das ist immer ein Trade-off: Gegen Security- oder Safety-Anforderungen kann Nachhaltigkeit hintanstehen, und das ist legitim.
Wichtig ist der Zeitpunkt. Nachhaltigkeit als Qualitätskriterium muss am Anfang der Softwareentwicklung adressiert werden, nicht am Ende beim Test. Die ISO 25010 ist keine Test-Norm, sondern eine für die Softwareentwicklung. Requirements-Engineers, Entwickler und die Fachabteilungen müssen früh definieren, welche Nachhaltigkeitskriterien sie umsetzen wollen und wie stark sie diese gewichten.
So fängst du mit nachhaltigem Testen an
Der schnellste Einstieg liegt beim nachhaltigen Testen, weil es greifbar ist und direkt auf Tester-Ebene beginnt. Schau zuerst auf die Tools. Die Tool-Auswahl zählt, weil manche Werkzeuge viel Speicher und Rechenlast verbrauchen, andere deutlich weniger. Für nachhaltige Software gibt es inzwischen den Blauen Engel als Siegel, an dem man sich orientieren und vergleichen kann.
Der zweite Hebel ist die Testautomatisierung. Häufig wird stumpf alles wegautomatisiert, weil Speicher und Arbeitsspeicher als kostenlos gelten. Daraus entstehen Redundanzen ohne Mehrwert. Denselben Testfall an drei Stellen laufen zu lassen, kostet dreimal so viel Rechnerkapazität, bringt aber keinen zusätzlichen Erkenntnisgewinn.
Testfälle intelligent schneiden und bei der Automatisierung überlegen, ob es nicht auch mit weniger getan ist. Therese Kuhfuß
Hier gilt das 80/20-Prinzip. Die ersten Testfälle finden die meisten Fehler, gegen Ende wird die Ausbeute immer geringer. Die ehrliche Frage lautet: Wie viel willst du wirklich finden? Bei Dokumenten, die an Kunden verschickt werden, lässt sich vielleicht ein Restfehler in Kauf nehmen, wenn man dafür die Hälfte der Testfälle einspart. Im Safety-Bereich, etwa beim Test von Flugzeugen, ist das keine Diskussion. Da werden keine Testfälle gestrichen, weil Menschenleben wichtiger sind als eingespartes CO2.
Ein dritter, oft übersehener Punkt ist die Laufzeit der Automatisierung. Warum laufen automatisierte Tests immer nachts? Wenn ein separater Rechner zur Verfügung steht, lohnt der Gedanke, sie tagsüber oder am Wochenende laufen zu lassen, wenn viel Sonnenenergie im Netz ist, die sonst verkauft oder durch Abschalten von Windrädern gekappt werden muss. Nachts kommt dafür eher Strom aus anderen Quellen zurück.
Warum die Einsparung des Einzelnen trotzdem zählt
Der Effekt einer einzelnen Maßnahme ist klein, die Summe macht den Unterschied. Vier übliche PCs, die in rund 150 Nächten laufen, verbrauchen über ein Jahr so viele Kilowattstunden, dass man damit alternativ etwa 4000 Kilometer mit einem Tesla fahren könnte. Das ist nicht die Welt.
Der Vergleich, der das Prinzip trägt, ist das Wählen. Eine einzelne Stimme zählt wenig, aber wenn alle gehen, entsteht ein Ergebnis. Genauso verhält es sich mit nachhaltigem Testen: Je mehr in der Community darauf schauen, was sie tun können, desto mehr bewegt sich am Ende.
Nachhaltigkeit in der IT rechnet sich auch wirtschaftlich
Der hartnäckigste Irrtum ist die Annahme, grün sei automatisch teuer. Das Gegenteil stimmt oft. Wer Leistung einspart, spart bares Geld, weil weniger Verbrauch direkt geringere Kosten bedeutet. Bei aktuellen Energiepreisen fällt das stärker ins Gewicht als früher.
Dieselbe Logik gilt für die Lebensdauer. Eine wartbare Software mit hoher Kompatibilität und Portabilität braucht nicht in drei Jahren ein Nachfolgeprodukt, sondern läuft zehn Jahre weiter. Änderungen an ihr sind günstiger, als sie jedes Mal neu zu bauen. Kostenersparnis und Ressourcenschonung sind hier dasselbe Ziel.
Der Aufwand, Nachhaltigkeit mitzudenken, ist gering, weil Teams ihre nicht-funktionalen Anforderungen ohnehin betrachten. Verfügbarkeit etwa wird in praktisch jedem Projekt geprüft, etwa die Frage, ob es eine 24/7-Anwendung ist oder eine, die nur tagsüber läuft. Wenn das Mapping zwischen Qualitätskriterien und Nachhaltigkeit einmal transparent vorliegt, kostet die zusätzliche Betrachtung kaum mehr.
Der sanfte Weg schlägt die Brechstange
Nachhaltigkeit lässt sich nicht per Ansage durchsetzen. Erst war Agilität das große Thema, dann KI: Wer mit der Brechstange kommt und alles umstellen will, nimmt die Leute nicht mit. Agilität hat Jahre gebraucht und ist in vielen Unternehmen bis heute nur halb angekommen.
Besser ist der schrittweise Weg von unten nach oben. Erst beim nachhaltigen Testen ansetzen, Tools und Automatisierung prüfen, und so im Unternehmen eine Wahrnehmung für das Thema schaffen. Wenn dann eine neue Softwareentwicklung ansteht, ist der richtige Moment, die Frage zu stellen: Wollen wir Nachhaltigkeit hier mitdenken, vielleicht sogar eine Programmiersprache wählen, die weniger Rechenpower braucht?
Bei Greenfield-Projekten ist der Einstieg am einfachsten, weil nichts umgebaut werden muss. Die Zeit für den behutsamen Weg ist da. Wenn alle zusammen daran arbeiten, ist es eine schaffbare Aufgabe.
Häufig gestellte Fragen
Muss man für nachhaltige Software eigene Qualitätskriterien neu definieren?
Nein. Die ISO 25010 kennt kein Kriterium mit dem Namen Nachhaltigkeit, verteilt das Thema aber über bestehende Kriterien: Leistungseffizienz senkt den CO2-Fußabdruck, Benutzbarkeit und Zuverlässigkeit verlängern den Lebenszyklus, Kompatibilität spart Adapter- und Schnittstellenprodukte. Was fehlt, ist die Transparenz. Ein sauberes Mapping, welche Kriterien auf Nachhaltigkeit einzahlen, müsste einmal erstellt werden, statt dass jedes Team es neu erfindet.
Geht es bei nachhaltiger Software nur um den CO2-Ausstoß?
Nein. Neben dem ökologischen Aspekt zählen soziale Faktoren und die Lebensdauer eines Produkts. Barrierefreiheit und höhere Benutzerakzeptanz machen eine Anwendung mehr Personengruppen zugänglich, das ist die soziale Ebene. Gute Usability und hohe Zuverlässigkeit sorgen zugleich dafür, dass ein Produkt länger genutzt wird und am Markt bleibt. Ein langer Lebenszyklus ist selbst eine Form von Nachhaltigkeit.
Was hat Wartbarkeit mit Nachhaltigkeit zu tun?
Eine sauber designte Software lässt sich um neue Anforderungen erweitern, ohne dass man jedes Mal von vorn beginnt. Das vermeidet teure Neuentwicklungen und verlängert die Nutzungsdauer. Gerade im regulatorischen Umfeld, wo der Regulator laufend neue Anforderungen vorgibt, entscheidet die Wartbarkeit darüber, ob Änderungen tragbar bleiben oder ob am Ende ein Nachfolgeprodukt gebaut werden muss.
Wann im Projekt sollte Nachhaltigkeit als Qualitätsziel festgelegt werden?
Am Anfang der Softwareentwicklung, nicht am Ende beim Test. Die ISO 25010 ist keine Test-Norm, sondern eine Norm für die Entwicklung. Requirements-Engineers, Entwickler und Fachabteilungen legen früh fest, welche Nachhaltigkeitskriterien umgesetzt und wie stark sie gewichtet werden. Der Test kann später nur prüfen, was vorher als Anforderung definiert wurde.
Darf Nachhaltigkeit hinter anderen Anforderungen zurückstehen?
Ja, und das ist legitim. Nachhaltigkeit ist ein Kriterium unter mehreren und wird im Projekt gewichtet, gegen Security- und Safety-Anforderungen tritt sie zurück. Beim Test von Flugzeugen werden keine Testfälle gestrichen, um Rechenzeit zu sparen, weil Menschenleben schwerer wiegen als eingespartes CO2. Bei Dokumenten an Kunden kann ein Restfehler dagegen vertretbar sein.
Ist es sinnvoll, möglichst viele Testfälle zu automatisieren?
Nein. Häufig wird stumpf alles wegautomatisiert, weil Speicher und Rechenleistung als kostenlos gelten. Denselben Testfall an drei Stellen laufen zu lassen kostet dreifache Rechnerkapazität, findet aber keinen zusätzlichen Fehler. Dazu kommt das 80/20-Prinzip: Die ersten Testfälle decken die meisten Fehler auf, gegen Ende sinkt die Ausbeute deutlich. Testfälle intelligent zu schneiden bringt mehr als Vollständigkeit.
Spielt es eine Rolle, zu welcher Tageszeit automatisierte Tests laufen?
Ja. Automatisierte Tests laufen aus Gewohnheit nachts, obwohl dann eher Strom aus anderen Quellen ins Netz zurückkommt. Steht ein separater Rechner zur Verfügung, lohnt der Gedanke, tagsüber oder am Wochenende zu testen, wenn viel Sonnenenergie im Netz ist, die sonst verkauft oder durch das Abschalten von Windrädern gekappt werden muss.
Ist nachhaltige Softwareentwicklung teurer als herkömmliche?
Nein, oft stimmt das Gegenteil. Wer Leistung einspart, spart bares Geld, weil weniger Verbrauch direkt geringere Kosten bedeutet. Eine wartbare Software mit hoher Kompatibilität und Portabilität läuft zehn Jahre weiter, statt nach drei Jahren ein Nachfolgeprodukt zu brauchen, und Änderungen an ihr sind günstiger als ein Neubau. Kostenersparnis und Ressourcenschonung fallen hier zusammen.
