JaSST'13東海SIG(15) - MasaoApril's Library.

「テストチャータを作るときに必要な要素は？」(後編)

　前回は、付箋のキーワードとして「操作」「開発背景」「想定外」でしたが、今回は「あやしい」についてです。

あやしい

製品

1機能にサブ機能が多い
仕様書の更新時刻が深夜
変更行数が多い機能(差分開発の場合)
不具合が多いモジュール
バグが多発している機能：バグ密度が高い機能
対象を絞る観点：バグが出たときの影響が大きいもの
- お金
- 時間
- 人名
- 企業イメージ
バグが多く出た機能：「What?」「When?」
- 設計時
- 統合テスト時
- FT時
- 市場リリース後

　1.～5.は、開発状況の情報を収集したときに気付いたことですが、開発現場で『よくある話』として身近な問題と実感できる内容です。不具合が発生しやすい特徴ですので、開発関係者で共有すると「テストすべき事」が発見できるかもしれません。

　6.は、リスク発生時に損失が発生する要素です。シナリオとして「○○装置と□□装置間の通信で通信バッファが枯渇し、通信不能になったら、××機能が継続できなくなり、△△の立場の人が●●の理由で困る」という状況で、「△△の立場の人が●●の理由で困るところから、何を探索するか？」を絞り込んで検討することも有効かもしれません。

　7.は、過去のバグについて検出時期(フェーズ)と機能を整理し、製品のライフサイクルと製品に関わるステークホルダから、何を探索したいかメンバーと議論すると、探索ポイントが発見できるかもしれません。

テスト仕様

テスト仕様書にあいまいな記述が多い
組み合わせ条件
- テストしていない組み合わせ
- 省略した組み合わせ
- 同値だと思うけど･･･
テスト回数が少ないところ

　1.は、テスト仕様書作成の工数が確保できない状況で、パラメータ設定の因子及び水準を抽出するとき、テスト仕様の抜けや漏れが発生することがあります。また、テスト仕様書の保守工数が確保できず、テスト仕様の見直しを数年行われていない場合、機能仕様が追加/変更が発生したとき、テスト仕様が使いものにならないことがあります。そこで、機能仕様で変わったところは何か特定し、「今の時代なら、○○なところを考慮したテストを実施するだろう」とテストケースを頭の中かメモやポンチ絵を書きながらテストを実施する作戦で進めることがあります。

　2.は、前述の1.に関連しますが、保守されていないテスト仕様書で抜けや漏れといった不備があり、実は必要な組み合わせ条件や暗黙的な仕様があることに気付くことがあります。私の現場ですが、数人でテスト実施状況を共有したときに何回か前述の事象が発生しました。気付いたら、「俺だったら、□□なテストをやってみるかな」と試してみたいテストを考え、実施へ進めます。

　3.は、5～10年前に作成された古いテスト仕様が直近3年間で1度も実施したことが無いとき、「何故、○○な観点のテスト仕様があるのだろうか？」と疑問に思い、「俺だったら、□□な感じのテスト仕様にする」と想像し、実際にテスト実施したところバグを見つけたことが1～2回程度ありました。恐らく、古いテスト仕様が存在するのは、当時の担当者が開発時に何らかの痛い目に遭い、教訓としてテストケースを追加したものと思われます。古いテスト仕様を発掘して、何の欠陥を検出したいのか？を分析して、チャータとして活用してもよいかもしれません。

　次回は、付箋からの議論内容について書きます。