あ～、やっとテスト終わった～
待て待て、バグの数が足りてないよ。テストやりなおし！
えー？バグが少ないんだから良いことじゃん！
基準を満たしていないからダメだよ。もっとバグ出して！
もっとバグを出す？？どういうことでしょうか？
実はバグの数は多くても少なくても怒られるのです。
テストは大事、だけど超めんどくさい
料理の後は「味見」をしますよね。
美容室の後は「鏡でチェック」しますよね。
論文執筆の後は「見直し」をしますよね。
プログラミングの後は、必ず「テスト」をします。
期待通りの動作をするか、変なところでエラーにならないかを確認する作業です。
要するに「バグがないかをチェックする作業」ですね。
でもそのマインドでテストをすると、潜在的にバグを見つけないようになってしまうので、「テストはバグを見るけるために行う」と教えられていることも多いと思います。
また、設計書を作ったり、プログラムを書いた時にも「レビュー」と呼ばれる第3者チェックが存在します。
ここで誤りを発見できれば訂正することは可能ですが、もし見過ごしてしまった場合、その誤りは後の工程まで残ってしまいます。
スルーされた誤りを発見するラストチャンス、最後の砦が「テスト」なわけで、とても重要です。個人的には一番大事な工程が「テスト」であると思っています。
でもテストって面倒なんです。私も一番嫌いです。
では、どれくらい面倒か簡単な例をみてみましょう。
以下のような画面のテストをすると仮定します。
日付を入れて検索できるかテストするだけだから簡単では？と思うと思います。
そんな簡単ではないのです。
テストはあらゆるケースを洗い出して漏れなく行う必要があるのです。
実際にテストが必要だと考えられるケースは以下のとおりです。
・「開始日」が日付形式の場合、正常に検索されること
・「開始日」が日付形式でない場合、エラーメッセージが表示されること
・「開始日」がありえない日付の場合、エラーメッセージが表示されること
・「終了日」が日付形式の場合、正常に検索されること
・「終了日」が日付形式でない場合、エラーメッセージが表示されること
・「終了日」がありえない日付の場合、エラーメッセージが表示されること
・「開始日」、「終了日」いずれも入力された場合、正常に検索されること
・「開始日」が未入力、「終了日」のみが入力された場合、正常に検索されること
・「終了日」が未入力、「開始日」のみが入力された場合、正常に検索されること
・「終了日」が「開始日」より過去の場合、エラーメッセージが表示されること
・「開始日」と「終了日」が同じ場合、正常に検索されること
内容は置いておいて、たくさんあることはわかっていただけたでしょうか？
しかも、多くの場合はテストをした証拠を残さなくてはいけません。
通常「エビデンス」と呼ばれます。
各テストの実行前と実行後の画面のスクリーンショットを取ってExcel等に貼り付けることが多いです。
正直、めっちゃめんどくさいです(笑)
バグには基準値があります。
「テストはバグを見るけるために行う」と前述しましたが、そのバグの数は「〇件見つけなさい！」という品質目標が掲げられていることがあります。
さらに、「バグの件数は基準値±5～10%の場合OK」とルールが定められていることが多いです。
例えば、「バグ目標値10件、許容値は±10%以内」というルールであれば9件～11件のバグを見つけなければなりません。逆に言うと9件～11件にバグを抑えなければいけません。
これを守れないと、「完了」になりません。
どうしても守れなければ理由の説明が必要になります。
これが面倒なのです。
基準値ってどうやって決めるの？
適当です。
色んなケースがありますが、未だに多いのは「プログラムの行数」で決めることです。
「1000行に1件はバグあるだろ」という考え方で、これ自体に明確な根拠があることは少ないです。
だって天才プログラマが作った場合と素人が作った場合で、差があるに決まってると思いません？
一般論であったり、過去の実績であったり考えた人なりの根拠はあるのでしょうが、難易度やプログラマによっても当然異なるので、ほとんど意味がありません。
では何のためにこんなことするのでしょうか？
それは
「上層部のためです。」
上層部は数値を気にします。むしろ数値しか気にしません。管理する立場上仕方がないのですが、ほとんど意味がありません。自分たちやお客さんを納得させるために、定量的に表現したいだけです。
品質管理と銘打ってはいますが、本当にこのやり方で品質があがるとは思えませんよね。
仮に10件のバグ目標値に対して、20件のバグを見つけたとします。
すると、
「設計は大丈夫？」
「ほかにももっとバグあるんじゃない？」
「プログラミングに問題あるんじゃない？」
と突っ込みを受けます。
では仮に10件のバグ目標値に対して、5件のバグを見つけたとするとどうなるのでしょうか？
残念ながら「優秀だな」とは言われません。
「ちゃんとテストした？？」
「テスト設計は大丈夫？」
と突っ込みを受けます。
一体どうしろというのでしょうね（笑）
「人が作るからバグは必ずあるもの」
ということはわかりますが、
根拠のない適当な目標値と大きなブレがあったからといってＮＧなのはよくわかりませんよね。
エンジニアの人ってよくそんな理不尽に耐えられるよね。
はい、慣れです(笑)
バグが少ないとテストを心配され、多いとプログラミングを心配される。
こんな時、エンジニアはどうすると思いますか？
有無を言わせない方法がひとつだけあることにお気づきでしょうか？
それは
基準内に収めること
です。
「バグ目標値10件、許容値は±10%以内」とルールであれば9件～11件に必ず収まるようにします。
そんなこと可能なのか？テストはしてみなければわからないよね？と思いますよね。
その通りです。
だからエンジニアは
数値合わせでテスト結果を偽装します。
バグ数が足りなければ、適当バグがあったことにしたり、誤字や脱字等ささいなことをバグ扱いにしたりします。
バグ数が多ければ、そのバグはこっそり修正して起きてなかったことにします。
そんなまさかと思いたいですが、やっているエンジニアは大勢います。
一番大事な作業なのに、一番適当にやられることが多いです。
こんな状態で完成したシステムの品質が高いと思いますか？
今のシステム開発のテストは間違っている？
品質を定量的に評価するため、数値で表すことは必要なことです。
また、バグ目標値は根拠が大したことなくてもひとつの目安としてはあったほうが良いです。
間違っているのはバグ目標を達成しなければいけないという文化とそれによって発生してしまうエンジニアのテストに対するモチベーションです。
目標はあくまで目標にすべきなんですよね。
エンジニアは適当である
細かい作業を黙々と繰り返すことが得意なイメージのエンジニアですが、実態はこんなものです。
以下の記事でも取り上げましたが
エンジニアに向いている人は「妥協できる人」だと思います。
※もちろんちゃんとやっている人もたくさんいますし、こんなことやっていない会社もいっぱいありますよ！
いかがでしたでしょうか？
最後までご覧いただきありがとうございました。