はじめに
はじめまして。atama plus で QA Engineering Manager をやっていますItoです。
atama plus Advent Calendar 2024の12月13日の記事になります！
昨年のアドベントカレンダーで池上さんから開発プロセス内でPlaywrightを活用して自動化を進めている話として、弊社でテスト自動化をどのように開発プロセスに組み込んでいるのかについて紹介しました。今回はそこから少し時間を遡り、テスト自動化の推進に舵を切り、Playwrightを導入した時の話をしたいと思います。
これからテスト自動化を導入したいと考えている方の参考になれば幸いです。
テスト自動化の推進の背景
本格的にテスト自動化の推進の検討を始めたのは、今から約3年前の2022年1月のことでした。
当時atama plusでは、リリース直前に実施するシステムテスト（弊社ではリリーステストと呼んでいるため、以降リリーステストと記載します）でノーコードの自動テストツールを導入していました。しかし、ツールがShadow DOMに対応していないという理由から、利用対象はShadow DOMに対応していないアプリの権限テストのみで、テストのほとんどを手動テストに頼っていました。ただ当時、それに課題を抱えていたかと言うと「そうでもなかった」というのが正直なところです。理由として、その夏にリリーステストを外注化したことで、ある程度のテスト増加に耐えられる体制が構築されていたことがありました。
ただ、以下の状況から、このまま手動テスト中心のリリーステストを実施し続けていたら、近い将来、限界が来るだろうということも感じていました。
- 新規メンバーの増加に合わせ、開発規模が拡大
- 仕様の認識齟齬による不具合が多発したり、想定外の箇所に不具合が発生するケースが多発
- 上記問題を、リリーステスト内のリグレッションテストでカバーしようとし、手動テストケースが増加
このような背景から、限界が来る前に手を打つべく、テスト自動化の推進タスクフォースを立ち上げ、検討を開始しました。
テスト自動化によって目指したいものって何だろう？
タスクフォースを立ち上げ、まず最初に実施したのが「私たちがテスト自動化によって目指したいもの」＝「あるべき姿」の目線合わせでした。
「将来の限界を回避すること」が背景にはありますが、それを活動の目的にすると、対応が限定的で一時的なものになる可能性があります。リリーステストを「手動テスト」中心から「自動テスト」中心へと変えるということは、大きくプロセスが変わるということ。大きく変わったプロセスによって、私たちは何を目指したいのか？この「あるべき姿」の目線を合わせることは、今後活動を続けていく上での軸になると考え、タスクフォースメンバーで議論を重ねました。その結果、以下2つをあるべき姿として定義しました。
1.「いつでも」「どこでも」自動テストが実施できること
「いつでも」は記載の通りですが、「どこでも」というのは、リリーステスト環境、開発環境、どこの環境でも、を意味しています。開発環境でも自動テストが実施できるようになれば、より早いフェーズで不具合を見つけることができ、シフトレフトの観点からもメリットが高いことから、将来的にはリリーステスト環境だけでなく開発環境でもテスト実施できることを1つ目のあるべき姿としました。
2.テスト分布が正常なテストピラミッドであること
当時の手動テストスクリプトには、膨大なシナリオテストが存在しており、シナリオテストの中に機能テストが混在している状況でした。テスト自動化を進めるにあたり、既存のスクリプトをそのまま自動化するのではなく、テスト構成を「シナリオテスト」と「機能テスト」に設計しなおし、正常なピラミッドにしてゆくこと（シナリオテスト＜機能テスト）を2つ目のあるべき姿としました。
ツールの選択
当初、ノーコードツールを利用していましたが、ツールの選定では、まずノーコードツールとノーコードでないツールのどちらを利用するか？の検討から行いました。
ノーコードツールは、「シナリオテスト」には非常に有効なツールですが、私たちがまず着手したいと考えていたのはテストピラミッドの下位である「機能テスト」の方でした。「機能テスト」を自動化するのであれば、「コスト」「メンテナンス」「テスト構成管理」の面から、ノーコードツールでないツールの方が向いているという判断をしました。（詳細は参考の図を参照ください）
その後、「Selenium」「Playwright」「TestCafe」「Cypress」のそれぞれについて比較項目を調査していきました。具体的な調査項目としては、「利用言語」「Shadow DOMの利用可否」「テスト実行速度」「出力レポート内容」「環境準備の容易さ」「実装の容易さ」「ビジュアルリグレッションの提供有無」「将来的なメンテナンス」などです。
これらの比較から最終的に「Playwright」に決定したわけですが、大きな決め手となったのが「環境準備の容易さ」でした。当初から、将来的にQAメンバー全員に自動テストを書いてもらうことを想定していましたが、メンバー全員がコーディング経験者というわけではありません。開発環境を用意することも初めてというメンバーが自走するには、「環境準備の容易さ」は重要な観点であると考えました。そのメリットの一方で、当時Playwrightは導入事例も少なく、ガイドも英語のみという状況でした。前職でSeleniumでのテスト設計の経験があったものの、PlaywrightもTypeScriptも初めての経験。ガイドを頼りに手探りで実装していく覚悟を決めての選択でした。
参考）
| 比較項目 | ノーコードツール | ノーコードでないツール |
|---|---|---|
| 適するテスト | シナリオテスト | 機能テスト |
| 利用のしやすさ | 誰でも作成が可能 | 一定のコーディングスキルが必要 |
| コスト | 実施シナリオ数や利用ユーザー数ごとに費用が掛かる。 シナリオごとにかかる場合、1シナリオを長く設計しがちになり、メンテナンス負荷を上げる一因になる。 |
無料のものも多い |
| メンテナンス | 自動修正機能があるものが多いが、シナリオテストがベースのため、特定機能の変更が複数のテストケースに影響する。 | ページオブジェクトパターン*1を採用すれば、特定機能の変更があった場合も、ページ側の修正をだけで済む場合も多い。 |
| テスト構成管理 | シナリオのリスト管理を提供していることが多く、機能ごとにテストケースを管理するのが難しい。 | 機能ごとにページクラスやテストケースを設計でき、機能テストの構成管理に向いている。 |
*1: ページオブジェクトパターンとは、Web画面を1つのオブジェクトとして捉えるデザインパターンのこと。各Web画面内の要素や操作を定義しておき、テストでは利用するWeb画面をオブジェクトとして呼び出し、定義されたメソッドを利用してテストを実行してゆく。
4つのフェーズとファーストターゲット
テストツールも決まったものの、「あるべき姿」を一気に実現することはできないため、実現に向け4つのフェーズを設定することにしました。
フェーズ１：主要な機能テスト（機能テスト）を自動化する
フェーズ２：主要な機能テスト以外の機能についても自動化を進め、自動テストのボリュームを増やしつつ、自動テストを安定稼働させる
フェーズ３：既存の手動の「シナリオテスト」から、自動化した機能テストを削除する
フェーズ４：テスト実行環境を、リリーステスト環境以外にも拡大する
なお、ファーストターゲットは、フェーズ１のうち、主要な機能テストの中でShadow DOMの影響を受けない機能をターゲットとしました。これは、主要な機能テストの22％にあたります。ファーストターゲットを絞ったのは、まずは自動テストのツールの使い方をマスターし、ベースとなるテスト構成を決めるための知見を得ること、スモールスタートで着実に自動テストの運用を軌道に乗せることを優先したためです。
ツールとゴールが決まれば、あとは書くのみです。タスクフォースメンバーと英語ガイドを読みながら試行錯誤を繰り返し、合宿と称してオンライン上で集まりながら黙々コードを書くこと5週間。こうして2022年4月末に、Playwrightによるリリーステストが開始されました。
Playwrightでテストを開始して3週間後、リリーステストで初めてPlaywrightによるバグ検知ができた時の安堵と喜びは、今でも鮮明に覚えています。
さいごに
今、Playwrightは、リリース活動だけでなく、開発時の機能テストにおいてもなくてはならない存在になっています。リリーステストで必要な機能テストのうち、自動化できるものについては80%近くを作成し終わりました。
振り返ると、テスト自動化は手段であって目的ではないということを改めて感じています。テスト自動化に取り組むことは、ただテスト時間の短縮などのメリットを得るだけでなく、自分たちのテストプロセスやテスト設計を見直すことでもありました。
そして今、ほぼフェーズ4までやり切ったことで、テスト自動化を組み込んだ新たなチャレンジも見えてきました。これからも私たちは、チーム一丸となってQAチームミッション「いいものをタイムリーに安定的にユーザーに届ける」ために走り続けます！
フェーズ4に至るまでに実施した施策の数々と、新たなチャレンジは、ぜひまた別の機会に、、、
Discussion