Software Testing Techniques

When we talk about software testing and quality, it’s easy to simply dive into types of testing, ways to break software: error cases, edge cases, bad input, good input. All of that is wonderful and fun, especially when approached with a creative mind. But let’s step back and define what we’re testing, why we’re testing, and what we’re trying to achieve. Two major questions that all software testing stems from are the following:

Is the software fit for purpose?

Does it meet the requirements?

Each of these questions is extremely dense with information. You have to almost step back and take it in, since this is what testing is all about, at least in this testing technique.

What is the purpose of the software? Is it to allow the user to achieve a certain goal, to help the company to become profitable, or maybe be smoothly used and integrated with other software systems? It does not matter how stable the software is or how well it meets the requirements when no one uses it (if that’s the purpose of the software). It does not matter how aesthetically pleasing the user interface looks if the functionality is never going to accessed directly by humans.

Does the software meet the requirements? What are requirements? They can literally be any expectation of the software to function a certain way despite whether it’s in the official requirements document or whether it is some unstated assumption people whose opinion matters may have. “Yea, the button should be blue, that’s the industry standard, I thought you knew that.” and other unobvious assumptions. But in the end, requirements support the first question, which is the purpose. If they don’t, I think it might mean that there is an unrealized purpose or this requirement may not be needed at all.