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

2022年4月11日

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

日本ではアジャイル開発の入門書として話題となった書籍「アジャイルサムライ」(オーム社,2011)や「初めての自動テスト」(オライリー,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も他社と同様に、テストにおける成熟のレベルをたどってきました。

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

fig

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

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

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

fig

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

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

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

fig

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

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

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

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

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

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

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

fig

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

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

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

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

fig

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

fig

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

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

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

fig

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

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

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

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

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

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

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

fig

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

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

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

fig

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

fig

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

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

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

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

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

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

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

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

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

fig

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

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

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

fig

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

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

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

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

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

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

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

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

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

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

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

fig

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

どうしたら技術志向の会社になれるか?

ここまでの説明は分かったけれど、自分の会社はどうやったらSpotifyや技術志向の会社になれるのだろうかと、よく聞かれます。

これに関しては私も考えていて、こう答えています。

Spotifyが他のどの会社よりも一番うまくやっている優れたところは、トラストとエンパワーです。彼らは従業員を信頼して彼らに権限委譲をする。彼らに自分たちで自主的にやらせているのです。

fig

例えば計画でここがうまくいってない、というところがあれば、スクワッドで計画を作り直しなさい、と言うわけです。プライオリティも変えてもいい。スクワッドで自分たちの優先順位を決めることができる。

もしも、もっと速いコンピュータが欲しいんだったら、それを買ってもいい。

スクワッドが新しいことをやりたいと考えたら、業務を2日ぐらい休んで集まり、次の数カ月間のテーマを決めて戻ってきてもいい。

この大事な点は、こうすると従業員は言い訳をできないということなんです。

従業員としてはいろいろ言い訳をすることは簡単ですよね。プロジェクトがうまくいかなかったのは時間がないから、提案が採用されなかったから、とか。

でも、Spotifyにおいてはこういった言い訳はもう全部なくしてしまいます。従業員が成功することだけを助けるということなんです。

すると、全員がとにかく成功だけを目指すようになります。計画も自分たちで作った優先順位も自分たちで決めた、いいマシンも買った、だから成功させるのは自分の責任なんです。

従業員に対して、本当に信頼感を抱いて、彼らに自律性を持たせて実行してもらう、ということです。

Spotifyの開発現場

私がSpotifyにいた頃に撮った写真を何枚か紹介しましょう。

これはプレステ版Spotifyのローンチですね。Spotifyがソニーのプレステで今から走るぞという日です。PS3、PS4のセットアップがもう済んでます。

fig

グローバルのダッシュボードです。右から段々とSpotifyがオンになるところをみんなで見ていきます。

fig

これは私達にとって重要なことでした。Spotifyにおいて当時これがナンバーワンの優先順位だったからです。絶対うまく行きたいとみんな思ってたわけです。

みんなで一緒になって、もう本当にロケット打ち上げのミッションコントロール状態でした。

fig

この後スイッチを入れるということでみんな緊張していました。そして大成功を収めていきました。

この写真はスクワッドの作業エリアです。このスクワッドは「BASES」という名前でした。Spotifyに使いやすい拡張可能なストレージを提供する、というミッションです。

fig

Spotifyはミーティングルームを使い終わったら綺麗にしてほしいと考えていました。

そこで、この4人の中の1人の誰かでない限りは、自分の仕事のあとは綺麗に清掃してねというポスターが貼ってありました。これはスウェーデンで最も人気のある音楽グループ、ABBAの写真です。

fig

これはHack Weekの例です。非常に大きな会場を提供します。チームの生産性を上げると思うことに取り組むことができるスペースです。

fig

そして1週間後、パーティーをやって、そしてデモをします。自分たちが何に取り組んで、何をやったのかを示していくわけです。質疑応答もあります。

それを通して他の人たちがインスピレーションを得て、また別の作業ができるわけです。

fig

Googleが最初にこれをやったんだと思いますが、一週間に1回、会社のタウンホールミーティング(対話集会)をやります。会社のリーダーたちが集まって、従業員からの質問に答えるというセッションです。

fig

この写真は、Spotify CEOのダニエルと人事部長のカトリンです。彼らが従業員のあらゆる質問に答えていきます。なぜ特定のディールを特定のパートナーとやったのか、アメリカに比べてスウェーデンがより良い育児給付を持っていることについてとか、いろいろな質問に答えていきます。

パート2はここまで、私の話は以上です。何かお役に立てれば非常に嬉しいです。

ご清聴ありがとうございました。

関連記事

あわせて読みたい

CI/CD DevOps アジャイル開発 ソフトウェアテスト・品質




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本