Quellcode-QA: Es ist nicht mehr nur etwas für Entwickler

Als ich vor zwanzig Jahren in der Automobilindustrie arbeitete, sagte der Direktor einer Fabrik oft: „Wir haben einen Tag Zeit, um ein Auto zu bauen, aber unser Kunde hat ein Leben lang Zeit, es zu inspizieren.“ Qualität war von größter Bedeutung. In reiferen Branchen wie der Automobil- und Bauindustrie ist die Qualitätssicherung ein wichtiger Aspekt, der systematisch in den Produktentwicklungsprozess integriert wird. Während dies sicherlich auf Druck von Versicherungsunternehmen zurückzuführen ist, wird es auch – wie der Fabrikdirektor feststellte – von der Lebensdauer des resultierenden Produkts bestimmt.

Wenn es um Software geht, bedeuten kürzere Lebenszyklen und kontinuierliche Upgrades jedoch, dass die Integrität des Quellcodes oft zugunsten neuer Features, ausgefeilter Funktionalität und schneller Markteinführung übersehen wird. Produktmanager räumen der Qualitätssicherung des Quellcodes oft die Priorität ein oder überlassen sie den Entwicklern, obwohl sie einer der kritischeren Faktoren bei der Bestimmung des Schicksals eines Produkts ist. Für Produktmanager, die darauf bedacht sind, eine solide Grundlage für die Produktentwicklung zu schaffen und Risiken zu eliminieren, ist die Definition und Implementierung einer systematischen Bewertung der Quellcodequalität unerlässlich.

„Qualität“ definieren

Bevor Sie untersuchen, wie Sie einen Quellcode-QA-Prozess richtig bewerten und umsetzen, ist es wichtig zu bestimmen, was „Qualität“ im Kontext der Softwareentwicklung bedeutet. Dies ist ein komplexes und facettenreiches Thema, aber der Einfachheit halber können wir sagen, dass sich Qualität auf Quellcode bezieht, der das Wertversprechen eines Produkts unterstützt, ohne die Kundenzufriedenheit zu beeinträchtigen oder das Geschäftsmodell des Entwicklungsunternehmens zu gefährden.

Mit anderen Worten, ein qualitativ hochwertiger Quellcode implementiert die funktionalen Spezifikationen des Produkts genau, erfüllt die nicht funktionalen Anforderungen, stellt die Zufriedenheit der Verbraucher sicher, minimiert Sicherheits- und Rechtsrisiken und kann kostengünstig gewartet und erweitert werden.

Angesichts der weiten und schnellen Verbreitung von Software können die Auswirkungen von Softwarefehlern erheblich sein. Probleme wie Fehler und Codekomplexität können das Endergebnis eines Unternehmens beeinträchtigen, indem sie die Produktakzeptanz behindern und die Kosten für das Software Asset Management (SAM) erhöhen, während Sicherheitsverletzungen und Verstöße gegen die Lizenzeinhaltung den Ruf des Unternehmens beeinträchtigen und rechtliche Bedenken aufwerfen können. Selbst wenn Softwarefehler keine katastrophalen Folgen haben, verursachen sie unbestreitbare Kosten. In einem Bericht aus dem Jahr 2018 stellte das Softwareunternehmen Tricentis fest, dass 606 Softwareausfälle von 314 Unternehmen im Vorjahr für Umsatzeinbußen in Höhe von 1,7 Billionen US-Dollar verantwortlich waren. In einem gerade veröffentlichten Bericht für das Jahr 2020 bezifferte CISQ die Kosten für qualitativ schlechte Software in den USA auf 2,08 Billionen US-Dollar, wobei weitere geschätzte 1,31 Billionen US-Dollar an zukünftigen Kosten durch technische Schulden entstehen. Diese Zahlen könnten durch frühere Interventionen gemildert werden; Die durchschnittlichen Kosten für die Lösung eines Problems während des Produktdesigns sind erheblich niedriger als die Lösung desselben Problems während des Testens, was wiederum exponentiell geringer ist als die Lösung des Problems nach der Bereitstellung.

Umgang mit der heißen Kartoffel

Trotz der Risiken wird die Qualitätssicherung in der Softwareentwicklung bruchstückhaft behandelt und ist eher durch einen reaktiven Ansatz als durch den proaktiven Ansatz anderer Branchen gekennzeichnet. Die Verantwortung für die Qualität des Quellcodes ist umstritten, wenn sie als kollektive Verantwortung verschiedener Funktionen angesehen werden sollte. Produktmanager müssen Qualität als wirkungsvolles Merkmal und nicht als Overhead betrachten, Führungskräfte sollten auf den Qualitätszustand achten und in ihn investieren, und Engineering-Funktionen sollten sich dagegen wehren, Code-Reinigung als „heiße Kartoffel“ zu behandeln.

Diese Delegierungsherausforderungen werden durch die Tatsache verstärkt, dass bestehende Methoden und Tools das Problem der Codequalität nicht als Ganzes angehen. Die Verwendung von Continuous-Integration-/Continuous-Delivery-Methoden reduziert die Auswirkungen von Code geringer Qualität, aber wenn CI/CD nicht auf einer gründlichen und ganzheitlichen Qualitätsanalyse basiert, können die meisten Gefahren nicht effektiv vorhergesehen und angegangen werden. Teams, die für QA-Tests, Anwendungssicherheit und Lizenz-Compliance verantwortlich sind, arbeiten in Silos mit Tools, die darauf ausgelegt sind, nur einen Teil des Problems zu lösen und nur einige der nicht funktionalen oder funktionalen Anforderungen zu bewerten.

Unter Berücksichtigung der Rolle des Produktmanagers

Die Qualität des Quellcodes spielt bei zahlreichen Dilemmas eine Rolle, mit denen ein Produktmanager während des Produktdesigns und während des gesamten Lebenszyklus der Softwareentwicklung konfrontiert ist. Technische Schulden sind ein schwerer Overhead. Es ist schwieriger und teurer, Funktionen auf einer Codebasis von geringer Qualität hinzuzufügen und zu ändern, und die Unterstützung bestehender Codekomplexität erfordert erhebliche Investitionen an Zeit und Ressourcen, die andernfalls für die Entwicklung neuer Produkte aufgewendet werden könnten. Da Produktmanager das Risiko ständig gegen die Geschwindigkeit der Markteinführung abwägen, müssen sie Fragen berücksichtigen wie:

• Sollte ich eine OSS-Bibliothek (Open Source Software) verwenden oder die Funktionalität von Grund auf neu erstellen? Welche Lizenzen und potenziellen Verpflichtungen sind mit den ausgewählten Bibliotheken verbunden?
• Welcher Tech-Stack ist am sichersten? Was einen schnellen und kostengünstigen Entwicklungszyklus gewährleistet?
• Sollte ich die Konfigurierbarkeit der App priorisieren (hohe Kosten/Zeitverzögerung) oder angepasste Versionen implementieren (hohe Wartungskosten/mangelnde Skalierbarkeit)?
• Wie realisierbar wird es sein, neu erworbene digitale Produkte zu integrieren und gleichzeitig eine hohe Codequalität beizubehalten, Risiken zu minimieren und die Engineering-Kosten niedrig zu halten?

Die Antworten auf diese Fragen können sich ernsthaft auf die Geschäftsergebnisse und den eigenen Ruf des Produktmanagers auswirken, doch Entscheidungen werden oft auf der Grundlage von Intuition oder Erfahrungen aus der Vergangenheit getroffen und nicht durch strenge Untersuchungen und solide Kennzahlen. Ein gründlicher Prozess zur Bewertung der Softwarequalität liefert nicht nur die für die Entscheidungsfindung erforderlichen Daten, sondern bringt auch die Interessengruppen in Einklang, baut Vertrauen auf und trägt zu einer Kultur der Transparenz bei, in der Prioritäten klar und vereinbart sind.

Implementierung eines 7-Schritte-Prozesses

Ein vollständiger Qualitätsbewertungsprozess des Quellcodes führt zu einer Diagnose, die den gesamten Satz von Qualitätsbestimmungen berücksichtigt und nicht einige isolierte Symptome eines größeren Problems. Die unten dargestellte siebenstufige Methode ist an den Empfehlungen von CISQ zur Prozessverbesserung ausgerichtet und soll die folgenden Ziele unterstützen:

• Finden, messen und beheben Sie das Problem in der Nähe seiner Grundursache.
• Investieren Sie intelligent in die Verbesserung der Softwarequalität auf der Grundlage allgemeiner Qualitätsmessungen.
• Gehen Sie das Problem an, indem Sie alle Messwerte analysieren und die besten und kostengünstigsten Verbesserungen ermitteln.
• Berücksichtigen Sie die Gesamtkosten eines Softwareprodukts, einschließlich der Kosten für Besitz, Wartung und Anpassung der Lizenz-/Sicherheitsvorschriften.
• Überwachen Sie die Codequalität im gesamten SDLC, um unangenehme Überraschungen zu vermeiden.

1. Produkt-zu-Code-Mapping: Die Rückverfolgung von Produktfunktionen auf ihre Codebasis mag wie ein offensichtlicher erster Schritt erscheinen, aber angesichts der Geschwindigkeit, mit der die Entwicklungskomplexität zunimmt, ist es nicht unbedingt einfach. In einigen Situationen ist der Code eines Produkts auf mehrere Repositorys aufgeteilt, während in anderen Situationen mehrere Produkte dasselbe Repository gemeinsam nutzen. Bevor eine weitere Auswertung erfolgen kann, müssen die verschiedenen Stellen identifiziert werden, an denen sich bestimmte Teile des Produktcodes befinden.

2. Tech-Stack-Analyse: Dieser Schritt berücksichtigt die verschiedenen verwendeten Programmiersprachen und Entwicklungstools, den Prozentsatz der Kommentare pro Datei, den Prozentsatz des automatisch generierten Codes, die durchschnittlichen Entwicklungskosten und mehr.

Vorgeschlagene Werkzeuge: cloc

Alternativen: Tokei, scc, sloccount

3. Versionsanalyse: Basierend auf den Ergebnissen dieses Teils des Audits, bei dem alle Versionen einer Codebasis identifiziert und Ähnlichkeiten berechnet werden, können Versionen zusammengeführt und Duplikate eliminiert werden. Dieser Schritt kann mit einer Bugspots-Analyse (Hot Spots) kombiniert werden, die die kniffligen Teile des Codes identifiziert, die am häufigsten überarbeitet werden und tendenziell höhere Wartungskosten verursachen.

Vorgeschlagene Tools: cloc, scc, sloccount

4. Automatisierte Codeüberprüfung: Bei dieser Inspektion wird der Code auf Fehler, Verstöße gegen Programmierpraktiken und riskante Elemente wie hartcodierte Token, lange Methoden und Duplikate untersucht. Die für diesen Prozess ausgewählten Tools hängen von den Ergebnissen der oben genannten Tech-Stack- und Versionsanalysen ab.

Vorgeschlagene Tools: SonarQube, Codacy

Alternativen: RIPS, Veracode, Micro Focus, Parasoft und viele andere. Eine weitere Option ist Sourcegraph, eine universelle Codesuchlösung.

5. Statische Sicherheitsanalyse: Dieser Schritt, der auch als statischer Anwendungssicherheitstest (SAST) bezeichnet wird, untersucht und identifiziert potenzielle Anwendungssicherheitslücken. Die meisten verfügbaren Tools scannen den Code anhand der häufig auftretenden Sicherheitsbedenken, die von Organisationen wie OWASP und SANS identifiziert wurden.

Vorgeschlagene Tools: WhiteSource, Snyk, Coverity

Alternativen: SonarQube, Reshift, Kiuwan, Veracode

6. Softwarekomponentenanalyse (SCA)/Lizenz-Compliance-Analyse: Diese Überprüfung umfasst die Identifizierung der direkt oder indirekt mit dem Code verknüpften Open-Source-Bibliotheken, der Lizenzen, die jede dieser Bibliotheken schützen, und der mit jeder dieser Lizenzen verbundenen Berechtigungen.

Vorgeschlagene Tools: Snyk, WhiteSource, Black Duck

Alternativen: FOSSA, Sonatype und andere

7. Geschäftsrisikoanalyse: Diese letzte Maßnahme umfasst die Konsolidierung der in den vorherigen Schritten gesammelten Informationen, um die volle Auswirkung des Quellcode-Qualitätsstatus auf das Geschäft zu verstehen. Die Analyse sollte zu einem umfassenden Bericht führen, der Stakeholdern, einschließlich Produktmanagern, Projektmanagern, Ingenieurteams und Führungskräften der C-Suite, die Details liefert, die sie benötigen, um Risiken abzuwägen und fundierte Produktentscheidungen zu treffen.

Obwohl die vorherigen Schritte in diesem Bewertungsprozess automatisiert und durch eine breite Palette von Open-Source- und kommerziellen Produkten erleichtert werden können, gibt es keine vorhandenen Tools, die den vollständigen siebenstufigen Prozess oder die Aggregation seiner Ergebnisse unterstützen. Da die Zusammenstellung dieser Daten eine mühsame und zeitaufwändige Aufgabe ist, wird sie entweder willkürlich durchgeführt oder ganz übersprungen, was den Entwicklungsprozess potenziell gefährden kann. Dies ist der Punkt, an dem ein gründlicher Software-Inspektionsprozess oft scheitert, wodurch dieser letzte Schritt wohl zum kritischsten im Bewertungsprozess wird.

Auswahl der richtigen Werkzeuge

Obwohl sich die Softwarequalität auf das Produkt und damit auf die Geschäftsergebnisse auswirkt, wird die Toolauswahl im Allgemeinen an die Entwicklungsabteilungen delegiert, und die Ergebnisse können für Nicht-Entwickler schwer zu interpretieren sein. Produktmanager sollten aktiv an der Auswahl von Tools beteiligt sein, die einen transparenten und zugänglichen QA-Prozess gewährleisten. Während oben spezifische Tools für die verschiedenen Schritte der Bewertung vorgeschlagen wurden, gibt es eine Reihe allgemeiner Überlegungen, die bei jedem Tool-Auswahlprozess berücksichtigt werden sollten:

• Unterstützter Tech-Stack: Denken Sie daran, dass die meisten verfügbaren Angebote nur eine kleine Gruppe von Entwicklungstools unterstützen und zu teilweisen oder irreführenden Berichten führen können.
• Einfache Installation: Tools, deren Installationsprozesse auf komplexer Skripterstellung basieren, erfordern möglicherweise erhebliche technische Investitionen.
• Berichterstattung: Tools sollten bevorzugt werden, die detaillierte, gut strukturierte Berichte exportieren, die wichtige Probleme identifizieren und Empfehlungen für Lösungen geben.
• Integration: Tools sollten auf einfache Integration mit den anderen verwendeten Entwicklungs- und Verwaltungstools überprüft werden.
• Preisgestaltung: Tools werden selten mit einer umfassenden Preisliste geliefert, daher ist es wichtig, die damit verbundenen Investitionen sorgfältig abzuwägen. Verschiedene Preismodelle berücksichtigen normalerweise Dinge wie die Anzahl der Teammitglieder, die Codegröße und die beteiligten Entwicklungstools.
• Bereitstellung: Berücksichtigen Sie bei der Abwägung der On-Premise- versus Cloud-Bereitstellung Faktoren wie Sicherheit. Wenn das zu bewertende Produkt beispielsweise mit vertraulichen oder sensiblen Daten umgeht, sind lokale Tools und Tools, die den Blind-Audit-Ansatz (FOSSID) verwenden, möglicherweise vorzuziehen.

Es am Laufen halten

Sobald Risiken methodisch identifiziert und analysiert wurden, können Produktmanager durchdachte Entscheidungen zur Priorisierung treffen und Fehler genauer selektieren. Teams könnten umstrukturiert und Ressourcen zugewiesen werden, um die aufkommenden oder vorherrschenden Probleme anzugehen. „Showstopper“ wie Lizenzverletzungen mit hohem Risiko würden Vorrang vor Mängeln mit geringerem Schweregrad haben, und es würde mehr Wert auf Aktivitäten gelegt, die zur Verringerung der Größe und Komplexität der Codebasis beitragen.

Dies ist jedoch kein einmaliger Vorgang. Die Messung und Überwachung der Softwarequalität sollte während des gesamten SDLC kontinuierlich erfolgen. Die vollständige siebenstufige Bewertung sollte regelmäßig durchgeführt werden, wobei die Qualitätsverbesserungsbemühungen unmittelbar nach jeder Analyse beginnen. Je schneller ein neuer Risikopunkt identifiziert wird, desto günstiger ist die Abhilfe und desto begrenzter sind die Auswirkungen. Die Bewertung der Qualität des Quellcodes in den Mittelpunkt des Produktentwicklungsprozesses zu stellen, fokussiert Teams, richtet Stakeholder aus, mindert Risiken und gibt einem Produkt die besten Erfolgschancen – und das ist die Sache jedes Produktmanagers.