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