単体テストの品質を保証する

共通ライブラリとして作成される機能の単体テストの品質をいかに保証するかってことについて考える機会がずっとあったのですが、そろそろいい加減ぶち切れそうなので、まずは自分的に闘う武器をメモしていきます。

無精査の駄文です。現時点では。

だめな現状

単体テストで洗い出される問題の大半は人間による不具合。それを洗い出すのに、そもそも「信頼してはいけない人間」の手作業や手作業による成果物をもって「品質を担保した」とか言ってるのは頭オカシイとしか思えない。

共通部品としての単独動作を確認する環境やツールを作るというルールは無い。開発者任せ（いわゆる、ドライバー的なものを作るという決まりは無い）。
単体テスト仕様書なるものは作られることがあるが、エクセルに、テスト手順開始までの準備等の記載ないまま「～であること」のような一覧を書いてチェック欄とか承認欄がついているだけ。
エビデンスなるものを記録しろ、と必ず言われ、やることはJPEGでのスクリーンショットをとる、もしくはデータダンプなどをとる。ただし、そのスクリーンショットやダンプデータに対する説明や、そこに至る経緯などは記載、記録されないことが多い。
結果、エビデンスは簡単に改ざん可能。また、エビデンスの正当性を確認しようにも、せいぜい「大丈夫そう」「エビデンスはある」くらいの確認しかできない（担当者はきちんと確認していると言うだろうが、単体機能の仕様等や、テスト状態に至る前後関係の情報無しにその妥当性を判断するのは現実的に無理）。

改ざんも容易で、内容の精査もできないようなものをエビデンスとして残す、それも、エビデンスの確保に大変な労力がかかる（スクリーンショットをとって、エクセルのテスト結果シートにテストケース番号を添えて貼り付ける、などの作業が必要）のであれば、その時間をテストケースの増強とより多くのテスト実施に費やした方が良い。また、共通ライブラリを作る人には分かると思うけど、自分が作ったものが「どこでどう使われるか分からない」というのは結構な恐怖。あとからくる問い合わせや不具合報告を考えれば、無駄な作業をしている時間を、実質的な品質強化や調査にかけた方が効果的であることは分かると思う。要するに、テストパターンやテスト実施の保証は、実装担当者へのプレッシャーによって行うことは可能。

もちろん、対外的な報告資料としてきちんとしたものを作る必要があるのは分かる。ただ、そこに「～メソッドに整数値の最大値をコピー＆ペーストした場合の最大文字長チェックが……」なんて話が載ることは無いだろう。一段上位層の話を実装レイヤーに持ち込むのはナンセンス。報告は報告としてなんとでもなる。

あるべき基本方針

誰もが相手をだませると想定した手順を組む。ただし、嘘偽りを探す手順は最低限で良い（嘘偽りを行ったものを洗い出しても、製品の納品先には何もメリットが無い）。
だますこと自体のメリットが失せるような環境を構築する。偽装や改竄する手間をかけるくらいなら、さっさとテストした方が楽、という状況では、だますことを目的とした人間以外はほぼ、やるべきことをやるようになる。
もう1つ、やるべきことを「やってみる」と「正しく出来る」には差があるので、個人的な能力差や不足による問題はきちんとキャッチ出来る必要がある。そこは、テストケースの十分な確認や、テスト環境構築を体系立ててできる仕組みを準備することから始められる。

改善案

自動テストが使えるならそれに越したことは無い。改ざんが技術的に可能でも、面倒でやってられないようなレポートや、時系列等の考慮が必要なログがエビデンスとして出力される自動テストの仕組みを実装と併せて作っていけば、それだけで良いと思う。
自動テストが導入出来ない環境の場合、共通機能のテストドライバーは必要。GUI系の部品であれば、テストドライバーにログ記録機能をつけ、それをもってエビデンスとすれば良い。テストケースに「あるべきログの姿」が記載してあれば、エビデンスの検証者は基本的には比較作業だけですむ。管理職レベルが乗り出してくる必要は無い。
コピー＆ペースト機能なども、ペースト時のクリップボード内容を記録するとかすればいい。
テストデータおよびテスト環境は容易に別環境へ移植可能なようにする。それなりに手間のかかる準備になるだろうが、実益を伴わない資料作りにかけている時間があればできる。
これまでにない作業に時間がかかるが、何度か繰り返すことで効率と精度は上がる。こればかりはどの手法をとっても、仕方がないことだろう。

とりあえずこんだけ。今から会社行く。