DevOpsのループ図およびシフトレフトテスト/シフトライトテストについての考察

Testing in DevOps 技術

はじめに

本記事は ソフトウェアテスト Advent Calendar 2023 および10X プロダクトアドベントカレンダー2023の5日目の記事です*1。

皆さんは「DevOpsに関する図を思い浮かべてください」と言われたら、どのような図を想像しますか？一番思い浮かべる人が多いのが、DevOpsのループ図ではないでしょうか？

DevOpsのループ図（vecteezyより拝借）

本記事では、DevOpsのループ図の発端を探しつつ、このループ図に対しての私なりの考えを述べた上で、シフトレフトテスト/シフトライトテストについて詳しく言及していきます。

目次

Danの考えるDevOpsのループ図

まず、DevOpsのループ図にはどのようなものがあるのでしょうか？

※12/5追記：Danの描いたDevOpsのループ図は発端では無かったため、本文中の表現を修正しました*2。

DevOpsのループを用いた図の1つとして、Dan Ashbyの「Continuous Testing in DevOps…」という記事*3があります*4*5。

Danの記事内に描かれているDevOpsのループ図を日本語訳したものがこちらになります。

記事「Continuous Testing in DevOps…」内記載の図に日本語訳を付けて作成

ループ図の解釈

DanのDevOpsのループ図からは、いくつか主張したい部分があると感じています。

テストの扱いについて

Danが描いたDevOpsのループ図をよく見てください。♾️の中に「TEST」という文字が存在しておらず、全てのフェーズに「テスト」の文字が刺されています。

Danは先述したブログ記事の中で以下のように述べています。

私にとって、テストはこのモデルのあらゆる点に適合します。

つまり、Danにとって♾️のループ図は、テストという活動が特定のフェーズに留まらないことを示すために描いたとも言えます。

一方で、冒頭に載せたような図のように、♾️のループの中に「Test」が描かれていることも多く、これはDanの示している意図とは異なることも理解できるでしょう*6。

ループの形について

この図はループになっています。これは、「リリース後にモニタリング(MONITOR)をテストして終わり」ではなく、次のプラン(PLAN)に繋げることの重要性を示していると言えるでしょう。

また、Danの記事内では以下のようにgif画像も用いながら記述しています*7。

しかし、図に欠けているものは何でしょうか…? 何かが足りない気がしてなりません…..
そうそう！それはもう明らかです！アイデアがないと計画を立てられませんよね？？

このモデルでは、計画を立てる前に行われるすべての作業については言及されていません。これについての私の考えを説明するために、爆発的なふわふわ雲の gif を示します。

アイデアを元に、計画を立てる前に行う作業のイメージ図

このgif画像では、アイデアが元にあり、そこからスリーアミーゴスやBDDといった活動を行って、ユーザーストーリーやマインドマップを作り、さらにコードやAPIなどに落とし込んでいくということを示していると理解しています。

つまり、モニタリングまで行ったことを元に、新たなアイデアが生まれ、そのアイデアがgif画像で示しているような活動を元に次のプランに繋がっていく形です。そうして、DevOpsがループしていくのです。

DevOpsのループ図とシフトレフトテスト/シフトライトテストの関係性

書籍『Agile Testing（邦訳：実践アジャイルテスト）』『More Agile Testing』『Agile Testing Condensed』の執筆者の1人であるJanet Gregoryは、Danの描いたDevOpsのループ図を元に、自身のブログ記事の中で「Continuous testing（継続的テスト）」として表現し直しました。

継続的テスト

この図を見ると分かりやすいのですが、デプロイをする前までのテスト活動（♾️の左側）をシフトレフトテスト、デプロイをした以降のテスト活動（♾️の右側）をシフトライトテストと表現することが多いです*8*9。

シフトレフトテストの具体的な活動は何か

上述では、デプロイをする前までの活動をシフトレフトテストと表現しました。それでは、いったいどのような活動なのでしょうか。

テスト駆動開発の適用

シフトレフトテストな活動で一番イメージがつきやすいのは、テスト駆動開発（以下、TDD）の適用でしょう。実装が終わった後だったテスト活動のタイミングを、実装をする前に行うように変えました。これもまさしくシフトレフトテストな活動といえます。

TDDのやり方について詳しくは、以下の動画をご覧ください。

www.youtube.com

実例マッピングの適用

ユーザーストーリーを書き終え、実装を始める前に行う活動である「実例マッピング」は、TDDよりもさらに前倒ししたシフトレフトテストな活動と言えるでしょう。

実例マッピングのやり方について詳しくは、以下の発表資料をご覧ください。

speakerdeck.com

レビューでの適用

テストで確認していた内容を、要求・要件レビューや設計レビューで確認することによってシフトレフトテストを実現することもできます。

これについて詳しくは、先日開催しましたJaSST Review'23の発表資料をご確認ください。セッション1の資料にて、以下の画像のような話を載せています。

レビューにおけるシフトレフトな活動の例

シフトライトテストの利点は何か

上述では、デプロイをした以降のテスト活動をシフトライトテストと表現しました。シフトレフトテストな活動に比べて、シフトライトテストな活動はあまり知られていません。そこで、なぜシフトライトテストを行うのかについて考えてみましょう。

シフトライトテストな活動を行う理由は主に2点あると私は考えています*10。

  1. 一般的なテスト活動（BUILDやINTEGRATE時点でのテスト）で解決するにはコストが高すぎるため
  2. 次の開発（PLAN）の参考にするため

シフトライトテストな活動を行う理由①：一般的なテスト活動で解決するにはコストが高すぎるため

一般的なテスト活動（BUILDやINTEGRATE時点でのテスト）で全てを明らかにしようとするとコストがかかりすぎるものが存在します。

例えばユーザビリティ観点です。ユーザビリティが良いかどうかについては、実際のユーザーの利用率を元に判断したい場合があります。理論的に良さを導き出すコストよりも実際にユーザーに使ってもらう方がコストが低い場合には、シフトライトテストとして任せるかもしれません*11。

なお、このようなものをシフトライトテストな活動にする際には、「この指標を用いて良さを判断する」とデプロイ前に計測内容を確定しておくことが大事です。とりあえずデプロイしてみて、その結果を後付けで考えるというのは得策ではありません。テスト結果はシフトライトテストな（デプロイ後に判明する）活動ですが、テストすべき指標の決定までシフトライトテストな活動にしないようにしましょう。

用いる指標の決定はシフトレフトの段階で行う

シフトライトテストな活動を行う理由②：次の開発の参考にするため

モニタリング結果などから次の開発に繋げる活動もシフトライトテストな活動と言えるでしょう。

この場合は、何か狙いを持っていなかったとしても、ユーザーがどのように使っているかを観察することで次に繋げられる場合があります。それは、「ループ図の解釈」の「ループの形について」で載せたgif画像のように、シフトライトテストな活動が次のアイデアに繋がり、それが次のシフトレフトな活動へと続いていくのです。

シフトライトテストな活動で見つけた気付きをアイデアとして次の開発に活かす

シフトライトテストの具体的な活動は何か（宣伝）

ここまででシフトライトテストな活動を行う理由について述べてきました。それでは、具体的にはどのような活動をすれば良いのでしょうか。 A/BテストやFeature flag(toggle)といったプラクティスは知られていますが、上述した「シフトライトテストな活動を行う理由」と紐づけて語られている事例はまだまだ多くありません。

まだ模索段階ではありますが、私が現在所属している10Xの開発チームではシフトライトテストな活動を行っています。そして、そこで実際に行った事例をRegional Scrum Gathering Tokyo (RSGT) 2024にて発表することになりました。

Regional Scrum Gathering Tokyo 2024 - できるだけ大きなアウトカムが得られるように、シフトレフトとシフトライトの両面から製品開発に取り組んだお話 | ConfEngine - Conference Platform

発表会場での聴講チケットは既に売り切れてしまいましたが、オンライン上からの聴講チケットはまだ販売しておりますので、ご興味のある方はお買い求めくださいませ！

2024.scrumgatheringtokyo.org

また、10X プロダクトアドベントカレンダー2023の6日目の記事で、こういちさんが具体的な活動の1つを紹介しています。こちらもご参照くださいませ！

note.com

おわりに（さらに宣伝）

今回はDevOpsのループ図とシフトレフトテスト/シフトライトテストについて述べてきました。

本記事の最後に書いた通り、10Xではシフトライトテストな活動も取り入れて、開発チーム一丸となって開発を進めています。私の所属している品質管理部では以下の職種で募集をしています。少しでも興味を持ってくれた方からのご応募をお待ちしております！

とりあえず話だけでも聞いてみたいという方がいればカジュアル面談もオープンにしていますので、こちらからどうぞ。

私とテストについて話したい場合はこちらからご応募くださいませ！

youtrust.jp

*1:アドベントカレンダーの前日の記事は、それぞれ以下の記事となります。

*2:もしかしたら、もっと昔に発端があるのかもしれませんが、私が調査した限りでは見つけることができませんでした。

12/5追記

辰巳さんより、発端の候補として2013年の記事があるそうです。辰巳さんありがとうございました！

www.appdynamics.com

*3:日本語訳の記事はこちら

*4:ここでいう、「DevOpsのループ図」とは、

  • ♾️の形をしている
  • 開発ライフサイクルの最初が左上に位置している
  • 起点（左上）から反時計回りで描かれ、右半分は時計回りで描かれている

を全て満たしているものとします

*5:細かいことを言うと、WEB上に公開されているものの中では「Continuous Testing in DevOps…」が発端でありますが、この記事を書く前からカンファレンスで同様のモデルを言及していたようです。

*6:ここではあくまでもDanの描いたループ図とは意図が異なることを示しただけであり、別の意図でループ図を使っていた場合には成り立つとも思っています。

*7:ちなみに、翻訳記事ではなぜかこのgif画像がカットされています。Danが主張したかった根幹の1つだと思うので、個人的には記載してほしいなぁ…と感じています。

*8:元々の単語の意味を考えると、「シフトレフト」とは、とある活動をタイムライン上の早い段階に前倒しすることを示します。しかし、一般的にテスト活動はビルド(BUILD)や統合(INTEGRATE)の際に行う活動と認知されているため、それを前倒ししている♾️の左側部分は総じてシフトレフトしていると言えるでしょう。シフトレフトテストに関して詳しくは、にしさんの発表資料を参考にすると良いです。

*9:今回は「継続的テスト」の図を本文で紹介しましたが、シフトレフト/シフトライトに対する誤解が生まれていることを感じてか、最近ではJanetは別の図を用いて紹介しているようです。詳しくは「Testing From A Holistic Point Of View」の記事（邦訳記事：「【翻訳】ホリスティック・テスト：プロセス全体からテストを捉えなおす（Testing From A Holistic Point Of View）」）をご覧ください。

*10:ちなみに、よくある誤解としてこんな話を耳にしました。

これに対する反論として本記事を書いている面もあります。

*11:「ユーザビリティ観点全てをシフトライトテストな活動で判断しろ」と言いたいわけではありません