JaSST'14 Tokai:基調講演「テストの意図、共有できていますか? - ドキュメントレビューの視点から」
10/31(金)に開催されたソフトウェアテストシンポジウム2014東海(JaSST'14 Tokai)に参加しました。以下に基調講演についてまとめてみました。
[1]テストの意図
- 何をテストで確認しているかわらないケースが多い。
- 共有できないと、テストの妥当性が確認できない。
[2]ドキュメントレビュー
[2-1]問題指摘
(例)電話番号:顧客電話番号9桁
- 海外の番号は?
- 数値では、市外局番052の0が無くなる。
- レビュー効果が得られる前提
→電話番号の取り決めについては、総務省の資料を参照する。
[2-2]レビュー見逃しによる手直し
[2-3]目的設定すると、欠陥検出が改善できる
- どのような問題を検出するか事前にメンバーと話し合う(合意をとる)。
- 絶対に見逃したくない問題種別を決める。ただし、10件以下に留めること。
[2-4]問題検出シナリオ
- 問題検出シナリオを考え、シナリオに沿って個別に問題検出。
- 検討漏れが無いか確認
- 人事異動で参入するメンバーや開発パートナーのペルソナを決める
- 常識が伝わるか?
- あるレベルで余分な情報を削ぎ落とす
- 誤解しないか?
- あいまい
- テストの意図が分からない。
- 「~など」の記述。
- 設計:将来的な仕様を考慮して書く。
- 仕様書読む人:などは、具体的に何か?
- 整合性
[3]森崎研究室の手法
シナリオ:テストで見つけ修正したとき
[4]テストドキュメントのレビュー
- 標準的なメンバーを想定してレビュー:標準的なメンバーになりきる
- レビューで確認したい内容
- シナリオ(=チェックリスト)
[4-1]検出シナリオ例
- テスト十分性
テストの漏れが無いか? - テスト効率
既存のテストケースと重複していないか? - 要求/仕様との対応を確認
要求や仕様変更
[4-2]モジュール/サブシステムを確認
[4-3]実施環境
○○の環境で△△を確認できるか?
[4-3]保守性
次バージョンで流用改造できるか?
[4-4]母体機種か派生機種(特定仕向け)か?
[4-3]多重障害
二重/三重障害
[4-5]参加者から
- 機能の優先順位が意図通りか確かめるテストができているか?
優先制御の優先順位 - テスト実施時に時間軸を持たせる
- テスト実施順序
- テスト対象が完成しているかどうか?
- 不具合があったときの影響度
- 依存しているもの:演算順序やデータフロー
- テスト実施順序
- テスト対象が存在するか?
テスト開始前にシステムの前提条件が明記されているか?
[5]「考える」「記録に残す」
- 考えるが、記録に残さない
- 考えたことを記録に残す
- コストとの兼ね合い
[6]参考記事
- Perspective Based Reviews(観点別レビュー)
→参考:森崎修司の「どうやってはかるの?」→「日本人なら意外にやっている? perspective based reading」(ITmedia オルタナティブ・ブログ) - Defect Based Reading
※参考:森崎修司の「どうやってはかるの?」→「漏れ、誤り、曖昧さを制約とする defect-based reading」(ITmedia オルタナティブ・ブログ)
[7]所感
本発表を聴講した中で、『[2-4]問題検出シナリオ』で「人事異動で参入するメンバー」などのペルソナを決めてレビューすることは、現場で適用したことが無いため、工夫の1つとして試行してみようと思いました。
また、探索的テストと共通しそうな点として、
- 「チェックリスト」→テストチャータ
- 「観点別レビュー」→James A. Whittakerの書籍『Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design』で言及しているツアーのメタファー
があると捉えました。探索的テストを進めるためのシナリオとして応用してみるのも試行する価値がありそうです。