「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？そしてソフトウェアテスト自動化を進化させる方法について（後編）。JaSST'22 Tokyo基調講演

今回は「「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？そしてソフトウェアテスト自動化を進化させる方法について（後編）。JaSST'22 Tokyo基調講演」についてご紹介します。

関連ワード（丸一日、大事、製品等）についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

Jonathan Rasmusson（ジョナサン・ラスムッソン）氏はアジャイル開発における著名人の一人であり、さまざまな先進的ソフトウェア企業において開発やテストに携わってきました。

日本ではアジャイル開発の入門書として話題となった書籍「アジャイルサムライ」（オーム社,2017）や「初めての自動テスト」（オライリー,2021）、「ユニコーン企業のひみつ」（オライリー,2017）の著者としても有名です。

そのラスムッソン氏が2022年3月10日と11日の2日間、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2022 東京」（JaSST’22 Tokyo）の基調講演に登壇しました。

この記事では、その基調講演の内容を紹介していきましょう。この記事では、その基調講演の内容を紹介していきましょう。この記事は、前編、中編、後編の3つに分かれています。いまお読みの記事は後編です。

企業ごとにテストのアプローチは異なる

ここからはパート2です。テストの話を詳しくしていきましょう。

テストというのは本当に興味深いトピックだと私は思っています。

業界の中ではどうやってテストをするかについていろんな議論がありますし、テック企業ごとにアプローチも違います。

Facebookは、私たちにはテストは必要ない、QA部門も必要ないし、テストエンジニアも必要ないと言いました。

マイクロソフトは、WindowsのOSを1日でビルドする、ワンデイビルドシステムを初めて構築しました。

Googleは、テストエンジニアというコンセプトを作り出しました。

NetflixはChaos Monkeyという革新的な方法を作り出しました。サーバをわざと落として、それを自分たちが対応できるかを試したのです。

Spotifyも、テストの手法を持っていました。ここではSpotifyにおけるテストのジャーニーを見てみたいと思います。

テストにおける成熟のレベルをたどる

Spotifyも他社と同様に、テストにおける成熟のレベルをたどってきました。

まず最初はマニュアルでのテストを行い、それを自動化し、やがて先進的な成熟したものになっていきました。

Spotifyはスウェーデンの小さなスタートアップでした。そして皆さんと同じように、マニュアルテストという段階から始めました。

Spotifyの最初の製品はWebブラウザで音楽を再生するものでした。そこで、本当に音楽を流せるのか、プレイリストを作れるのか、製品出荷前に全てをマニュアルテストする必要がありました。

最初の数年はマニュアルテストを行っていました。しかしこれは時間もかかりますし、ミスもたくさん発生します。テスターの人数も必要です。

そのため、もっといい方法があるはずだと考えました。そこでテストの自動化に取り組み始めたわけです。

そこで、最も簡単なところからテストを自動化しました。それはユーザーインターフェイスのテストです。

Spotifyを起動する、ログインをする、再生などさまざまな操作をする、といったUIテストのスクリプトを書いて自動化していきました。これは非常に大きなレベルアップになり、大きな価値をもたらしました。

しかし会社が大きくなり製品の機能などが増えるにつれて、UIテストにありがちな問題が発生しました。テストにかかる時間がどんどん長くなっていったのです。

最初は全てのテストが30分で終わったのに、それが3時間になり、7時間になり、そして丸一日になります。

さらに実行結果が成功したり失敗したりと不安定なテスト、これをFlaky Test（フレイキーテスト）と言いますが、そうしたものも発生します。

テストのメンテナンスも課題です。UIテストというのはユーザーインターフェースと結びついていますので、ボタンの位置や種類などユーザーインターフェースを変更すると同時にUIテストをメンテナンスしなければ、テストが失敗してしまいます。

UIテストは素晴らしいですし、助けにもなりますが、Spotifyとしては、さらにより良いテストの手法を探さなければならなくなりました。

UIテストは控えめに、統合テスト、単体テストを活用する

そこで伝統的なテストピラミッドがこちらです。

少数のUIテストが一番上にあり、その下に統合テストがあり、一番下には多数の単体テストがあるのです。

時間のかかるUIテストは控えめにし、統合テストと単体テストでUIテストの不足を補うのです。

これを実現するには、テスト部門だけでなく開発部門やプログラマの支援も必要だとSpotifyは気づきました。

私はこの段階でテクニカルコーチとしてSpotifyに入社し、プログラマやテスターがより優れた自動テストを実現できるようにトレーニングの支援をしました。

テスター、デザイナー、プログラマなどを集めて、2日から3日のワークショップでテストにおける実際の問題を取り上げ、どうしたらそのテストが自動化できるかを学んでいきました。

こうしたことを通してSpotifyのテスト文化を作り上げ、多くの人がテストの自動化に関わるようになってきました。

通常の業務時間では対応できない課題にも取り組む

Spotifyでは会社レベルでこのテスト自動化の文化を強化していきました。オフィスにこういったサインを掲げたのです。

「つまずいてますか？でしたらFix It Week（修正強化週間）で対応しましょう」というサインです。

Fix It WeekはHack Weekとも呼ばれています。

それはチームに許可を与えて1週間ぐらい業務を止め、生産性が高まるようなことに何でも取り組める1週間にするわけです。

いろいろなテストをやり、あるいはビルドを改善する機会となります。Spotifyはこういった方法で、通常の業務時間内では対応できないような課題にも取り組む時間を与えたわけです。

テスト自動化をさらに推し進めるためにしたこと

こうしてSpotifyは成長し、そして成功も収め、スウェーデンだけではなくアメリカ、カナダ、ヨーロッパ、そして日本など多くの国で使われるようになりました。

するとさらにテストしなければならないことが増えていきます。カーステレオ、スマートスピーカー、ゲームマシン、Webブラウザ、iPhone、Androidなど、Spotifyが対応するプラットフォームでテストをしなければなりません。

Spotifyのテストは進捗しているけれど、もっと上のレベルに行かなければならないと気づいたわけです。

それで、いわゆる「パンダ」と呼ばれているスクワッドを作りました。パンダのミッションは、Spotifyのテスト自動化文化を改善する、というものです。

Spotifyのチーム全てが継続的デリバリーを実現し、反復的な作業をする中で、ソフトウェアの品質に確信を持ってデリバリーできるようにする。そうした成熟したテストを一連の自動化によって実現する、というのがパンダの目標でした。

さらに社内の認証プロセスも作っていきました。この認証プロセスを通して、テストの自動化が進歩していることを示すためです。

継続的なビルドが認証の「レベル1」です。チームがレベル1を達成するためには、認証プロセスにおいて継続的なビルドが実現できていることを実証しなければなりません。

「レベル2」は、レベル1の継続的なビルドに加えてソフトウェアが機能するということを示すための自動化されたテストがあることの実証が必要となります。

「レベル3」は十分なテストカバレッジがあるのか、十分なテストができているかどうかを示します。

「レベル4」はビルドのスピードです。ビルドシステムのボトルネックに対応し、より大規模なテストに対応し、テストを信頼できる形で迅速にできるかどうか。

「レベル5」が一番高い認証のレベルですけれども、外部のチームがリポジトリに作業内容をコミットしてもらえるということです。

つまり、テストシステムに信頼を持っているので他のチームにコミットしてもらえる。そしてプロジェクトにソフトウェアを貢献してもらえる。これが一番高いレベルです。

レベルが上がると、そのチームはTシャツやバッジをもらえます。すると社内で自慢できるのです。

テスターにはいろんな種類や役割がある

続いてテスターの役割について。テスターといっても一種類というわけではなくて、いろんなタイプの役割を持ったテスターがSpotifyにはいました。

まず、マニュアルテストをやる人たち。

私がSpotifyでプレイステーション対応のプロジェクトをしていたとき、信じられないほど探索的なテスターたちがいました。

Spotifyの新しいビルドをプレステで実行し、スキップボタンを50回ぐらいものすごい速さで押して、さらに早送りや早戻し、サッカーゲームをやりつつSpotifyを裏でクラッシュさせてみるとか、マニュアルテストが本当に上手い人たちです。

オートメーションのエンジニアという人たちもいます。彼らはスクワッドが作っているソフトウェアのテストをするためにスクリプトを書く人たち。

それからテストメンターと呼ばれるコンサルタント。

彼らはいろんな人たちのところに行って、テスト自動化のプラクティスを見せたり、コンサルタントとしていろいろ相談にのってあげています。

APIテスターもいます。そういった人たちはひたすらHTTPのエンドポイントだけを見ます。

リクエストを出してJSONのレスポンスが返ってくるかどうかを、ひたすらWebのエンドポイントで起こってることを確かめます。

プラットフォームテスターは、生産性スクワッドと一緒にビルドとテスト自動化がシームレスに繋がり、簡単に使いこなすことができるかを確認する人たち。

デベロッパーとテスターがペアで課題を解決する

もちろん、一つの部隊だけで全てができるわけではありません。Spotifyとしては、デベロッパーが集まって、ペアで問題を解決するということを推奨しています。

デベロッパーがテスターの人とペアになって、改善していくにはどうしたらいいのということを2人で進める、ということをやっています。

Spotifyで特に私がクールだなと思ってるのは、グローバルチェックリストがあるということです。

私はiOSエンジニアでもあり、SpotifyのiPhone用の新しいバージョンをリリースする前に、世界中のチームそれぞれが必ずチェックしなければならないチェックリストを作りました。

例えば、ストックホルムがログインをチェックする、ニューヨークがペイメントをチェックする、そしてヨーテボリ（注：Spotifyのオフィスがあるスウェーデンの街）は音楽をチェックし、サンフランシスコはFacebookなどとのインテグレーションがうまくいくということを必ずチェックする、というチェッククリストです。