Reviewing QA Work From the Perspective of Verification and Validation

Introduction

I am oshima from the Quality Assurance Group. I am an old man born in Kansai and a Hanshin Tigers fan. I feel like 38 years ago was not so long ago. Although I do not have any special skills or qualifications, I have been working in QA for more than 20 years.
I am currently in charge of QA for page designs and functionality improvements of services that have been released such as KINTO ONE, KINTO ONE (Used Vehicles), KINTO FACTORY, and Mobility Market, as well as QA for static content, such as introductory pages for new vehicle models.
Today, I will talk about the difference between the concepts of verification and validation, which are relatively old-fashioned in the QA area, explain the projects I am currently in charge of, and describe the focus points and issues (directions I want to go in) I think about personally.
I bring up verification and validation because I was asked in a job interview to explain the difference between the two. I had not thought about the terms or the difference between them before. That happened almost ten years ago, but it left a deep impression on me. I believe we should remember these concepts in today's QA work, which is why I am bringing them up.

A Brief Explanation of the Difference Between Verification and Validation

So, what is the difference between verification and validation?
If you look them up on Google Translate, they come up with the same result. They may seem the same, but strictly speaking, they check different things.

Verification	・ Making sure the notations and actions match specifications ・ checking that they are executed correctly
Validation	・ Making sure the notations and actions align with product requirements ・ checking that their correctness

For example, suppose you are testing an event announcement page (leaving aside if its appropriate or not), and you find the description, "The application deadline is November 31". Checking the specifications, the documentation also states, "The application deadline is November 31".
From a verification perspective, it is correct because the page being tested matches the specifications.
However, from a validation point of view, there are only 30 days in November, and it is not possible to have 31st as the deadline, so it is not indicating an existing deadline. Therefore, it will fail the test.
You should not miss a date that does not exist, but it is hard for QA to decide whether there is a spelling mistake or incorrect expression if it involves a legal term in a contract or a new conceptual term for a new service, so you have to be careful.

Characteristics of an Actual Case

As I said earlier, at KINTO Technologies I am mainly responsible for improving our existing services and doing final reviews of static content such as those presenting events or introducing new models. In this article, I will focus on the static content which is relatively frequent and large in volume.
QA for static content-related projects is slightly different from general program testing, but I am working hard on it since KINTO customers see the results firsthand.
The main job in testing is to check whether the layout is broken and whether the descriptions and numbers on the page are different from the price list given by the sales department or the vehicle images given by the design department.
In terms of the way I described verification and validation, checking static content is mainly verification and has a few aspects of validation.

Contributions and Challenges of Verification

Checking static content is not hard if you check the design and writing specifications (it requires attentiveness).
The downside is that if you cannot check the essential specifications, you cannot proceed to the verification stage. The problem is that it has to be passive, and you have to make gradual confirmations such as "The XX area can be checked, YY will be updated later." You have to be flexible and monitor the progress each step.
I think verification helps improve what is being tested by pointing out things that are ambiguous and not determined by the specifications before the test stage, although that may sound like a paradox.
In terms of test automation, if you simply check specifications and the expected values based on them, testing becomes a simple comparison between specifications and implemented results.
For that reason, differences can be inspected automatically as it can be done more accurately than inspecting by sight, and it reduces workload.
However, you cannot make comparisons if the specifications or expected values have not been determined, and if you cannot detect whether a change in specifications is reflected in the implemented results, there is no point in automating the test.
You have to define what is correct before testing. Just like Akinobu Okada, a former Hanshin Tigers coach, I think this is an important part of a project's success.

What You Can Do With the Contributions From Validation

QA cannot say anything about static content because designs and other elements are up to each of the subject matter experts in their fields. However, an engineer with knowledge on topics such as UX and design elements may be able to point out things from upstream.
You can do that without thinking too hard if you look at the explanations for the new service, become familiar with the explanations, and see whether it is easy for the customer to understand and the figures correctly reflect the content of the service. I think this is related to validation because you are not making a comparison with the specifications, but seeing whether the service being provided is accurately communicated to the customer.
Here is a more common example of the difference between verification and validation. I once checked an information page for a vehicle type has a link to a related article. The URL matches the specifications, but the vehicle type was different from the one in the article.
This is okay in terms of verification, but wrong in terms of validation. Whether it is really correct is questionable, but in terms of whether not there is a mistake, you have to keep the quality of the service you provide the customer high.

Conclusion

Although I talked big, I am aware that it is hard to reflect that in reality, and it’s closer to ideals than what we encounter. However, by doing the usual work again and again, you can gradually make that dream a reality.
We are looking for skilled partners to conduct QA with us, especially superstars who can easily accomplish things we have not been able to do yet. People who are neither super nor a star but are willing to do their best with us are also welcome. See the recruitment page below for more information.
Thank you for reading until the end.