A43 デシジョンテーブルとエビデンス

レビューの今昔

私の経験した昔のレビューはプログラム仕様書と単体テスト一覧表が中心だったと思う、ですが、直近でお世話になったプロジェクトではデシジョンテーブルとエビデンスが中心でした、それだけでも時代は大きく変わったと感じました、昔はデシジョンテーブルとエビデンスなんて誰も使っていませんでした、これは大賛成ですね、手間暇とレビュー時間はかかりますが効果は大です

デシジョンテーブル（決定表）の必要性

デシジョンテーブルを記述できないのならプログラムも作成できない、ゆえに、プログラム作成前にデシジョンテーブルをレビューする、とても理にかなっています、デシジョンテーブルは決定表とも言われケースバイケース（事象）に応じてプログラムがどのような実行結果を出すべきかを確認できます、デシジョンテーブルの大きな特徴は発生しない事象を確認できることです、発生しない条件は何故発生しないのかを再確認するわけです、発生しないのですから単体テストの対象外になります、とても納得

エビデンス（証拠）の必要性

例えば、単体テストの実行結果を画面コピーを利用してエビデンスとして残す、デシジョンテーブルで確認された単体テスト項目とエビデンスをペアで確認、これで、何をすべきか（デシジョンテーブル）の実行結果（エビデンス）をペアで確認できます、これも理にかなっていると思いませんか

うっかりミスを無くする効果

単体テストの試験結果をプログラマーの裁量で回答できるのなら嘘をつくことが可能です、ですが、デシジョンテーブルとエビデンスによるレビューによって嘘がつけなくなりました、大切なのは意図的な嘘を防ぐ効果もありますが、うっかりミスを無くす効果があることです、これ大切です、つまり、プログラムの機能抜けを防ぐ効果が高まります、デシジョンテーブルとエビデンスの確認作業を続けるとレビューにて機能抜けを指摘できる可能性に期待が持てます