アジャイル開発にテスト自動化が必要な理由と導入のポイント解説

アジャイルコーチ・テスト自動化コンサルティングとして活動している藤原と申します。楽天、メルカリを経て現在はフリーランスとして企業様を支援させていただいています。 私が最近コンサルタントとしてお受けする案件では、テスト自動化案件が増えてきています。

その背景には開発の高速化があるのですが、実際のテスト自動化の導入は日本ではやや遅れ気味です。

そこで今回はテスト自動化に必要な要素や流れは何なのか、そのほかおすすめツールなどご紹介しますので、ぜひ参考にしてください。

なぜ、今テスト自動化が必要なのか?

技術の進化とともにアジャイル開発が主流になりつつある

会社によってそれぞれやり方は違いますが、現在は環境的にも技術的にも進化していて、基本的に開発スピードが早まってきています。

例えば今まではインフラはインフラエンジニアが自分たちでコードを書いて構築していましたが、今はAWSやGCPなどのクラウドサービスによって、項目を選ぶだけで環境整備ができるようになってきています。いわゆるKubernetesのようなコンテナオーケストレーションツールやコンテナ技術であるDockerについても同様ですね。CI/CDを提要するサービスも増えてきたため、どんどん普及しています。 これまで人力で行なっていた作業を外部サービスで自動化できるということは、自分たちはより自分たちにしかやれないことに集中できるということです。お客さんに安定した価値提供ができ、売上につなげる取り組みがしやすくなっています。

その中ではいかに素早く開発サイクルを回すのかが求められるようにもなっています。さらに、幸いソフトウェア開発は作り直しや修正が可能だという点も相まって、少しずつ小さく積み上げる、変化に強いアジャイル開発が当たり前になりつつあるのかなと思います。

テスト領域も徐々に自動化の流れにシフトしている傾向

ですが、残念ながらテストという分野は飛躍的な技術的進化がまだありません。

開発スピードが速くなるということはそれだけプロダクトもたくさん作れるということなので、結果としてテスト回数も増えるのですが、基本的にはマンパワーで運用している環境が多いのではないでしょうか?どんなに開発の生産性が高まるツールが登場しても、それをテストするのが人、さらにマンパワーでは、テストがボトルネックになりがちです。

それでも最近は徐々に海外のサービスが進化してきたり、国内でもQA自動化プラットフォーム「Autify」のようなスタートアップ企業のサービスが登場したりして、テストのハードル自体は下がってきています。

市場も徐々に自動化の方向にシフトしようとしているわけです。

アジャイルテスティングが登場したものの現在は試行錯誤の段階

こういった文脈の中で登場したのがアジャイルテスティングです。実例も徐々に増えてはいますが、まだまだ「どう実現したらいいのだろう?」という段階で止まっているお客様が多いです。というのも、アジャイル開発におけるQAエンジニアやテストエンジニアの役割にはまだまだ試行錯誤すべき部分が多く、ベストな正解を決めにくいんです。

ただ、私が海外のカンファレンスを回っていて感じたのは、テスト領域のエンジニアは非常にチャレンジ精神が旺盛だということです。海外だとチャレンジしないとクビになってしまうからかもしれません。

海外ではいかにテストを自動化するか、あるいはキャリアチェンジをするのかといったことに積極的なのですが、日本はそこまで厳しくないので、温度差があります。

アジャイル開発やDevOpsにおける継続的テストのあり方

日本におけるテスト自動化はまだまだこれからの領域ということをここまでお伝えしました。

ただ、そうは言っても実際にアジャイルで継続的に開発をするとしたら「最後にまとめてテストをする」という手法がボトルネックになってしまうので、テストは継続的に実施しなければなりません。

それを端的に示したのが以下の図です。

DevOpsを支える4つの継続的アクティビティ

図:DevOpsを支える4つの継続的アクティビティ (引用元:テスト自動化の最前線

こちらの図は作ったシステムをJenkinsに代表されるようなインテグレーションツールを用いてコードがサブミットされた瞬間にマージしてテストして、デリバリー、リリース、そしてモニタリングするというサイクルを回さなければならない、ということを示しています。

今までは考えて作ってリリースするだけのV字モデルと言われるものだったところから、どんどん改善を繰り返していくサイクルにしなければいけないということですね。ですから全ての単語に「Continuous(継続的な)」とついています。

また、以下の図は、Agile 2018 ConferenceでEbay社のテストエンジニアによって紹介されたDevOpsにおけるテストの在り方です。

コーディング、マージ、ビルド、リリース、デプロイ、オペレーション(運用)、モニタリング、そのアイディアをもとにプランニングするというサイクルが示されています。

“WE TEST HERE”と書かれているとおり、プロセスの中では常にテストが必要とされるという点からも、継続的なテスト活動が必要であることがわかります。

図:Continuous Testing in DevOps by Dan Ashby

こうした継続的にテストを実施するには、手でやっているのでは間に合いません。だからこそ自動化せざるを得ない状況なのです。あるいは資金があるのであれば、人を増やすくらいしかできません。

実際にテスト自動化を導入するには?

企業がテスト自動化導入において直面しがちな壁

私がメルカリにいた際は、実はあまり上手くテスト自動化できませんでした。自分の部署のQAエンジニアが現場でテスト自動化を試行錯誤していたのですが、なかなか現場に時間がなかったりして実装までに至らなかったんです。その壁を超えるのが、自動化導入の難しい点ですね。

この壁を乗り越えるには、まず自分たちの活動をどんどん共有することです。slackでテストが書けたことをチャンネルで流すなど、社内の自動化に対する意識を一緒に作り上げていくことができれば上手くいくかもしれません。

私自身も他社事例をよく見ていますが、上手くいっている企業は大体それができています。

テスト自動化のための自動テスト基盤構築にはツールがおすすめ

実際にテスト自動化をするためには、基盤を構築しなければいけません。

その考え方を示したのが以下の図です。

テスト自動化のための自動テスト基盤

図:テスト自動化のための自動テスト基盤 (引用元:テスト自動化の最前線

例えばスマホアプリを作ったらビルドしてPlayストアなどにアップするわけですが、ここを自動化するためには、ログインが必要ならログイン用のユーザーデータを作るといった仕組みが必要です。それを基にテストを実行し、正誤を確認しなければなりません。

こういった取り組みをいろいろと進めていくと、図にあるアプリ自動ビルド、テストデータ作成基盤、テスト実行基盤、テスト結果データ基盤の一連の流れを遂行するためのコードがテストコードとして残ります。

上記の事例ではCircleCIやテスト用APIなどさまざまなツールを作ってビルドパイプラインを構築していますが、その流れそのものも自動化したい、ということです。ビルドして、データ作成をして、という個々の作業をいちいち行うのも面倒ですから、テストコードによって一連の流れを実行することができれば、テスト自動化の環境が完成します。

もちろんこれらを全て作るのは大変なので、最近は上記を実行してくれるWebサービスツールの導入支援をよく行なっています。

なかなか自社で基盤構築をする余力がある企業は少ないと思うので、最初は便利なサービスを使った上で、必要があれば自社で内製する形をおすすめします。

テスト自動化導入の際に押さえておきたいポイント

QAエンジニアにテスト自動化を推進してもらうのは難しい

メルカリに所属していた頃は「全員自動化」を合言葉として、前述で軽く触れたとおりQAエンジニアも含めてテスト自動化に取り組んでいました。ただ、手作業が基本のQAエンジニアがプログラミングを覚えるには非常に時間がかかります。「彼らがコーディングを覚えるまで待てるか?」は重要な意思決定のポイントとなるはずです。

さらに、「全員自動化」に取り組む体力がある企業もさほど多いわけではありませんから、人材育成という観点では、特定のエンジニアにテストや品質のことを覚えてもらうほうが手っ取り早いかもしれません。

その上で、先ほど言ったようなWebツールを使ったり、少しずつ自動化をするというのが現実的な手法です。あるいは業務委託でコードを書ける人を採用し、その人を中心にQA活動を推進するのも良い方法だと思います。

つまり、自分たちの状況やプロダクトや組織の規模に合わせた作戦が必要だということです。

実は自動化で「コスト削減」はできない

よく自動化で言われるメリットにコスト削減があるのですが、実は自動化しても直接的なコスト削減にはなりません。この点については、GREEさんの事例が面白いと思います。2019年のCEDECで1年間継続したテスト自動化の取り組みに関する発表をされているのですが、「局所的なものに留まり、目に見えて大きな成果は出せていない」と発表されているように、人力以上の効果は出ず、コスト削減にも至らなかったとしています。これは正直ですごく良い発表だと思いました。

というのも、テスト自動化は実はROIを出しにくいからです。もちろん自動化したコストに対してかかった時間、発見したバグの数などは算出できるのですが、これらは直接的なコスト削減にはつながりません。

例えばサイトテストを1日1回、1人が担当していたとして、自動化によってテストを1日10回できるようになっても1回で十分だとしたら意味は無いわけです。簡単に言えば「自動化を実行すればするほど儲かる」という話にはなりにくい。自動化を流すことそのものにメリットがありますが、自動化でエラーが起きたら当然確認が必要ですし、その分コストはかかってしまいます。

ずっと利用していても安定していて壊れたりもしないという環境にまで辿り着いて、やっとコスト的なメリットが出てきます。そこが導入時に間違いやすい部分です。

アジャイルは「バグを作らない」「自動化をしよう」「良いものを作ろう」という文化醸成が最終的な到達地点になるのですが、そこがわかっていないと「コスト削減できるからRPAを入れよう」というような判断をしてしまいがち。RPAはいい方法かもしれませんが、本来は「そもそも無駄な作業をなくせないか?」を考えるべきです。手段は最後でいい。

ですからテスト自動化を導入する際は自動化を行う目的をはっきり定義しておくことが必要です。目的が無い限り、「自動化すればハッピー」ということにはならないからです。

テスト自動化のためのおすすめツール

最後に自動化導入の際に私がおすすめするツールをご紹介します。

・ mabl ・ Autify

mablは海外のテスティングツールですが、最近導入事例がどんどん増えてきています。

Autifyは元DeNAの近澤さんが起業した話題の会社です。どちらもプログラミングスキルが無い人でも使えるプラットフォームとして売り出されています。日本でテスト自動化ソリューションと言えば今はAutifyくらいですから、テスト自動化の流れをリードしていってくれるのをとても期待しています。

藤原 大 アジャイルコーチ、テスト自動化コンサルティング 藤原 大 さん
楽天株式会社、株式会社メルカリを経て現在はフリーランスのアジャイルコーチ、エンジニアリングマネージャとして活動。 「リーン開発の現場」の翻訳者でもありアジャイルな創造的、継続的、持続的なソフトウェア開発の実現に向けて奮闘中。 週末に娘と息子とお昼寝しながら世界のビーチや離島を旅する夢を見るのが安らぎ。
LINEでフリーランスの案件情報や最新Tipsを受け取る

FLEXYとはABOUT FLEXY

『FLEXY』はエンジニア・デザイナー・CTO・技術顧問を中心に
週1~5日のさまざまな案件を紹介するサービスです