Imagine that you finished a big, big, BIG project. You’re delivering it. The client sings the final check and shakes your hand, thankful. Two weeks later, you receive a call. It’s your lawyer. Your client wants to sue you because what you did is not what he asked for (at all). So… you have three choices: a) you rot in jail, b) you deliver a new product (that means, you work extremely in order to make it fast and good) or c) you travel back in time and check that what you’re developing is actually what the client needs. I have great news! Although option C is physically imposible, you can do something similar: do it before every project you build.
Verification and validation may seem the same concept. To identify the difference, ask yourself: am I building the product right? This is verification. In the other hand, am I building the right product? This is validation. Both are equally important.
There are three other concepts that are important. One might think they’re all the same, but they’re not. Here are the concepts about errors:
- Fault: when your code is wrong, when you forgot a parenthesis, when you named the file with a wrong extension. Simple bugs, generally debugged by the IDE or compiler iteslf.
- Failure: runtime error. It happens during execution of the program. These must be debugged manually.
- Malfunction: this is a deeper error. It involves the structure and architecture of the program. Usually, this are the worst bugs. These take days to be solved. Sometimes one must restructure from zero.
This process is directly related to software testing and requirements elicitation.
