Nachhaltigkeit von Software testen – Wie testet man Nachhaltigkeit als Qualitätseigenschaft von Software?

„Nichtfunktionale Anforderungen sind Beschränkungen, die einem System auferlegt werden, um Qualitätsmerkmale wie etwa Zuverlässigkeit, Wartbarkeit oder Skalierbarkeit zu definieren.“ So haben es vermutlich viele Informatikerinnen und Informatiker im ersten Semester gelernt. Viele der „-keiten“ oder „-ilities“ (Usability, Scalability ...) sind als messbare Qualitätsanforderungen an Software in der ISO-Norm 25010 für „Software Quality Requirements“ definiert. Was dort bis dato jedoch fehlt, ist die Nachhaltigkeit (Sustainability). Wie also operationalisiert man Nachhaltigkeit als testbare Qualitätsanforderung an Software?

Tools zur Überprüfung der Nachhaltigkeit von Software

Erste Schritte zur Testung der Nachhaltigkeit von Software gehen oft über die CPU-Last. Dabei wird gemessen, wie sehr Software den Prozessor auslastet. Da Prozessoren einen großen Teil des Stromverbrauchs verursachen, lässt sich durch die Messung ihrer Auslastung grob abschätzen, wie hoch der Stromverbrauch ist. Der Vorteil: Fast alle Sprachen verfügen über Bibliotheken, um die CPU-Last zur Laufzeit zu messen.

Die CPU-Last allein sagt zwar nichts über den exakten Stromverbrauch von Software aus, wenn aber zwei Versionen derselben Software – auf gleicher Hardware – unterschiedlich viel CPU-Last erzeugen, reicht diese Info, um grobe Trends nachzuvollziehen. Da die Messung der CPU-Last einen leichten Einstieg in die Messung darstellt und wenig Modifikation der Codebases voraussetzt, ist sie gut geeignet, um erste Erfahrungen mit dem mittelbaren Testen von Nachhaltigkeit zu sammeln. Auch wenn sie in der Reproduzierbarkeit und der Vergleichbarkeit gewisse Schwächen hat, wie dieser Artikel von Green Coding Berlin darstellt.

Quellcodebasierte Messung von Nachhaltigkeit

Eigentlich sollte man nicht von „Messung“ sprechen, solange keine spezialisierte Hardware oder keine spezialisierten Stromzähler installiert sind. Aus digitalen Beobachtungen von CPU, Disk, Bandbreite und I/O können grundsätzlich nur Schätzungen über die tatsächlichen Umweltauswirkungen angestellt werden. Einige quellcodebasierte Tools, die hinreichend gute Schätzungen für die Nachhaltigkeit von Software produzieren, gibt es jedoch: JoularJX für Java, co2.js für JavaScript und Codecarbon für Python sind jeweils Bibliotheken, die einfach in Code eingebunden werden können und damit näherungsweise korrekte Aussagen über das Laufzeitverhalten ermöglichen. Anspruchsvolle Lösungen wie Scaphandre, PowerJoular oder TRACARBON setzen teilweise spezielle Hardware oder RAPL voraus und ermöglichen dadurch tatsächliche Messungen und nicht „nur Schätzungen“.

Monitoring der Nachhaltigkeit von Software

Die Tools oben zählen zur konstruktiven Qualitätssicherung. Wenn Software fertigentwickelt ist und quellcodebasierte Messungen von außen mit analytischer Qualitätssicherung auf die Probe gestellt werden sollen, bietet sich ein Monitoring zur Laufzeit an. Gängige Online-Tools wie greenframe.io oder digitalbeacon.co – die eine Messung des Footprint von Websites unterstützen sollen – sowie ihre Vor- und Nachteile werden in diesem Artikel von .eco vorgestellt. Da der Zusammenhang zwischen Datenübertragung und den Umweltauswirkungen in der Praxis jedoch eher schwierig ist – wie in diesem Blog-Beitrag erklärt –, werden diese Tools hier nicht als Instrumente der quantitativen Softwarequalitätssicherung inkludiert.

Für schnelle lokale Tests – insbesondere für Desktop-Anwendungen – bietet sich softwarefootprint von Jens Gröger am Öko-Institut an. Vergleichbar, aber für den Browser, beinhaltet der Firefox Profiler zudem seit der Version 104 ein Toolkit, um die Nachhaltigkeit von Anwendungen im Browser zu testen. Gegenüber Online-Tools, in die man URLs von Webseiten eingibt, bietet dies den Vorteil, dass auch nicht öffentlich zugängliche Seiten und Anwendungen getestet werden können.

Zwei Tools im Cloud-Kontext für das Monitoring zur Laufzeit sind Kepler und Cloud Carbon Footprint (CCF). Kepler bietet die Möglichkeit, einzelne Pots in Kubernetes-Clustern zu monitoren. CCF ermöglicht die Anbindung unterschiedlicher Cloud Provider über Billing-APIs und kann über abgerechnete Ressourcen eine Alternativbetrachtung zu den oft „schöngerechneten“ Dashboards der Provider selbst bieten.

Nachhaltigkeit testen in CI/CD Pipelines

Im klassischen Testen werden viele Qualitätskriterien von Software automatisch in Entwicklungs-Pipelines geprüft. Sobald Code bereitgestellt wird, überprüfen diese Pipelines Regeln, bevor der Code integriert und anderen zur Verfügung gestellt oder in Betrieb genommen wird. Ein gängiges Tool für die Abbildung solcher Pipelines ist SonarQube, für das die EcoCode Plugins viele Best Practices für nachhaltigen Code prüfen. Es handelt sich dabei um eine statische Codeanalyse, die den Vorteil hat, dass Code nicht ausgeführt werden muss, um seine Nachhaltigkeit zu beurteilen. Gleichzeitig kann über die Ausführung von Unit-Tests auch der Energieverbrauch von Software bereits in Pipelines gemessen werden und bei Überschreitungen definierter Limits die Integration des Codes gestoppt werden.

Das Forschungsprojekt SoftAware des Umweltbundesamts in Zusammenarbeit mit der Sustainable Digital Infrastructure Alliance setzt auch bei den Pipelines an. Da die meiste moderne Software zu einem Großteil aus externen Komponenten und Bibliotheken besteht, hat das Projekt zum Ziel, genau diese wiederverwendeten Komponenten innerhalb von Pipelines zu analysieren, um einem ganzheitlichen Bild der Nachhaltigkeit von Software näher zu kommen. Wer zudem den Energieverbrauch seiner Pipelines selbst verbessern möchte, sollte sich die Eco-CI Actions für GitHub und GitLab CI anschauen.

Ebenfalls zu den eher statischen Verfahren zählen Inspektionen und Reviews. Wer Nachhaltigkeit ernsthaft in den Softwareentwicklungs- und Qualitätssicherungsprozess integrieren möchte, muss sicherstellen, dass auch bei Merge Requests und in Code Reviews auf die Code-Qualität im Sinne der Nachhaltigkeit geachtet wird. Hier bietet es sich an, projekt- und organisationsspezifische Guidelines und Checklisten für Best Practices und Antipatterns zu definieren. Einige Inspiration für entsprechende Pattern finden sich bei der VU Amsterdam und dem European Institute for Sustainable IT.

Methodik für nachhaltiges Software Testing

Sobald das Toolset feststeht, muss entschieden werden, was und wie gemessen wird. Es ergibt keinen Sinn, eine Software einmalig mit einem User zu testen. Ein repräsentatives Standardnutzungsszenario muss definiert und regelmäßig unter realistischer Last gemessen werden. Dabei sollte die genutzte Hardware der des Produktivbetriebs entsprechen. Zudem müssen Aspekte des Skalierungsverhaltens in elastischen Infrastrukturen berücksichtigt werden.

Neben der Messung unter Last sollte auch der Leerlauf betrachtet werden, da viele Systeme gelegentlich ohne akute Auslastung betrieben werden. Die Gefahr besteht, dass Systeme im Leerlauf eine unverhältnismäßig hohe IT-Last erzeugen, während Optimierungen oft nur unter Last betrachtet werden.

Letztlich müssen Messergebnisse eingeordnet und bewertet werden, denn eine Messung allein hilft noch keine Entscheidung zu treffen. Durch die Definition von Ziel-KPIs und kritischen Werten können Messergebnisse so in einen Kontext gesetzt werden. Auch muss berücksichtigt werden, ob die Umweltauswirkungen in einem vertretbaren Verhältnis zum Anwendungsfall stehen. Wie in der Ökobilanzierung bietet es sich hier an, funktionale Einheiten – etwas User, Sessions oder Transaktionen – zu definieren, zu denen KPIs ins Verhältnis gesetzt werden.

Zusammenfassung

Datenbasierte Verbesserungsstrategien tragen mehr zur Erreichung von Nachhaltigkeitszielen bei als die blinde Optimierung von Code, deren Wirkungsgrad nicht objektiv beurteilt werden kann. Der technische Lösungsweg für nachhaltige Software ist mittlerweile gut verstanden. Herausforderungen für nachhaltige IT in Organisationen sind heute eher die Kultur und die Datenlage. Solange Nachhaltigkeit nicht flächendeckend als Qualitätseigenschaft verstanden und gemessen wird, kann unmöglich beurteilt werden, welche Entscheidungen zu mehr Nachhaltigkeit führen. Zusammenfassend sollten für nachhaltiges Testen daher folgende Schritte bedacht werden:

• 1. Nachhaltigkeits-KPIs: Definition von KPIs, Zielen und funktionellen Einheiten.
• 2. Quellcodebasiertes Messen: In der Entwicklung, um früh Erkenntnisse zu Design-Entscheidungen einzubeziehen.
• 3. Statische Codeanalyse: Vor der Integration von Code, um gängige Antipattern zu vermeiden.
• 4. Reviews: In Teams, um komplexe Abhängigkeiten und Zielkonflikte transparent zu diskutieren.
• 5. Monitoring: Kontinuierliche Überwachung zur Laufzeit.

Ausblick

Eine große Limitation der vorgestellten Tools und Methoden ist, dass sie sich auf Treibhausgasemissionen und Stromverbrauch beschränken. Rechenzentren, Hardware, Mineralien, Kühlsysteme, Wasserverbräuche, Unterseekabel und Elektroschrott verursachen messbare Umweltauswirkungen, die über den reinen Stromverbrauch hinausgehen. Auch berücksichtigen nur wenige Tools die Stromquelle zur Laufzeit, obwohl diese in der Entwicklung beeinflusst werden kann, wie in diesem Blog-Beitrag gezeigt wird.

Dieser Herausforderung begegnen wir bei adesso gemeinsam mit unseren Partnern im Projekt ECO:DIGIT, das durch das Bundesministerium für Wirtschaft und Klimaschutz gefördert wird. Übergeordnetes Ziel des Projekts ist es, Transparenz, Objektivierbarkeit und Standardisierung zur Bewertung des Ressourcenverbrauchs beim Einsatz von Software herzustellen. Indikatoren werden dabei der Stromverbrauch der Arbeitsumgebung, die Inanspruchnahme von Hardware-Ressourcen, aber auch weitere Metriken, wie die Menge an Rohstoffen und Chemikalien für die Hardware-Herstellung, sein.

Die betrachteten Tools und Methoden sind also ein guter Start und es sollte nicht erst auf die Entwicklung der perfekten Methodik gewartet werden, bevor erste Erfahrungen mit der Messung von Nachhaltigkeit gesammelt werden. Solange allerdings nicht die ganzen Umweltauswirkungen von Systemen systematisch erfasst und bewertet werden, kann heute die tatsächliche Qualität von Software und damit von Arbeitsergebnissen nicht abschließend beurteilt werden.