第294回： 「ALTAのテキストをつくろう」49 （探索的テスト 前編）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、「3. テスト技法」の「3.3 経験ベースのテスト技法」の「3.3.2 チェックリストベースドテスト」について書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「3.3 経験ベースのテスト技法」の「3.3.3 探索的テスト」の定義等について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢3の「リグレッションテストには使用しない」が52.9%と最も多く、正解も3です。
選択肢２は、個人的には【誤った記述】と思っていますが、シラバスにありますのでALTAの模擬試験としては3の方を正解とします。
選択肢1は、それ自身がチェックリストベースドテストの定義です。選択肢4は、チェックリストベースドテストの代表的な使いどころです。
前回の復習は以上として、今回のnoteのテーマに移ります。
≡ 探索的テストの定義
JSTQBのALTAシラバスの該当箇所の全文を引用します。
探索的テストには、テスト担当者がテスト対象とその欠陥についての学習、完了すべきテスト作業の計画、テストの設計と実行、および結果の報告を同時に行うという特徴がある。テスト担当者は、テスト実行時にテストのゴールを動的に調整し、軽量のドキュメントのみを準備する[Whittaker09]。
テスト担当者が行うという点に注意が必要です。なぜなら探索的テストは基本的に「テスト実行」プロセス内で完結しているからです。
探索的テストの定義は太字にした部分、すなわち要約すると、「学習、計画、テスト設計、テスト実行、テスト結果の報告を同時に行うテスト」ということです。
つまり、ほとんど準備なしにテスト対象を操作するテストです。
これだけを聞くと「アドホックテスト（ad hoc testing）」（テスト分析やテスト設計なしに行われる非形式的なテストのやり方）と何が違うんだろう？と思われるかもしれませんが、探索的テストは経験ベースのテスト技法に位置付けられている点が違います。
アドホックテストやモンキーテストのように、「未経験者やテスト対象ドメインの経験がない人が適当に操作するテスト」ではなく、熟練したテストのエキスパートが「その場でテスト設計をして、それを実行し、テスト実行した結果をもとに、そこをもっと探索するか、探索する個所を変えるか判断しながら進めていくテスト」のことです。
ここで、最も重要な点は「テスト実行した結果をもとに探索する」点です。
探索的テスト以外のテスト技法は、テスト実行の前にテストケースをつくりますのでテストを実行した結果として、得られた情報をテストに活用することが困難です。
ここで、不可能と書かずに困難と書いたのは、探索的テスト以外にもテスト実行プロセスを途中で止めて、それまでに検出した欠陥情報をもとにテストケースを作り直すことがあるからです。
また、普通は、コンポーネントテストの結果をもとに統合テストで実する予定の内容を再検討していると思うのですが、探索的テストはそのサイクルが究極に短く高速に行うテストととらえると良いと思います。
≡ 探索的テストの適用
JSTQBのALTAシラバスの該当箇所の全文を引用します。
優れた探索的テストは、しっかりと計画されており、対話的で創造的である。探索的テストは、テスト対象のシステムに関するドキュメントをほとんど必要としないため、ドキュメントが入手できない、あるいは他のテスト技法では十分ではない状況で使用することが多い。探索的テストは、他のテスト技法に追加して、追加のテストケースを開発するためのベースとして使用することが多い。探索的テストは、アジャイルソフトウェア開発において、最小限のドキュメントのみでユーザーストーリーテストを柔軟かつ迅速に行うために頻繁に使用される。さらに、この技法は、シーケンシャル開発モデルを用いたプロジェクトにも適用可能である。
太字にした「アジャイルで頻繁に使用される」は抑えおいた方がよい特徴です。
でもなー。テストケースを書かないことの免罪符にしているケースも多いので、そういうのを見ると、『あーあ』と残念に思います。
≡ 探索的テストの制限／注意事項
シラバスには、ここに、探索的テストを行う上でのアドバイスが書かれています。したがって、探索的テストを実行することになった人はこの箇所をよく読むことをおすすめします。なかでも最初の段落は読んだ方が良いので引用します。
探索的テストのカバレッジはまちまちでまとまりがなく、実行したテストを再現するのが困難になる可能性がある。テストセッションでカバーする領域を指定したテストチャーターや、テストで使える時間を決定するタイムボックスは、探索的テストをマネジメントする技術である。1回のテストセッション終了時、または複数のテストセッション終了時に、テストマネージャーは状況報告のセッションを開催し、テスト結果をとりまとめ、次のテストセッションのテストチャーターを決定することができる。
「テストセッション」、「テストチャーター」、「タイムボックス」といった専門用語が読みにくくしているので、以下にISTQB用語集を張っておきます。
「タイムボックス」についてはISTQBの用語集にはありませんでした。
「探索的テストを実施する制限時間を決めておく」くらいに考えておくのが良いと思います。タイムボックスでタスクを管理するときには、「制限時間」に加えて「完了基準」も決めておくほうが良いのですが、探索的テストでは、やってみないと分からないことが多いので完了基準を用意できないことが多いものです。
シラバスに戻りますと、「テストマネージャーは状況報告のセッションを開催し、テスト結果をとりまとめ、次のテストセッションのテストチャーターを決定する」とあります。
これは、良いノウハウと思いますので、やっていないプロジェクトは採用することをおすすめします。
なお、シラバスには明記してありませんが、複数名で探索的テストを実施するときには、テスター同士の情報交換が大切です。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
TA-3.3.2 （K3）与えられたシナリオから探索的テストを識別する。
「与えられたシナリオ」とは、例えばユーザーストーリーのことです。
K3ですので、知識だけではなく適用できる（探索的テストを実施できる）能力が求められます。（K2：理解、K3：適用、K4：分析）
《問題》
下記は探索的テストについて述べたものである。正しいものはどれか。
1. テストセッションごとにテスト結果をとりまとめると良い
2. タイムボックスを決めて実行する方法はなじまない
3. テスト対象とその欠陥についての学習は別に行う
4. アジャイルのテストでのみ使う
答えは次回に書きます。
≡ おわりに
今回は、「探索的テスト」がテーマでした。
テストケースをつくらずに、気の赴くままテストするのは、楽しいですよね。
次回は、「3.3.3 探索的テスト」の後編（カバレッジと、検出できる欠陥の種類）です。
この記事が気に入ったらサポートをしてみませんか？