リスクに立ち向かう探索テストとその手法
こちらも同じくDan Ashby氏によるセッション「"It's a trap!" - How not testing risks is a huge risk」のレポートです。このセッションではソフトウェアテストに潜む「リスク」に注目した内容でした。
まず、「リスク」とは何でしょうか？ 辞書を調べると「ネガティブなことが起きる可能性」「ビジネスやエンジニアリングの場で潜在的に起こりうるイベント」などがでてきます。ソフトウェア開発におけるリスクにはどのようなものがあるでしょうか？
- ビジネスリスク
- 人員的リスク
- プロジェクトリスク
- プロダクトリスク
ソフトウェア開発に関わる方であれば、上記のようなリスクは誰もが経験したことがあるはずです。
ここで、簡単な演習として「イス」をどうやってテストするかを考えることになりました。イスをテストする場合、どのような観点でテストするでしょうか？
- 座ってみる
- 高さを調整する
- ローラーが付いているので動かしてみる……
セッションでは、いろんな観点が参加者からでてきましたが、氏は参加者に以下のように問いかけます。
- そのアイデアがすぐに出てきましたか？
- それらのアイデアをどのように整理するとよいでしょう？
- そのアイデアはどういった情報をカバーしていないでしょうか？
- そして、どういったリスクをテストしようとしたでしょうか？
テストの目的とは「情報を明らかにすること」です。その中で特に、リスクを明らかにしていかなければなりません。
ここで氏から、明らかにするべきリスクを見つける手助けになるモデル図が紹介されました。あらゆるレベルでプロダクトのリスクを考慮し、シンプルに以下の質問によってリスクを切り分けます。
「そのリスクは重要だろうか？ 我々はそのリスクを考慮すべきだろうか？」
この質問に対して「Yes」と考えた場合、Test Charterなどのツールを使ってさらに調査を進めていきます。Test Charterとは、探索テストを実行する上で利用する手法です（Test Charterについては後述します）。
開発プロセスごとのリスクを見てみましょう。開発する前、開発中、開発後、で見つかる情報は異なります。
例えば、リスクに対する意思決定をする場合、開発前のフィードバックがもっとも早いものとなり、開発後になるともっとも遅いフィードバックとなってしまいます。バグを見つけて報告する……というのは正しい行動ではありますが、根本原因を解決する正しい解決方法とは言い切れません。
いうまでもなく、早期のフィードバックほど重要なものはありません。
しかしながら、ソフトウェア開発にはたくさんのテストが存在し、さまざまなテストを見ていくと、「テストフェーズでやるテスト」になってしまう傾向があります。例えば、セキュリティテストやパフォーマンステストをソフトウェア開発後に行っているとすれば、フィードバックも遅くなってしまうわけです。
そこで探索テストが登場します。まだ明らかでないリスクを発見するために、探索テストが利用できます。
探索テストにはTest Charterという手法が有効です。調べてみると、本来は「Actor, Purpose, Setup, Priority, Reference, Data, Activities」といった項目を埋めていくようですが、上記のようにシンプルなフォーマットになると、アジャイル開発で使われるユーザーストーリーのように見えてきます。
- データ型のリスクを発見するために
- ものすごくたくさんの文字列一覧を利用して
- コメントボックスを探索する
他にも「データによる負荷のリスクを発見するために、10000文字を1回のリクエストに利用して、アカウントAPIを探索する」という書き方もできるので、APIテストといったシステムのバックエンド側のテストでも使えます。
氏のセッションには「Heuristic（試行錯誤的な。経験則）」というキーワードが何回も登場します。「Testing & Quality」トラックにはたくさんのテスターが参加していましたが、探索テストのような自動化できない部分をテストする手法に、テストの未来を感じます。
