Test Driven Development (TDD - Testgetriebene Entwicklung) ist ein Entwicklungs- und Designparadigma für Software, bei dem das Testen von Programmkomponenten dazu verwendet wird, den gesamten Prozess der Softwareentwicklung zu leiten. TDD ist eine Designstrategie, die das Testen vor dem Erstellen des Quellcodes ansiedelt und mit Bezug auf die Abläufe vorrangig behandelt. Das Ziel liegt darin, die Qualität der Software maßgeblich zu erhöhen und den Wartungsaufwand im Nachhinein zu verringern. TDD wird meist im Rahmen agiler Methoden und insbesondere beim Extreme Programming verwendet. Kent Beck definierte TDD Ende der 1990er Jahre. Testautomatisierung gibt es schon seit einiger Zeit, aber viele Unternehmen investieren weiterhin zu wenig in Softwaretests. Kontinuierliche Tests bleiben hinter den Investitionen in die Automatisierung von Bereitstellungen mit CI/CD, den Aufbau einer Infrastruktur als Code (IaC) und andere Entwicklungspraktiken zurück. Da immer mehr Organisationen DevOps verwenden, um die Bereitstellungshäufigkeit zu erhöhen, müssen Teams kontinuierliche Tests einführen, Feature-Flags verwenden, Canary-Releases aktivieren und AIops-Funktionen hinzufügen. Entwickler und Teams nutzen immer häufiger kontinuierliche Tests mit generativen KI.

Testautomatisierung ist das automatisierte Durchführen von Software Tests. Das Software Testing überprüft, ob die entwickelte Software den definierten Anforderungen entspricht. Diese Anforderungen lassen sich in vier Kategorien einordnen:

  • Sicherheit
  • Funktion
  • Leistung
  • Robustheit bzw. Zuverlässigkeit

"Durch Testen kann man stets nur die Anwesenheit, nie aber die Abwesenheit von Fehlern beweisen." (Edsger Wybe Dijkstra)

Reihenfolge der Tests: Unit Tests => Integrations Tests => System Tests => Abnahme Tests.

Beim Software Testing, ob manuell oder automatisiert durchgeführt, unterscheiden wir drei Arten:

  • Unit-Tests werden in der früheren Phase der Softwareentwicklung durchgeführt. Sie dienen dazu, die einzeln entwickelten Komponenten separat voneinander zu testen. Bei Unit-Tests handelt es sich um eine Methode zum Testen von Software, bei der ein Programm in seine kleinsten Funktionskomponenten, sogenannte Einheiten, zerlegt und jede Einheit gründlichen Tests unterzogen wird, um sicherzustellen, dass sie wie erwartet funktioniert. Diese Tests dienen dazu, das Verhalten einzelner Einheiten isoliert zu bewerten und sicherzustellen, dass sie für verschiedene Eingaben die erwarteten Ergebnisse liefern. Das Hauptziel von Unit-Tests besteht darin, Defekte oder Fehler im Code frühzeitig im Entwicklungszyklus zu erkennen und so die Ausbreitung von Fehlern auf höhere Integrationsebenen zu verhindern. Die Unit-Tests spielen eine entscheidende Rolle im Softwareentwicklungs-Lebenszyklus, da sie eine Reihe von Vorteilen bieten, die zur Gesamtqualität und zu Stabilität eines Softwareprodukts beitragen:
  1. Fehlererkennung
  2. Verbesserte Codequalität
  3. Dokumentation: Gut geschriebene Unit-Tests dienen als lebendige Dokumentation der Codebasis.
  4. Zusammenarbeit: Unit-Tests ermöglichen die Zusammenarbeit zwischen Entwicklern.
  5. Continuous Integration and Delivery (CI/CD): Tests sind ein Eckpfeiler effektiver CI/CD Pipelines. Automatisierte Unit Tests können in den CI/CD-Prozess integriert werden, um Änderungen automatisch zu validieren und zu verhindern, das fehlerhafter Code in die Produktion gelangt.
  • Integrationstests überprüfen, wie die einzelnen Komponenten zusammen funktionieren. Es werden auch die Schnittstellen zwischen unterschiedlichen Systemen und Anwendungen getestet.
  • Akzeptanztests: Es wird die gesamte neue Anwendung End-2-End getestet. Dabei geht es vor allem darum zu überprüfen, ob die entwickelte Lösung die Anforderungen und Wünsche der zukünftigen Nutzer erfüllt. Akzeptanztests werden UI-basiert durchgeführt. Das bedeutet, dass das Verhalten der zukünftigen Nutzer auf der Benutzeroberfläche der Anwendung imitiert wird.

Bekannte Testautomatisierungs-Werkzeuge sind Selenium, Cucumber, Postman/Newman, TestComplete oder IBM Rational Functional Tester.

Vorteile von Testautomatisierung: Seitdem die Softwareentwicklung agil ist, kommt dem Testing eine größere Bedeutung zu. Mit dem Ansatz der kontinuierlichen Entwicklung (Continuous Development - CD) wird Software in Bausteinen entwickelt und kontinuierlich getestet. So können Fehler frühzeitig erkennen und beheben. Manuelles Testen ist zeitaufwendig, fehleranfällig und teuer. In einigen Fällen ist der Wartungsaufwand der Testsoftware schlichtweg höher als der Aufwand der manuellen Durchführung der Tests. Der größte Teil der Testaktivitäten können und sollen automatisiert durchgeführt werden. Gerade vor dem Hintergrund des agilen, kontinuierlichen Testens verringert sich so der Aufwand deutlich. Automatisiertes Testen schont die zeitlichen und finanziellen Ressourcen und ist weniger fehleranfällig als manuelles Testen. Mithilfe der Testautomatisierung können große Mengen an Testdaten schnell getestet werden. Große Testdatensätze sind wichtig, um alle möglichen Szenarien zu testen. Das manuelle Testen dieser großen Datenmengen ist sehr aufwändig. Robotic Process Automation (RPA) wird für die Automatisierung manueller, regelbasierter Prozesse mithilfe von Software Robotern eingesetzt. Im Kern ist ein sogenannter RPA Roboter nichts anderes als eine Testsoftware. Beide werden eingesetzt, um manuelle Aufgaben, die immer gleich und in hohem Volumen durchgeführt werden, effizienter und weniger fehleranfällig umzusetzen. Vor allem für Akzeptanztests, also UI- und End-2-End Testings, eignen sich virtuelle Roboter oft hervorragend. Auch bei den Integrationstests kann es sinnvolle Anwendungsbereiche für RPA geben. Ein Roboter kann beispielsweise schnell und mit einem hohen Volumen an Testdaten überprüfen, ob der Datentransfer zwischen zwei Systemen oder Anwendungen funktioniert. Beim Unit Testing, also dem Testen der Einzelkomponenten, lässt sich RPA ebenfalls einsetzen.

Behavior Driven Development (BDD) oder auch Specification Driven Development (verhaltensgesteuerten Entwicklung) ist eine Technik der agilen Softwareentwicklung. Ziel ist es, die Zusammenarbeit im Qualitätsmanagement und in der Geschäftsanalyse zu stärken. Im modernen Panorama der Softwareentwicklung erweist sich der BDD-Ansatz als eine zentrale Praxis. BDD ist ein Softwareentwicklungsansatz, der auf der testgetriebenen Entwicklung (TDD) aufbaut. Er legt den Schwerpunkt auf die Verwendung einer verständlichen und einfachen Sprache, um das erwartete Verhalten von Software zu beschreiben. BDD ist eine Praxis, bei der das Testen von Programmkomponenten zur Steuerung des gesamten Softwareentwicklungsprozesses verwendet wird. Heute ist es nicht mehr notwendig, eine fertige Software wochenlang auf ihre Funktionalität zu testen.  Bei BDD betrachtet man die Software aus der Perspektive des Benutzers. Dies fördert die Zusammenarbeit zwischen Entwicklern, Qualitätsmanagern und dem Kunden. Je komplexer die Softwareanwendungen werden, desto mehr Qualitäts- und Testmanagement ist erforderlich. Dies ermöglicht es, Fehler schnell auszumachen. Die gewünschten Anforderungen werden von allen Teammitgliedern definiert. Anschließend kann der Programmierer den Quellcode erstellen. Das bedeutet, dass die Teammitglieder Beschreibungen liefern können, die der Programmierer dann umsetzt. Auf diese Weise können sich alle aktiv an der Erstellung beteiligen. BDD schließt die Lücke zwischen Entwicklern und dem Rest des Teams, indem es die Zusammenarbeit und das gemeinsame Verständnis fördert. Außerdem wird in kleinen und schnellen Iterationen gearbeitet, um das Feedback zu erleichtern und es wird eine Systemdokumentation erstellt, die automatisch mit dem Verhalten des Systems abgeglichen werden kann. BDD macht den Entwicklungsprozess für alle Beteiligten zugänglicher und verständlicher, von Entwicklern und Testern bis hin zu Interessenvertretern und anderen nichttechnischen Teammitgliedern. 

Rapid Application Development (RAD) - Schnelle Anwendungsentwicklung ist eine Methode der Softwareentwicklung, bei der Rapid Prototyping und iterative Bereitstellung einen hohen Stellenwert haben. Das RAD-Modell ist daher eine gute Alternative zum typischen linearen Wasserfallmodell, das sich weitgehend auf Planung und sequentielle Entwurfspraktiken konzentriert. Die 1991 erstmals vom James Martins eingeführte schnelle Anwendungsentwicklung hat sich zu einer der beliebtesten und leistungsfähigsten Entwicklungsmethoden entwickelt. Durch die Verwendung von RAD können Designer und Entwickler das während des Entwicklungsprozesses gesammelte Wissen und Entdeckungen nutzen, um das Design zu gestalten oder die Softwarerichtung vollständig zu ändern. RSD ist eine Form der agilen Softwareentwicklungsmethodik. Im Gegensatz zu den herkömmlichen Methoden legt RAD Wert auf funktionierende Software und Rückmeldungen von Benutzern über strenge Planung und Anforderungserfassung. Weil das RAD-Modell genaue Planung erfordert gibt es ein paar Schritte und Phasen, die jedes Entwicklungsprojekt durchlaufen muss. In den meisten RAD-Systemen wird häufig Prototyping eingesetzt. Die Verwendung von Prototypen während des gesamten Entwicklungszyklus bietet eine Reihe von Vorteilen:

  • Einbindung des Benutzers (Beim herkömmlichen Wasserfallmodell muss das Entwicklerteam mit den Benutzern besprechen, welche Funktionen und Implementierungen notwendig sind und welche Spezifikationen geplant werden müssen. Im Gegensatz dazu ermöglicht das RAD-Modell die schnelle Erstellung eines Prototypen, zu dem die Benutzer ein Feedback geben, anstatt die abstrakten Umsetzungen eines Designdokuments bereitzustellen.)
  • Durchführbarkeit (Durch das Prototyping kann das Entwicklungsteam die Durchführbarkeit einer besonders komplexen oder riskanten Komponente gut und schnell beurteilen. Durch die frühzeitige Erkennung und Bearbeitung komplizierter Systeme im Entwicklungszyklus wird die Software robuster, weniger fehleranfällig und für zukünftige Konstruktionserweiterungen besser strukturiert.)
  • Fehlerreduzierung und Fehlerbehebung (Durch die schnelle Bereitstellung eines Prototyps während eines Projekts ist es wahrscheinlicher, dass Fehler viel früher im Entwicklungszyklus entdeckt und behoben werden als bei einem typischen Wasserfallansatz.)

Refactoring (Überarbeitung) bezeichnet die - manuelle oder automatisierte - Restrukturierung einer Software (meist) unter Beibehaltung des Funktionsumfangs. Er ist ein zentraler Bestandteil der Agilen Softwareentwicklung. Kaum hat ein Unternehmen eine neue Version einer Software veröffentlicht, stellen Anwender neue Anforderungen für neue Versionen. Im Laufe der Zeit wächst der Funktionsumfang, doch je umfangreicher und älter eine Software und ihre Architektur werden, desto schwieriger wird die Weiterentwicklung. Hier hilft das Refactoring.

Design Patterns sind wiederkehrende Muster in der Softwareentwicklung und stellen eine große Erleichterung in der Programmierarbeit dar. Begrifflich ist das Design Pattern zurückzuführen auf den Architekten Christopher Alexander. Zu unterscheiden sind grundsätzlich Strukturmuster, Verhaltensmuster und Erzeugungsmuster.

  • Strukturmuster oder Structural Pattern lassen sich verstehen als Entwurfsmuster für Klassenbeziehungen. Das Ziel ist eine Abstraktion, die imstande ist, mit anderen Lösungsansätzen zu kommunizieren. Dies ist insbesondere im Zusammenhang mit der Schnittstellen-Programmierung relevant.
  • Verhaltensmuster oder Behavioral Pattern modellieren das Verhalten der Software. Es handelt sich um Pattern zur Vereinfachung komplexer Steuerungs- und Kontrollprozesse. Zu diesem Zwecke ist es möglich, zwischen Algorithmen und Objekt-Verantwortlichkeiten zu wählen.
  •  Erzeugungsmuster oder Creational Pattern dienen der   Erzeugung von Objekten, die eine vereinfachte Darstellung der Prozesse für bestimmte Instanzen ermöglicht. Das geschieht von der Art der Objekterstellung in einer Software unabhängig.

Builder Pattern dienen der Trennung der Objekt-Entwicklung von ihren Repräsentationen. Factory Pattern erzeugen ein Objekt durch den Aufruf einer Methode. Das Singleton Pattern trägt es dazu bei, dass von einer Klasse nur exakt ein Objekt existiert. Das Composite Pattern ist ausgelegt auf dynamische Strukturen und kommt beispielsweise in der Dateiorganisation oder der Datenkompression zum Einsatz. Decorator Pattern integrieren zusätzliche Funktionalitäten beziehungsweise Zuständigkeiten in bestehende Klassen. Das Facade Pattern bietet eine Schnittstelle zu anderen Systemen und Untersystemen. Das Observer-Pattern leitet Änderungen an Objekten an Strukturen weiter. Strategy-Pattern dienen der Definition von Familien austauschbarer Algorithmen. Visitor-Pattern dienen dazu, ausführbare Operationen in einer Weise abzukapseln, dass neue Operationen möglich sind, ohne Veränderungen an den entsprechenden Klassen vorzunehmen.

Die Software-Qualitätssicherung (Quality Assurance - QA) oder auch Software-Qualitätsmanagement beinhaltet folgende Maßnahmen: Vorgabe von Code-Konventionen, regelmäßige Design- und Code-Reviews, Einsatz statischer Code-Analyse-Tools (diese Tools können den Quellcode scannen und nach Schwachstellen suchen und können den Source Code anhand der unternehmensspezifischen Projektspezifikationen validieren und sicherstellen, dass Projektanforderungen erfüllt werden. Ein bekannter Code-Analyse-Tool ist SonarQube. Zur QS gehört auch die Verwendung von Testautomatisierungstools (z.B. Selenium oder Postman), automatische Erstellung von Systemdokumentationen (z. B. mit Doxygen), Verwendung von Versionsverwaltungs-Tools und von Bugtracker (Fehler-Verfolgungs-Tools).

Versionsverwaltungs-Tools (z.B. Git, GitLab, CVS, Subversion (SVN)) werden eingesetzt um Softwareentwicklung im Team zu ermöglichen also in Softwareprojekten, an denen mehrere Programmierer gleichzeitig arbeiten. Hier ist die Verwaltung der Codes unabdingbar, um dessen Evolutionsprozess nachvollziehbar abzubilden. Um das zu gewährleisten, historisiert das System jede Änderung (=> Version) die Ihre Programmierer an einer Datei bzw. Software vollziehen. Tritt bei einem Test Ihrer Software ein Problem auf, so kann  Fehlerquelle - inklusive Zeitstempel und Benutzerkennung - schnell erkannt und behoben werden. Umgekehrt besteht ebenso die Möglichkeit, einen älteren Zustand der Software wiederherzustellen. Das Versionskontrollsystem trägt somit step by step zur Optimierung des Softwareprojekts bei. Die Versionsverwaltung bietet allen beteiligten Entwickler die Möglichkeit, an einer lokal geklonte Version des Projektes zu arbeiten und mit einem lokalen Stand abzugleichen und auch den Quellcode durch andere Entwickler oder automatisierte Mechanismen überprüfen zu lassen wobei der Source Code in einer zentralen Repository abgelegt wird. Außer der Versionsverwaltung werden auch sogenannte Bug Tracker zur Verwaltung der bekannten Fehler eingesetzt.

Aktuelle Trends in der Softwareentwicklung sind Continous Integration (CI), Continous Delivery (CD) und DevOps (aus den Wörtern Development und Operations). CI stellt sicher, dass Codeänderungen von zahlreichen Entwicklern in ein Software-Projekt integriert werden. Beispiele für CI sind Bamboo, Rational Build Forge, Jenkins und Jira. Durch CD werden Funktionsänderungen sowie Bugfixes schnell und nachhaltig realisiert. DevOps umfasst CI und CD und soll dafür sorgen, dass die Bereiche, die für die Entwicklung und den Betrieb der im Unternehmen und/oder der von Kunden verwendeten Software zuständig sind, effizient zusammenarbeiten. Ein bekannter Tool der in CI eingesetzt wird ist Jenkins. Jenkins ist ein webbasiertes Open Source Continous Integration System. Es ist in Java geschrieben und plattformunabhängig. Die Basis von Jenkins unterstützt zahlreiche Werkzeuge darunter SVN, Ant, Maven sowie JUnit.

Die Softwarekonfigurationsmanagement (SCM) hat die Aufgabe, Änderungen in der Software zu verfolgen und zu steuern. Zu den SCM-Praktiken gehören die Revisionskontrolle und die Festlegung von Baselines. Maven ist Teil vom SCM und ist ein leistungsfähiges Werkzeug, um viele in der Softwareentwicklung immer wieder anfallende Prozeduren zu automatisieren und zu vereinfachen.

Interoperabilität bezieht sich auf die Fähigkeit von Systemen oder Anwendungen, miteinander zu kommunizieren und zusammenzuarbeiten, unabhängig davon, welche Technologien oder Plattformen sie verwenden. In der Softwareentwicklung bezieht sich Interoperabilität normalerweise auf die Fähigkeit, Softwarekomponenten aus verschiedenen Quellen oder in verschiedene Programmiersprachen zu integrieren.

Reverse Engineering ist ein Prozess, bei dem man ein ausreichendes Verständnis für ein Produkt auf Design-Ebene erlangt, um dessen Wartung, Verbesserung oder Ersatz zu unterstützen. In der Softwareentwicklung handelt es sich um einen Teil des Prozesses zur Softwarewartung, der dabei hilft, das System ausreichend zu verstehen, um Entscheidungen darüber zu treffen. Bei diesem Prozess wird das System in keiner Weise verändert. Redokumentation ist ein Teilbereich des Reverse Engineering, bei dem es darum geht, verlorene oder nicht vorhandene Dokumentation über das System wiederherzustellen. Design Recovery ist ein zweiter Teilbereich des Reverse Engineering, bei dem das Ziel darin besteht, alle Informationen zu reproduzieren, die eine Person benötigt, um vollständig zu verstehen, was ein Programm tut, wie es und warum es dies tut. Forward Engineering bezeichnet den Prozess, der von den Anforderungen über den Entwurf bis zur Implementierung eines Produkts führt. Während also das bestehende System der Ausgangspunkt für ein Reverse Engineering ist, ist es der Endpunkt beim Forward Engineering. Restrukturierung (Refactoring) ist der Prozess der Änderung der zugrundeliegenden Struktur eines Systems, ohne sein äußeres Verhalten zu beeinflussen. Reengineering bezeichnet die Neugestaltung und Implementierung eines Systems in einer neuen Form. Unterschieden werden zwei Formen: beim "reinen" Reengineering soll das System lediglich rekonstruiert werden, ohne das Funktionalität hinzukommt, beim "erweiternden" Reengineering wird das System rekonstruiert, um vorhandene Funktionalität zu verändern oder neue hinzuzufügen. Es gibt eine Reihe von Zielen, die beim Reverse Engineering adressiert werden:

  • Die Bewältigung von Komplexität
  • die Generierung alternativer Ansichten
  • die Wiedererlangung verlorener Informationen
  • das Erkennen von Nebeneffekten
  • die Synthese von höheren Abstraktionen
  • die Erleichterung der Wiederverwendung

Interessanterweise decken sich viele dieser Ziele mit den Ansätzen einer Clean Code Softwareentwicklung. Clean Code fordert die klare, verständliche, nachvollziehbare, logische und disziplinierte Implementierung von Code. Ziel ist es, Software effizient und effektiv zu produzieren und dabei den Code so zu gestalten, dass er leicht lesbar, änderbar, erweiterbar und wartbar ist. In anderen Worten: Reverse Engineering und Clean Code ergänzen sich großartig. Heutzutage stehen viele Firmen  nicht nur vor dem Problem, ihre Informationssysteme durch neue zu ersetzen, gleichzeitig müssen sie auch die Kontrolle über ihre Altanwendungen bzw. ihren Legacy Code behalten. Reverse Engineering bietet zu diesem Zweck die Möglichkeit verlorene Informationen wiederzuerlangen, vorhandene Softwarearchitekturen mit ihren Komponenten und entsprechenden Zusammenhängen und Funktionsweisen zu verstehen, komplexe Systeme umzustrukturieren, alte Systeme in eine neue und besser wartbare Architektur zu überführen oder Software zu portieren. Und damit wird Reverse Engineering gemeinsam mit Forward Engineering zum Reengineering.

Softwarefehler (Bugs)

Software ist inzwischen so komplex geworden, dass es nicht mehr möglich ist, alle Einflüsse auf die Softwarezuverlässigkeit zu kontrollieren und völlige Fehlerfreiheit (keine Bugs) zu erreichen. Mit genügend großem Zeit- und Geldaufwand lässt sich Software zwar bis zu einem vorgegebenen Grad an Sicherheit testen, allerdings stößt dieser Aufwand schnell an wirtschaftlich vertretbare Grenzen. Hinzu kommt, dass die heutige Softwareentwicklung zu einem dynamischen Prozess geworden ist, bei dem viele Einzelkomponenten parallel entwickelt werden.

Ziel ist es, schon sehr früh in der Entwicklungsphase eine Aussage über die Stabilität der späteren Software treffen zu können. Dieser Aspekt ist vor allem für Qualitätsmanager interessant, die den Ursachen möglicher Mängel an Softwarezuverlässigkeit in ihrem Unternehmen auf den Grund gehen möchten.

Im Mittel gibt es 1 bis 3 Bugs je 1000 Zeilen Sourcecode. Generell gilt der Leitsatz: Je früher in einem Entwicklungsprozess der Fehler auftritt und je später er entdeckt wird, desto aufwendiger wird es, den Fehler zu beheben. Schon möglichst früh in der Softwareentwicklung (Pflichtenheft, Design) sollen Fehler gefunden und beseitigt werden.

Eine Software, die besonders gründlich geprüft wurde, ist die des NASA Space Shuttle: man schätzt, dass in seine 3 Millionen Zeilen Quellcode nur noch 300 Fehler geblieben sind.

Arten von Softwarefehler (Bugs)

  • lexikalische Fehler (z. B.unbekannter Bezug)
  • syntaktische Fehler (z. B. vergessenes Semikolon)
  • semantische Fehler (falsche Deklaration)
  • Laufzeitfehler (falsch formatierte Eingabedaten)
  • logische Fehler (z. B. plus statt minus, Schleifenfehler)

Berühmte Softwarefehler und Computer-Attacken

  • Tippfehler im Sourcecode,1962 (Verlust des NASA Satelliten Mariner I)
  • Softwarefehler verursacht durch Überlauf eines Zählers, Bank of New-York, 1985 (Transaktion von Wertpapieren gestoppt dadurch Zinsverlust von 5 Millionen $ an  einem Tag)
  • Fehler in neuen Software bei AT&T, 1990 (60000 Menschen könnten 6 Stunden lang keine Ferngespräche führen)
  • Pentium Prozessor Divisions-Fehler, Intel, 1994 (Mehrkosten von 475 Millionen $ wegen Austausch des Prozessors)
  • Rechnerabsturz wegen zu klein bemessenen Stapelspeicher, Eisenbahn-Stellwerk Hamburg, 1995 (unbeabsichtigtes Schließen des Stellwerks)
  • Vorhandenes Programmcode des Ariane-4-Rakete übernommen, 1996 (Verlust des Ariane-5-Rakete)
  • Fehler durch Umrechnung der englischen Einheiten zu metrische  Einheiten im Programmcode, 1999 (Verlust des NASA Mars-Orbiters)
  • Datumsfehler durch Überlauf des Zählers (Jahr 2000-Y2K Bug, Jahr 2038 auf Unix-Systemen, ist ziemlich glimpflich gelaufen)
  • Fehlende Kompatibilität von Softwaremodulen, Toll Collect, 2003 (Einnahmeausfällen in Milliardenhöhe)
  • Obamacare-Software schluckt ein Drittel der Versicherungsanträge, 2010
  • Private Daten von sechs Millionen Mitgliedern eines sozialen Netzwerks weitergegeben, 2013
  • Makro-Computervirus (Malware) und E-Mail-Wurm für Outlook "Melissa" infizierte viele Rechner, 1999, USA und teilweise Europa (Schaden in Höhe von 1,1 Milliarden $)
  • "I love You!" Computerwurm, 2000 (zwang viele Outlook-Server in der Knie - Schaden von 3 Milliarden $)
  • Computerwurm "MyDom" infizierte 2004 um die 300000 Rechner (Schaden von über 30 Milliarden $)
  • Computerwurm "Stuxnet", 2010 (Eine seiner aggressiveren Varianten infizierte später über das Internet allein in China 6 Millionen Rechner)