DEV Community: marvinav

Screenshot testing using storybook: real browser, fast performance, less visual regressions

marvinav — Sat, 29 Mar 2025 07:49:31 +0000

Introduction

When developing medium and large applications, UI/UX testing becomes a challenge. To verify the design and form interactions, we often need to understand the entire business flow, like how to navigate from Sign In Form to Add PayPal payment details form.
This frequently requires:

Creating test users
Configuring necessary permissions
Populating the database with test data

In such conditions, design validation becomes a struggle for developers, designers, and project managers.

Decouple UI/UX Testing from the Backend

I believe that UI and UX validation should be independent from the backend. There is no reason to understand the entire business process just to:

Open User Profile view;
Verify that the save button is enabled only after valid input;
Ensure error messages appear appropriately when invalid data is entered.

How to Achieve This?

The only solution is to develop custom dev tools at least that:

Mock API calls
Modify application stores
Enable quick navigation within the UI

This allows:
✔️ Rapid validation of new frontend features;
✔️ UI/UX testing without backend dependencies;
✔️ Comparing current designs with previous versions.

Presets, dynamically change backend response, navigate between views.

With dev tools, the desire to automate visual regression testing comes to mind. This leads us to the next topic: screenshot testing. Screenshot testing is the name for the assertion, not the type of testing. Screenshot testing could be e2e (for example playwright or selenium support screenshot snapshots), or unit tests.
However E2E is slow, moreover they require a lot of business knowledge and sometimes infrastructure knowledge from developers. And do we really want to run the e2e test after changing the button padding? I don’t think so. The front-end unit test should care about consistency of design after changing the button padding. But true is

FRONTEND TESTS DON’T CARE ABOUT STYLES AT ALL

It doesn’t make any sense for me, because even if it is just a small padding, it could create such a mess. Why do frontend developers ignore that? That is how I was working:

testing-library - utils for testing React
jest for running test
node - javascript environment

The problem in such an approach is: I don’t see the browser in the list. Where are we testing frontend units? Inside the virtual js-dom, it even doesn’t have 100% compatibility with the Browser DOM. Application behavior heavily depends on the device and environment:
📱 Android, iOS
💻 MacBook, Windows, Linux
🌐 Chrome, Safari (even browser versions affect performance!)
And here we are, frontend developers, who believe that js-dom inside nodejs runtime is a good idea to run tests.
After discovering of the screenshot tests, I stopped testing UI unit test that are:

Ensuring DOM elements are rendered.
Verifying the presence of a <div id="test"> , or any other tests related to rendering, view or styles.

However, unit testing with jest/node is still essential for logic independent from rendering. This is why separating view from model and state is crucial! But testing frontend view without styles or Browser APIs is like tasting a cake by only reading the recipe.

Environment

Storybook

Devtools for quickly navigating around UI components or pages is not something I created. Actually, it’s a pretty old issue which, in my opinion, has been solved by Storybook.js. What it could do now is quite impressive, and I only used like 25% of all Storybook features. Storybook is incorporated inside the frontend repository, and it has direct access to all UI components and code, but it doesn’t leave a trace in code. It’s like a jest unit test, but with different name extension:

Login.test.tsx → Login.story.tsx

You could write stories as just plain stupid components, or you could make an actual story: full flow of some user activity. For more details on what is a storybook, you could check the official storybook page.
Storybook showcase I like: React95

Docker

Docker needs for several reasons:

Minimal requirements to run screenshot test, just have docker installed
Make you dev setup platform agnostic
Chrome browser image (to have the same version of chrome across all developers and env)
DPI and other OS setup/configuration affects the screenshots.

Loki

Bunch of scripts for starting chrome, getting a list of stories, making screenshots and comparing them with references.
Below you could find the example configuration for loki. It shows that you could run tests on chrome in laptop or mobile emulator (not a real mobile emulator, but the one in desktop devtools), and ios, android (never tested).

"loki": {
    "chromeSelector": "#my-decorator > *",
    "configurations": {
      "chrome.laptop": {
        "target": "chrome.app",
        "width": 1366,
        "height": 768
      },
      "chrome.iphone7": {
        "target": "chrome.docker",
        "preset": "iPhone 7"
      },
      "chrome.a4": {
        "target": "chrome.aws-lambda",
        "preset": "A4 Paper"
      },
      "ios": {
        "target": "ios.simulator"
      },
      "android": {
        "target": "android.emulator"
      }
    }
  }

Loki stores screenshots in folder .loki:

./loki/reference

Screenshots in this folder are references for loki, they are gold standard. When loki runs a test, it compares the screenshot from this folder with the current test screenshot.

./loki/current

Screenshots in this folder are the screenshots from the latest run tests. Using them you could check the style, design and state of your current working tree.

./loki/difference

This folder contains an image diff between screenshots from current and reference.

How to write a screenshot test

1) Write a react component

import React from 'react';

import './button.css';

export interface ButtonProps {
  /** Is this the principal call to action on the page? */
  primary?: boolean;
  /** What background color to use */
  backgroundColor?: string;
  /** How large should the button be? */
  size?: 'small' | 'medium' | 'large';
  /** Button contents */
  label: string;
  /** Optional click handler */
  onClick?: () => void;
}

/** Primary UI component for user interaction */
export const Button = ({
  primary = false,
  size = 'medium',
  backgroundColor,
  label,
  ...props
}: ButtonProps) => {
  const mode = primary ? 'storybook-button--primary' : 'storybook-button--secondary';
  return (
    <button
      type="button"
      className={['storybook-button', `storybook-button--${size}`, mode].join(' ')}
      style={{ backgroundColor }}
      {...props}
    >
      {label}
    </button>
  );
};

2) Write a story for this component. It’s really easy. All file is basically story configuration

import type { Meta, StoryObj } from '@storybook/react';
import { fn } from '@storybook/test';

import { Button } from './Button';

// More on how to set up stories at: https://storybook.js.org/docs/writing-stories#default-export
const meta = {
  title: 'Example/Button',
  component: Button,
  parameters: {
    // Optional parameter to center the component in the Canvas. More info: https://storybook.js.org/docs/configure/story-layout
    layout: 'centered',
  },
  // This component will have an automatically generated Autodocs entry: https://storybook.js.org/docs/writing-docs/autodocs
  tags: ['autodocs'],
  // More on argTypes: https://storybook.js.org/docs/api/argtypes
  argTypes: {
    backgroundColor: { control: 'color' },
  },
  // Use `fn` to spy on the onClick arg, which will appear in the actions panel once invoked: https://storybook.js.org/docs/essentials/actions#action-args
  args: { onClick: fn() },
} satisfies Meta<typeof Button>;

export default meta;
type Story = StoryObj<typeof meta>;

// More on writing stories with args: https://storybook.js.org/docs/writing-stories/args
export const Primary: Story = {
  args: {
    primary: true,
    label: 'Button',
  },
};

3) Build storybook (good for CI/CD or one-time run) or run storybook server (option for HMR to speed up development)
4) Run loki to create a reference screenshot
From this moment, if something will change the design (also UX) of the button, loki will let you know with a FAILED test.

Rules to write stories

Best story is a story isolated from the backend. The best way of thinking about a story is a unit test.
Isolate stories from each other. It’s a unit test, the same story should produce the same output every time. It means avoid SIDE EFFECTS, avoid GLOBAL STORE.

Component is a function. Story is a function. Even OOP languages under hood are functions (all languages send instructions to CPU, not a Class Animal, but the instruction CPU is required to perform). Our life is the list of functions. Everything is a function. That is why it’s important to remember The Pure Function Rules:

the function return values are identical for identical arguments (no variation with local static variables, non-local variables, mutable reference arguments or input streams, i.e., referential transparency)

the function has no side effects (no mutation of local static variables, non-local variables, mutable reference arguments or input/output streams).

Conclusion

Screenshot unit tests are fast (faster then classical e2e tests), they are informative (you could see we current state of ui), they are useful (you are not mocking browser environment in node runtimer). From my own experience two hundreds screenshot tests run in 2min 30s on machine with 1gb RAM and 2 CPU.
Lets consider that you update button style and want to merge it in main branch. In this case you need:

Run loki tests and approve new screenshots
Add new screenshots to commit and create a PR

Goog thing about remote gits (gitlab, github, bitbucket) is all of them supports diff of images. You could check this PR in demo-screenshots repository and check how it's cool! You have options to compare old and new button story in three modes:

Side-by-side

Swipe

Blend mode

In the next part I will write you in details how to integrate loki in development workflow and which options you have to store your screenshots in your repo (git, git lfs, parallel repository).

Resources

1) Storybook

2) Visual tests by Storybook (Chromatic)

Premium and cloud solution for screenshot testing. Basically, we
replicate it itself, but on our own.

3) Loki

Basically a driver to run a storybook and make a screenshots. It is not so big, and storybook/chrome interface is pretty stable, so I didn’t have unsolved problem in about last two years.

4) Demo screenshot test repo

cp .config/.env.example .config/.env.development
cp .config/.makerc.example .config/.makerc
make run SERVICE=loki

Fantastic Bugs and Where to Find Them

marvinav — Tue, 18 Jun 2024 10:50:19 +0000

Introduction

Welcome back to our magical journey through the land of software bugs. If you missed the previous part, where we deciphered the enigmatic signs of bugs, fret not. This chapter will delve deeper into the mystical sources of these bugs and reveal the charms and spells needed to ward them off.

Bugs living in code

In the enchanted world of software development, there exists a hidden realm where bugs lurk like mischievous pixies. Much like the infamous Cornish Pixies released by Gilderoy Lockhart, these bugs wreak havoc in the most unexpected ways, causing chaos in codebases instead of classrooms. Welcome, dear reader, to a magical exploration of the dark arts of debugging, where we'll uncover the curious creatures known as mistype bugs, logical bugs, misusing bugs, and the ever-elusive integration bugs. Grab your wand (or, in this case, your keyboard) and prepare for a journey through the enchanted corridors of coding mishaps, where every spell cast (or line of code written) can lead to unexpected enchantments—or disasters.

Mistype bugs

Mistype bugs are typically not dependent on the developer's experience level. They tend to be more a function of company culture than any one person's skill. Common contributing factors are poor code review, no linters in CI/CD pipelines, few unit tests, and tight deadlines. Mistype bugs can range from simple typographical errors to more subtle mistake types that even avoid static code analysis tools. And to give you a personal example: I mixed in the letter 'c' from Cyrillic (UTF16 0441) with the letter 'c' (UTF16 0063) in the name of the endpoint. The name for the endpoint was createPhase with the Russian 'c' at the start. Deployment of this bug led to three web services failing.

Mistype bugs can result in various problems within an application: infinite loops, out-of-memory problems, security hazards, and program freezes. For example:

const Component = () => {
  const [count, setCounter] = useState();
  useEffect(() => {
    setCounter(count++);
  }); // If you forgot the second parameter, the empty array, as a dependency. It will be trapped in rendering an infinite cycle of increasing the counter

  return <div>{count}</div>
};

Logical bugs

Logical Bugs are the ones that live inside the code logic. They occur when the code does not work as expected, even though it is syntactically correct. For example:

const calculateSum = (a, b) => a + b;
const Component = () => {
  const [result, setResult] = useState(0);
  useEffect(() => {
    setResult(calculateSum(1, '2')); // Logical error: '2' is a string and causes the output to be combined
  }, []);
  return <div>{result}</div>
};

In this case, the cause for logical error is that the function calculated should add two numbers, but one of the arguments is a string. This leads to string concatenation instead of numerical addition hence the result it gives is something that is not expected.

Misusing bugs

Misusing bugs occur when a library or infrastructure or some language feature is wrongly used. Those bugs occur because the developer does not know the right way to use the tool and thus gets something wrong or some mistake in the code. These misconceptions can generally result in significant issues regarding the functionality of the application and its performance. Take, for instance, the following misuse of the useEffect hook in React:

const Component = () => {
  const [data, setData] = estate (null);
  useEffect(() => {
    fetch('https://API.example.com/data')
      .then(response => response.json())
      .then(data => setData(data));
  }, [data]); // Misuse: Including 'data' as a dependency leads to an infinite loop of fetching data

  return <div>{data? JSON.stringify(data) : 'Loading.'}</div>
};

In this case, the dependencies for useEffect are being misused, making it result in an infinite loop. The fetch operation is called again on every update of data, hence leading to an infinite re-fetch operation and can be a performance nightmare.

Misusing debounce from lodash:

import _ from 'lodash';

const handleResize = _.debounce(() => {
  console.log('Window resized');
}, 1000);

window.addEventListener('resize', handleResize); // Forgetting to remove the event listener on component unmount

Integration bugs

System-level integration bugs occur mainly when the interaction of two or more units of code written by different developers fails to interact correctly with one another. Inconsistencies or incompatibilities between the components often lead to these bugs in many situations. They are complex to find and repair because developers need to look at more significant chunks of code, which can be lengthy to replicate. For instance, consider the following scenario of an integration problem between a frontend React app and a backend API:

Example 1: Mismatched API Contract

// Frontend: React component expecting data in a specific format
const fetchUserData = async () => {
  const response = await fetch('/api/user');
  const data = await response.json();
  setUser(data. user); // Expects the API response to having a 'user' field
};
// Backend: Express route sending data in a different format
app. get('/api/user,' (req, res) => {
  res.json({ userData: { name: 'John Doe,' age: 30 } }); // Sends 'userData' instead of 'user'
});

In this example, the frontend expects the API response to having a user field, but the backend sends a userData field. This then causes integration problems, leading to failure of the frontend in the correct processing of data.

Example 2: Version Incompatibility

// Frontend: Using an old version of a shared library
import { format } from 'shared-library@1.0.0';

const formattedDate = format(new Date()); // Uses old formatting function

// Backend: Updated to use a new version of the shared library
const { format } = require('shared-library@2.0.0');

const formatted date = format(new Date(), 'YYYY-MM-DD'); // New formatting function requires an additional parameter

Here, the frontend and backend are two different environments working with the same shared library, but in this case with versions not compatible with each other. Because the frontend relies on an older version of the formatting function, it will break when working with the backend, which has the updated version of the library.

Bugs created by business

The incantations of business requirements often summon unexpected creatures into our codebase. Much like a misfired spell from a novice wizard, these bugs emerge from the foggy misunderstandings between developers and the business side of things. Gather around, dear reader, as we delve into the world of business-induced bugs—those mischievous gremlins that sneak past the boundaries of specifications, twist the logic of business rules, and conjure unnecessary complexities.

Out of Bound

Features and functionalities may go past or deviate from the specified requirements or intended use cases. The error might have occurred because of miscommunication or misconception in the first place between business developers and users. Implementation usually happens in features that are not required that are not accurately defined, or that are outside the project's scope. This may lead to resource waste, increased complexity, and potential issues in another part of the system.

Example 1: Unnecessary Features

A project requirement calls for a simple user registration process. A developer goes ahead to implement a multi-step registration that is meant to integrate with social media and additional verification steps because they misunderstood the requirements. It went out of scope, unnecessarily added complexity, and possibly more points of failure.

Example 2: Misinterpreted Requirement

The requirement is that users should receive email notifications for critical updates. A developer perceives these as notifications for every minor change, and the end users get bombarded with irrelevant emails, hence missing out on crucial updates.

Business Logical Bugs

Business logical bugs arise when the implemented logic does not align with the business rules, requirements, or use cases. These bugs usually arise from an improper or partial understanding of business logic, leading to features whose functionality does not serve the intended purpose, or they misbehave under certain conditions. Such bugs may have terrible effects on a system's functionalities and operability.

Example: Application of Discount in the Wrong Manner

An e-commerce website has a business rule that declares that a 10% discount applies on orders over $100. Developers implemented this logic, but after new feature was deployed product owner seen that discount applies for order with the price after tax applied for it. This case wasn't clarified in requirements, and e-store owner spent more money on the promo campaign than it wanted.

Reducing the Number of Bugs

Bugs, after all, are an inevitable part of software development. Still, their frequency and impact can be significantly reduced through best practices incorporated throughout workflow processes, code development, and business communication. A brief guide is given below.

Workflow Process

Implement Project Management Methodologies: For example agile methodologies have made it easier to do iterative development with continuous feedback and adaptive planning. This way, you can address pitfalls early in the development phase.
Continuous Integration/Continuous Deployment (CI/CD): Automated integration and deployment processes further ensure that any change to code keeps being validated and integrated, with a reduction in the chances of integration bugs and maintaining builds in a stable state.
Code Reviews: This is a means of correcting mistakes that may be overlooked. Multiple pairs of eyes on your code can easily catch potential issues earlier and improve the general quality of the code.
Automated Testing: Unit, integration, and end-to-end tests as part of the CI/CD pipeline detect bugs at various levels of the development process.

Code Development Process

Adopt Coding Standards and Guidelines: Having coding standards and guidelines ensures that code is uniform, readable, and maintainable and that one can quickly identify and fix bugs.
Static Code Analysis Tools: Utilize tools such as ESLint, SonarQube, and Pylint, among others, to check the source code for likely issues: errors, code smells, and security vulnerabilities that a developer has to take into account beforehand.
Unit Test Writing: Ensure that all test cases are written to find bugs on-time—more of the logic and mistyped bugs. Try to attain a high percentage of coverage with meaningful test cases.

Business Communication Process

Clear Requirement Gathering: Thorough and precise requirement gathering from stakeholders is critical. Arrange regular meetings with stakeholders so the development team is well-versed with business needs.
Maintain a Well-Defined Glossary: Involvement in creating and maintaining a glossary will ensure that team members have a common understanding of central concepts and terms. Thus, it will minimize the possibility of miscommunication.
Regular Feedback Loops: Ensure that your development team has set up regular feedback loops with the stakeholders. This ensures that the project work is coherent with the business objective; thereby, any deviation may be checked promptly.
User Acceptance Testing (UAT): Engage users in testing the system to ensure the software meets their needs and expectations. Business logical bugs are not likely to be detected by developers; UAT is an effective way of identifying these errors.

Conclusion

Minimizing the number of bugs is an exercise in several dimensions, calling for perfection in all phases of software development. Best practices in workflow processes, along with the rigorous development of code and intensive communication of business issues, ensure a significant reduction in the number of bugs that crop up; this ultimately results in more reliable and robust software.

What do the bugs mean?

marvinav — Fri, 31 May 2024 09:05:53 +0000

Introduction

Bugs are often defined as the resulting undesired behavior—coming from the developer's mistake—in the code. Bugs are, of course, a very human-made thing. This article contextualizes the entire historical background around the word "bug," from Thomas Edison to the famous incident with a moth by Grace Hopper. It goes even further to speak of the significant consequences of software errors: economic losses, and critical failures within various industries. This serves to sharpen the point that human errors in software development should be tested for these consequences to be reduced.

The origin of termin

The simplest answer to this question most common amongst developers is ‘bug is some undesired behavior caused by mistake in the code’. In general, this is a right answer that does not conflict with the true meaning of bug definition. But let’s look at how dictionaries define the bug.

Webster: an unexpected defect, fault, flaw, or imperfection.
Cambridge: a mistake or problem in a computer program.
Oxford: with the sense ‘of or relating to errors or other causes of malfunction in a computer program’.

However, those definitions do not highlight a very important detail that the bug is always caused by humans. For instance, if a user splits a coffee on his laptop and it stops working - this is not a bug. However, if the laptop stops working, because voltage regulator modules send 2 V on cpu instead of 1.4 V - this is the bug. With keeping this in the mind let's expand the definition of the bug:

A bug is a flaw, failure, error, or fault in computer software or system, caused by humans, that leads to unexpected or incorrect results, or to behave in unintended ways.

I don't just want to draw attention to the human factor for no reason, but because in the next articles we will see that all ways to reduce the number of bugs should be aimed precisely at combating the human factor. But for now, let's trace the history of the bug.
In the IT, there is an opinion that the concept of a bug started to be used after a real insect got stuck in the computer relay.

In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. She traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitch's in a program a bug.

"Danis, Sharron Ann: "Rear Admiral Grace Murray Hopper"". ei.cs.vt.edu. February 16, 1997. Retrieved January 31, 2010.

Picture 1 - Photo of the origin entry log in journal with the taped moth.

Disclaimer. I want to note in advance that a good historical analysis was done by Peggy A. Kidwell, and my favorite work is the article 'Stalking the Elusive Computer Bug' published in 1998 in the IEEE Annals of the History of Computing. If you are interested in delving deeper into this issue, I recommend referring to this article, as well as to the works of his. Below, I will provide only a brief overview of this article with some additional illustrations.

A funny fact, but in the 1945 edition of the Oxford dictionary, you can find a definition for "debugging," but not for "bug." What does all this mean? The story about the moth is essentially true, however, the entry in the journal dates back to 1947, not 1946. So, in the early days of programming, among Harvard staff, the term "bugs" was used before the story with the Mark computer. It turns out they adapted the terms "bug," "debug," and "debugging" from technical slang prevalent in the USA.

The word "bug" and its relation to technology, or more particularly to computers, in reality, dates back to the time of Thomas Edison. He wrote the first documented use of the term "bug" in a letter describing problems he is having with his phonograph:

"It has been just so in all of my inventions. The first step is an intuition—and comes with a burst, then difficulties arise—this thing gives out and then that—'Bugs'—as such little faults and difficulties are called."

These problems are the kinds one of the U.S. engineers had long held to have been called about quite a while ago. This became popular because the term is short, and means the flaw is small and manageable. This conceptual history of the terminology is well-traced in sources ranging from dictionaries to anecdotes.

1924: In a comic strip from a 1924 telephone industry journal, a naive character learns that a man works as a "bug hunter" and gives him a backscratcher. The man explains that "bug hunter" is just a nickname for a repairman.

1931: The first mechanical pinball game, Baffle Ball, was marketed as being "free of bugs."

1940: The term bug is used to describe a defect in direction-finding equipment in the film Flight Command.

1942: In a book, Louise Dickinson Rich refers to an ice cutting machine needing the "bugs" removed before it could resume operation.

1944: Isaac Asimov refers to bugs as issues with a robot in his short story "Catch That Rabbit."

The lexicon of computer science grew increasingly formal, arguably from the 1950s and certainly from the 1961's, as the Association for Computing Machinery (ACM) and other professional groups started publishing standardized glossaries. By the early 1960s, terms like "bug" and "debug" were used in mainstream language. As computing technology advanced, it also became widely used in the popular press and in everyday language. For instance, "Grin and Bear It" contained jokes about "computer bugs". Advertisements for services of various kinds assured the consumer with such slogans as "We'll Get the Bugs Out."

The cost of bugs

It seems that computer bugs are like small, innocent pranks that prevent the engineering system from working at full capacity. But are they really that harmless?

In 2002, software bugs cost the United States economy approximately $59.5 billion, which is a small figure considering the overall GDP of the USA. However, with the growth of digital services, the cost of bugs for the economy has grown proportionally. According to research by Tricentis, in 2016, software failures in the US cost the economy $1.1 trillion in assets. In total, software failures at 363 companies affected 4.4 billion customers and caused more than three and a half years of lost time. Since 2016, the damage to GDP has grown by almost one and a half times, and it is now estimated at 7% of the US GDP.

Picture 2 - Cost of software bugs on the USA economic

We've all heard about the famous Y2K bug, but do you know how much it cost the economy? To address the potential fallout, organizations globally invested heavily in Y2K remediation efforts. The total cost of these preventive measures is estimated to have ranged between $300 billion and $600 billion. This expenditure was incurred by governments, businesses, and other entities to update software, replace hardware, and implement extensive testing and contingency plans. Significant financial resources were allocated to ensure critical systems would transition smoothly into the new millennium. Governments, especially in developed countries, undertook extensive campaigns to prepare public services and infrastructure. Businesses, particularly those in finance, utilities, and transportation, conducted exhaustive checks and upgrades to mitigate the risks.

But even with such investments to fix this bug, minor problems were still recorded:

The US official timekeeper, the Naval Observatory, reported the date as 19100 on its website.
In Japan, the system collecting flight information for small planes failed.
In Australia, bus ticket validation machines failed.
In the US, over 150 slot machines at race tracks in Delaware failed.
In Spain, a worker was summoned to an industrial tribunal on February 3, 1900.
In South Korea, a district court summoned 170 people to court on January 4, 1900.
In Italy, Telecom Italia sent out bills for the first two months of 1900.
In the UK, some credit card transactions failed.

Bugs are expensive, but they also lead to not just financial losses, but far more serious consequences.

Intellectual Damage, which hampers the development of humanity

1962: NASA’s Mariner 1 Incident: In one of the earliest and most expensive software errors, NASA's Mariner 1 spacecraft, aimed at Venus, veered off course due to a missing hyphen in the code. This led to the spacecraft being destroyed shortly after launch, costing NASA $18 million. This incident underscored the critical need for meticulous coding and testing in software development.

1996: Ariane 5 Rocket Failure: A software error in the Ariane 5 rocket caused it to deviate from its path and self-destruct 37 seconds after launch. The problem stemmed from code reused from the Ariane 4, which was not compatible with the new rocket's flight conditions. The failure resulted in a loss of over $370 million, underscoring the critical need for software adaptation and testing in space missions.

1999: Mars Climate Orbiter Loss: NASA's Mars Climate Orbiter disintegrated upon arrival at Mars due to a software error involving unit conversion from English to metric measurements. The $327 million mission failure highlighted the importance of consistency and precision in software used for interplanetary exploration.

Political Damage (which almost triggered a war between nuclear powers):

1980: NORAD False Missile Alert: A software error caused NORAD to report a false missile attack on the United States. The mistake was due to a faulty circuit that the software did not account for, nearly triggering a nuclear response. This event highlighted the severe implications of software errors in military and defense systems.

1983: Soviet False Missile Alert: A Soviet satellite falsely reported incoming US missiles, almost leading to a nuclear counterstrike. The officer on duty trusted his instincts and chose not to react, preventing a potential disaster. This incident again emphasized the dire consequences of software errors in critical systems.

Environmental Damage (which also showed that bugs could be used as weapons):

1982: Siberian Gas Pipeline Explosion: In a Cold War incident, the CIA allegedly inserted faulty software into a Soviet gas pipeline control system, leading to an explosion visible from space. While the precise cost remains undisclosed, this event is remembered as one of the most monumental non-nuclear explosions, illustrating the destructive potential of intentional software bugs.

Bugs can also claim lives:

1985-1987: Therac-25 Radiation Overdoses: A software bug in the Therac-25 radiation therapy machine resulted in patients receiving massive overdoses of radiation, causing several deaths and serious injuries. This tragic case demonstrated the fatal risks associated with software failures in medical devices and the essential need for rigorous testing and validation in healthcare technology.

1994: RAF Chinook Helicopter Crash: A software fault in the flight control system caused a Chinook helicopter to crash in Scotland, killing all 29 passengers. Initially blamed on pilot error, later investigations revealed the software glitch as the true cause, stressing the importance of reliable software in aviation safety.

2000: Panama City Radiation Overdoses: Faulty therapy planning software from Multidata caused radiation overdoses in patients, resulting in several deaths. This incident reiterated the deadly risks of software errors in medical applications and the crucial need for stringent testing protocols.