こんにちは、QAエンジニアのうえやまです。
現在私はE2Eテスト自動化に携わっており、日々さまざまな特性を持ったテストの自動化に取り組んでいます。
本記事では、自動化したいテストの内容が決まった後、「そのテストの特性に合わせた設計をどう行うか」という品質と効率を左右する重要な部分にフォーカスして、私の経験から得られた3つの設計パターンをご紹介します。
いずれも、キャプチャ＆リプレイ（ノーコード、ローコード）やスクリプティングでの自動化といった環境によらず適用可能な設計方法になります。
テスト特性にフォーカスした自動テスト設計方法
１．新規に作成する場合：基本となる設計思想
E2Eテストの自動化に着手する際に重要な初期ステップの一つは、どのようなテストを自動化するのか、全体像を明確に描くことです。特に新規で自動テストを作成する場合「自動化ならではの注意点」を事前に考慮した設計が、後の運用フェーズでの手間を大きく左右します。
まず自動化用のテスト構成を検討し、テストケースに起こします。このとき「１ケースにつき１スクリプト」として作成するのが良いでしょう。
理由としては複数ありますが、一連のシナリオごとにテストを分割管理することで以下のようなメリットが生まれます。
- 可読性と管理性の向上: スクリプト名を見るだけで、どのようなテストかが直感的に理解でき、管理が容易になります。例えば、特定の機能に不具合が見つかった際、その機能に関連するスクリプトが明確に分かれていれば、影響範囲の特定や修正作業が迅速に行えます。
- 安定性の向上: テスト実行時間が長くなるほど、ネットワークの瞬断や予期せぬポップアップなど、外部要因による失敗のリスクが高まります。テストを短く区切ることで、それぞれの成功率が上がり、CI/CDパイプラインに組み込む際の信頼性も大きく向上します。
構成の検討が出来たら、共有ステップ化出来そうな処理を検討します。他のテストでも使えそうな一連の処理（ログイン、利用者作成 等）があれば共有ステップ化しましょう。
共有ステップは、自動テストの「再利用性」を高めるために不可欠です。一度作成すれば複数のテストケースで利用できるため、スクリプト全体の記述量を減らせるだけでなく、共通処理の修正が発生した場合も一箇所の変更で済み、メンテナンスコストを大幅に削減できます。
下図では、本編の前後に初期処理と後処理を入れています。
内容としてはケース内で登録するデータ（下図でいうところの「連絡先追加」で追加した連絡先など）の削除になります。この「テストデータのクリーンアップ」は、自動テストの信頼性を保つ上でとても重要です。特に、テスト環境が共有されている場合、他のテストや手動テストに影響を与える可能性があります。
もし自動テストがエラーになって中断されデータが残った状態で次回実行されると、それが原因でテストが通らなかったり意図したテストが出来なかったりする恐れがあるため、クリーンアップ作業は必ず入れるようにしています。
また、テストデータもここで検討出来ると良いでしょう。私は以下に注意して検討しています。
■テスト同士が干渉しないようにスクリプトごとにデータを分けて設計する
これは、テストの独立性を保つために重要なポイントです。例えば、Aというテストが作成したデータをBというテストが意図せず変更してしまい、結果としてBのテストが失敗するといった「テスト間の依存性」を避けることができます。
このような依存関係があると、テスト結果が不安定になり問題の特定が困難になるため、各スクリプトが独自のテストデータを持つか、実行ごとに初期状態にリセットされるような設計が理想的です。
■なるべく本番環境でより多く使われているデータを採用する
テストデータのリアリティは、テストの有効性を大きく左右します。本番環境で頻繁に使われるデータパターンを中心に含めることで、実際の運用に近い状況でテストを実行し、より現実的な不具合を発見しやすくなります。
■自動テストを動かすために事前に登録が必要なデータを記載しておく
自動テストを安定して実行するためには、常に決まったテストデータが環境に存在している必要があります。そのため、テスト環境を再構築する際や新しい環境をセットアップする際に、どのような初期データが必要なのかを明確にドキュメント化しておくと後々便利でしょう。
以上、新規に自動テスト設計する場合について記載しましたが、これらの内容をドキュメントにまとめてレビューに出し、通れば実装開始する流れが多いです。
既に存在している手動ケースをもとに作成する場合も、画像のようにおおまかなブロックに分けるところから流れや注意点は同様です。
２．データドリブンテストを行う場合
データドリブンテストは、同じテストシナリオを異なる入力データで繰り返し実行する必要がある場合に非常に効果的です。
例えば、5種類の異なる権限を持つユーザーで、同じ「ログイン〜特定機能の操作」をテストしたい場合を考えてみてください。もし5つのスクリプトを個別に作成すると、少しの仕様変更でも5つのファイルを修正する必要があり、非効率的です。
データドリブンテストでは、「操作を定義するスクリプト」と「入力値や期待値を定義するテストデータ」を分離します。これにより、テストしたいデータの増減があっても、ExcelやCSVファイルといったデータソースを修正するだけで対応でき、スクリプト本体に手を入れる必要がありません。
この手法のメリットは以下です。
- 高いメンテナンス性: ロジックとデータが分離しているため、テストデータの追加・変更が容易です。非エンジニアのメンバーでもスプレッドシートを編集するだけでテストパターンを増やせます。
- カバレッジの拡大: 多言語対応サイトの翻訳文字列チェックや、ECサイトの様々な割引パターンの計算など、組み合わせが膨大になるテストも効率的に網羅できます。
私が過去に担当したプロジェクトでは、PDFにまとめられた大量の仕様データをテストデータに活用する必要がありました。その際に行った、手作業を軽減する整形手順をご紹介します。
- データ原本のPDFをWordで開いてhtml形式で保存
- html形式で保存したデータをExcelで開き、Excel形式で保存し直す
- 上記をスプレッドシートにコピーし、テストで使用したい変数と値の形になるよう関数やフィルターを使い整形する（最終的に画像右「テストデータファイル」のような形になります）
- 整形したデータをスクリプトから参照し、データドブリンテストを行う
私が使っている自動化ツールはCSV形式のみ参照可能のため、CSVで出力しツールに取り込む作業も挟みますが、これはあくまで一例です。
より高度な方法として、PythonのPyPDF2やpdfplumberといったライブラリを使い、PDFからのデータ抽出プロセス自体をスクリプトで自動化することも可能です。定期的に更新される仕様書からテストデータを生成するような場合には、こうしたアプローチが大きな力を発揮するでしょう。
３．画面遷移確認を目的としたテストの場合
最後に、システムの各画面への遷移を網羅的にテストすることを目的とした設計で使用した方法をご紹介します。
特に、大規模なWebアプリケーションや頻繁にUI変更が発生するシステムでは、全ての画面遷移を手動で確認することは非常に困難です。このような状況において、自動テストによる画面遷移確認は、品質保証の効率化に有効なアプローチとなります。
普段図を描く系のドキュメントはMiro(Miro | イノベーション ワークスペース)を使って作成しているのですが、今回紹介する方法でもmMiroを使うのがおすすめです。図を使ったドキュメントを感覚的に綺麗に作成出来るツールです。
※使用するツール、アカウントはプロジェクトに確認してください。
画面遷移テストの設計の流れとしては以下になります。
- 作業対象画面を決め、画面名と番号を振る。（画面一覧があればそれを元にします）
- Miroにテストしたい画面のスクリーンショットを貼って各ボタン・リンクからの導線を描く。この時以下２点をルールとしています。
- 一筆書きになるよう遷移順を振る
- 上から下に遷移順になるよう並べる（追いやすさに配慮）
- 作成した導線通りにスクリプトを実装する
テキストベースのテスト仕様書では、「どの画面の、どのボタンを押すと、どの画面に遷移するか」という流れを直感的に把握するのが難しく、レビューの際にも認識齟齬が生まれがちです。しかしこの方法では視覚的に遷移パスを示すことで、設計者もレビュー者も容易に内容を理解できます。
また、設計段階で「見落としがちな遷移パス」や「意図しない画面ループ」、「どこからもリンクされていない孤立した画面」などを発見しやすくなるという副次的な効果も期待できます。
例としてAGESTのホームページの遷移図を一部描いてみると以下のようになります。
Miroだと同じ資料上の違う要素にリンクで飛べるようにも出来るので複雑な遷移でも分かりやすく表現可能です。
以下にこの方法のメリットとデメリットをまとめますので、参考にしてみて下さい。
メリット:
- 設計の網羅性の向上: 視覚化により、考慮漏れや設計の不備を早期に発見できます。
- レビューの効率化: テキストを読み解く必要がなく、直感的なレビューが可能です。
デメリットと対策:
- ドキュメントの陳腐化: UIの変更が頻繁に発生する場合、Miroの図を最新の状態に保つためのメンテナンスコストがかかります。これを完全に防ぐのは難しいですが、UI変更のタスクとセットでMiroの更新も行うというチームルールを設けることで、乖離を最小限に抑えられます。
まとめ
本記事では、3つの異なるテスト特性にフォーカスした自動テストの設計方法を、具体的な事例を交えながらご紹介しました。いずれの手法においても、設計段階からテストの安定性、メンテナンス性、そして可読性を意識することが重要です。
自動テストは一度作成したら終わりでなく、プロダクトと共に育てていくものです。そして、その価値を最大限に引き出すためには、作成者だけでなくチームの誰もが内容を理解し、修正できる状態になっていることが不可欠です。
誰もが触れる「開かれた自動テスト」は属人化を防ぎ、チーム全体の資産となります。完璧な設計は存在しませんが、プロジェクトの特性やチームのスキルセットに合わせてトレードオフを理解し、最適な手法を選択していくことが、自動化を成功に導く鍵となるでしょう。
本記事が、皆さんのテスト設計における新たなアイディアや改善のきっかけになれば幸いです。最後までお読みいただき、ありがとうございました。
