Verification＆ValidationからQA作業を見直してみた

はじめに

QAグループのoshimaです。38年前なんてついこの間という感覚の、関西産・虎党のオッサンです。
大したスキルや資格があるわけではないものの、なんやかんや20年以上QA界隈でお仕事させていただいております。

現在は、すでにリリースされたサービス「KINTO ONE」「KINTO ONE(中古車)」「KINTO FACTORY」「モビリティマーケット」の機能改善やページのデザイン変更、また新規提供車種の紹介ページなど静的コンテンツ系のQAを担当しております。

今回はQA界隈では比較的使い古された概念「Verification」と「Validation」の違いのお話から、現在主に担当している案件に関してのご紹介と注力ポイント、個人的に考える課題（進歩させたい方向）に関して記載していきたいと思います。

「Verification」と「Validation」を取り上げるきっかけとしては、とある転職面接での質問として、「この二つは何が違うか説明せよ」というものがありました。それまであまり意識してこなかった二つの用語とその違いに関しては、十年近く前のことなのに印象深いエピソードとして心に残るとともに、現在のQAとしての仕事を再確認するにはいいキーワードと思い、取り上げました。

「Verification」と「Validation」の違いを簡単に説明

では「Verification」と「Validation」とはそもそも何なのか。そして違いに関してご説明します。

Google翻訳を利用すると、「Verification」も「Validation」もどちらの結果も「検証」となります。これだけ見ると同じようですが、厳密には

Verification	・ 仕様書通りの表記や動作であること ・ 「正しく」作られていることを検証する
Validation	・ 要求に合った表記や動作であること ・「正しい」ものが作られていることを検証する

と検証したい内容が異なります。

例として（適切かどうか怪しいですが）あるイベントの告知ページのテストの際、「申込期限は11月31日」という記載を見つけたとします。ところが仕様書にも「申込期限は11月31日」と記載されている場合

Verificationの観点では、『仕様書とテスト対象が合致しているので正しい』
となりますが、
Validationの観点では、『11月は30日までであり、31日というあり得ない日付を期限にしているので本当に締め切りたい時期を指定できておらず不合格』
になります。

さすがにあり得ない日付を見逃すことはない（はず）ですが、例えばこれが契約に関しての法律用語や新サービスに伴い新たな概念の用語になると、誤字や表現に関して間違いか正しいかをQAで簡単には判断できないことになるので要注意となります。

実担当案件の特徴

上述の通り、私が主にKINTOテクノロジーズで担当しているのは、既存サービスの改善や新しい車種の紹介ページ、イベント案内ページなどの静的コンテンツの最終確認案件となります。その中でも比較的頻度やボリュームの大きい静的コンテンツに絞って話を進めます。
静的コンテンツ関連案件で行うQAは、一般的なプログラムのテスト業務とは少し毛色が異なりますが、KINTOのお客様が直接目にするコンテンツを対象としているため、力を入れて取り組んでいます。

テスト内容としては営業部門の作成した価格表やデザイン部門作成の車両画像などを元に構成されたページに対して、レイアウト崩れが出ないかであったり記載文言や数値の違いがないかの確認が主となります。

先ほど取り上げた「Verification」と「Validation」と絡めると、静的コンテンツ確認は「Verification」が主であり「Validation」の側面が少ない特徴があります。

「Verification」での貢献と課題

静的コンテンツ確認ではデザインや文言などの仕様が確定していれば、実際の確認作業自体は難しくない（注意力は必要）面があります。

ただし、弱点といえば肝心の仕様確定ができない限り、「Verification」の段階まで持ち込めないことにあります。この点、受け身にならざるを得ないところが課題であり、実作業では「〇〇のエリアは確認可能、××については後日更新」といった段階的確認となるため、融通を聞かせた確認作業を都度都度状況見つつ行う現実があります。

「Verification」での貢献としては、逆説的ですが「仕様が決まらない、曖昧である」点に対しての指摘をテスト開始前の段階で行うことで、テスト対象の品質向上を支えていることではと考えています。

テストの自動化を考えた場合、仕様や仕様に基づいた期待値が確定していれば、テストとしては仕様書と実装の差分比較になります。
そのため、自動で差分を検出できるという点では、目視より正確かつ実施工数も削減できることで、導入には適していると思います。

逆に、仕様や期待値が固まっていなければそもそも比較ができない、あるいは仕様変更が実装反映されていないことを検知できず、それだとテストを自動化したところで意味を成さなくなります。

『テストを実施するには正解を用意する』という普通のことをしっかりやる。岡田阪神同様、プロジェクトの成功には大事な点と考えています。

「Validation」での貢献は何ができるか

静的コンテンツの場合はデザインなどは専門部隊マターとなるため、QAから口を出すことはほとんどありません。ただ、UXなどデザイン要素を含めて知見のあるエンジニアならば、この点においても上流からの指摘をできる可能性はあります。

そこまで難しく考えなくても、新しいサービスの説明図をみて、「お客様が理解しやすいか」「図の内容はサービス内容を正しく反映できているか」といった指摘は、サービスの仕様に詳しくなることでやりやすくなると思います。この辺りは仕様書との比較ではなく、提供するサービスがお客様に正しく伝わるという視点での「Validation」につながるのではと考えます。

もっと卑近な例では、上述の「Verification」と「Validation」の違いに近いパターンで、ある車種の案内からリンクされている関連記事の確認を行なった際、指定されたURLは仕様書通りでしたが、記事内で取り上げられている車種が異なっているという間違いを指摘したことがありました。

この場合、Verificationの観点ではOKですが、Validationの観点ではNGとなります。厳密には正解かどうかを質すという視点からは少し異なりますが、間違いではないけどわかりにくい　といった、お客様に提供する品質としては高い状態を維持していければと思います。

おわりに

などと大言壮語してみたものの、なかなか現実化できていない夢想に近い内容となっています。とはいえ、いつもの作業の繰り返しに終わらずに少しでも夢想を実現できるよう進歩していきたいです。

QAの進歩を我々と一緒に支えていただける優秀な仲間の方を募集しております。自分たちでは今まで出来なかったことを簡単にこなせてしまうスーパースターの方を特にお待ちしております。スーパーでもスターでもない方も一緒に頑張っていただける方なら大歓迎です。詳細は下記の採用ページをご参照ください。

最後までお読みいただきありがとうございました。