こんにちは。ダイの大冒険ガチ勢のbun913と申します。
わたしはSDET（Software Development Engineer in Test）という職種で働いており、名前からするとテストの自動化などを中心にしていそうですが、実際は効果的なマニュアルテストという貢献をチームにするべく頼りになるQAエンジニアの先輩に師事し、マニュアルUIテストの計画・分析・実行も行っています。
その中で、「探索的テスト」という形でテストを実行するのですが、これまで「かなり経験や知見に依存するテストなのでは？」「QAエンジニアとしての経験があまりない自分では難しいのでは」と感じているところがありましたので、Explore It!という洋書を読んで学習しました。
この書籍の概要
| Key | value |
|---|---|
| タイトル | Explore It! |
| 作者 | Hendrickson、Elisabeth |
| 出版社 | Pragmatic Bookshelf |
目次
- Part1 -- Establishing Foundations
- On Testing and Exploration
- Charter Your Explorations
- Observe the Details
- Find Interesting Variations
- Evaluate Results
- Part2 -- Adding Dimensions
- Vary Sequences and Interactions
- Explore Entities and Their Relationships
- Discover States and Transitions
- Explore the Ecosystem
- Part3 -- Putting it in Context
- Explore When There Is No User Interface
- Explore an Existing System
- Explore Requirements
- Integrate Exploration Throughout
- Interviewing for Exploratory Testing Skills
- Test Heuristics Cheat Sheet
心に残ったポイントの紹介
ここからは書籍を読んで特に私の心に残ったことを紹介します。
Chapter 1.2 Essential Elements of Exploratory Testing
筆者は探索的テストについて以下のような定義を利用されているとおっしゃっていました。
Simultaneously designing and executing tests to learn about the system, using your insights from the last experiment to inform the next
日本語に訳するならば「システムについて学ぶためにテストを同時に設計・実行し、前回の実験から得た洞察を次の実験に活かすこと」といった感じでしょうか。
この「システムについて学ぶために」ということが本質的な意味合いを表現しているような気がしており、その少し前にも以下のような公式が書かれています。
テストを行う際にはたとえば「要求を満たしているか」「仕様通りに動いているか」ということをチェックするだけでなく、他に懸念されるリスクがないか探索してみることを行う必要がある。という意味合いだと理解しています。
特に自分が開発者であった経験から「仕様通りに動いているか」「明らかにセキュリティ的にまずい実装になっていないか」というチェックの観点から開発者テストを書くことが多いので、この「思いもよらないところを探索して、開発者も知らない部分を明らかにする」という探索的要素を意識しようと思いました。
まさに探索的な感じがしてワクワクしてきませんか？
Chapter 2. Charter Your Exploration
この章では探索をするにあたって良い「チャーター」とは何か？ということを解説してくれています。
特にテスト技術者ではない方には馴染みがない言葉だと思いますが、私たちが探索をする時には何か目的を持ってしますよね。
- スコップを持って埋蔵金を探るためにジャングルの奥地に向かうのか
- オーパーツが眠るとされる古代遺跡を見つけるためにスペースシップを使って宇宙の果てに向かうのか
「なんかジャングルに行く」という形ではなく、意味のある探索をするには良いチャーターが必要だと言うことで、この書籍では以下のようなテンプレートが今後の章で繰り返し出てきます。
Explore: editing profiles
With: various login methods to discover surprises
なお、以下の資料にて「徘徊ではなく探索」ということが紹介されており、この書籍と相互に理解をブーストさせると思いますのぜひご覧ください。
なお、良いチャーターの目安として
- 詳しい手順になりすぎず
- 探索におけるミッションが明確で
- そのために何を使うのか
という点が強調されているように思います。
具体例としては以下のようなチャーターが記載されています。
EXPLORE: input fields
With: JavaScript and SQL injection attacks
to: discover security vulnerabilities
私自身も探索的テストの段階でこれら3点を明確化せずに、目的のない徘徊のようにテストを実行していたことがあったので、この章を読んでからは特にこの点を明確にするようにしています。
Chapter 3. Observe the details
この章の冒頭では以下の動画が紹介されています。（ムーンウォーキングベアーという言葉に聞き覚えがない方はぜひご覧ください）
It's easy to miss something you're not looking for
私は案の定、この動画に隠された秘密に気づかなかった人なのでとても刺さりました。
この章では、そんなソフトウェアの中に実は存在している熊を探すために注意すべき観点が以下のように書かれています。ぜひ興味がある方はご覧ください。私としては、特に Console and Noise が目に入り、たとえば「エラーはユーザーに返らないが、非同期のキューイング処理が失敗し続けて永久にシステムログが出続けないか？」といった観点でもテストを考えるように意識しています。
- Asking the Deeper Question
- Be Alert for Subtle Clues
- An Unexpected Noise
Chapter 4. Find Interesting Variations
ここでは特に Subtle Variables を見つけることの重要さやヒントが書かれています。（日本語だとかすかな変数という感じでしょうか）
皆さんもシステム開発やテスト実行の中で思いもよらない行動や状態がバグを生んだ経験はありませんか？この章では実際にそれらを見つけるためのヒントとして以下のようなものが挙げられています。一部だけ記載しています
- Things You Can Count
- ユーザーが所属しているグループの数などシステム上の数えられるものですね
- 個人的な経験ですと、「ユーザーから見ると1個の実体に見えるものが、実はバージョニングで保持されており、そのバージョニングが悪さをしていた」というような経験があります。数えられるものを把握しておくことも大事ですね
- Files and Storage
- Geographic Locations
- タイムゾーン・郵便番号などはわかりやすいですね
- Timing, Frequency, and Duration
- この書籍の作者が言いたいこととは違うかもしれませんが、実は時間制限がある処理などはなんだろう？と考え始めました
- ログインセッション、ファイルをアップロードするための一時URLの有効時間、非同期ジョブが実行されるまでの間の時間などです
Chapter 5. Evaluate Results
探索的テストでは「これってどうなるんだっけ」を突き詰めた結果、「この結果ってどうなるんだっけ？要件にのってないぞ」というようなシステムの挙動を発見することがありますよね。（そのような驚きや未知を探索してるわけですので）
見つけた挙動をどのように評価するのか、システムとして正しいのか、悪いのか。もしくは、そのような挙動を見つけるためのヒントとなるようなことがここでは書かれていました。ここでも一部だけ記載しています。
-
Never and Always
- 個人的にはこの考え方は探索的テストの時に必ず持ち込みたい考えだと思いました
- システムが提供するべきものは？どんな価値を提供するために常にあるべき姿、逆にあってはならない姿はどのようなものか？
- それを崩すような結果を導ける行動はどんなものだろう？といったものを考える良い観点になります
- また、この書籍にはステークホルダーと集まって話すことなども書かれており、もう少し深めてみたい考えでもあります
- Standards
- たとえばクレジットカード番号を取り扱うようなシステムの場合満たしておくべき業界スタンダードなどがあります
- そのような要件を概念的にでも良いので頭に入れておき、システムの挙動の面からそれらを満たしているか探索するという見方も面白いと感じました
Chapter 6. Vary Sequences and Interactions ~ Chapter 9. Explore the Ecosystem
このChapterから Adding Dimensions というパートに入り、皆さんがよく知るテスト技法に近いものが出てくるようになります。
個人的にはテスト分析の時に頭に入れているようなこともありましたので、面白そうだなと思ったところなどを抜粋します。
Nouns and Verbs
現実のシステムのユーザーはデザインされた通りのユースケースを通ってくれるとは限らず、思いもよらない操作をすることがありますよね。この技法はシステムが提供しているリソースや機能を動詞と名詞で分けて、ランダムに組み合わせてテストしてみようというものです。
わかりにくいので、たとえばビジネス用のデビットカードを発行し利用できるシステムを仮想的に考えてみました。
| Nouns(名詞) | Verbs(動詞) |
|---|---|
| 残高 | 貯める |
| ポイント | 引き出す |
| カード | 追加 |
| 明細 | 絞り込み |
| お問い合わせ | 送信 |
| 従業員 | 追加 |
| お知らせ | 表示 |
| 仮想カード | 削除 |
この本ではこれらの名詞や動詞をそれぞれカードにして、ランダムに組み合わせを引くような方法が描かれています。たとえば「残高」「追加」などはわかりやすいですが、「従業員」「貯める」などの組み合わせはちょっとわからないですね。
書籍中にはそのような一見ナンセンスな組み合わせにこそ、創造性を働かせてソフトウェアの未探索領域を広げてみることが推奨されています。
「お知らせを貯めるってなんだろう。後で使えるように取っておくっていうことと捉えるならアーカイブしておくみたいな感じが近いかな？表示期間を過ぎたお知らせがそれに近いのかな？期間といえばタイムゾーンの影響とかどうだろう？お知らせは何種類あって・・・」というように考えを深めるのは面白そうだなと思いました。
ただしカードを作ってランダムに組み合わせを考える時間を取るのは難しいので、特に新しい概念やリソースが出た時に既存の動詞と組み合わせてテストを考えるといったやり方は良さそうだと思いました。
なお以下は Chapter 7 ~ Chapter 9 にてそれぞれ記載されている観点やテクニックになりますが、テスト分析の考えの際に普段利用しているやり方と大きな違いがないため、ダイジェストさせていただきます。
- Chapter 7 Explore Entities and Their Relationships
- システムで提供されているリソース（エンティティ）やそれら同士のつながりを整理するやり方が紹介されていました
- 必ずしもER図のようなデータの持ち方に限らず、ユーザーから見えるリソース同士のつながりや1:Nの関係などを整理することで探索領域を整理する考えだと思います
- たとえば整理した後に「ではカードはユーザーと1:1で紐付きそうだが、カード単体を発行することは可能か？」「1:Nで発行はできる？」などと
CRUD with Zero, One, Many Dependentsという発想で探索ができそうです
- Chapter 8 Discover States and Transitions
- 状態遷移図や状態遷移表を整理して、テスト領域を整理する手法が書かれていました
- 興味のある方は以下資料をご覧ください
- 参考: 状態遷移テスト 魔法を駆使して魔王を倒すぞ！
- Chapter 9 Explore the Ecosystem
- システムの内部構造や外部の誰から使われるか、外部の何に依存しているかということを図示する手法です
- 構成図ほど詳細ではありませんが、システム内部の構成要素（Web App, DB, Cache DBなど）を図示し、外部とのつながりを整理するものです
- これを整理した上で「What if」を整理する手法が記載されています。（ぱっと思いつくのは外部の依存システムがメンテナンス中は？といったものだと思います）
Chapter 10. Explore When There is No User Interface ~ Chapter 13. Integrate Exploration Throughout
ここから Putting It in Context というパートに入り、既存のシステムに対するものや要求に対しての探索的テストに関する手法が紹介されています。その中でもすぐに使えそうだと思ったChapter 12について少しだけ記載します。
12. Explore Requirements
今ではかなり目にするようになった要求時点でQAエンジニアが入り、潜在的なリスクやあるべき姿を早い段階で明らかにする手法について語られています。
前半では筆者の実際のストーリーを通しながら重要性や意味が語られておりますが、その中でも心に残った言葉が、この本やこの記事でもたびたび出てきている Ask "What if" という言葉です。
- ではその同期処理が失敗した場合、リトライされずに詰んでしまうんだっけ？
- その外部依存とのやり取りのインターフェースが変わるとどうなるんだっけ？
- その場合ユーザーへのフィードバックはどのように表示されるんだっけ？
質問ばかり書いているので、かなりしつこく感じますね。実際は「本来の機能の背景からすると〜こういう形が望ましいですかね」といった形で、これまでの探索やテスト活動でわかってきたシステムの Never や Always を踏まえて提案もできると素敵だなと思っています。
全体的な感想・業務に活かしていること
- テスト分析やテスト実行をする際に「今はチェックの視点か」「探索の視点か」ということを意識するようにしています
- また探索の視点の際には「誰も発見してない（気づいてないような）何を発見しようかな」「これをしたらどうなるんだろう( What if )」の観点を持つようにしました
- チェックの視点でテスト実行をしている中でピンときた探索先とツールが見つかったらすぐにタスクメモに書き出して、後で実行できるようにしています
- 私が探していないものは見つけることが難しい
- エラーが画面に表示されることだけ確認するのではなく、その出力結果がたとえばログや通知として現れるならそちらはどうか？見逃している出力先はないか？ということを意識しています
- What if を再現する武器を磨く
- 自分はSDETという職種であり、QAエンジニアの経験が少ない代わりに、開発やクラウド周りの知見が少しだけあります
- たとえば外部の依存がエラーレスポンスを返すことを再現できるようにツールを使ったり
- DBの値を参照し、内部の動作を確認したり、時には変更をすることをバックエンドエンジニアと相談して実行することもできるでしょう
- そのような想像力を実際のエラーとして再現するための情報収集を欠かさずに行おうとより強く思いました
洋書であり、読了に時間を要しましたが、そこまで複雑難解な英語が多用されているわけではないですし、ページ数も200ページもないので洋書チャレンジとしてもやりやすい部類に入ると思います。
これからもインプットした知識は、自分の中に取り込んでアウトプットをして定着していくように意識したいと思います。以上、ありがとうございました。
Discussion