"Is it done?"
- a question that I hear probably 10 times a day and one that can often be hard to answer. When is a project or a task really done? How do we tell? These questions often lead to problems with budget and scope, and cause nightmares for customers and consultants alike. The Computer Science world recognized this issue a long time ago - albeit in a different context - and created a standard for requirements to avoid these problems: A requirement must be Testable. Testable is (basically) that a requirement must have a clear success condition (or conditions). In the realm of Computer Science this normally means that (to quote my professor from college) "We get confidence in the quality of our software by expressing it in multiple and independent ways that can be checked." ~Dr. Purtilo, Professor at UMD. This says two things - first that each requirement should be independent - we'll discuss this later - and secondly, that each requirement must be able to be tested. Each requirement should be able to be checked or tested. Is it complete or not? Does it work or not? Does it do what we want? It should be noted that there are 2 types of testing or checking - Verifying and Validating. Verifying asks whether what was built works. Validating asks whether what was built does what was desired. Each requirement should be validated before any development occurs and then each 'functional unit' (what was developed) should be both verified and validated. In order to be able to both verify and validate code at the end of the day a requirement must be written in a Testable way. A couple examples: 'The page must support at least 2000 characters' is a testable requirement while 'The page must look nice' is NOT testable. This is a somewhat silly example to make the point but thinking about whether the requirements you're writing can be easily evaluated is an important step in writing a good requirement. A second, equally important part, of this is writing code that is testable. What makes code testable?
- Modular code is more testable than non-modular code
- If a function does 15 different things its difficult to separately test these functionalities
- Properly Encapsulated code is more testable
- This (again) has a lot to do with independence of code
- See http://misko.hevery.com/code-reviewers-guide/ for a more detailed examination of this idea.
There are many more ways to make code more/less testable - but the basic idea is that good code is testable and hack-y code is hard to test. Writing both testable requirements and code will lead to happier clients and less 'thrown away' time and code (and money). The basic reasons for writing testable requirements and code are very similar to those for writing traceable requirements. All of these ideals are intended to increase efficiency and help your projects succeed. TL:DR A requirement is testable if it has a defined success condition. Code is testable if each requirement can be tested separately without (unnecessary) dependancies.