はじめに
「手動テストと自動テスト全体を俯瞰・最適化したい」という要望が増えています。 これを実現するためには、自動テスト結果をテスト管理ツールに自動で連携することが必要不可欠になります。
QualityForwardと、 自動テスト結果の連携の実現方法や、最新自動テストSaaSとの連携方法に関してご紹介します。
シリーズ記事は<前編>、<中編>、<後編>の3部構成となっており、 <前編>では手動テストと自動テストを一元管理するメリットと、実現手段の全体像に関して解説します。
手動テストと自動テストを一元管理する3つのメリット
いきなり「手動テストと自動テストを一元管理する」というアイデアの実現手段をお伝えする前に、 まずは手動テストと自動テストを一元管理するメリットについて簡単に触れておきます。
手動テストと自動テストを一元管理するメリットは多いですが、代表的なものに以下の3点が挙げられます。
- 複数の成果物を閲覧する必要がなくなる
- テストの全体像を把握しやすくなる
- 手動テスト/自動テストが担当者に閉じた活動から、チーム全体の活動へと広がるキッカケになる
複数の成果物を閲覧する必要がなくなる
多くの現場では手動テスト結果はExcelで、自動テスト結果は専用のレポーティングフレームワークで別々に管理されているのではないでしょうか。 これら成果物を一つにまとめることで、複数のファイルやシステムを切り替えずともテスト結果を確認でき、単純に作業効率が上がることが第一のメリットです。
テストの全体像を把握しやすくなる
また、手動テストと自動テストの結果だけでなく、手順や期待値を含めたテストケース群全体(テストスイート)を一挙に見られることから、 テストの全体像を把握しやすくなることもメリットといえます。
テスト内容の重複を見つけテストスイートを最適化したり、今ある手動テストケースを自動化できないか検討したりする良い機会となるはずです。
手動テスト/自動テストが担当者に閉じた活動から、チーム全体の活動へと広がるキッカケになる
手動テストと自動テストの両方がひとつのテストスイート上で管理されることで、 チーム全体が手動テスト・自動テストの両方に意識を向けるようになるという点があります。
特に手動テスト担当者と自動テスト担当者が分かれているチームにおいては、自らの担当範囲外のテスト内容について詳しく知らないケースも少なくありません。
手動テストと自動テストが同一のテストスイートで管理されていれば関係者全員が日常的にその記載を眺めることになります。 このことがお互いが何をしているのかを知るキッカケとなり、担当者間やチーム全体でのテスト戦略・設計の最適化につながる可能性が生まれます。
実現手段について
実現手段は実現の全体像に関するパートと、個別具体的な実装に関するパートの2つからなります。 <前編>では前者、実現の全体像に関して解説し、後者に関しては<中編>にてご紹介しようと思います。
業務フローの検討
手動テストと自動テストの一元管理を実現するには、まずは業務フローの検討が必要です。 自動テスト結果の連携に関する部分では、以下のような業務フローで実現ができるでしょう。
- テスト管理ツール上で自動テストを格納するチケット/列などを定義する
- 自動テストを実行する
- 自動テスト結果をテスト管理ツールに連携する
- テスト管理ツール上で自動テスト結果を確認する
ここでポイントとなるのは1と3です。以下では3のシステムアーキテクチャについて説明します。(1に関してはQualityForward上でのテストスイート・テストフェーズの設計で説明します。)
システムアーキテクチャ
自動テスト結果をテスト管理ツールに連携するためにはそのためのシステムが必要になってきます。 以下ではテスト管理ツールにQualityForwardを採用することを前提として話を進めます。*1
自動テストの結果をQualityForwardに連携させるシステムは以下のアーキテクチャで構成されます。
テスト管理ツール
QualityForwardを採用します。
CIツール
CIツールは現在該当するプロジェクトで運用されているもの、あるいは社内で標準的に運用されているものに合わせるとよいでしょう。
実行系
ここでいう実行系は「①自動テストの実行システム」と、「②QualityForwardへの結果連携システム」の両方を内包しています。
①に関しては既にある自動テストの実行システムで問題ありません。
②に関しては、①でスクリプトベースの自動テストシステムを採用しているのか、 実行エンジンが内包された自動テストツールを採用しているのかで多少考慮する事項は変わるものの、 基本的には①と同じプログラミング言語か、担当者の方が使い慣れている言語で連携スクリプトを記載するとよいでしょう。
サンプルスクリプトのご紹介
さてここからは連携スクリプトの具体的な実装のご紹介になりますが、ここから<中編>に移ります。
なお、先んじて具体的な実装を知りたい方に向けて、公式サンプルスクリプトを公開しました。<GitHubへのリンク> ご興味ある方は是非ご覧ください。
*1:テスト管理ツールにExcelを採用しても、他のテスト管理ツールを採用しても、基本的には同じシステムアーキテクチャで実現できるはずです。
QualityForward上でのテストスイート・テストフェーズの設計
テスト管理ツール側での準備にあたる行為として、 QualityForwardではテストスイートとテストフェーズの設計(作成)を行う必要があります。
テストスイート
テストスイートとはテストケース群のことで、今回は一元管理のため、手動テストと自動テストが混在した一つのテストスイートを作成することになります。 この際、以下の3点の設計を行うことが必要になります。
- 「テストケースの識別子」の設計
- 「テスト優先度」列の設計
- 「テスト結果」列の設計
「テストケースの識別子」の設計
QualityForward上のテストスイートに自動テストの実行結果を投入するには、 連携スクリプト上で実行結果から投入すべきQualityForwardのテストケース列を特定できる必要があります。 この際に用いる"テストケース列特定のための情報"を「テストケースの識別子」とここでは呼称します。 テストスイートを作成する段階で、このテストケースの識別子を設計し、テストスイートに記載しておく必要があります。
実行系を問わず、実行結果には必ずテストメソッド名が含まれます。 このため、テストメソッド名の全体、あるいはその一部を識別子とするのがよいでしょう。

「テスト優先度」の設計
QualityForwardには「テストケースに"優先度"列を設定することで、各テストサイクルで集計する対象テストケースを分ける」という機能があります。 これを活用すると同一のテストスイート上で、「手動テストのみを集計対象としたテストサイクル」と「自動テストのみを集計対象としたテストサイクル」を作ることができます。
一例として、以下のような優先度付けが考えられるでしょう。
- A : 完成した自動テストケース
- B : 完成した手動テストケース
- C : 手順が確定していない手動テストケース/未実装の自動テストケース
なお、この定義は本来の「優先度」列が意味する「Priority」とは意味合いが異なり、「テストケースの種類・状態(手動か自動か/完成か未完成か)」を表現していることに注意してください。
「Priority」を定義したい場合は、他の列に別途記載をするか、Priorityとテストケースの種類・状態を組み合わせた形で優先度を設計する必要があります。
「テスト結果」列の設計
最後にテスト結果列のフォーマットを定義しましょう。 テスト結果列は対象テストスイートの「設定」より編集できます。
標準的な自動テスト実行結果は下記の要素を含むため、そのそれぞれを格納する列を用意するとよいでしょう。
- QualityForwardデフォルトで必須の列(定義不要)
- テスト結果(Pass / Fail / Skip)
- テスト実行者(自動テスト作成者のIDで可)
- 別途結果列として定義が必要なパラメータ
- テストメソッドが属するファイルパス(ないしクラス名)
- テスト実行時間
- エラーメッセージ
なお、エラーメッセージに関しては、全体をQualityForward上に格納するとテスト結果の視認性が低下するため、以下のようにするとよいと思います。
- エラーメッセージの一部だけを格納する
- 専用の自動テストレポートフレームワークを用意し、QualityForwardからリンクを張る
テストフェーズ
テストスイートの定義が完了したら、そのテストスイートを紐付ける形でテストフェーズを作成してください。
フェーズ終了日は長めにとっておき、テストスイートが更新された段階で別のテストフェーズにするとよいでしょう。
テストフェーズが作成できたらQualityForward上での準備は完了です。
QualityForward連携スクリプトの設計と実装
QualityForward連携スクリプトは下記の順で実行されます。 サンプルスクリプトで実装を確認しながら解説を読んでいただくとよいかと思います。
- テストサイクルの作成
- テスト実行結果の取得
- 実行結果のパース
- QualityForward上のテストケースとテスト結果のマッチング
- テスト結果のQualityForwardへの格納
テストサイクルの作成
ここからはQualityForward連携スクリプトの内部実装の解説をしていきます。
まずは自動テスト実行結果を投入するためのテストサイクルを作成する必要があります。
テストサイクルの作成に使うのは以下のAPIリクエストです。
POST /api/v2/test_phases/:test_phase_id/test_suite_assignments/:test_suite_assignment_id/test_cycles.json
パス・クエリストリング
パス上で指定するパラメータは以下の2つです。
- test_phase_id
- test_suite_assignment_id
この2つのパラメータを確認するには、QualityForward上のテストスイートの「テストサイクル一覧」ページのパスを見るのが最も簡単です。 QualityForwardにログインしたあと、左サイドバーから「テストフェーズ」を選択し、下準備2で作成したテストフェーズの「スイート一覧」>「サイクル一覧」より確認できます。
またパスの後にクエリストリングの形でAPIキーを指定します。 APIキーはQualityForwardにログインしたあと、「ダッシュボード」>右上の「設定」から生成することができます。
パス・クエリストリングを統合したURLは以下のような形式になります。
https://cloud.veriserve.co.jp/api/v2/test_phases/0000/test_suite_assignments/1111/test_cycles?api_key=YOUR_API_KEY
リクエストヘッダ
{"Content-Type": "application/x-www-form-urlencoded"}
を指定してください。
リクエストボディ
リクエストボディとして最低限必要なパラメータは以下になります。
"test_cycle[name]"
- 任意の文字列。
- 同名のテストサイクルが複数作成されると視認性が落ちるため、日時など適当な変数を付与するとよい。
"test_cycle[target_priorities]"
- テストサイクルで集計対象とするテストケースの優先度。
"test_cycle[start_on]"
- テスト実行開始した日付。
"test_cycle[end_on]"
- テスト実行終了した日付。
"test_cycle[status]"
- テストサイクルの状態。
"unexecuted"(
未実行)/"in_progress"
(進行中)/"waiting_for_review"
(レビュー待ち)/"complete"
(完了)のいずれかをとる。- 自動テスト実行後にテスト管理者の確認を入れるという運用では
"waiting_for_review"
(レビュー待ち)を設定するとよい。
- 自動テスト実行後にテスト管理者の確認を入れるという運用では
- テストサイクルの状態。
テスト実行結果の取得
テスト実行結果の取得方法にはJUnit形式のxmlレポートでの取得や、APIリクエストによる取得などがあります。
サンプルスクリプトではJUnit形式のxmlレポートを使用しています。 JUnit形式のxmlレポートのフォーマットに関してはDevelopersIOさんの下記の記事が詳しいです。dev.classmethod.jp
実行結果のパース
パースの実現方法には自分で正規表現等を使う方法と、既存のライブラリを使う方法があり、どちらでも実現が可能です。 前者はカスタマイズ性が高く、後者は手軽に実装ができます。
サンプルスクリプトでは後者の方法で、"junitparser"というOSSライブラリを使用しました。 具体的な記法・用法はライブラリ公式ドキュメントに譲ります。
QualityForward上のテストケースとテスト結果のマッチング
APIリクエストを送る前に、それぞれのテスト結果がQualityForward上のどのテストケース列に相当するかマッチングをする必要があります。 [「テストケースの識別子」の設計]でテストスイート上に識別子列を既に定義しているので、下記の模擬コードで表現される処理によりマッチングの実現ができます。
API GET <QualityForwardテストスイート> for each <自動テスト実行結果>: for each <QualityForwardテストケース>: if <自動テスト実行結果中のテストメソッド名> in <QualityForwardテストケース中の識別子列>: return <QualityForwardテストケース番号> # マッチ
サンプルスクリプトでは、api.py中のメソッドget_test_case_no_from_id
がこのマッチング処理に相当します。
テスト結果のQualityForwardへの格納
テスト結果の格納に使うのは以下のAPIリクエストです。
POST /api/v2/test_phases/:test_phase_id/test_suite_assignments/:test_suite_assignment_id/test_cycles/:test_cycle_id/test_results.json
パス・クエリストリング
パス上で指定するパラメータは以下の3つです。
- test_phase_id
- test_suite_assignment_id
- test_cycle_id
1, 2はテストサイクル作成時と共通です。 3はテストサイクル作成時に返却される値を使用すれば問題ありません。
またクエリストリングにはテストサイクル作成時と同じAPIキーを指定してください。
パス・クエリストリングを統合したURLは以下のような形式になります。 "https://cloud.veriserve.co.jp/api/v2/test_phases/0000/test_suite_assignments/1111/test_cycles?api_key=YOUR_API_KEY"
リクエストヘッダ
{"Content-Type": "application/x-www-form-urlencoded"}を指定してください。
リクエストボディ
リクエストボディとして最低限必要なパラメータは以下になります。
- "test_result[test_case_no]"
- 結果を格納するテストケースの番号。
- マッチングにより取得
- "test_result[result]"
- テスト結果(Pass / Fail / Skip / Error)
- "test_result[user_id]"
- テスト実行者のユーザID
- "test_result[executed_at]"
- テストの実行日時
更に、「テスト結果列」の設計で定義したフォーマットに対するパラメータを追加してください。 項目1は"test_result[content1]"、項目2は"test_result[content2]"というキーになります。
- テストメソッドが属するファイルパス(ないしクラス名)
- テスト実行時間
- エラーメッセージ
リクエスト時の制約
QualityForwardのAPIリクエストは1秒に1回の制限があるため、複数回のループ処理を実行する結果格納処理のような処理を行う際には time.sleep(1)
のようなwait処理を挿入するようにしてください。
自動テストSaaSとQualityForwardの連携
非スクリプトベースの自動テストツールとQualityForwardとの連携方法のご紹介として、 近年トレンドとなっている自動テストSaaSとQualityForwardとの連携について検討していこうと思います。
結論としてはMagicPod・mabl・Autifyは、すべてQualityForwardとの連携が可能です。 *2
まずはじめに各サービスを知らない方に向けて、簡単にサービスの特徴を解説した後、 MagicPod・mabl・AutifyとQualityForwardのそれぞれの連携方法についてご紹介します。
各自動テストSaaSの特徴
MagicPod
MagicPodはウェブサイトとモバイルアプリの両方の自動テストをドラッグ&ドロップで作成できることが特徴のサービスです。SeleniumとAppiumを利用したことがある方であれば問題なく利用を開始でき、 特にモバイルの自動化に関しては現状最も強力なサービスの一つと言えるでしょう。 また課金体系が実行回数単位でなく、テストケース単位であり、コストパフォーマンスに優れる点も見どころです。
mabl
mablは「開発ライフサイクル全体にわたって信頼性の高いテストを実施できる」ことを特徴としている海外発のサービスです。 UIテストだけでなくAPIテストもカバーできるなど、まさに"mabl駆動開発"の実現に向けて、急速に開発が進められています。 また2021年に日本展開が本格化されており、公式ドキュメントの日本語化や各種イベント開催など、日本ユーザ向けのサポートも充実してきています。
Autify
Autifyは「ブラウザで操作を記録するだけでテストがノーコードで誰にでも簡単につくれる」ことを特徴としているサービスです。 日本市場で展開されているテスト自動化SaaSとしては恐らく最大手で、多くのユーザに愛されています。 元々はWeb自動化向けのサービスでしたが、 2021年にモバイルの自動化を実現するAutify for Mobileもベータリリースとなりました。
先述のmablとAutifyはブラウザ拡張でテスト手順をレコーディングするという点で一見似ていますが、 mablは「ローコード」(コーディングやコンピュータ知識を背景に、主にエンジニアに向けた効率的なサービスの提供)を標榜している一方、 Autifyは「ノーコード」(誰にでも簡単に自動テストを作成することができるサービスの提供)を標榜しており、 サービスの未来像は大きく異なっています。
MagicPodも含め、ツール採用の際にはどのサービスが自分たちのプロダクトや開発文化に合うか、しっかりと検討することが必要と言えるでしょう。
各自動テストSaaSとQualityForwardの連携
ここからは各自動テストSaaSとQFとの連携方法を解説していきます。
実行系にどの自動テストSaaSを採用する場合にも、以下の図のアーキテクチャ自体は変化しません。
焦点となるのはQualityForward連携スクリプトをどう実装するかという点です。
方針として、JUnit形式のxmlレポートが出力できる場合にはそちらで結果取得をしサンプルスクリプトを流用、 xmlレポートを出力できない場合や、xmlレポートには記載されていない情報をQualityForward上に記載したい場合に APIリクエストによる結果取得をするとよいでしょう。
MagicPod
MagicPodはクラウド実行とローカル実行が可能で、ローカル実行のみQFに連携が可能です。
2021年8月12日現在、MagicPod APIで各テストケースの実行結果を取得することはできないようです。
MagicPod APIの詳細は下記を参照ください。
ローカル実行の場合はMagicPod Desktopを利用することでJUnit形式のxmlレポートを出力できるため、サンプルスクリプトを流用できます。 MagicPod Desktopによるxmlレポートの出力方法に関しては下記の記事が詳しいです。
mabl
mablはクラウド実行とローカル実行が可能で、クラウド実行時のみQualityForwardに連携が可能です。
mablではJenkins, CircleCI, Bambooなどといった各種CIツールの公式プラグインが提供されており、 これらを利用するとJUnit形式のxmlレポートを出力できます。これらを使用し、サンプルスクリプトを流用するとよいでしょう。 mablのCI連携については以下のヘルプページが詳しいです。
なお、APIによる結果取得もできますので、こちらで結果を取得することも可能です。 mablはサービス内でAPIリクエスト文を生成することが可能です。下記ヘルプページを参考ください。
Autify
Autifyは現在クラウド実行のみが可能です。QualityForwardとの連携はAutify APIによる実現になるため、連携スクリプトを自作する必要があります。 APIリクエストGET /projects/{project_id}/results/{result_id}
のレスポンスに含まれる"test_case_results"
を使用するとよいでしょう。 Autify APIの詳細は下記ページをご覧ください。
*2:APIによる結果取得が可能なSaaSであれば理論上すべてQualityForwardと連携可能です。