PlayWrightを利用して、QAエンジニアがE2Eテストコードを書いてみた。
サマリー
E2E(End to End)テストとは、フロントエンド開発におけるテスト手法の一つです。ユーザーが実際に利用する流れで、システム全体の動作をテストします。
今回は、QAエンジニアの視点で、Playwrightを利用してE2Eテストのうち、ユーザーが実際に利用する流れでシステム全体の動作をテストする、ユースケーステストケースを作成してみました。
このユースケーステストケースを作成する際につまずいた個所について、説明していきます。
PlayWrightとは
Playwrightは、Microsoft社が提供しているE2Eテストツールです。Webブラウザの操作をAPIで提供しており、Node.jsアプリケーションで使用することができます。
Playwrightの特徴は、以下のとおりです。
- 複数のブラウザをサポートしている。
- ブラウザの操作をシンプルなAPIで記述できる。
- テストコードの実行が高速である。
- 無料で利用でき、公式ドキュメント(英語)も豊富
公式ドキュメントですが、リファレンスマニュアル形式のため、「何々を実施したい」という探し方が難しく、テストコード作成に詰まった際には先駆者たちの資料を参考にして悩んだら公式ドキュメントを読んで試してみるという、Try&errorを繰り返していました。
テストコード作成
まず前提としてですが、Webアプリケーションのテストコードを作成するのは初めてではありません。20年ほど前ですが、有償の自動化テストツールを使ってE2Eテストを作成・自動実行した経験を持っています。
この時には有償ツールのためサポートを受けられましたが、Webアプリの進歩が速いためか、「JavaScriptは追加オプションでサポートしている(ので購入してください)」と回答をもらって作成を断念したこともあります。
一方、PlayWrightは無償ツールですがテストコードの情報もいろいろネット上に公開されていて、あまり不便さを感じません。また、PlayWrightには、コードを生成できるCodegen(コードジェネレータ―)が提供されているので、Codegenで作成したコードを参考にすることができます。
ただし、2023年9月現在で日本語の書籍があまりないので、その点がネックになるかもしれません。
今回は、フロントエンジニアに作成してもらったユースケーステストをサンプルとして活用し、うまく動作しない個所については、Codegenで生成されたテストコードを参考にして、テストコードを生成することで、テストコード作成に不慣れな自分も実際に動作するテストコードを書くことができました。
テストコード作成時の3つのTips
今回のユースケーステスト作成を通して、テストコード生成に行き詰った個所についてTipsとして紹介します。
-
ファイルアップロードができない。
Codegen(コードジェネレータ―)で生成されたテストコードは利用できません。
擬似的なPCのファイル選択画面となるfilechooserを利用する必要があります。
また、ファイル名にハイフンが含まれていると、PlayWrightからファイルが認識できません。
ここ気づくまでに、ファイルアップロードのコードに問題があるかチェックしていました。 -
複数存在するアイコン要素をクリックできない。
画面に同じアイコン要素が複数存在すると、アイコン要素をクリックできません。
htmlにあるtitle要素を指定してもヒットできないことがあります。
理由は、同一となる要素が複数存在していると該当する要素が探せなくなり、エラーとなるためです。
- タイトルやプレースホルダー、テキストといった要素でヒットできないか確認する。
- 複数のアイコン要素を表示させた環境で、Codegenでテストコード生成を行い、アイコンの特定方法を確認する。
- 同一のdiv要素に存在するセレクトボックスが選択できない。
一つめのセレクトボックスの選択結果により、アコーディオン型で画面出し分けがあるケースの場合、特定の要素となるテキストが表示されることを確認してから、二つめとなるセレクトボックスを選択させるテストコードに書き直すとよい。
現状では、画面上での絞り込み操作を行って画面表示される要素を限定することで、処理可能なテストコードを作成しています。しかし、画面表示される要素を限定するにも限度があるため、確実にテストコードを実施するためにはテーブル要素での指定が必要になるかと考えています。
QAエンジニアがテストコードを作成するメリットとは
最後に、QAエンジニアがテストコードを作成するメリットについてお話しします。
フロントエンジニアに任せておけばよいという声も諸説ありますが、QAエンジニアならではの視点でテストコードを作成できることに大きなメリットがあると考えています。
- クライアントがサービスに求める目的をしっかりと理解したQAエンジニアが、適切な箇所に適切な内容のユースケーステストのコードを作成することで、長期的なプロジェクトにおける開発工数が削減できる。
- 機能改善やリファクタリング時に、テストコードを簡便に何度でも自動実行が行えるため、テストの漏れによる不具合事象の流出を抑制でき、その結果として運用フェーズでの保守工数削減に寄与できる。
アジャイルテストの4象限で方向性を示すと、左上の第2象限(Q2)における機能確認テストとユースケーステストを、QAエンジニアがPlaywrightを活用してテストを自動化していくのが、アジャイル開発の品質向上に効果的だと考えています。
最後に
Tipsにも書いたとおり、現状では画面表示される要素を限定した方法でユースケーステストを処理していますが、なんとか自分なりに形になるテストケースを作成できるようになりました。
とはいえ、確実に特定のテーブル要素を指定するためにはある程度の経験が必要だと感じています。今後も日々精進し、得られたノウハウをTipsとして展開したいと考えています。
Discussion