94. テストの目的 その⑥
テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする
JSTQBで書かれているテストの目的の6つ目はタイトルの通り。
妥当性確認は、成果物やサービスが意図された使い方や用途を満たしているかの確認です。
システムは「～したい！」という要求があって、それをどうシステムにするか……と考え要件、そしてより細かい仕様に落としていきます。
その大本の「～したい！」がちゃんと実現できてるんだっけ、という部分の確認です。
作者は妥当性確認はシナリオテストを用いることが多いです。
例えば社内の部署で使う業務システム。
その部署での業務フローがあったりしますよね。
あと想定されているシステムの使い方とか。
それをシナリオにして、ちゃんと運用を満足できるか（やりたいことができるか）の確認です。
もちろん運用は一本道ではなく、日々使うなら様々なイベントが発生したりします。
そういったところもできるならシナリオにして確認したりします。
こういうことをすると各機能単体で見てると良さそうだったのに、
「みんなエクセルで開くから、CSVの文字コードはshift-jisでないとダメ」
とか
「何百回も繰り返す登録作業なのに毎回ハンバーガーメニュー開いて呼び出しなの！？」
「夜間作業のメンバーに伝言を残すメモ欄、改行が反映されないの見づらい」
といったユーザビリティまで、実業務ならではの問題点が出てきたりするわけですね。
検証と妥当性確認の違い
テストの勉強をしているとV&Vという言葉に出会ったことがあると思います。
Verification(検証) & Validation(妥当性確認)です。
で。
「何が違うのさ！？」
という言葉がよく出てきます。
検証はというと、
「ちゃんと設計通り作ったよね」
とか
「ちゃんと仕様通り動くよね」
といったように、各プロセスの作業成果物が、設計書や仕様などの入力情報から正しく作られているか、の確認です。
妥当性確認は上で書いた通り、
「そもそもやりたいことができてるんだっけ？」
といった「～したい！」という要求が実現できてるのかの確認です。
これは最終成果物にもできますし、途中の各プロセスの作業成果物でもできます。
参考：https://www.ipa.go.jp/files/000036457.pdf
例として
「スーパーゴージャスで美味しいパフェを作りたい！」
だとしましょうか。
そのスーパーゴージャスで美味しいパフェという要求から要件、仕様と落とされます。
仕様はというと。
「苺の砂糖漬け」
これに対し苺がレシピ通りの砂糖漬けであることを検証します。
「自家製苺ソース」
これもレシピ通り作られていることを検証します。
「ベルギー王室ご用達の高級チョコレートショップ・ピエールマルコリーニのチョコアイス」
これもコンビニのチョコではないことを検証します。
「北海道産高級ムラサキウニ」
これもバフンウニではなく仕様通りムラサキウニであることを検証します。
「北海道産高級イクラ」
そしてようやく
『最高級苺とチョコのゴージャスパフェ feat.うにといくら』
が完成しました！！
全体が設計通り組み立てられていることは検証済みです。
あとは最終成果物の妥当性確認として試食会を開催です。
開発費を払ってくださったお客様は
「なにfeat.しとんねん！！」
と大層ご立腹です。
（作者、ちょっと食べてみたいって思ったけど）
それぞれの成果物も設計も書かれている通り「正しく」作りました。
けど最終成果物としては要求に対して「正しい」ものが作れなかったようです。
（そもそも要件にするのに失敗してますよね…）
CSVファイル
カンマ区切りのテキストファイルのこと。
表っぽいモノとか2次元なデータ構造になってるものをこのCSVで保存したりする。
表計算ソフトも対応していて便利。
とりあえず表っぽいファイルはみーんなエクセルで開きます。
これがまたつらいポイントです(^-^;
開発は大体のものの文字コードをUTF-8で作ってたりします。
今はまぁ、それで基本問題ないんですよね。
なんだけどエクセルは文字コードShift_JISで開いたりします。
そうすると日本語部分は見事文字化けして「困った……」という連絡が押し寄せるわけです……。
BOM付きだと正しく開いてくれるとのこと。
リングフィットアドベンチャー
作者は「欲しいな欲しいなー」と思っていたけど、品切れで買えずじまい。
けど、よくよく考えたらダンベルがあればいいかなーって思いました。
