What is software testing?
When I started at JMP over a decade ago, if you were to ask me what software testing is, I would have gone to my preferred web search (or these days an AI LLM assistant) and came back with something along these lines: Software testing is the process of evaluating a software application or product to ensure it works as intended and meets user requirements.
However, through many discussions with my colleague Joseph Morgan, I have adopted a definition from software engineering, succinctly stated by Glenford Myers [1]:
“Testing is the process of executing a program with the intent of finding errors.”
Is this definition so different? I would argue yes. While Myers et al. [1] have a great discussion on this, for most people there’s a psychological difference between asking someone to check that something works versus trying to break it. By adopting Myers’ definition, a test engineer has their goal – finding errors. Not only does this provide structure, but by finding and fixing these errors (or as we might think of, bugs) early and thoughtfully, the result is software that works as intended and meets user requirements.
Where are the bugs?
If you’re still with me, and are comfortable with the definition of testing, the natural next question is where to even begin trying to break the software. For this we can turn to Boris Beizer [2]:
“Bugs lurk in corners and congregate at boundaries.”
Let’s break this down into two parts, where we’ll treat an input as some sort of data or information that you give to software to get a reaction or do something with that information.
Bugs congregate at boundaries: This emphasizes that bugs are commonly found at the edges of what the system is designed to handle. For example, if a function is supposed to accept inputs between 0 and 1, we should test the boundaries (0 and 1) as well as just outside them.
Bugs lurk in corners: This suggests that bugs often hide in the parts of a system that involve more than one of the inputs. That is, much like we think of interactions, we won’t find a bug unless we test these combinations.
Where do we go from here?
Over the coming weeks, you’ll hear from my colleagues and me about different topics related to validating (are we building the right product?) and testing (finding bugs, making sure the software works). What is particularly interesting to me is that there is a deep connection between testing and design of experiments (another topic that I love talking about).
Whether you are building your own applications, are faced with your own testing challenge, or are just generally interested in this topic, I hope you continue to read. Any topics you want to see covered? Let us know in the comments!
And, since a blog doesn't seem complete without a picture, Picture of the first “computer bug”, as with part of a team at Harvard University in 1947 that included Grace Hopper.
Courtesy of the Naval Surface Warfare Center, Dahlgren, VA., 1988., First Computer Bug, 1945, marked as public domain, more details on Wikimedia Commons
References.
- G. Myers, C. Sandler, and T. Badgett, The Art of Software Testing, 3rd ed. , New Jersey, John Wiley & Sons, Inc, 2011.
- B. Beizer, Software Testing Techniques, Van Nostrand Reinhold Electrical/Computer Science and Engineering Series, 1983
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.