{"id":38571,"date":"2016-11-23T22:32:07","date_gmt":"2016-11-24T04:32:07","guid":{"rendered":"http:\/\/mmiranda96blog.wordpress.com\/?p=180"},"modified":"2016-11-23T22:32:07","modified_gmt":"2016-11-24T04:32:07","slug":"software-verification-and-validation-14","status":"publish","type":"post","link":"https:\/\/kenscourses.com\/tc1019fall2016\/syndicated\/software-verification-and-validation-14\/","title":{"rendered":"Software verification and validation"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

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:<\/p>\n