Software-Tests neu denken: Perspektiven aus der Welt der Hardware

Hardware und Software erscheinen oft wie zwei verschiedene Welten - und in vielerlei Hinsicht sind sie das auch. Aber vor allem beim Testen kann die eine viel von der anderen lernen.

Eine Anleitung von Rajiv Prabhakar veröffentlicht am 9. Februar 2021, 12:01 Uhr

Hardware, wie Prozessoren, wird anders getestet als Software. Einige Prinzipien aus Hardwaretests könnten und sollten jedoch übernommen werden. (Bild: Yoshikazu Tsuno/AFP via Getty Images))

Dieser Artikel ist eine Übersetzung. Das Original des Softwareentwicklers und Bloggers Rajiv Prabhakar ist hier zu finden.

Computeringenieure bei Intel verbringen, genau wie Softwareentwickler, die meiste Zeit am Schreibtisch und schreiben (Verilog-)Code, der das gewünschte Systemverhalten implementiert. Anschließend kompilieren (synthetisieren) sie ihren Code, um Ausgaben auf niedrigerer Ebene (digitale Schaltungen und physikalische Layouts) zu erzeugen. Dann schreiben sie automatisierte Tests für ihr SUT, um sicherzustellen, dass der Code funktional korrekt ist.

Ich kenne das alles gut, war selbst als Hardwareentwickler tätig und bin später in die Softwareentwicklung gewechselt. Nach meinem Masterabschluss in Rechnerarchitektur habe ich mehr als fünf Jahre bei Intel und Sun als Hardware-Verifikationsingenieur gearbeitet, bevor ich eine leitende Position bei Apple ablehnte, um meine Karriere als Softwareentwickler neu zu starten.

In den vergangenen Jahren habe ich in einigen großartigen Software-Teams bei Unternehmen wie Google gearbeitet und in meiner Freizeit zudem die Entwicklung mehrerer persönlicher Projekte geleitet. Die Programmierer, die ich kennengelernt und mit denen ich zusammengearbeitet habe, sind zweifellos intelligent und verfügen über einige Fähigkeiten, die sich meine Hardware-Kollegen zum Vorbild nehmen sollten. Eine Sache, die mir jedoch aufgefallen ist: Wenn es ums Testen geht, sind ihre Instinkte ... falsch. Und zwar ziemlich falsch.

Dieser Text ist mein Versuch, komprimiert jene Lektionen zu vermitteln, die ich aus meinen Hardware-Tagen gelernt habe, und zu zeigen, wie sie angewendet werden können, um unsere Software-Testmethoden und -Ergebnisse zu verbessern.

Disclaimer: Dieser Beitrag konzentriert sich auf Nicht-UI-Programmierung, bei der die Funktionalität ohne Eyeballing, also die visuelle oder Sichtkontrolle zu 100 Prozent geprüft werden kann. Front-End-/UI-Tests sind ein ganz anderes Thema und eines, von dem ich mich lieber fernhalte.

Den Einsatz erhöhen

In den meisten Softwareunternehmen ist der Blick auf das Testen ein Problem. In der Hardware ist die Pre-Silicon-Verifikation im Entwicklungsprozess quasi ein First-Class-Objekt. Engagierte Verifikationsingenieure verdienen sechsstellige Gehälter, sitzen bei allen Planungsmeetings neben den RTL-Designern und haben Karrieren, die genauso prestigeträchtig und lukrativ sind.

Im Vergleich dazu wird das Testen in den meisten Softwarefirmen, die ich kenne, als "Second-Class-Objekt" behandelt. "Testingenieur" oder schlimmer noch: "Tester" zu sein, gilt oft als weniger prestigeträchtig oder lukrativ.

Dieser Unterschied ist kein Zufall, sondern eine natürliche Folge des viel höheren Einsatzes, der bei Hardware auf dem Spiel steht. Da der Tapeout-Prozess so teuer und zeitaufwendig ist, kann das Auffinden eines einzigen Fehlers die Markteinführung eines Produkts um Monate verzögern und Millionen Dollar kosten.

Oder schlimmer: Wird ein Fehler gefunden, nachdem die Kunden die Chips bereits gekauft und installiert haben, kann dies zu sehr teuren Rückrufaktionen führen - selbst wenn der Fix aus einer simplen, einzeiligen Codeänderung besteht.

Die Folgen von Softwarefehlern können ebenfalls katastrophal sein. Aber zumindest ist die Behebung logistisch gesehen extrem billig. Code-Verteilung und Software-Patches sind weitaus schneller und billiger zu haben als die Herstellung und Verteilung von neuem Silizium. Daher nehmen Hardwareunternehmen das Testen viel ernster als vergleichbare Softwareunternehmen.

Die Ergebnisse sprechen für sich: Hardware-Produkte, die in den Händen der Kunden landen, haben sehr viel weniger Bugs. Der Prozentsatz der Bugs, die vor der Veröffentlichung abgefangen werden, ist in der Hardwareindustrie wesentlich höher als in der Softwareindustrie.

Wie es besser geht

Die Versuchung ist groß zu sagen, dass Hardware-Teams allein wegen ihrer größeren finanziellen Möglichkeiten besser testen können. Und dass Software-Teams bereits am Optimum arbeiten und Verbesserungen in der Testqualität nur durch mehr Zeit oder höhere Kosten erreicht werden könnten.

Eine solche Sichtweise ist zu optimistisch, was den Stand der Dinge angeht, und zu pessimistisch, was das Verbesserungspotenzial betrifft. In den vergangenen Jahrzehnten haben wir unsere Praktiken und Methoden der Softwareentwicklung enorm verbessert. Es gibt keinen Grund zu glauben, dass wir jetzt einen Zustand des Nirwana erreicht haben, in dem keine weiteren Verbesserungen mehr möglich sind.

Auch wenn viele Programmierer dazu neigen, ihr zu wenig Beachtung zu schenken: Die Testmethodik ist ein Skill-Set. Eines, das im Lauf der Zeit von einer ganzen Branche erlernt und verbessert wird, und zwar proportional zur Höhe ihrer Investitionen. In diesem Sinne ist die Hardwareindustrie meilenweit voraus, wenn es um Best Practices beim Testen geht. Nicht weil sie in irgendeiner Weise "schlauer" ist, sondern schlicht, weil ihr Überleben davon abhängt.

Man würde nicht erwarten, dass ein Fußballspieler so hoch springen kann wie ein Basketballspieler. Man würde nicht erwarten, dass ein Restaurant so hohe Hygienestandards hat wie ein Krankenhaus. Man sollte definitiv nicht erwarten, dass eine Softwarefirma das Testen so gut beherrscht wie ein Hardwareunternehmen.

Aber wenn man die Kunst des Testens beherrschen möchte, sollte man unbedingt mit einem Hardware-Verifikationsingenieur sprechen.