Mercari Engineering Blog

We're the software engineers behind Mercari. Check out our blog to see the tech that powers our marketplace.

Agile 2018 レポート:テスト戦略モデルにおける「INFORMATION」とは何か?

こんにちは。メルカリの Automation & QA グループ(通称:AQA)でQAエンジニアとして日夜テストをぶりぶりしているこんどうです。

QAリードのすがぴーも以前こちらで紹介していたアジャイルカンファレンスに同行してきました。数多くのセッションに参加しましたが、今回はわたしのなかで特に印象に残ったUK eBay の Head of Software Testing である Dan Ashby氏のセッション「Testing in Agile」のなかで提唱されていた、アジャイルテスティングにおけるテスト戦略モデルについて、Dan Ashby氏ご本人から許可をいただいたのでこちらに紹介したいと思います。

テスト戦略とは

そもそもテスト戦略とは、いまある自分たちの会社やチーム、プロジェクトでの様々なコンテクストに応じて最適なテスト実施の方向性を決めることを指します。定義された要件通り確実に動作していることを確認すべきなのか、それとも、リリース速度を優先し、のちの修正も考慮した上でまずは優先度の高い機能の動作を最低限保証すべきなのか。あるいはすべてを自動テストでカバーできうるのか。状況に応じて取りうるテスト戦略はさまざまです。

このようなテスト戦略についてのシンプルでわかりやすいモデルとして、James Bach氏のヒューリスティックテスト戦略モデルがあります。このモデルによると、プロジェクト環境(Project Environment)とプロダクト要素(Product Elements)、 品質基準(Quality Criteria)という3つのコンテクストを通じた分析結果によりテスト技法(Test Techniques)を確定し、最終的にお客さまに「知覚される品質(Perceived Quality)」を導きます。

f:id:hkondo134:20180829213826p:plain
James Bach氏によるヒューリスティックテスト戦略モデル

http://www.satisfice.com/tools/htsm.pdf

ヒューリスティックテスト戦略モデルからのアップデート

Ashby氏も当初は、このJames Bach氏によるヒューリスティックテスト戦略モデルを参考に自身のテスト活動を行なっていたそうですが、eBayにJOINし新たなテスト活動をしていくなかで、ヒューリスティックテスト戦略モデルからのアップデートを行う必要性を感じたようです。そこでAshby氏が考案したものが以下のモデル図になります。

f:id:hkondo134:20180829214156p:plain
Dan Ashby氏によるテスト戦略モデル

https://danashby.co.uk/2017/12/13/a-new-model-for-test-strategies

従来のヒューリスティックテスト戦略モデルにもある前述した3つのコンテクストに加えて、リスク(Risks)やメンバーのスキル(People&Skills)、ツール(Tools)が追加され、さらにはコンテクストと知覚される品質(Perceived Quality)との間に、テストアプローチ(Approaches)やテストアイデア(Driving Test Ideas)、テスト実行(Test Execution)といった、より実践的で具体性のある要素も追加されています。ひと目でソフトウェアテストライフサイクル(STLC)が概観でき、シンプルでありながらとても有用な図です。

「QAって、日々テストしてくれているのはわかるけど、具体的に何を考えてどのような指針のもとに行動しているのだろう?」と疑問に思うPMの方や非エンジニアなステークホルダーの方も多くいらっしゃると思うので、そのような方々にもぜひこちらの図は参考にしていただきたいです。もちろんモデル図であるがゆえにあくまで理想像ではありますが、「プロダクト品質を維持・向上させる上で必要なものとはなにか」のエッセンスが凝縮されていると思います。

INFORMATION

このモデルのなかでひときわ興味深いのが、モデル図内の中心に位置し、以下の4つの特性に分類される「INFORMATION」というコンセプトです。

f:id:hkondo134:20180830020842p:plain
INFORMATION拡大図

  • 明確に分かる情報(Known Explicit Information) / テストスクリプト化可能な情報
  • 暗黙の情報(Tacit & Implicit Information)/ 言語化・説明の難しい情報 (自転車に乗る時のバランス)
  • 気がついているけど不確かな情報(Unknown that We are Aware of)/ 根本原因のわからない問題
  • 気がついてさえいない未知なる情報(Unawareness of Unknowns)/ 考慮漏れなど気づかれてない潜在的な問題

従来、プロダクトの「仕様(Specification)」という大枠のなかに隠されて明確に概念化されてこなかった「不確かな部分」について、「INFORMATION」というシンプルなフレーズで言語化し、テスト活動とは、その未知なる「INFORMATION」を知識に変換していくプロセスであると定義しています。

さらにこの4つの情報特性のうち、明確な期待値(Asserting Expectations)をもったテスト(Scripted Approach)が実行可能で、テスト自動化のアプローチ(Automation Approach)をも取りうるものといえば、左端の「明確に分かる情報(Known Explicit Information)」のみであり、その他のINFORMATIONについては、探索的アプローチ(Exploratory Approach)などによる調査(Investigation)を通じて明確化させていく必要があると言われています。

探索的アプローチとは、主には探索的テストを用いた調査を意味しています。探索的テストというのは「学習、テスト設計、テスト実施を同時に行うもの (James Bach)」と言われる通り、テスト手順の明確なドキュメント化は行わず、事前の調査結果やテスト実施者本人の知識・経験に基づいて、対象を実際に操作しながらテストを進めていく手法です。

すなわち、テストケースに落とし込めるものだけをテストしても、本来はやるべきたくさんのテスト活動を見落としてしまうのです。そう考えると、テストケースを作成したり自動化したりできる部分は、テストすべき領域の一部分でしかないことがよくわかります。

TESTING ISN’T JUST ABOUT TESTING DEVELOPED SOFTWARE

では、氏の考えるこのテスト戦略モデルが「アジャイル開発におけるテスト」とどのように結びつけられるのか。そこでは、モデル図内において「INFORMATION」と連携するように描かれた「継続的テスト(Continuous Testing)」という要素がキーになります。

f:id:hkondo134:20180829215059p:plain
継続的テストの部分(Continuous Testing)

  • アイデアをテストする (Testing the Ideas)
  • アーティファクト(成果物)をテストする (Testing the Artefacts)
  • デザインをテストする (Testing the Designs)
  • コードをテストする (Testing the Code)
  • ソフトウェアをテストする (Testing the Software)
  • プロセスをテストする (Testing the Processes)
  • ∞ (The Infinite Loop)

単に「ソフトウェアをテストする(Testing the Software)」ことというのは、「INFORMATION」を明確にしていく継続的なテストにおけるほんの一部でしかありません。新機能はもちろん、アーティファクト(成果物)やUX / UIデザイン、コードデザイン、コードの実行、CIパイプライン(継続的インテグレーション)、リリースプロセス、アジャイルプロセスなど、それぞれのプロセスやアクティビティのなかで出てくる様々なアイデアに対して継続的にテストをし、そのたびごとに不明確だった「INFORMATION」を明確化していくことこそが氏の考える「Testing in Agile」です。

f:id:hkondo134:20180829215404p:plain
どこでもTestできるの図

セッション内で提示されたこちらのスライドが示すとおり、DevOpsの継続的なプロセスの中のあらゆる局面でテストは有効だといいます。「テストはロール(役割)やフェーズ(段階)ではない」といったこともアジャイルにおいてはよく言われますが、このセッションを通じて、「プロダクト開発に付随するあらゆる事柄をより良いものにする」ための上位概念として「テスト/QA」が存在する、という実感を改めて強くしました。

プロダクト開発のあらゆるプロセスやアクティビティ、成果物において品質に対する意識が充分高まっていれば、QAエンジニアというロール自体必要なくなるかもしれません。それこそが理想ではあります。では実際はどうか。

ただ、「要件にマッチしているか?」「 予想通りに機能しているか?」といった従来型のテストを実行しているだけになってはいないか。アジャイルと言いつつ、期間が短いだけのウォーターフォール型のプロセスになってはいないか。

テストや品質に対する意識がこのようなままでは、テストというアクティビティそのものが死んでしまう。既存のテスト戦略モデルや手法に則りつつも、プロダクト開発を「INFORMATION」という新たなコンセプトを中心に捉え直すことで、テストというアクティビティそのものの可能性を押し広げてくれるセッションでした。

おわりに

今回のカンファレンス参加についてはAQAマネージャーの@daipresentsを中心にCodeZineでもレポートを書かせていただいてますので、そちらも合わせてご覧ください!

codezine.jp

codezine.jp

codezine.jp

またテストや自動化の話をカジュアルにできるようにFacebookグループ Agile Testing, Automation and QAの現場 を作ってみました。もしご興味があれば、ぜひ遊びにきてください!

 
Agile Testing, Automation and QAの現場
Facebookグループ · メンバー116人
グループに参加
アジャイルテスティング、自動化、品質保証。そんなキーワードに関心のある方が集まるグループです。アンケートにお答えいただいたからから随時承認中です。ご協力お願いいたします。 日本語をメインで使っていますが、 Some member can communicate with you in English...