2024.06.13
ソフトウェア開発において、品質を維持しつつ、プロダクトのリリースサイクルを早く行うにはテスト自動化が必須です。開発したものを常にテストする仕組みが、デグレード等の不具合を高速に検知し、テスト期間を短縮し、結果として新しい機能をはやく世の中に出すことができます。
ただ、テスト自動化を初めて取り組む人たちにとっては、上手く構築できるかどうか不安が大きいのではないでしょうか？また、一度テスト自動化をやったことがあるが、上手く運用することができずに途中で諦めた人もいるのではないでしょうか？
そこで今回は、自身も「テスト自動化で失敗し、途中であきらめた経験がある、その中で学んだことを活かしながらテスト自動化をブラッシュアップし、正常運用までもっていった」と語るバルテス・ホールディングス株式会社の江村 禎昭 氏に、テスト自動化で失敗してきた過去と学んだことについてお伺いしました。
今回話を伺ったプロ
- 江村 禎昭
バルテスホールディングス株式会社 ソリューション事業推進部 主席研究員
石川県金沢市生まれ。趣味は富士山登山、ほぼフルマラソン。20年以上インターネットサービス会社に勤め、アプリケーションエンジニア、プロダクトマネージャ、テストエンジニアと様々なロールを担当してきた。バルテスホールディングスに入社後、テスト自動化導入のコンサルティングや、テスト自動化ツールであるT-DASHの導入支援を担当する。
Jasst Hokkaido, Tohoku, Tokyo 等で講演
1．初めてのUIテスト自動化をやって失敗した
――テスト自動化を最初に始めたきっかけや、どのように進めたかについて教えてください。
私がアプリケーションエンジニアだった際、所属していた部全体でテスト自動化を促進しようという方針が打ち出され、私のグループでもUIのテスト自動化を始めることになったのがきっかけです。
テスト自動化のKPIが設定され、「カバレッジ〇％以上」が目標となり、短い期間で実施することに。その時は、エンジニアを1名アサインしてテスト自動化に着手しました。テスト自動化のフレームワーク選定も、そのエンジニアに任せていました。
当時、UIのテスト自動化で流行りであった、Selenium + Ruby + Capybara + Cucumber の構成を用いて行いました。結果的に２～３か月でUIのテスト自動化を構築することができ、カバレッジ目標も達成しました。
――初めてのテスト自動化は成功に思えますが、その後はどうなったのでしょうか。
「めでたし、めでたし」で終わるかと思いきや、問題は後からやってきました。まず、このテスト自動化をどのように活用していくのか、が決まっていなかったのです。
当初は、「リリース前にそのテストを流せばいいか」と思っていました。しかし、テストを流す仕組み化がされていなかったこと、QAが終わってからテストを流すことにあまり意味がなかったことがあり、使う場面がありませんでした。
また、テスト自動化の人依存も問題でした。１名のエンジニアが構築しましたが、アーキテクチャやメンテナンスに関わるドキュメントを残さずいなくなったため、誰もメンテナンスをすることができなくなってしまったのです。
アプリケーションの仕様を変更すれば、当然テスト自動化のスクリプトの修正が発生します。しかし、その都度メンテナンスすることを想定しておらず、誰も修正することができなくなってしまいました。
そして３か月後、構築されたテスト自動化は封印することになりました。
――構築後に問題が見つかったのですね。初めての失敗で学んだことはありますか？
この最初のUIテスト自動化で学んだことは以下の３つです。
- テスト自動化の目的を明確にする。（リグレッションで早く不具合を検出させる 等）
- 誰がテスト自動化を使うのかを明確にする。（属人的にならないように、かつ使う人のスキルレベル）
- どのようにテスト自動化を使うのかを明確にする。（毎日テスト実施する、仕様変更の頻度はどれくらいか 等）
2．QA組織を立ち上げ、テスト自動化運用の再挑戦
――次の挑戦はどのように進めたのでしょうか。
アプリケーションエンジニアの後、部でQA組織を立ち上げることになりました。当然、テスト自動化も検討し、導入することに決まりました。
前回の失敗を受けて、今回はテスト自動化を導入するにあたって３つのステップで進めることにしました。
まずは「テスト自動化の目的設定」です。様々な目的がありますが、その中で重要視する目的として、一定の品質を保つこと（リグレッションテスト）と、手動テストの軽減（コスト削減）を選びました。
続いて、「運用設計」を行いました。テスト自動化の実行頻度を毎日１回とし、すべてのテスト実行が６時間以内に終了する事（夜中実施して、朝出社時に結果が出ていることが理想）、そしてメトリクスとしてテスト総数とテスト成功率等です。
最後に「テスト自動化のツール検討」です。QAエンジニアのスキルセット（多少のコードがわかる）、２～３週間の仕様変更に耐えるための容易性、iOSやAndroidのversion up等に追従しやすい保守性に耐えられるための有償ライセンスのテスト自動化ツールを選定しました。
今回は、複数人のテストエンジニアでテスト自動化のスクリプティングを行いました。ツールは、ローコードで容易に実装できる面と、C#等を使ってローレベルのコードを書くことで複雑な処理を実現できる面の両面を持ち合わせていました。
――最初の失敗の反省を生かして進めていたんですね。順調に進んだのでしょうか。
私も順風満帆にいっているように感じていましたが、半年ほど経過して突如座礁しました。今回は２つの岩礁に乗り上げてしまったのです。
１つ目はテストの粒度がバラバラであった点です。
機能を操作する処理の粒度は同じでしたが、検証する粒度が人によって異なっていました。
例えば、ページ遷移した時、そのページに遷移したことを検証させるためにタイトル等が正しいかを細かく検証する人がいれば、まったくしない人もいます。更新するテストシナリオでは、最後にすべての設定項目が反映したかを検証する人がいれば、更新しましたという成功メッセージだけを検証する人もいました。
このように、テストの粒度がバラバラであり、特にルールを設けていなかったのが問題でした。この検証項目は多くすればいいのかもしれませんが、その反面スクリプティングの工数が増え、テストスピードが徐々に遅くなり、仕様変更が入った時の修正コストが大きくなります。
２つ目は複雑な処理を実装してしまう点です。
Ｃ＃等では独自実装できる機能があるため、基本機能では実現できないテストも再現することができます。また、同じルーチンの処理をＣ＃でライブラリ化して実装の効率化を図ることもできます。
ただ、これをすることで本来のテスト自動化ツールの特徴である、「そこそこのＱＡエンジニアが容易に使える」というメリットを打ち消してしまうことになります。かつ、そのコードが属人的なものになってしまい、メンテナンスしにくいものになってしまいます。
――2回目の挑戦ではどのようなことを学ばれたのでしょうか。
2回目の挑戦で学んだことは大きく２つあります。
1つ目は、テストの粒度の基準はどこまでテスト自動化でテストさせるかによって異なるため（例えば、各ページのＵＩまで確認するか）、テスト自動化の目的に応じて決めること。
一番重要なのは、そのテストの粒度を複数人のエンジニアで統一させることである、ということです。
2つ目は、スクリプティングは、ローコードで実現する範囲と、複雑なテストを実現するための独自実装の許容範囲を決めたほうがいいということ。
場合によって、テスト自動化しないという判断基準があってもいいと思いました。テスト自動化もアプリケーションであるため、テストが発生します。テスト自動化のテストを最小限にしないと、本末転倒になってしまうことを学びました。
3. 関係者達から厳しい指摘を受ける
――テスト自動化への挑戦で苦労した点は何でしょうか。
先ほどお話しした通り、テスト自動化エンジニア内では、様々な課題に直面しつつも、基準を明確にして乗り切っていたので、なんとかなっていたように感じていました。しかし、関係者の方からの指摘はきつかったです。
手動テストチームからは、「テスト自動化は何をテストしているのかわからない」、開発チームからは「本当にコスト削減になっているのか」とご指摘がありました。
「そりゃそうだ。」とも感じました。どのテストをカバーするか、は共有していましたが、基本的にテスト自動化チームの中だけで完結するような運用になっていたからです。
テスト自動化がリグレッションテストをすべて受け持つから、手動テストはプロジェクトの影響範囲だけを集中してテストすればいい、という前提でやっていましたが、結局ブラックボックスのリグレッションテスト自動化は、外から見ると何を品質保証しているのかわかりません。
――円滑に進めるためには周囲の方々への配慮も重要なのですね。どのように解決されていったのでしょうか？
この問題を解決するために、２つのことを取り組みました。
１つ目は手動テスト・自動テスト共通で用いるマスターテスト観点表です。
これはすべてのテスト観点を網羅し、自動テストがカバーしている個所を可視化するものです。手動テストチームからすれば、テスト自動化ですでにカバーされている個所が分かるため、テストスコープを決めやすく、かつ不要な手動テスト工数を削減することができます。
また、開発チームからは、テスト自動化で何％カバーされているか等が定量的に見えるため、テスト自動化の効果がより分かりやすくなります。
２つ目は、テスト自動化のテストシナリオの設計書の見直しです。
先ほどのマスターテスト観点表では、具体的にどのようなテストを行っているかが分かりません。そのため、テストステップ、テスト自動化のする・しないところを設計書に盛り込み、手動テストチームでも個々のテスト自動化のシナリオが何を行っているかを理解できるようにしました。
ただ、課題も残りました。それはドキュメントのメンテナンスコストです。
細かいテストステップをテスト自動化のスクリプトと並列でメンテナンスしていく必要があり、テストケースがそのままテスト自動化のスクリプトになるような、テスト自動化の効率を上げる取り組みが次に求められました。
ここで学んだことは、プロダクトに関わる人たちにテスト自動化の価値、内容を正しく伝え続ける仕組みが必要であることです。
周囲からはテスト自動化の期待が十分に高い分、より詳しくテスト自動化の成果を知りたがっていることを実感しました。
4. 最後に
――最後に、テスト自動化に取り組もうとしている方へのメッセージをお願いします。
ここまで私のテスト自動化の経験談と、躓きそうなポイントについてお話してきました。これからテスト自動化を始めようとする人たちに参考になれば幸いです。
テスト自動化は、目的によって使い方が異なり、ここで述べた課題とはまた異なったものが出てくるでしょう。テスト自動化は構築時より、運用時が多くの課題が出てくるので、初めはテスト自動化の範囲を小さく始めて、運用に乗ってから徐々に大きくしていくといいのではないかと思います。
また、運用を託されるメンバーがテスト自動化を長く使い続けるための、テスト自動化ツールを選定しておくことも重要です。
テスト自動化はどんどん進化をしており、ローコードやlocationを半自動でとれるもの、テストケースがそのままテスト自動化のスクリプトにできるものが出てきています。
ライセンスソフトは、一見導入コストが高くなるように見えますが、スクリプティングコストやメンテナンスコストを考えるとトータル的には決して高くはありません。
また、開発スピードを求められる昨今、テスト自動化の構築スピードを速めるのにも、すぐに使えて操作が簡単なツールは大きな役割を果たすと思います。
ぜひ参考にしてみてください。
――本日はありがとうございました。
