Products, especially software, are designed to meet requirements. Requirements describe the functions you expect a product to perform. Once the product is ready, it is the requirements which determine the test criteria though of course, the requirements may have changed during product development from what was originally defined.
The product’s expected behaviour is determined by the tester’s interpretation of the specifications, regardless of whether they have been kept up to date. A program is considered tested if it behaves correctly on all inputs. However, even with the most trivial piece of software, the collection of all potential inputs is typically too large to test each one. Exhaustive testing is not often used in practice.
It is usually left to the tester to determine what makes up all possible inputs. The first step is to analyse the requirements. If the requirements are complete and unambiguous, the collection of all possible inputs can be defined.
A software component is considered functionally correct if it responds to each input as planned. Identifying the collection of invalid inputs and checking the software against those inputs are important components of testing. When the program behaviour on invalid inputs is not specified by the specifications, the programmer should build in functionality handle or reject these.
There are many aspects to juggle when building out a suite of tests to help improve your software quality. To improve the situation, automation and tools can assist with planning, constructing, building, running and reporting on tests against your code.