JaSST'13東海SIG(13)

JaSST'13東海SIG(12)からの続きです。

今回は、「探索的テストに必要な要素」です。

探索的テストを探索する from Masao Tsuzuki

「探索的テストに必要な要素は何か？」(※没案)

本題に入る前に...

　タイトルの括弧内が「※没案」とあるように、SIGでは「考えにくい」「何を書けばよいか分からない」という意見があったため、別案で実施しました(※別案の内容は、後日書きます)。今回は、当初考えていたことを示します。

動機

　「(テスト対象の)何」を「どこの(機能)」で「いつ(のタイミングで)」探索するか、探索的テスト実施前に検討するとメリハリのあるテスト実施が容易です(経験上)。「探索目的」「テスト対象の探索ポイント」をそれぞれ[目的]と[手段]で分けて考え、探索しやすくなると仮定し、自分の開発ドメイン(これまで紹介した内容の具体的なところ)で検討しました。

<探索目的>

　目的の切り口を3W(What/Where/When)で考えてみました。理由は、「何」を「どこ」で「いつ」探索するか、メンバー間で方針を決めないとad-hocテストと変わらず、潜在バグや新たな気付きを発見するのが困難なためです。

(1)What

頻繁な仕様変更

　過去のプロジェクトで、テスト実施中に仕様変更が発生したが、インシデントレポートで報告される不具合内容の傾向があるため。

(2)Where

テストが手薄

　機能拡張開発で数ヶ所の仕様変更が発生したが、(テスト工数があまり確保できない状況で)テスト実施がほとんどできなかったところを狙った。

(3)When

仕様書最終版

　品質保証部門から、「潜在不具合があると思われるのでテストして欲しい」と設計部門経由で依頼があったため。

<テスト対象の探索ポイント>

　経験発表内容をベースに考え、テスト対象を取り巻く要素をメンバーで共有できる形に分解し、ad-hocテストに変質しないよう歯止めを掛ける。

(1)入力

やったことが無い操作

　過去のテストで、メンバーから「テスト工数が不足して実現できなかったが、今まで考えつかなかった操作をやってみて、バグがあるか確認したかった」という声があり、メンバー間で取り入れて実施することに合意したため。

(2)出力

出力が不安定な値

　過去のテストで、メンバーから「ある機能のテストを実施したとき、ある変数をモニタしたら、一瞬異なる値に変化する現象があった」と話があり、何としてでも再現したいとメンバーで合意したため。

(3)内部処理

レビューで揉めた機能

　ある機能のレビュー指摘リストを見たとき、「レビューで揉めたところは、外部仕様がフラフラしてカチッと決まらないよね」と話題になり、いざテスト実施したときに仕様が複数解釈で振る舞いが変化することに気付いたため。

(4)気になる事/関心事

頻繁にテスト失敗した機能

　頻繁にテスト失敗した機能の担当者のレビュー指摘内容をみると、指摘箇所が機能を実現するためには致命傷であったため。

次回は、「探索的テストの5要素」または文頭にあった別案です。