2年目社員がテスト自動化実装に挑戦した!

グッドビーではプロジェクト内で実装した成果物の品質担保の手段としてテストの自動化を積極的に導入しています。しかし、お客さまが主体に開発した今回のプロジェクトはまだ自動化テストツールが導入されていなかったこともあり、自動化テストツールの導入から実装までを入社2年目の僕が挑戦する機会をいただきましたのでご紹介したいと思います。
テスト工程とは
はじめにテスト工程がなぜ必要なのか?という点に触れていきます。テスト工程は実装を行ったプログラムが正常に動作するか、要件や設計通りに作成され、ユーザーが使用するにあたり品質が担保されているかを確認するために行います。この工程を怠るとバグや不具合を見つけきることができず、品質が担保されていないシステムを納品し、運用されてしまう可能性があります。
自動化テストツールに取り組むことになった経緯
今回は既存システムに自動化テストツールを実装しました。実施に至った経緯としては、納品の度にすべてのテストシナリオを手作業で行うため、膨大な工数がかかっていたこと。都度バージョンを切っていたため機能の増減があるなど、複雑な仕様によってリリース前に作り壊しが発覚することがありました。
自動化テストツールを導入することで、リリース時のテスト工数の削減と定期的に作り壊しのチェックを行えるようにしたいという目論見がありました。
自動化テストツールの概要
自動化テストツールはソフトウェアの動作確認を手動ではなく、プログラムで自動的に実行・検証する仕組みを提供するツールのことを指します。3つの観点から手動テストと自動テストの比較を行ってみました。

Playwrightについて
自動テストには様々なテストの種類がありますが、今回はE2EテストツールのPlaywrightを使用しました。E2Eテストとはユーザー目線での動作確認を行うテストのことです。例としてネットショッピングのECサイトで考えてみると、
- ECサイトを開く
- 購入したい商品を探す(検索やおすすめなど)
- 購入したい商品を選択し、カートに入れる
- カート画面から注文手続き画面に遷移する
- 注文手続き画面でお届け先や決済方法を入力する
- 購入確定ボタンを押す
- 購入確定画面が表示される
といった流れになると思います。E2EテストではECサイトを開くところから購入確定画面が表示されるところまでをプログラムで操作し、動作確認を自動化することができます。
Playwrightの特徴として以下の点が挙げられます。
- Chromium / Firefox / WebKit(Safari含む)といった主要ブラウザに対応している。
- 複数のタブ・ウィンドウの操作ができる。
- モバイル表示にも対応している。
- テストの操作を画面録画することが可能。
┗操作中にどこでバグが発生したか
┗テスト成功時のエビデンス
などを明確にすることができます。
実際に使用してみて
今回は提示されたテストシナリオに沿った動作を行うコードを実装しました。具体的にはログインやCRUD処理が中心です。
実装して難しかった点は以下になります。
- 要素の絞り込み
⚪︎Playwrightでは画面内で指定した要素が重複すると[strict mode violation]というエラーが表示されます。そのため、画面内のどの箇所の要素なのかを指定しないといけません。
⚪︎業務内ではラベル以外にも“どのコンテナの中か”など指定したい要素が一つになるまで絞り込みを行いました。
- 高速動作への対応
⚪︎実装したコードに基づいて高速で動作を行うことから、更新した値の確認をする時にまだ更新処理が完了していなく、値が更新されていないというエラーが表示されるなど、こちらの想定していない動作になってしまったことがありました。
⚪︎ 値が更新されるまで待ち時間を明示して、値の更新が確認できるまでは次の動作に進めないようにしました。
今回のプロジェクトを通じて
以前から自動化テストツールを扱っていましたが、改めて自動化テストツールを導入・実装することによってテスト工数の削減や作り壊しのチェックが定期的に行えるようになるメリットを知ることができました。
また、今回の案件を通じて、自動テストの領域にさらに興味・関心がわいてきました。今後は最新ツールの紹介やAIと組み合わせた自動化テストの導入など社内勉強会などから情報を発信し、会社としても個人としても、さらなる成長につなげていきたいです!