「探索的テストで工夫したこと」(2)探索的テスト実施前：情報収集
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」について、当時私が考えていたことを数回に分け書き記しています。
前回書いたこと
[1]探索的テスト実施前：情報収集
下記について書き記します。
図中の凡例は、下記5点です。
- 白地の四角
抽象度：低の成果物 - 白地の円
抽象度：低のプロセス(行動、やること) - 黒地の四角
抽象度：高の成果物 - 黒地の円
抽象度：高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度：低の成果物)を集約した情報
なお、ET："Exploratory Testing(探索的テスト)"と略称しています。
何故、ET実施前に情報収集を行うのか？
私だけかもしれませんが、テスト対象で不具合が隠れていると思われる機能を絞り込み、どのような手段でテストを行うか頭の中で検討するためです。また、漠然とテストしたところ、不具合を見つけることができなかったことがありましたので、「テスト対象の怪しいところは何か？」を明確にしたいと考え、「怪しいところ」に繋がる情報を収集したら、不具合が見つかるだろうと考えました。
初めに取り組んだこと
当時、インシデントレポートを多く読んでいなかったのですが、 ソフトウェアテスト293の鉄則の『鉄則055：報告の内容でテストをした“人”がわかる』を読んだ後、「発見したバグは何故修正しないといけないか？」という理由が明確なインシデントレポートを探して読んだら、「テスト対象やシステムのあるべき姿は何かを考えることができるのでは？」と考え、これまで関わったプロジェクトや同僚が関わった過去プロジェクトのインシデントレポートを印刷して読み込みました。
インシデントを何件か読んでいくうちに...
スクリプトテストを実施しながら、「バグが存在することでユーザが困ることは何か？」「どのような手段で、ユーザが困ることを見つけることができるのだろうか？」と思い始め、テスト対象に関する仕様書(要求仕様、製品仕様、テスト仕様)や過去プロジェクトのインシデントレポートを参考情報として、読み漁りました。
読み漁った後...
スクリプトテストで疲れたので、少しリフレッシュしようとペットボトルのお茶を飲んでいたとき、(「そういえば...」と)デジャブを感じるバグが何件かあることに気付きました。バグの傾向をつかみ、インシデントレポートから新たなテストケースを頭の中や裏紙に書きながらテストケースを思いついたので、試しにテストを実施してみたら、偶然バグを発見することができました。
開発者に状況を話したところ、開発者から「それはバグですね。インシデントレポートを書いて、私に送ってもらえますか？」ということで、少しずつですがバグのにおいを感じるようになりました。
次回
[2]ET実施中について、詳細を説明する予定です。
