Day 1 of Learning Testing: What Testing Actually Is

I recently started teaching myself Testing in Software Engineering. I thought it would be a great idea to document my journey, share what I’m learning, and hopefully help others who are on the same path. I’m structuring my learning around the ISTQB Certified Tester Foundation Level (CTFL) syllabus, which is the gold standard for testing basics.

To kick things off, let’s start with the most basic question.

What Exactly is Testing?

Almost everyone these days uses software daily. If you are reading this article, you are one of them! And I’m willing to bet you’ve had an experience where an app, website, or program didn’t work the way it was supposed to. Have you ever tapped a button and an app immediately crashed? Or maybe you tried to buy something online and the shopping cart glitched out?

Software that doesn’t work correctly can lead to massive headaches. For companies, a software bug can mean a huge loss of money, wasted time, and a damaged business reputation. In extreme cases like with software used in medical devices or airplanes, a software failure could even cause injury or death. Software failures have caused significant injuries and fatalities, particularly in transportation, medicine, and defense.

Some key examples are given below.

1. Boeing 737 Max MCAS system failures causing 346 deaths.
2. The Therac-25 radiation machine overdosing at least six patients.
3. A bug in the Patriot Missile system failing to prevent a 1991 missile strike, killing 28 soldiers.

That is exactly why testing exists.

By performing software testing, we essentially put the software under a microscope. It allows us to assess the quality of the software and reduce the risk of it failing once it gets into the hands of real users.

What is Software Testing, Really?

In simple terms, software testing is a set of activities we do to discover defects and evaluate the quality of a software artifact (like code, a design, or a requirement). When we are testing one of these artifacts, we call it a test object.

Before we go any further, let’s clear up a few common misconceptions about testing.

• Myth 1: Testing is just running the software. Many people think testing is only about executing code and checking the results. In reality, testing includes much more than that! It must be aligned with the entire Software Development Life Cycle (SDLC).

• Myth 2: Testing is only about “Verification.” While testing does focus on verifying the test object, that is only half the topic. Testing actually involves both verification and validation. What’s the difference?

  • Verification: Did we build the system right? (Checking if the system meets the specified requirements).
  • Validation: Did we build the right system? (Checking if the system actually meets the users’ and stakeholders’ needs in the real world).

• Myth 3: Testing requires the software to be running. Not exactly! Testing can actually be dynamic or static. Dynamic testing involves actually executing the software. Static testing, on the other hand, does not involve executing the software. Instead, it involves things like reviewing code, reading through requirements, or using tools for static analysis. (We will dive deeper into the different techniques for dynamic testing later in this series!).

• Myth 4: Testing is just about using tools. While testers absolutely use tools, it’s wise to remember that testing is mostly a highly intellectual activity. It requires specialized knowledge, analytical skills, critical thinking, and systems thinking. It’s about your mindset, not just the software stack you use. Like everything else in software engineering, testing needs to be properly planned, estimated, monitored, and controlled.

So, Why Do We Test? (The Test Objectives)

Depending on the project, a tester’s goals might shift. However, typical test objectives include:

• Evaluating work products (like requirements, user stories, designs, and code).
• Triggering failures to find hidden defects.
• Ensuring required coverage of a test object.
• Reducing the risk of putting out a product with inadequate quality.
• Verifying that specified requirements have been met.
• Checking compliance with contractual, legal, or regulatory standards.
• Providing information to stakeholders so they can make informed decisions.
• Building confidence in the quality of the software.
• Validating that the test object is complete and works as expected by the users.

Keep in mind that these objectives can vary based on context. The goals will change depending on what exactly is being tested, the level of testing, the risks involved, the SDLC being followed, and business factors (like tight deadlines or competitive markets).

Testing vs. Debugging: What’s the Difference?

A lot of beginners confuse testing and debugging, but they are two completely different activities handled by different people.

Think of it like this: Testing finds the problem. Debugging fixes it.

When a tester performs dynamic testing, they trigger failures that are caused by defects (bugs) in the software. When static testing is performed, the tester directly identifies defects in the documentation or code.

Once the tester finds the failure, the developer takes over for debugging. Debugging is concerned with finding the root cause of the failure, analyzing it, and eliminating it.

The typical debugging process looks like this:

1. Reproduction: Recreating the failure.
2. Diagnosis: Finding the root cause of the defect.
3. Fixing: Modifying the code to remove the cause.

Once the developer fixes the bug, it goes back to the tester for confirmation testing. This is a check to ensure the fix actually resolved the problem (preferably done by the same person who found the bug initially!). We also usually run regression testing afterward to ensure that the developer’s fix didn’t accidentally break something else in the software.

(Note: If a defect is found during static testing, there is no need to reproduce or diagnose a failure. Because the defect was found directly in the text/code without running the software, the developer can just go straight to fixing it!)

References

• ISTQB® Certified Tester Foundation Level (CTFL) Syllabus v4.0 — The core concepts, definitions, and structure of this series are based on this official syllabus provided by the International Software Testing Qualifications Board.

That wraps up Day 1! In the next article, we will dive into exactly why testing is necessary (and the crucial difference between Quality Assurance and Quality Control). Stay tuned!