ソフトウェアの品質を学びまくる2.0

旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

シナリオベースの探索的テストとは何か。

 2014年度に取り組もうと思っているテーマの一つが、「探索的テスト」です。もともとは「2014年に取り組もう」と思っていましたが、もう3ヶ月経ったので「度」で仕切りなおします。

 探索的テストは一般的に、手順が明確に定義されたスクリプトテスト(自動・手動は問わない)と比較されることが多いですね。また、明確な手順がある≒自動化しやすい ということでもあり、その逆を行く探索的テストは、自動化されたテストでは埋まらない間隙を埋める要素の一つとして紹介されているのも、よく見かけます。

 さて、探索的テストについて書かれたネット記事を眺めていると、goyoさんのブログ記事で、「ランドマークツアー」という単語が出てきました。

goyoki.hatenablog.com

 きちんとした手順にもとづいて探索的テストの戦略やチャータを設定し、ランドマークツアーやマニュアルベースのような手法活用の経験を積ませれば、各自の意志で実施する探索的アプローチの効果も高まっていくと思う。

 何だろこれと思ってググってみると、MSDNこちらの記事に辿り着きます。『Exploratory Software Testing』の抄訳とのことです。

Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design

Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design

 機械翻訳はあるのですが、ちゃんとした日本語訳を見つけられなかったので、ここで紹介してみます。

シナリオベースの探索

 記事では、探索的テストの概要、目的、長所や短所、スクリプトテストとの関係などについて述べた後、Scenario Based Explorationsというコンセプトを説明しています。
 テストの「シナリオ」という言葉がたくさん出てきますが、以下の記事で書いているような「業務シナリオ」に類するものではなく、操作手順のバリエーションみたいなものを指しています。

kzsuzuki.hatenablog.com

Scenarios, like maps, are a general guide about what to do during testing, which inputs to select, and which code paths to traverse, but they are not absolutes.

 ここでシナリオは、地図になぞらえられています。
 地図はゴールへの道を教えてくれるけれども、その道は必ずしも一つではないし、最短ルートが強制されるわけでもありません。そうではなく、複数のありうるルートを示すことを目的としている。
 シナリオベースの探索的テストも同じで、ルートをたくさん見出し、そこにどう色付けていくかのヒントにするかがポイントになります。

様々な「ツアー」

 Exploratory testing toursという節では、複雑なソフトウェアにおける探索的テストを、初めて大都市を訪れるツアーになぞらえたうえで、探索を行うための「切り口」をそのメタファーから導くという面白い展開になっています。
 探索的テストはテストエンジニアの経験や直感に基づいて進められることが多いとはいえ、何の道標もない状態だと途方に暮れてしまう。それを整理するための様々な視点を与えてくれるものです。

 以下に列挙しますが、どうしてこうなった?については原文をあたってください。妙に詳しく説明されています。特に後半は、無理矢理感がすごい!(笑)

  • ガイドブックツアー The Guidebook Tour
    ユーザーマニュアルに基づき、主要なポイントのみを外さないように操作を進める。
  • マネーツアー The Money Tour
    営業の人間が見込み客向けに行うデモをなぞってテストする。
  • ランドマークツアー The Landmark Tour
    対象のソフトウェアにおけるランドマークをリスト化し、ランドマークからランドマークへの経路のカバレッジを取る。
    あまり詳しい説明はないのですが、ここでいうランドマークとは、ソフトウェアのある状態、たとえば「ユーザ登録が終わった時点」などを指しているのかなと思います。
  • 知的ツアー The Intellectual Tour
    入力値などについて、ソフトウェアにとって可能な限り厳しい使い方を選んで進める。
  • FedExツアー The FedEx Tour
    ソフトウェアの中を流れるデータを特定し、そのライフサイクルを最初から最後まで追う。
  • ゴミ収集車ツアー The Garbage Collector’s Tour
    細部にはこだわらず、画面ごと、ダイアログごとに、明らかにおかしいことがないかをチェックする。
  • 嫌な隣町ツアー The Bad-Neighborhood Tour
    バグは偏在する傾向があるので、すでにバグの出た箇所を狙う。
  • 美術館ツアー The Museum Tour
    レガシーコードの残っているあたりを叩く。
  • 裏通りツアー The Back Alley Tour
    ユーザに使われそうにない機能を叩く。
  • 徹夜ツアー The All-Nighter Tour
    ファイルを開きっぱなしにするなど、中途半端な状態で放置する。
  • スーパーモデルツアー The Supermodel Tour
    見た目や第一印象だけで、可否を判断する。パッと見の画面の様子や性能などの問題をターゲットにしている。
  • カウチポテトツアー The Couch Potato Tour
    必要最低限の操作で機能を使う。画面系なら、すべてのフィールドをデフォルト値にしたまま先に進めるなど。
  • 強迫観念ツアー The Obsessive-Compulsive Tour
    同じ操作を何度も何度も繰り返す。
    この辺になるともう、旅行のメタファーが説明されてないですからね!

 MECEを保証するとかカバレッジを高めるというよりも、ランダムに陥りがちな探索的テストについて一本を筋を通すための切り口の発想を与えているというところですね。
 ゴミ収集車ツアーとか、「どこが旅行のメタファーです?」としか言いようがないのですが、この無理矢理感が大好きです。探索的テストの事前レビューで「今回は"美術館"で行く・・!」とか宣言したいですね。