テスト戦略の実践は、運用環境への"プッシュ・アンド・プレイ(push and pray)"デプロイメントから、継続的かつ確信を持って行うデプロイメントへの移行を支援する。さまざまなイネーブラ(enabler)を備えたフレームワークにマッピングすることにより、テストという強力なセーフティネットの下で、運用への移行に先立ってプロダクト全体の品質メトリクスを調整することが可能になるのだ。
ThoughtWorksの主任品質アナリストであるVaruna Srivastava氏はConTEST NYC 2021で、デプロイメントに重大な問題を抱えたプロダクトのケーススタディを紹介し、テスト戦略をドライバとしてデプロイメントの完成度を向上したその企業の判断について論じた。
テスト戦略のライフサイクルは、プロジェクトに強く結び付いている。戦略には進行中のプロジェクト/プロダクトに基いた複数の要素があり得る、とSrivastava氏は説明する。
私たちのプロダクトはモバイルアプリで、サポート対象とするデバイスとバージョン、エンドツーエンド全体に及ぶ品質プロセス、さまざまなテスト形式、運用への道筋の決定、リスクマイグレーション計画といったものが戦略的要素でした。
プロダクトではトランクベースの開発を採用していたので、頻繁なプロダクションデプロイメントを行うためのフィーチャやリリースのトグルにも力を入れていました。私たちのテスト戦略は、クライアントへの提供前にプロダクトのフィーチャのオンとオフの両方をテストする、というものでした。この戦略は、運用環境において障害やブロッカが確認された時、任意の機能をロールバックするために役に立ちました。
新たなテスト戦略に必要なスキルを開発するため、その企業では、プロジェクトに必要な能力を明確化した上で、そのニーズに基いたトレーニングをチームメンバに提供した、とSrivastava氏は述べている。企業全体として、チームのニーズに基いて作業方法をカスタマイズする、という方法も考案された — すべてのチームが同じ原則に従う中で、それぞれのカラーを持つのだ。チームが自律性と協性を原則として開発に着手する一方で、知識を企業全体に広げようという意図から、さまざまなチーム間でのメンバローテーションが頻繁に行われた。
Srivastava氏によれば、テスト戦略が企業にもたらすメリットは次のようなものだ。
品質上のメトリクス — テスト戦略は計測可能な品質メトリクスで構成されており、そのスコアはプロジェクトの健全性であると同時に、改善の余地をも反映する。
エンジニアリングプラクティスの成熟性 — テスト戦略は、迅速かつ信頼性の高い運用リリースを最適化する、エンジニアリングプラクティスの成熟によって可能になる。これは、spotifyやSAFeといったフレームワークをチームに植え付ける上でも有効だ。さらにテスト戦略は、プロジェクトと技術的ガバナンスを組織のビジネスおよび技術的ニーズに一致させる役割を果たすとともに、バックログの継続的なグルーミングへの注力や、相互依存型チームによるロードマップ定義も可能にする。
インフラストラクチャの完成度 — テスト戦略は、セルフサービスデプロイメント、ロールバック、監視などを行うための、インフラストラクチャパイプラインの提供を可能にする。ダウンタイムにおける警告の受信に有効である。
Varuna Srivastava氏に、企業におけるテスト戦略の実施方法について話を聞いた。
InfoQ: "プッシュ・アンド・プレイ"式のデプロイメントアプローチでは、企業はどのような問題に直面するのでしょうか？
Varuna Srivastava: プッシュ・アンド・プレイデプロイメントには信頼性がありません — 運用環境でも問題なく動作する場合もありますが、インテグレーション上の問題が浮かび上がることが非常に多いのです。機能提供に対する顧客の信頼は失われます。
サポートチケットは数千件に達し、サポートコールが一日中鳴り続けることになる場合がほとんどなのです。ブランドの価値や、機能開発に従事した人々のモラルにも影響を与えます。
市場投入までの時間も長くなり、チームメンバ間やチーム内には不信頼感が漂い始め、チームのダイナミクスや企業内の作業文化にも影響するようになるでしょう。
InfoQ: テスト戦略とはどのようなものでしょう、どのようなメリットがあるのでしょうか？
Srivastava: プログラミング言語のフレームワークと同じようなフレームワークのひとつで、何を実践するか、あるいは実践しようとするか、ということです。継続的なリファクタリングやフィードバックによって、プロジェクトのライフサイクルを通じて進化し、テクノロジ、ビジネスの両方に共通するアクションプランの立案を支援します。私たちのプロジェクトでは、ニーズを定義し、そこから成果物を合意する上で役立てています。
InfoQ: テスト戦略をアップデートするために、どのようなフィードバックループをセットアップしましたか？
Srivastava: テスト戦略のフィードバックループは、プロジェクトで定義されたSMART(Specific(具体的)、Measurable(測定可能)、Attainable(達成可能)、Relevant(関連性のある)、Time(期限のある)フレームワーク) KPIやRAIDに結び付いています。フィードバックを継続的に取得して、KPIに提供し続けられるように、スプリントのイテレーション上にさまざまなチェックポイントを設けました。プロジェクトチームはニーズで始まって、KPIに基いたアクションで終了します。KPIの一部として、次のようなアスペクトを計測することにしました。
- 不具合流出率(defect escape rate)
- MTTR、MTBF、故障率の算出
- テスト自動化のカバレッジとフェール率
- テスト自動化のフィードバック時間
- 不具合マトリクス(defect matrix)
不具合マトリクスは、プロダクトの状況に関する全体像を提供してくれます。私たちは、不具合の優先度と緊急度に基づいて不具合マトリクスを作成したのですが、これによって、障害を防止する方法についての行動を起こすことが可能になると同時に、新たな機能への入力としても使用することができました。
RAID(リスク(Risk)、仮定(Assumption)、問題(Issue)、依存性(Dependency))は、不確実性や問題、部分的ないし全体的に直接的なコントロールの範囲外にあるものを理解する上で、プロジェクトチームに何が必要かを特定し、分析してくれます。
RAIDの例をいくつか挙げましょう。
- この一連のテストが実行されない場合に、稼働が遅れる可能性
- テスト環境において可能な、相互依存システムの仮定の検証
- 問題を認識する
- 下位環境でテストを実行するための、運用データへの依存性
チーム内で識別され合意されたRAIDは、デプロイメントの"プッシュ・アンド・プレイ"段階を離れて、顧客から稼働開始を導き出す上で有用なものになります。
InfoQ: 実践されたもののひとつとして、"強力なテクノロジチャンピオン"を目指す、というものがありました。これはどのような考えに基づくもので、どのようなステップで実現されるものなのでしょう？
Srivastava: その会社では、個人が自ら学習パスを進める、というキャリアパスを実践していました。このパスが、"現在の自分"、"次の自分"、"自身の計画"を反映したフレームワークを構築していたのです。コンサルタントは、関心に基づいて自身の目標を立て、タイムラインを設定し、完了したものに"達成"をマークすることが可能です。各人は、ラーニングハブプール(learning hub pool)の中から、自身が必要とするトレーニングセット(最新のアーキテクチャ実装、デリバリサイクルにおけるテスト、など)を選択して、自ら応募することができます。
"強力なテクノロジチャンピオン"を育成するというアイデアの背景には、情熱を持った、自身の学習パスを進むことのできる人材を企業内に育てたい、という企業の思惑があります。個人のキャリアに対する可視性を確保し、企業としての整合性を生み出す上でも有効です。