考慮漏れのディメンジョン

今日は自分のプロジェクトでのトラブル対応に終始。「何故」を5回以上繰り返して、根本原因を突き止めろ。

==

このトラブルを見つけたときの第一声は、「あ、その場合か！」でした。つまり、考慮にすらされてなかった条件で欠陥が見つかったというケースになるかと思います。ただ、「考慮漏れ」というくくりではまだ浅い。以下、
思ったことをつらつらと・・・。落ちがない状態で終わる可能性大。

• 考慮漏れ、をフェーズによる切り口で見てみる

仕様考慮漏れ、システム/モジュール設計考慮漏れ、設計カバレッジ考慮漏れ、リスク分析考慮漏れ、あたりか。要求仕様にない機能は設計、実装、テスト設計ではほとんど見つけ出すことができない致命的な考慮漏れ。でも、設計考慮漏れであれば、テスト設計において仕様書をベースにすることで漏れに気づくことが可能かもしれない。リスク分析で考慮されなかったリスクについても、それ以降の工程で見つけるのは難しくなりそうだ。

• 考慮漏れ、をディメンジョン(次元)という切り口で見てみる
ディメンジョンとは、考慮漏れのレベル、と位置づけてみる。実験計画法の用語を使ってみる。
• 提供機能考慮漏れ

高レベルの考慮漏れであるが、システムテスト・ユーザー受け入れテストで比較的見つけやすいか。ここまで大胆な考慮漏れは途中で気づくもの。
• 因子考慮漏れ

レベル高い。直交表で言うと1列なくなる。影響かなりあるし、意外に気づきにくいか。気づくための手法としてはマインドマップなどのブレーンストーミング、信頼できる仕様書の作成か。
• 水準考慮漏れ

レベル中度。直交表で言うとテストケース数が小さくなるか、あるいは考慮された水準についてはより厚く検証ができる、多因子間網羅率が高くなる。どの水準を考慮しなかったかによって、怪我の功名になる場合もあり？
• 組み合せ考慮漏れ

レベル低い。直交表で言うと1行なくなる。1行なくなる＝網羅ケースが1つということではなく、複数の因子組において網羅率が低下する。ただし、4つの中で一番「レアケース」に近いか。

中途半端だけど、今日はこのくらいで。