[翻訳] DevOpsにおける継続的テストとは何か？

Dan Ashby氏による「Continuous Testing in DevOps…」を、本人の了承を頂いてざっくり意訳させていただいたきました。彼のアイデアを知ったのはAgile 2019というカンファレンスでしたが（DanさんはTesting系セッションのオーナーだった）、記事は2016年のもので、今になっても全然色褪せない本質をついた内容です。彼の書いた手書きの図が、さまざまな場所で引用されているのをみても、彼の視点がとても高いレベルにあるのだとおもいます。

Continuous Testing in DevOps…

最近、いくつかのカンファレンスに参加しました。テストやアジャイル開発や開発に関係するイベントです。新しい人達に出会えたり、色んな人の物語を聞けるた点では全体的にとてもよいイベントだったと思いますが、いくつかの講演はなかなか辛いものでした。その理由は、自動化、アジャイル開発、BDD、TDDなどに対する誤解があったからだと思います。

よく耳にしたテーマは「DevOps」でした。多くの人がこのテーマについて話していました。きっと大きなトピックですよね！ しかし、たくさんの人達が「DevOpsの素晴らしい世界観のどこにテストが入りこむのか？」で非常に混乱しているように見えました。「DevOpsには自動化だけが必要だ」という人もいましたが、説明を求めるとその説明や議論はずさんなものでした。また、一部の人たちは、DevOpsにおけるテストをどうするか？考えることすら露骨に拒否しているようでした。

ある人は「テストは必要ない」と言っていました。なぜなら、スライドに登場するDevOpsというモデルは、テストについてまったく触れられていなかったからです。

手書きでそのDevOpsモデルを書いてみるとこんな感じです。

このモデルはカンファレンスの至るところで語られていました（あるいはとても似たようなものが紹介されていたはずです）。この図をみればわかると思いますが、テストについて言及されていないこの図において、どこでテストをするのが適切なのか？ 誰もが苦労していたのです。

僕の考えでは、このモデルのすべてのポイントにおいてテストをするのが適切だと考えています。その意味を説明するために、図をこのようにアップデートしてよりブレークダウンしていきましょう。

「計画（Plan）」はテストできます。DevOpsの世界において、計画が「デザイン（Design）」を意味していても、テストは可能です。ソフトウェアにおけるデザインのテストとは、本質的に探索的テストになるはずで、リスクベースで考えられたものになるでしょう。我々は調査を集中的に行えるように、リスクを経験的に利用できるはずです。質問を通じて探索する方法は、より多くの情報を発見するのに役立ちます。その情報はデザイン（またはPlan)をリファクタリングしてより良いものにしてくれます。

「ブランチ（Branch）」もテスト可能です。branch（枝）とはいっても物理的な木のことじゃないですよ。たしかにテスト対象としてはなかなかチャレンジですが・・・。ここでいうブランチは独立した開発ブランチを指しています。開発ブランチはテスト可能ですし、それぞれの環境のブランチ戦略もテスト可能です。たとえばブランチ戦略に関する会話に耳を傾け、質問したりアイデアを調べたりリファクタリングするならば、それは立派なテストです。

もちろん「コード（Code）」も調査可能です！ 計画づくりの一部として予想する動作を議論し、確定した動作を全体にコードをチェックします。コードレビューはどうでしょう。ミスを発見するだけでなく、よいコードを見つけたり、よりよいコードにできそうな部分を調べるために探索的テストは非常に優れた方法です。ユニットチェックを見てみましょう。コードレベルで自動化された優れたチェック方法は、コードが期待通りに動作していことを確認できます。たとえばあなたが開発者としてコードを書いているならば、テスターとペアになって作業するのもいいでしょう。きっとテスターはクールなテストのアイデアや、違った視点のリスク、視点、価値などを織り交ぜた知識を共有し、コーディングの間、あなたを正しい方向へ導いてくれるはずです（うん！かっこいい！）。

「マージ（Merges）」もテストや確認が必要です！ 結合ごと（および様々なレベルでの統合）の中に隠れたリスクや、マージによるクラッシュにも注意が必要です！

「ビルド（Build）」も確実にテスト可能です！ ビルドプロセスをテストして拡張してはどうでしょう？ その上で、環境ごとにプロダクトを起動し、探索的テストを実施してみてはどうでしょう？ 探索的テスト（Exploratory testing：記事では ETと略している）は最も効果的なアプローチであり、認識された品質レベルを確認するのにとても役立ちます。

「リリース（Release）」時にはリリース作業だけでなく、リリースプロセスも確実にテストできます。「デプロイ（Deploy）」もテストできます（テスト環境や本番環境のデプロイなど）。一部の人達は「サニティ（Sanity）」や「スモーク（Smoke ）」テスト（チェック）を好んでいるようです。あなたの心の声に従いましょう！ テストやテストデータがユーザに影響を与えないことを確認してください。

プロダクトがリリースされると、間違いなくユーザは新しく追加された画面をみて、「これを使ったらどうなるのかな？」といった好奇心を満たすようになるでしょう。

そして最後に「Monitoring（モニタリング）」がはじまります・・・が、最後と言いましたがDevOpsには最後がありませんのでご注意を。モニタリングはとてもパワフルです。プロダクトによって何が伝わり何が伝わってないかがよくわかります。これはまさにテストできる部分です！ こちらの意図がユーザに正しく伝わっているでしょうか？ 我々が求める有益な情報たちがモニタリングによって自動的に送られているでしょうか？ 届いた情報をもとに探求しましょう！ 情報に目を光らせて、それがどういう意味なのかを考えましょう。

さて、図には何かが欠けているように思いませんか？ なにか足りないものがあるようにおもいますね・・・そうです！ 今なら気がつくはず！ それは「アイデア（Idea）」です。アイデアがないと計画を立てられませんよね？

このモデルでは計画の前に必要な作業がぜんぜん言及されていません。この点について僕なりの考えを説明するのに役立つ画像を紹介します。

アイデアのテストは、まるでこのモデルのように、乗りたいボートに完全に乗り遅れてしまうのと同じぐらい残念なことです。なぜならば、アイデアのテストは不可欠だからです。愛でのテストは、不明確な情報を調査したり、より強固なアイデアにするためにリファクタリングすることをさしています。これによって、たくさんの間違った中間成果物ができるのを避けたり、リファクタリングによって正しく整えていったりできます。さらに、設計や計画、開発、テスト、確認・・・といった様々な活動の成果物として活用できます。こういった活動はたくさんの有用なアイデアを生み出します。高品質なソフトウェアを実現するために！

このブログに皆さんが興味を持っていただき、DevOpsの世界においてテストをどのように適用させるか？という、難解なパズルを解決する第一歩になることを祈っています。

原文： Continuous Testing in DevOps…

Thank you for giving great article, Dan!