まえおき
仕事でウォーターフォール開発案件に携わったとき、Playwrightを用いてシナリオテストの自動化を行いました。その時のことを思い出しながら、表題についてまとめてみます。
前提
まずは、テスト自動化をおこなうにあたっての「Why?」となる部分を整理します。
Why? 自動テスト
私が携わったのはいわゆる「改訂案件」で、既存のシステムを開発対象としています。1年かけてウォーターフォールの上流から下流までやって大改訂、また次の1年でウォーターフォールを上流から下流までやって大改訂...というものです。
私はこの案件に参画したての頃、ひたすら結合テスト・システムテスト・シナリオテストをやり続けていました。このテストやりまくり期に感じた課題は、
- 負担の大きさ：テストすべきユーザのパターン数が多いので時間がかかる
- コスト：人手が足りず、大部分のテストは外注しているため費用がかかる
- 品質保証のばらつき：OK・NGの判定基準を厳密に定義しずらく、テストの再現性を担保しにくい
といったことです。
自動テストの実施準備のために、新たな工数が生じることはもちろんわかっています。しかし、毎年改訂を繰り返すという案件の特性上、リグレッションテストの観点での自動化を一度行えば、
- 自動化元年：テストを1から作る（大変）
- 翌年：昨年作ったテストをもとに改訂箇所の調整をするだけ（楽）
- 翌々年：昨年作ったテストを基に改訂箇所の調整をするだけ（楽）
という形で、上記に上げた課題を上手く解決できるのでは？と考えました。
案件の特性に合わせた観点でテスト自動化を検討する。
何度も改訂が発生する案件では、リグレッションテストを自動化する方針が有効。
Why? Playwright
自動テストを導入するにあたっては、PlaywrightというE2Eテストツールを選定しました。ブラウザ操作を自動化して対象のWebシステムをユーザ目線で動かしつつ、アサーションする機能ももちろんあります。
有名どころのCypressやSeleniumも候補に挙がったのですが、以下の理由でPlaywrightを選びました。
Auto-waitingで安定したテストが書きやすい
Playwrightには、Auto-waitingという機能があり、HTMLの要素が操作できるようになるまでDOMのロードを自動で待ってくれます。明示的な「待ち」の処理を入れるのを最小限にしつつ、「要素がまだ表示されていないのに操作しようとする」みたいな状況を回避することができます。
実際には、完全にAuto-waitingに頼りきれるというわけではなかったのですが、意識的に「待ち」を入れなくてもある程度の操作を安定して行えるというのは、テストスクリプトの書きやすさに大きく貢献してくれたと感じています。
Auto-waitingで「待ち」処理の記述を省略して、スクリプトをシンプルにする。
Codegenでテストスクリプトを自動生成できる
Playwrightでは、HTMLの要素をLocatorというAPIで扱うことができます。テストスクリプトを書くときには、
- 要素を特定する（Locatorオブジェクトを取得する）
- 要素に対してアクションを起こす or アサーションする
の2段階で作っていくのですが、Codegenによる自動生成によってかなり楽に作業を進められます。
Codegenはプロジェクトメンバーにも好評で、「まずCodegenで大まかな流れを記述してから、不安定な部分は自分でコードして整える」というやり方が浸透しました。そもそも、私も含めて初めてPlaywrightを書くメンバーが多数だったので、書き方のノリをつかみやすいという良さもあったように感じています。
Codegen:スクリプト自動生成機能で、メンバーへの展開をスムーズにできた。
プロジェクトへ実際に導入してみた
上司・PMへの提案
プロジェクト中の開発工程の一部として、「自動テスト準備」のフェーズを設けるために、自動テストの導入提案兼計画書を作成して、上司やPMに提案しました。
提案書の中で伝えたことは以下の内容です。
- 手動100%のテストの課題とテスト自動化で受ける恩恵
- 負担の大きさ・コスト・品質保証のばらつき
- 人が行う作業と自動テストBotが行う作業の切り分け
- Playwrightでできること・できないこと・できるか未確認なこと
- 自動化準備の計画（仮）
- テスト項目作成のスケジュール・役割分担
- 自動テストBotの仕組み作りのスケジュール・役割分担
- テストスクリプト作成のスケジュール・役割分担
上司やPMの理解あってのおかげで、プロジェクト計画に自動テスト準備フェーズも含めてもらいつつ、準備が始まりました。
自動テストBotプロジェクトの作成
「自動テストBot」と題して、Playwrightを動かすためのNode.jsプロジェクトをyarnで作成しました。
自動テストBotを作成するためには、テストスクリプトをいきなり作り始めるのではなく、そもそもPlaywrightを動かすための環境構築や設定ファイルの調整が必要でした。ほかにも、
- テスト対象システムへのログインをPlaywrightから行うための認証スクリプトの作成
- テストすべきユーザのパターンに合わせて実行するテストを動的に切り替える仕組みづくり
- 共通化できそうな操作処理の作成
を行いました。上記のように必要そうな準備をGitHubのIssue機能で洗い出して、順々に対応していくことで少しずつ仕組みが完成していきました。
上記の準備諸々については、これからPlaywrightを始めようとしている方々にも有用な気がしているので、いずれ記事化して投稿します。（2024/11/20時点の決意。）
スクリプトの作成&レビュー
テストスクリプトを書くにあたっては、その前段階でテスト項目書を作成し、自動化するorしないを仕分けしてスクリプトの作成対象を明確にしていました。「自動化しない」としたテストの例は以下の通りです。
- 複雑な前提条件がないと実行できないテストケース
- そもそも前提条件の準備に時間がかかるため、自動化したところで得られるうまみが小さいと判断し手動実行とする
- 通知機能の確認
- 自動テストを実行するタイミングによってそもそも通知があるorないが変わってくるため、手動実行とする
全てを自動化することを目的にするのではなく、「自動化したときのうまみ」があるかどうかを考えながら判断しました。
前述のCodegen機能を駆使しながら、6人体制でテストスクリプトを書いてもらい、GitHubのPull Requestを投げてもらってレビューしました。レビュー観点の一部を以下に抜粋します。
- Locatorの取得方法
- XPathのような可読性の低い・壊れやすい方法で取得していないか
- その画面の中で一意に定まるような方法で取得しているか
- アサーションの方法
- テスト項目書で定めた観点に基づいたアサーションを行えているか
- auto-waitingを適切に使えているか
特に、アサーションの方法については、テスト項目書作成時点で定義し漏れていたものの本来するべき観点がないかについても改めてレビュー時に確認を行いました。
例えば、「次へボタンを押下でコンテンツ一覧画面に遷移すること」という期待値で定義されていたテストケースがあったとします。
手動テストならば、「コンテンツ一覧画面」に遷移したかどうかは、テストの実施者が「コンテンツ一覧画面とはどういうものか」を設計書なりで参照してなんとなく判断できます。
しかし、自動テストBotは当然ですが、設計書を参照できません。テストスクリプトを作る時点で、何をもって「コンテンツ一覧画面に遷移したか」を定義する必要があります。
例えば、
- ヘッダ部分のタイトルが「コンテンツ一覧画面」となっていること
- 現在のURLが設計で定義した「コンテンツ一覧画面のURL」と一致していること
- ボディ部分に「コンテンツ」の情報がn個表示されていること
- そのほか「コンテンツ一覧画面」に表示されているべきものが表示されていること
など、観点を挙げようと思えばいくらでも挙げられるのですが、どの観点を選ぶかはテスト設計者のさじ加減にならざるを得ないので、その認識がずれていないかをダブルチェック的にレビューしました。
ある意味、自動テストを通じて、品質保証のばらつきをなくすきっかけにもなったと感じました。
テスト実施
最終的には、約200ケース×23ユーザパターン分の計4600件程度のテストを自動化することができました。
自動化前のテスト消化の時間から計算するとおおよそ7.5割の時間削減となっていたので、自分でもかなりの驚きです。
まとめ
Playwright最強！
自動化の準備には時間はかかりましたが、その中でPlaywrightのテクニックや準備の段取り計画などもできたので、その話もいつか別記事にまとめたいものです。
つらつらと当時を思い出しながら書いてしまいましたが、少しでも皆様の自動テストの方針のお役に立てればうれしいものです。