JaSST'14東京(1)
ソフトウェアテストシンポジウム'14東京に参加しました。前回は、コミュニティブースの話でしたが、本稿は参加したセッションの内容で思ったこと感じたことを書いてみます。
今回は、「探索的テストを活用したシステム開発手法の提案」です。
探索的テストのメリット/デメリット
・メリット
(1)バグ検出率：高い
・デメリット
(1)追加のテスト：増加
(2)バグ再現率：低い
(1)と(2)は陥りがちですが、工夫次第で制御できると思いました。(1)は、1日に追加する項目数に制限をかける。(2)は、ペアで探索的テストを実施し、一人はテスト実施し、もう一人はテスト実施中のモニタリングを行いながら、操作や設定内容をメモ書きすることも有効です。
SIのプロジェクト
・計画に乗ったプロジェクト
・SIのテストで求められていること
(1)客観性
(2)可監査性
SIのプロジェクトで(2)の可監査性が重要視されているという状況なので、公式なテスト(スクリプトテスト)でエビデンスが必要と解釈しました。探索的テストは、ad-hocテストとして誤用されることがあるので、何をどのようにテスト実施したかエビデンスを残す仕組みが必要です。
5W
[Why]
Q:探索的テストは受け入れられるか？
A内部のQCD向上を目的とする
[What]
Q:ターゲットは？
A:異常が分かりやすいS/W(例えば、UI系)
[Who]
Q:誰が探索的テストを実施するのか？
A:業務ノウハウ(経験)を熟知した人
[Where]
Q:どのような環境で探索的テストを実施するのか？
A:非機能系は不向き(機能テストに向いている)
[When]
Q:いつ終えるのか？
A:信頼度成長曲線が探索的テストと相性が良い
探索的テストを実施する理由を説明するとき、5Wを用いて問いかける形で検討すると、ステークホルダが納得しやすいと思いました。また、テストチャータのベースになりそうだと思いました。
戦略
どこを攻めるのか？
・マインドマップから検討
メンバーで共有する形は、表現の違いはありますが、私が適用したときと同じであることに気付きました。問題vs我々の構図で進めると効果的です。
どう攻めるか？
・過去のトラブル
・意地悪漢字
過去の経験を引き出す工夫として、過去のトラブルを活用することが探索的テストでは必須と思います。また、意地悪漢字(鈴木三紀夫氏考案)は、メンバーの暗黙知を引き出すアプローチして有効と思います。
やらないこと
・不具合発生の再現
理由：再現しないことが多いため
・バグの解析
理由：時間がかかるため
限られたリソースで探索的テストを実施する場面が多々ありますので、ステークホルダに対し「やること」「やらないこと」を明示し、合意を取ることは必要です。
Q&A
下記2点の質問をしました。メモとして残しますので、参考頂ければ幸いです。
