探索的テストとリスクベースドテストの概要と使いどころの考察

2024年12月27日 23:08

この間、探索的テストとリスクベースドテストということを話の流れで聞いて、あまり知らないテスト技法だったのでどういうものか勉強がてら使いどころを考えてみました。

システム開発では昔からあるテスト技法だが、最近でも取り上げられている

どちらも1970～1980年代に出てきたテストの考え方ではあるようで、1990年代にだんだん広がってきているようです。
特に探索的テストはアジャイルの普及とともに広がっていったようです。
※アメリカ基準なので、日本では2000年代あたりからかと思います。

古いものかと思いつつも、最近の更新日の記事も結構でてくるのでそこまでの古さは感じずといったところ。

探索的テストはテストケースなどを作らず、テスターの経験や洞察力に頼ってバグがありそうなところを学習しながらテストしていく手法です。

バグを短期間で効率的に検出するために利用しますが、網羅的なテストやテスト結果を評価できるものではないので品質の担保まではできません。

使いどころとしては以下が良いのかなと思っています。

結合試験前の疎通テストで活用
結合試験を開始して、バグが出て先に進めないことが多発すると生産性がガクッと落ちます。
そのため、事前に試験のクリティカルな導線になるような箇所のバグをつぶして結合試験の生産性を上げるのに役立ちそうです。
強化テストで活用
一通り総合テストまでした後の強化テストとしても活用できると思います。

システム全体を満遍なく完璧にテストするのはとても大変なことです。
限られた期間やコストの中では濃淡をつけてテストをした方が良いという考えがリスクベースドテストです。

基本的な考えとしては、機能ごとにリスク評価をして、リスクの高い機能のテストを多めに、リスクの低い機能のテストを少なくします。

リスクは発生可能性と影響度で掛け合わせて評価します。

発生可能性はその機能に対するバグが潜在している可能性。複雑なロジックや新しい技術的要素を盛り込んだ機能などが頻度が高いといった感じ。

影響度はビジネスへの影響度です。その機能に不具合が発生した場合、システム全体が止まってしまったり、お金を扱う機能などは影響度が高いといった感じで影響度の高さを評価していきます。

小規模なシステムではここまで濃淡はいらないと思いますが、ある程度規模が大きいシステムであればこの考えを取り入れることでコストも労力も最小限にしていけるかと思います。

あくまで、どうでもいい機能は、商用でバグ見つかったら直せばいいよねという理解があってものもですが。

簡単にまとめましたが、こういう考えがあるというのを知っておくだけで、リスクベースドテストだとか名前を付けて言うととで、テストの簡略化を説得力を持って説明することができる気がしました。

以下は、chatGPT君にいろいろ本件を聞いたものを最後にまとめてもらったものです。参考までに張ってみました。

概要: テスト設計と実行を同時に行う手法。テスターの経験や洞察に基づいて、発見的にシステムの問題を特定する。
特徴:
- 柔軟性が高い。
- 仕様が不明確な場合や初期段階のテストに有効。
具体的なプロセス:
1. テストチャーターの作成（目的を設定）。
2. システムを観察し、テストを実行。
3. テストログの記録と学習。
4. 次のチャーターの改善。

概要: システムやプロジェクトのリスクを評価し、リスクの高低に応じてテストの優先度や範囲を決定する手法。
リスク評価の方法:
- 影響度（Impact）と発生可能性（Likelihood）でリスクスコアを算出。
- 手法: FMEA、リスクヒートマップ、ペアワイズ比較。
具体例:
- 高リスク箇所（例: 支払い処理）→ 詳細なテスト、異常系テスト。
- 中リスク箇所（例: UI）→ 標準テスト、探索的テスト。
- 低リスク箇所（例: 既存機能）→ 簡易チェック。

以上を活用して、テスト戦略を効果的に設計できます！