ITの教本には載ってないバグの発生ポイントに触発されました。二番煎じです。

システム開発していて何がストレスかというと後になってやばいバグが出た時ほどつらい時って他にはないような気がします。（ウソです。いろいろ思い出すとキリがありません。）

同僚のバグ報告を受けて、レビューの時に気をやっていた方法を手順化しました。いや、私の事だったかもしれません。

　摘要範囲

いつでも良いのです。ただし他のテスト技法で作成したテストを通した後に適用します。
「思ってもなかった」バグにはこの方法は効果がありません。

　ポイント

バグを出したあと、反省としてテスト項目を増やすのは問題です。特に上司報告においては懲罰的にテストを厳しくすることを約束したくなります。

しかし、チェックが厳しくなった場合、ちょっとした変更にも時間がかかるようになり、ゆっくりと生産性が落ちていきます。生産性が落ちると遅れが出てプレッシャーが増します。プレッシャーが増すと目に見えない作業を減らします。即ち、テストをレビューにギリギリ通るレベルまで削減します。結果、またバグを作ってしまいます。悪循環です。

増えてしまったテスト基準だったら減らすのはなかなか困難です。これ以上は増やさないようにするにはどうすればよいかと思い考えました。

無意識に見逃したテスト項目は、不安という形をとって残ります。これを利用しようというのがこの方法です。

　効果

• リリース前の不安が減る(メイン)
• やばいバグを見つけることがある(副作用)

　ご利用の前に

基本的には、他のテスト技法を使いましょう。適切に運用されていれば「そういえば・・・」という種類のバグは減ります。

どのようなバグでも発見・防止に大切なことは、”本当にその方法でこの問題を解決できる”かです。対策を懲罰的に行う問題は、作業効率が落ちた分しかバグが減らないことです。

　手順

1. 通常のテストケースをクリアします
2. 誰か読んできます(ゴムのアヒル等でも可)
3. 「バグが不安じゃない？」と聞いてもらいます。答えが「いいえ」なら、終了です。
4. 「どこが不安なの？」と訊いてもらいます。よ~く、考えて応えます。
5. 「どうやって、取り除く？」と訊いてもらいます。よ～く、考えて応えます。
6. 「それで、不安がなくなる？」と聞いてもらいます。よ～く、考えて不安がなくなりそうもなかったら前項に戻ります。
7. テストケースを追加して、テストします。
8. 「それで、この点について不安はなくなった？」と訊いてもらいます。「はい」と即答できなければ、5に戻ります。
9. 3に戻ります。

（gotoを書き過ぎでそれこそ不安でたまりません。次から、こういうのは疑似コードで書きます。）

　さいごに

基本的に言語化できないものを言語化する作業なので、めんどくさいしキツイ作業です。最終的に言語化されなくてもテストが追加でき不安が解消されれば完了です。不安がバグの形をとるまで解決しないこともあるでしょうから、うまく行かないときはリスク許容できるか試すのも手だと思います。

リファクタリングと同じように効果は測定が難しいですが、開発に安定性をもたらす方法なので試してみてはいかがでしょうか。