Was kosten Softwarefehler wirklich? Der 2.3-Milliarden-Dollar-Bug

Softwareentwicklungsteams bemühen sich, mit der unermüdlichen Nachfrage nach innovativerer Software von heute Schritt zu halten - schneller. Die meisten suchen nach neuen Wegen, um die Release-Zyklen zu beschleunigen (agil, lehnen DevOps..). Angesichts der Anzahl der Softwarefehler, die jetzt täglich Schlagzeilen machen, ist es jedoch offensichtlich, dass eine einfache Beschleunigung bestehender Prozesse nicht ausreicht.

Wie können Softwareentwickler auf dieses Bedürfnis nach Geschwindigkeit reagieren, ohne das Risiko kostspieliger Fehler zu erhöhen? Das war das Thema von Wayne Ariola Was kosten Defekte wirklich? Viel mehr als Sie denken Sitzung bei StarEast letzte Woche. Ariola enthüllte seine Forschungen zu den tatsächlichen Kosten von Softwarefehlern - und warum ein neuer Test- / Qualitätssicherungsansatz erforderlich ist, wenn Sie nicht für einen Softwarefehler verantwortlich sein möchten, der Ihr Unternehmen in die Schlagzeilen bringt.

Die folgende Zusammenfassung dieser Sitzung wurde von geschrieben Noel Wurst, Chefredakteur bei Skytap, dem führenden Anbieter von On-Demand-Environments as a Service (EaaS). Es wurde ursprünglich auf der veröffentlicht Skytap-Blog...

Passive Qualitätskultur führt zu „Ticker Shock“

Fragen Sie einen Raum voller Software-Tester: "Was kosten Fehler wirklich?" und ihnen dann zu sagen, "viel mehr als Sie denken", bevor jemand die Möglichkeit hat zu antworten, ist ein ziemlich mutiger Schritt. Es ist sicherlich eines, das für den Chief Strategy Officer von Parasoft, Wayne Ariola, auf der STAREAST-Konferenz in der vergangenen Woche leicht nach hinten losgehen könnte.

Es schlug nicht fehl und nach Wellen von Beweisen für die immensen finanziellen Auswirkungen, die Produktionsfehler auf ein Unternehmen haben können, hatte ich das Gefühl, dass viele im Raum sich Gedanken machten, um nach ihrer Rückkehr einige sehr ernsthafte Gespräche mit verschiedenen Abteilungen zu führen.

Jeder weiß, dass Fehler zu stundenlangen Nacharbeiten führen und neue Feature-Releases zurückgedrängt werden. Manchmal müssen Patches angewendet werden. Die Quantifizierung der tatsächlichen finanziellen Auswirkungen ist jedoch nicht nur schwierig, diese Zahlen werden auch selten an Entwickler, Tester und andere außerhalb von weitergegeben die Investoren- und Führungsebene.

Ariola zitierte bekannte Softwarefehler von Banken und Versicherungen, die ständigen Hacks von Sony, das Identitätsdiebstahlproblem von Target im Jahr 2014 und den jüngsten iPad-Fehler von American Airlines und wechselte dann zu einer Reihe schwer zu ertragender Liniendiagramme, die die fallenden Aktienkurse zeigten, die bei jedem dieser Fehler auftraten verursacht.

Unmittelbar nach diesen Fehlern, als die Nachrichten wuchsen und die Social-Media-Aktien stiegen, sanken diese Aktien weiter. In einigen Beispielen fielen die Preise, sobald sie wieder zu steigen begannen, weit unter den Preis pro Aktie vor der Veröffentlichung oder der Entdeckung von Fehlern.

Ariola machte diese Fehler auf eine „Kultur zurückzuführen, sich nicht auf Softwarequalität zu konzentrieren“, und niemand war anderer Meinung. Das soll nicht heißen, dass diese Tester im Raum nicht auf Qualität ausgerichtet sind, aber sind es alle anderen? Unwahrscheinlich. Und für etwas, das so schwer zu ändern ist wie die Kultur, ist es nicht die Zeit für Tester oder andere, mit den Fingern zu zeigen. Es ist Zeit, das Schiff zu reparieren, bevor Ihre Organisation die nächste in den Schlagzeilen ist.

Wie beheben wir das?

Zum einen sagt Ariola, es sei an der Zeit, Finanzinformationen wie Aktienkurse mit Entwicklern zu teilen - und ich würde Produktbesitzer, Designer und alle anderen hinzufügen, die einen Release-Kandidaten berühren, bevor er ausgeliefert wird. Und das bedeutet nicht, dass Sie eine vierteljährliche E-Mail mit etwas mehr als einem dreimonatigen Screenshot der Aktienhistorie an das Unternehmen senden.

Hierbei wird der Aktienkurs Ihres Unternehmens zu dem Zeitpunkt betrachtet, zu dem eine neue Version herauskam, und anschließend werden andere wichtige Momente von dort aus verfolgt. Wann wurde der Fehler gefunden? Wer hat es zuerst gefunden? Wurde es veröffentlicht? Wie lange hat es gedauert, bis es repariert werden konnte? Wie schnell kann der Support Probleme lösen und Kunden zufrieden stellen? Dies sind die Arten von Metriken, die sich absolut auf etwas auswirken können, das so weit entfernt zu sein scheint wie auf die Wall Street - ein Bereich, in dem einige möglicherweise nicht wissen, dass sie so große Auswirkungen haben.

Und für diejenigen, die nicht für ein börsennotiertes Unternehmen arbeiten, gibt es andere Messgrößen, wie die Anzahl Ihrer Kunden oder die Anzahl der Personen, die derzeit Ihre mobile App verwenden. Ariola fragte früh: "Wie viele von Ihnen haben jemals eine App heruntergeladen, die Sie gehasst haben?" Natürlich ging jede Hand nach oben und als er dann fragte: "Und was hast du getan, als du gemerkt hast, dass du es hasst?" wir alle riefen stolz und riefen sofort gemeinsam: "Wir haben es gelöscht!"

Dies ist die Denkweise von heute. Das einzige, was weniger Zeit zum Herunterladen einer mobilen App benötigt, ist das Löschen. Wie bei einem Aktienkurs kann dies ein ernstes Problem sein, wenn die Anzahl der Abonnenten / Benutzer Ihrer Software häufiger sinkt als steigt.

Ein Vorschlag zur Bekämpfung von Buggy-Releases war, nicht mehr zu fragen: "Sind wir mit dem Testen fertig?" Und stattdessen zu fragen: "Hat der Release-Kandidat ein akzeptables Risiko?" Einige gehen möglicherweise fälschlicherweise davon aus, dass diese beiden ähnlich genug sind, um eine Änderung des Testansatzes nicht zu rechtfertigen. Dies ermöglicht jedoch nur, dass die aktuelle Kultur Ihr Unternehmen und Ihre Kunden weiterhin gefährdet.

Selbst wenn es allen irgendwie gelungen wäre, sich auf eine Definition von „erledigt“ zu einigen, wird niemand im Falle einer Katastrophe hören (oder sogar sagen) wollen: „Aber wir haben die Tests abgeschlossen!“ wenn jemand wissen will, wie dieser Fehler es in die Produktion geschafft hat.

Während die Sitzung fortgesetzt wurde, gab es einige im Raum, die Geschichten darüber erzählten, wie sie die Berichterstattung durch kontinuierliche Tests, „Verschieben nach links“ und Verwenden, erhöhten Cloud-basierte Entwicklungs- / Testressourcen- und ich hoffe, diese Geschichten haben dazu beigetragen, einige von denen zu inspirieren, die die vor ihnen liegende Herausforderung zu Hause kannten.

Als ich diese Zusammenfassung noch einmal durchlese, stelle ich fest, dass es so klingt, als wäre die Sitzung eine Predigt aus Feuer und Schwefel, die uns alle dazu bringen soll, in unsere Büros zurückzukehren und nie wieder Freizeit oder unsere Familien zu sehen, aber das ist weit aus dem Fall.

Jeder bekam die Nachricht, ohne über den Kopf geschlagen zu werden, sie galt für jede Softwareindustrie auf der Welt, das Publikum war sehr involviert, und Ariola schaffte es fast, die gesamte Sitzung zu absolvieren, ohne ein einziges Mal die Waren seines eigenen Unternehmens zu benennen oder zu werfen - etwas, das ich während einer Lieferantenpräsentation buchstäblich nie gesehen habe.

Während des Q&A-Teils am Ende fragte ein Teilnehmer aufgeregt, Stift und Papier in der Hand: „Haben Sie irgendwelche Service-Virtualisierungs-, Testautomatisierungs- oder Continuous-Testing-Tools, die Sie empfehlen würden?“

Und nach einem Kichern hatte er keine andere Wahl, als Parasoft als großartige Option vorzuschlagen, und das Lachen und der Applaus der Menge bewiesen, dass er sich den Stecker definitiv verdient hatte.