Whilst there are variations on the definitions of both of these terms, within the broad software QA and testing fields, there is general consensus that verification describes correctness whilst validation refers to the worthiness of the last product.
Applying these general definitions to software testing, we note that the practical differences affect the context and goals of the testing, rather than any difference in software testing methods or tools. The context and goals of'validating'software is the end user or customer context whilst the context of software verification is'meets the specification '. Indeed many software products are designed correctly, that is they meet standards and specifications, nevertheless they fail to generally meet the true end user (i.e. customer) requirements.
Ultimately validation may be the focus of what the consumer is paying for and whoever does validation represents the voice of the client (or end user in the case of software applications developed for internal use). In practical terms this implies separating the software quality control teams (i.e. test teams) into two broad groups, one that has intimate knowledge of the client context of the finished product and another group that's strong knowledge of how a pc software product ought to be produced.
By way of example consider an accounting application that records general ledger bookings. The business requirements will be produced which outline the business (accounting) rules to be followed. From the business enterprise requirements a complex specification will be produced which will document the behavior (i.e. program specification) of the'to be'delivered software.
In the aforementioned example software validation would include the initial walkthrough of the business requirements, with the company representatives, to'validate'that the requirements do actually reflect what the application is needed to do for the business. When the ultimate application has been developed any testing against the company requirements is also a validation activity. The walkthrough of the technical specification to make sure it has all of the functionality of the business requirements is a verification activity. Also the testing of the delivered software against the technical specification can be a verification activity.
Essentially validation can only just be done by individuals with familiarity with how a delivered software will probably be utilized whilst verification can be done by anyone who is able to read a specification (or standard) and determine when it is correct. Although we utilize the phrase'only ', this is simply not to demean the value of the verification team but alternatively to convey the fact that strictly speaking the act of verification only requires knowledge of standards and specifications.
In practical terms their education of complexity of the business requirements will determine whether or not a specialized software validation team needs to exist. When there is considerable complexity and effort in understanding the company requirements then a business analyst would typically accept the role of software validation. In cases of high business complexity the analyst would specialize in given business areas in order to breakdown the situation domain.