Tester-Tea-Time (Teil 2): Rechtschreibung in Anwendungen – mehr als nur Kleinlichkeit

Die „Tester-Tea-Time“ ist ein Beitragsformat auf diesem Blog, in dem Themen aufgegriffen werden, die Testerinnen und Tester tagtäglich beschäftigen. Gewisse Problemstellungen oder Themen kehren immer wieder, daher soll hier eine Basis geschaffen werden, solche Phänomene zu erläutern und Lösungen dafür zu finden. Zudem sollen Diskussionen und neue Denkweisen angeregt werden. Im Testing können wir viel voneinander lernen, indem wir unseren Alltag beobachten!

Moderator: Willkommen zur Tester-Tea-Time! Im Interview mit Testerinnen und Testern der ZEISS Digital Innovation (ZDI) werden wir erneut spannende Themen diskutieren.

Widmen wir uns nun dem heutigen Thema. Dazu sprechen wir mit Sandra Wolf (SW), Testerin bei ZDI. Warum beschäftigen wir uns dieses Mal mit dem Thema „Rechtschreibung“ und wo siehst du den Zusammenhang mit der Softwareentwicklung?

SW: Der Alltag eines Testers hält viele Herausforderungen bereit. Gerade während des Testprozesses ist große Konzentration gefragt, wenn jedes Detail auf Qualität überprüft werden muss. Eines dieser Details ist die Rechtschreibung und Grammatik. Oft wird es unterschätzt, wie wichtig die korrekte Orthografie sein kann.
Im Arbeitsalltag passiert es oft, dass Rechtschreibfehler in der Software gefunden werden. Doch wenn diese zur Behebung an die Entwicklung gemeldet werden, kommt es nicht selten vor, dass der Tester dafür belächelt wird. Die vorherrschende Meinung ist, dass das nur sehr kleine und unwichtige Fehler wären. Im heutigen Gespräch soll mit dieser Meinung aufgeräumt werden. Rechtschreibung und Zeichensetzung sind nicht gerade die beliebtesten Themen und werden häufig als sehr trocken empfunden. Dabei sind gerade diese Regeln, die wir seit der Schulzeit lernen, eine Orientierungshilfe für uns und unser Gehirn. Ein Wort, das richtig geschrieben wird, wird auch leichter gelesen, im Satz zu einer Aussage kombiniert und somit im Gehirn verarbeitet. Aufmerksame Leser – oder im Fall der Softwareentwicklung – Nutzer werden zwangsläufig über falsche Rechtschreibung in der Software stolpern. Es wurde sogar nachgewiesen, dass bestimmte Persönlichkeitstypen unterschiedlich emotional auf falsche Orthografie reagieren (vgl. Weiß, 2016). Somit können Fehler in diesem Bereich im Gegensatz zu ihrem trockenen Ruf Emotionen auslösen, die dann als Konsequenz den Umgang mit der Software beeinflussen.

Zwei Kollegen zum Interview über Videokonferenz verbunden
Abbildung: Stanislaw Traktovenko und Sandra Wolf in der virtuellen Tester-Tea-Time im Gespräch.

Moderator: Von welcher Art der Beeinflussung sprechen wir in diesem Fall?

SW: Korrekte Rechtschreibung strahlt zum Beispiel Seriosität aus. In Bewerbungen und amtlichen Anträgen wird eine fehlerfreie Rechtschreibung vorausgesetzt. Es ist sogar in Studien belegt worden, dass beispielsweise die Chancen auf Bewilligung eines Kreditantrags durch sprachliche Fehler vermindert werden (vgl. Weiß, 2016). Übertragen wir das nun auf die Software, die wir entwickeln, ist nur ein möglicher Schluss zu ziehen: Rechtschreibung ist essenziell für eine adäquate Nutzung und die Außenwirkung der Software beim Kunden. Und somit sollte dieses Thema innerhalb des Entwicklungsprozesses eindeutig ernster genommen werden und mehr Aufmerksamkeit bekommen als bisher.
Schauen wir uns den Alltag von Testern und Entwicklern an, dann wissen wir, dass die Funktionalität der Software im Mittelpunkt steht. Natürlich ist nachvollziehbar, dass ein kosmetisch wirkendes Thema wie die Rechtschreibung hinter aufwendig programmierten Anwendungsteilen zurücktritt. Das sollte alle Beteiligten des Prozesses allerdings nicht über die Wichtigkeit hinwegtäuschen. Denn ganz klar ist, dass der Erfolg eines Produktes und somit auch einer Anwendung von der sprachlichen Qualität beeinflusst werden kann. Der erste Eindruck beim Lesen eines Textes oder beim Nutzen einer Software lässt uns automatisch auch auf den Bildungsgrad der Schöpfer schließen (vgl. Frost, 2020). Somit kann durch eine fehlerhafte Rechtschreibung ein schlechtes Licht auf eine gute Software geworfen werden.

Moderator: Wie muss ich mir dieses “schlechte Licht”, in dem die Software dann steht, im Detail vorstellen?

SW: Durch eine schlechte Rechtschreibung kann das Vertrauen in die Qualität der Software verloren gehen und die Akzeptanz für die Anwendung sinken. Der Nutzer könnte davon ausgehen, dass generell wenig Wert auf Qualität gelegt wird, wenn schon mit der Rechtschreibung nachlässig umgegangen wird. Schließlich drückt eine korrekte Orthografie nicht nur Professionalität, sondern auch einen gewissen Respekt gegenüber dem Leser/Nutzer aus. Es konnte sogar festgestellt werden, dass eine Textqualität beeinflusst, ob jemand vom Interessenten zum Käufer wird. Wird das auf die Softwareentwicklung bezogen, kann es auf jeden Fall Budget einsparen, wenn von Anfang an auf die Rechtschreibung geachtet wird und die Meldung solcher Fehler ernst genommen wird (vgl. Frost, 2020).
Letztendlich präsentieren wir in unseren Projekten auch unser Unternehmen, weshalb das Thema der Orthografie weitreichendere Auswirkungen haben kann, als wir zunächst denken. Im besten Fall kann durch eine gute Rechtschreibung der Ruf unserer Softwareentwicklung verbessert werden bzw. erhalten bleiben. Dadurch können wiederum mehr Kunden und höhere Umsätze erzielt werden, weil die gleichbleibende Qualität unserer Softwareprodukte ein Argument für eine Zusammenarbeit mit der ZDI sein kann.

Moderator: Hier möchte ich gern anknüpfen und Stanislaw Traktovenko (ST) aus unserem Usability-Team zu Wort kommen lassen. Welche Bedeutung nimmt das Thema der Rechtschreibung aus deiner Sicht ein? Siehst du ebenfalls die Auswirkungen in dem von Sandra Wolf beschriebenen Maße?

ST: Aus meiner Sicht hat die Rechtschreibung einen Einfluss auf die Lesbarkeit und dadurch auf die Wahrnehmung der Informationen in der Anwendung. Wir ordnen das den Usability-Prinzipien Konsistenz und Sprache zu. Rechtschreibfehler haben also potenziell eine direkte Auswirkung auf die Usability einer Anwendung. Eine inkorrekte Orthografie stört zum Beispiel den Lesefluss und somit die Wahrnehmung der Software durch den Nutzer. Es entsteht ein negatives Gefühl und der Nutzer beschäftigt sich nicht mehr mit der Aufgabe, die er mit der Software eigentlich verfolgt hatte. Er wird durch eine falsche Rechtschreibung abgelenkt und das beeinflusst seine Effektivität und Effizienz. Auch wenn Rechtschreibung nur ein kleiner Bruchteil der Usability ist, kann sie somit größere Auswirkungen haben als gedacht, so wie Sandra bereits vorher erläutert hat.

Moderator: Vielen Dank, Sandra und Stanislaw für diese interessanten Einblicke. Die Auswirkungen sind tatsächlich weitreichender als erwartet, das ist sehr erstaunlich. Wir können somit zusammenfassen, dass das trocken wirkende Thema der Rechtschreibung in allen Softwareprojekten ernst genommen werden muss, um eine möglichst hohe Qualität zu liefern und sowohl die Produkte als auch uns als Unternehmen adäquat zu präsentieren. Das Thema der Rechtschreibung wirkt im ersten Moment vielleicht banal, hat aber im Endeffekt eine große Wirkung und somit Wichtigkeit für uns alle. Das Thema sollte daher unbedingt die Aufmerksamkeit bekommen, die es verdient hat.

In den folgenden Beiträgen werden wir weitere Problemstellungen aus dem Alltag von Testerinnen und Testern aufgreifen und besprechen, welche möglichen Lösungsansätze es dafür gibt.

Security und Compliance in Softwareprojekten – Dependencies unter Kontrolle bringen

Symbolbild: Weiße Tastatur mit Schloss und Schlüssel

Dieser Blogbeitrag befasst sich mit den hohen Ansprüchen an Security und Compliance, die wir an jedes Softwareprojekt stellen. Dafür verantwortlich ist in jedem Projekt ein ausgebildeter Security Engineer. Dabei stellen ihn insbesondere die unzähligen Dependencies in Softwareprojekten, welche in ihrer Vielzahl von Versionen unter Kontrolle gebracht werden müssen, vor große Herausforderungen.

Abbildung 1: Ein Ausschnitt aus dem Abhängigkeits-Graph eines npm Paketes, aus npmgraph.js.org/?q=mocha

Herausforderungen in Softwareprojekten

Große Softwareprojekte bestehen schon seit langer Zeit aus kleineren Teilen, die für ihr jeweiliges Gebiet wiederverwendet werden können. Komponenten, bei denen es nicht um geheime Funktionalität geht, werden zunehmend als „FOSS (Free and Open Source Software)“ veröffentlicht. Das bedeutet „quelloffen“ (Open Source) und mit einer freien Lizenz zur Weiterverwendung.

Dabei ist es für die Einschätzung und Prävention von Sicherheitslücken äußerst wichtig, eine vollständige Übersicht über alle eingebundenen Drittbibliotheken zu haben. Denn jedes unserer importierten Module kann ebenfalls mit mehreren Abhängigkeiten verbunden sein. Schnell steigt dann die Anzahl an zu beobachtenden Abhängigkeiten in die Tausende und es ist nicht einfach, zwischen allen Versionen den Überblick über Lizenzen und Sicherheitslücken zu behalten.

Die Auswirkung der Problematik wird z. B. klar, wenn man Fälle von „Supply chain attacks“ und „Dependency Hijacking“ der letzten Jahre liest. Eine interessante Meta-Analyse ist „What Constitutes a Software Supply Chain Attack? “ von Ax Sharma (https://blog.sonatype.com/what-constitutes-a-software-supply-chain-attack). Den Umgang mit diesen Komponenten in großen wie kleinen Softwareprojekten aus Sicht eines Security Engineers möchten wir weiter erläutern.

Lösungsmöglichkeiten mittels FOSS Scanner

Über die Zeit haben sich einige Projekte dem Problem der Kenntlichmachung von FOSS-Komponenten gewidmet. Es gibt Programme zum Erstellen von Bill of Material (BOM) und Übersichten zu Sicherheitsrisiken, welche wir verprobt haben.

Weiter gibt es große Kataloge wie den „Node Paketmanager“ (npm), die selbst ausführliche Informationen zu den jeweils angebotenen Komponenten geben.

Auch wenn es diese freien und quelloffenen Komponenten gratis gibt, so sind sie nicht ohne Aufwand, besonders in langlebigen und wichtigen Softwareprojekten.

Wir haben für die Evaluierung den OWASP-Dependency Check (DC) und das OSS Review Toolkit als kombinierte Lösung für das Auffinden von Sicherheitsproblemen mit DC und Überprüfung der Einhaltung der Lizenzbestimmungen eingesetzt. Im Vergleich zu kommerziellen Lösungen wie BlackDuck bieten diese frei und kostenlos die Möglichkeit einer Übersicht über die FOSS-Komponenten in Projekten und die Bewertung von Risiken.

Das war aber unserer Erfahrung nach mit Mehraufwand sowohl in der Konfiguration als auch bei der kontinuierlichen Überprüfung, d. h. neuen Scans auf neue Sicherheitsprobleme, verbunden.

Verantwortung als Software Engineer

Unsere Richtlinien für sichere Entwicklung und den Einsatz von Open Source geben die notwendigen Prozesse und Ziele vor, an dem sich unsere Security Engineers in Vertretung der Projekte orientieren. Der vielleicht wichtigste Ausschnitt daraus wird im folgenden Abschnitt aufgeführt:

It is our responsibility that the following so called Essential FOSS Requirements are fulfilled:

  • All included FOSS components have been identified and the fitness for purpose has been confirmed.
  • All licenses of the included FOSS have been identified, reviewed and compatibility to the final product/service offering has been verified. Any FOSS without a (valid) license has been removed.
  • All license obligations have been fulfilled.
  • All FOSS are continuously – before and after release – monitored for security vulnerabilities. Any relevant vulnerability is mitigated during the whole lifecycle.
  • The FOSS Disclosure Statement is available to the user.
  • The Bill of Material is available internally.

For that it must be ensured that

  • the relevant FOSS roles are determined and nominated.
  • the executing development and procurement staff is properly trained and staffed.

Anhand dieser Richtlinien werden verpflichtende Trainings, Wissensträger und Qualitätskontrollen gebildet.

Vorstellung der Abläufe

  • Untersuchen vor Einbindung (Lizenzen, Operational Risk wie Update-Häufigkeit)
  • Überwachen von Updates (Operational Risks)

Irgendwann soll eine neue Funktion zu einem Softwareprojekt hinzugefügt werden. Oft kennen Entwickler bereits mögliche FOSS Software, die bei der Funktionalität hilft.

Ein wichtiger Aspekt ist, dass möglichst jeder Entwickler den Umgang mit Paketmanagern und mögliche Implikationen kennt, um Ergebnisse aus den Tools oder Analysen richtig einordnen zu können. Es ist z. B. sehr wichtig, sich zu veranschaulichen, aus wie vielen Teilen eine Top-Level-Abhängigkeit besteht – oder verschiedene Abhängigkeiten gleicher Funktionalität im Hinblick auf zukünftige sichere Entwicklung (Operationelle Risiken) zu bewerten. Immer öfter sehen wir das Ziel, die Zahl an Abhängigkeiten klein zu halten. Das sollte bei der Auswahl von Komponenten berücksichtigt werden, um möglichst nur das wirklich notwendige an Funktionalität von zusätzlichen Abhängigkeiten zu erhalten.

Bereits vor dem Einbinden sind durch den Security Engineer potenzielle Imports auf ihre kompatible Lizenz und bestehende Sicherheitslücken zu überprüfen. Ebenso wichtig ist aber auch der Blick auf das, was unter operationale Risiken fällt wie z. B.:

  • Aktualität
  • Lebendige Community oder aktive Instandhaltung
  • Update-Zyklus ausreichend agil, um auftretende Sicherheitslücken zu beseitigen
  • Wird Wert auf den sicheren Umgang mit Abhängigkeiten gelegt?
  • Ist die Anzahl an weiteren Abhängigkeiten sinnvoll und wird wenn möglich reduziert?

Im laufenden Entwicklungsprozess und später im Betrieb muss das Projektteam auch informiert werden, wenn neue Sicherheitslücken entdeckt oder geschlossen werden. Dafür können periodische Scans oder eine Datenbank mit Alerts für Sicherheitslücken eingesetzt werden. Für periodische Scans spricht die größere Unabhängigkeit von der einen Datenbank – dafür müssen Hardware und Alerts selbst bereitgestellt werden. Diese wiederum sind einer der Mehrwerte einer Software-Composition-Analysis-Lösung wie BlackDuck.

Da der Anteil an gut gekennzeichneter FOSS steigt, wird bei neuen Versionen der Zeitaufwand für manuelle Kuration vergleichsweise geringer. Dazu zählen das Deklarieren einer Lizenz – und leicht auffindbare und formatierte Copyright-Angaben in den Komponenten, was in älteren Komponenten oft sehr individuell formatiert oder ganz weggelassen wurde. Ist keine Lizenz angegeben, so darf dies nicht fälschlicherweise als „Freibrief“ verstanden werden. Ohne eine Lizenz darf eine Komponente nicht ohne Einverständnis der Autoren benutzt werden!

Beispiel einer Sicherheitslücke

Ein Beispiel für eine komplizierte Sicherheitslücke ist unter dem CVE-2021-32796 veröffentlicht worden. Eingebunden wird das problematische Modul xmldom indirekt über zwei weitere Abhängigkeiten in unserem Beispielprojekt.

BlackDuck zeigt uns zu dem Modul folgende Sicherheitswarnung:

Abbildung 2: BlackDuck: Beispiel Zusammenfassung einer Schwachstelle  

Damit kann der Security Engineer bereits eine grobe Einschätzung zur Tragweite der Sicherheitslücke vornehmen. Auch ist ein Hinweis auf dem Patch in Version 0.7.0 angegeben.

Wichtigkeit von Vorlauf für Updates/Austausch von Kompetenzen

Wir haben in der Zeit bis zu der „frischen Veröffentlichung“ unter @xmldom/xmldom bereits überprüfen können, welchen Aufwand es bedeuten würde, ohne diese Abhängigkeit auszukommen.

Um diese Zeit zu haben, ist es sehr nützlich, bereits im Entwicklungsprozess – und mit genügend Vorlauf zu einer Produktveröffentlichung – eine Übersicht über mögliche Probleme zu bekommen.

Das erleichtert den Entwicklern das Evaluieren von Ausweichlösungen für problematische Software-Bibliotheken, sei es wegen Sicherheitslücken, inkompatiblen Lizenzen oder anderer operativer Risiken.

Fazit

Dieser Beitrag hat einen Überblick über unsere Arbeit mit der großen Vielfalt an Open Source in unseren Projekten und die Aufgaben als Security Engineer im Umgang mit Open Source gegeben. Damit bringen wir mittels moderner Werkzeuge die Vielfalt an Abhängigkeiten unter Kontrolle und schaffen die notwendige Transparenz und Sicherheit. Bereits vor Einbinden von Abhängigkeiten sollte eine Evaluierung dieser von einem geschulten Team durchgeführt werden, und danach während des ganzen Software-Lebenszyklus überwacht und auf Probleme reagiert werden.