探索的テストについて
ご無沙汰しています、halspringです。
本記事は『ソフトウェアテスト Advent Calendar 2020』5日目の記事です。
登録したものの書くことが思い浮かばなかったので、自分の中の理解をまとめてみようと思います。
探索的テストとは
定義
まずはじめに探索的テスト(Exploratory Testing)とはなんでしょう。 JSTQB FL シラバスを参照してみます。
『4.4 経験ベースのテスト技法』として説明されています。
探索的テストは、形式的ではない(事前定義されていない)テストであり、テスト実行時に動的に設計、実行、ログ記録、および評価をする。テスト結果を使用してコンポーネントまたはシステムについての理解を深め、さらにテストを行わなければならない領域のテストケースを作成する
次に、JSQTB ALTA シラバスを参照してみます。 『3.4 経験ベースの技法』として説明されています。
探索的テストには、テスト担当者がプロダクトとその欠陥の学習、完了すべきテスト作業の計画、テストの設計と実行、および結果の報告を同時に行うという特徴がある。テスト担当者は、テスト実行時にテスト目標を動的に調整し、軽量のドキュメントのみを準備する[Whittaker09]。
JSTQB によると探索的テストは技法のひとつのようですね。
『知識ゼロから学ぶソフトウェアテスト』やその著者の高橋寿一さんの発表資料では、技法ではなく"スタイル"と説明されていたりもします(厳密には Cem Kaner による定義)。
定義ややり方は人によって幅があるように見えますね。
定義が異なったり同じ人物でもアップデートされていたりしますが、共通しているのは「動的にテストの設計,実行を並行して行い、学習を含んでいる」ことのようです。
ちなみに個人的には探索的テストといちいち書いたり口にするのが面倒なので ET (Exploratory Testing)と呼んでいることが多いです。 twitter 等でテストの文脈から急にスピルバーグ作品名が出てくる確率は低いと思いますので、自分が ET と言っていたら探索的テストのことを指しています。 会社でも頻繁に使うため皆が ET と呼んでいるので、ついポロっと出てしまいます。許して。
特徴
次に探索的テストはどのような要素を持っているでしょう。 自分が認識しているのはおおよそ以下の通りです。
- 学習, 設計, 実行, 報告のサイクルが存在する
- 再現性に乏しい
- 網羅性に乏しい
- 具体的なテストケースを用いない
- テストマネジメントが難しい
- (相対的に)短時間で不具合を見つけることができる
- (相対的に)複雑な操作による不具合を検出しやすい
- ドキュメントが不足していても実施することができる
テストケースとして手順が記述されたようなテスト(以下、スクリプトテスト)と比べてメリットだけが存在するわけではありません。 「探索的テストをするからスクリプトテストをしなくていい」ということにはならず、あくまで使い分けが必要です。
実施について後述するので、各特徴についてはそちらをお読み頂けばある程度は納得できるかと思います。
探索的テストの実施
探索的テストでは前述の通り基本的にテストケースを用いません。 では、どのように探索的テストを実施するのでしょう。
様々なのは定義だけではなく、実施の方法にも幅があります。 ここでは大きく3つの方法を取り上げます。
しっかりと系譜を知った上で語るわけではないため自分の認識になります、というカッコ悪い大きな保険を掛けておきます。誤りがあれば有識者の方にはぜひご指摘をお願いします。
ここではフリーな探索、ツアー、チャーターを紹介します。 フリーで実施する探索的テストでは著しく個人差が大きくなり、かつ網羅性や再現性が乏しくなります。 さらに「どこでテストをやめるのか」といった判断も難しくなります。
ツアーや後述のチャーターを用いることで、これらの要素を抑制することができます。 ただし、代償としてテスト実施者の自由を制限することになります。 もちろん制限も絶対的なものではなく脱線してはいけないわけではありません。
ツアー、チャーターは探索的テストに方向を与えます。 完全にフリーダムな探索では実施者による差が大きくなりますが、方向が揃うことでこの差を小さくします。 加えて、用意したツアー、チャーターをすべて実施したらテスト終了のような基準として用いたり、タイムボックスを用意してそれらを割り当てることでマネジメントをしやすくする効果もあります(別に推奨するとは言ってません)。
フリーで探索する
ひとつめは特に準備をせずフリーで探索を行う方法です。 方法と呼んでいいのか怪しいかもしれませんが、無計画にただプロダクトを触るわけではありません。
ただ彷徨うだけではなく探索をします。 上述の探索的テストの定義で共通しているものとして「動的にテストの設計,実行を並行して行い、学習を含んでいる」と述べました。 何かを考えながら、プロダクトを触っています。
では、その考えている「何か」とはなにか。 フリーな探索の場合、本当に個人差が激しくなりますので、自分個人の場合をご紹介します。 自分の場合はプロダクトに対して、
- どんな動きをするのか/して欲しいか
- どんな設計/実装になっているか
- 開発中、どの部分に時間が掛かっていたか
といったことを考えていることが多いです。 ざっくりとひとつずつ説明をします。
どんな動きをするのか/して欲しいか
主にプロダクトがどんな動きをするのかを知るためのものです。 自分の場合は要件定義書や仕様書にさっと目を通すことが多いですが、文字列で読んだ挙動と実際に自分で操作するのとでは理解度に違いがあります。
プロダクトに詳しくない実施直後はこれを考えていることが多いです。 先入観が薄い状態で探索できるため、「直感的にわかりにくい機能」や「勘違いしやすい表現」なども発見しやすいです。
JaSST Online Bergamot で、探索的テストが実施される様子を見るセッションがありました。 そのセッションでも後述するチャーターは用いずにフリーの探索でプロダクトと向き合うことから始めていました(参加報告のブログや togetter をご参考ください)。
どんな設計/実装になっているか
ふたつめはどんな設計/実装になっているか、です。 自分ならどう設計/実装するかを想像しながらプロダクトを触り、不具合を探します。
たとえば単純な CRUD 機能であれば、
- データは論理削除か物理削除なのか
- 削除後にデータ更新をするとどうなるか
- フォームの入力内容は表示時にエスケープされているか
- Create の連打(複数生成)は防止されているか
- 検索時のクエリで悪さできるか
といったことを考えながら、どんなバグが作り込まれるかを想像します。そして、そのバグはどう操作すれば見つかるかを考えて操作を行います。 見つからなかった場合も、プロダクトがどんな挙動をしたかを観察し、実装を想像しながら次に繋げます。
開発中、どの部分に時間が掛かっていたか
みっつめは、どこに時間が掛かっていたか、言い換えると、開発中にどの機能/画面に仕様変更/遅延があったかです。 プロダクトの開発過程を知ることができる状態であれば、進捗報告等に参加して様子をメモしておきます。
経験上、仕様変更が度々起こる場所は修正漏れがあったり、修正に伴い新しくバグを作り込んでいることが多く、 遅延しているところは実装が複雑になっておりパラメータの組み合わせ等で誤りや考慮漏れが潜んでいることが多いです。
ただし、自分の場合はプロダクトのことや開発者のことを知っている前提があります。 誰が過去にどんなプロジェクトに参加していて、どの機能に詳しいかを踏まえて怪しいポイントを探っています。 そういった意味では、ドキュメントの準備が少ないことが探索的テストの特徴ですが、時間を掛けて人のことを知ることも重要かもしれません。
ツアーを用いて探索する
続いてツアーを用いた探索です。 ツアーとは探索的テストを旅行に例えたものです。 いくつか例を見たほうがわかりやすいと思います。 『Exploratory Software Testing』では以下のような例をあげています。
- ガイドブックツアー
- ユーザーマニュアルをガイドとして利用し、ユーザーがソフトウェアに期待する主要な機能を辿る
- ランドマークツアー
- 主要な機能をランドマークに見立て、ランドマークを網羅するように辿る
- 博物館ツアー
- レガシーコードという骨董品をめぐるように開発者が中身や存在を忘れいているところをテストする
- 雨天中止ツアー
- 実行中の処理を途中でキャンセルする
このように、一回の探索に目的を与えてくれるのがツアーです。 書籍の中では他にもツアーが紹介されていますし、検索すれば解説が出てくると思います。 注意事項として、これらはツアー例であり、書籍に載っているツアーをすべて実施すれば良いわけではありません。 旅を比喩として用いることで探索的テストに応用するといったエッセンスですので、実施する際にはもちろん書籍を参考にしながら必要なツアーを考えてみてください。
チャーターを用いて探索する
最後はチャーターを用いる方法です。 チャーターも冒険家や旅から着想を得ているものだった気がします。 由来は忘れました。
チャーターを利用することでツアーと同様、探索的テストに目的という方向が与えられます。 ツアーとどう違うかですが、自分はおおよそ粒度の違いだと理解しています。 どちらも決まったフォーマットはないものの、ツアーは複数箇所をめぐるようなもので、チャーターは一箇所(ないし関連の強い箇所)に対して行うようなもののイメージです。違ったらごめんなさい。
『Explore it!』では "Explore {target} with {resources} to discover {information}" のフォーマットが紹介されています。
「{information}を探索するために{resources}を用いて{target}を探索」です。 target には機能や要件、information には見つけたい情報、resources にはツールやデータセットなどを入れます。
これを事前に用意することで、実施者で分担することができるようになり、かつ時間が経ってからも用いたチャーターを見ることである程度同じバグを再現できる可能性が高くなります。
おわりに
探索的テストの特徴や実施方法を紹介しました。 ツアーやチャーターを用いても再現性や網羅性が比較的乏しいことは理解して頂けたかと思います。
特徴を理解した上で、既存のスクリプトテストと併用したり一部置き換えたりしながら用法用量を守って実施をしていただければと思います。 そして得た知見はネットの海に放って共有してくださると自分も助かります。
あとしつこいようですが、誤りがあればご指摘をお願いしますm(_ _)m