A key concern for any business is ensuring that its products meet the quality levels expected of it. Unfortunately, Quality Assurance takes time and effort, requiring your development staff to spend part of their time on testing, or hiring specialist software testers to ensure the product meets its requirements. The more testing you do, the more expensive it will be, so it is useful to have some guidelines for knowing when you can get off with as little as possible.
The simplest test is a manual inspection of the code’s behaviour and there are some situations where this is appropriate. The most obvious case is throwaway code, such as the one line shell script a developer uses to manipulate some data, or the excel function that calculates VAT on your purchases. Once it is written, and is producing the expected output, it is forgotten about, never to be thought about again. There is also little point in testing prototypes or proof of concepts as their purpose is to determine the possibility of something or to explore the design space. Once that target has been attained, the software has served its purpose and can be discarded.
This gives us two useful questions. First, “Will it be obvious that the requirements are met?” This is usually true when the requirements are straightforward and few in number. Second, “Will the requirements for the system change once it is complete?” For example, once a prototype is complete, if there are any criticisms or questions about its behaviour, they will not become new requirements that the prototype must meet. Instead they will become requirements for the full scale system that will be built later. So, if your system has obvious requirements that you do not expect to change, then a simple inspection is all you need and you can spend more time shipping your product.