MagicPodのテスト結果をTestRailで管理している話

# 概要
はじめまして、私は社内でテスト自動化の推進を担当しています。CI環境などを構築し、社内に提供したり、自身も自動化を行っています。
唐突ですが皆さんは、自動テストの結果をどのように集計し、どのように活用されておりますか？
私は、**MagicPodのテスト結果をTestRailに連係し、TestRailでMagicPodのテスト結果を管理**しています。
なぜTestRailで管理しているのか、どのようなメリットがあったのかなどを本記事では紹介いたします。

質問などあればコメントください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961957/4decb652-d95d-bd8b-f227-0520f92ba867.png)
※自身でコード書いて、TestRailのAPIを用いて結果連係しています。

## 記事のターゲット
* 実行結果の活用を模索している人
* マニュアルテストでTestRailを使っている人
* 不安定なテストに困っている人
* 実行結果と失敗原因を一緒に管理したい人

# MagicPodとは
>高速・高品質なソフトウェア開発を支える**AIテスト自動化プラットフォーム**
MagicPodは、モバイルアプリテスト、ブラウザ(ウェブアプリ)テストの両方に対応したAIテスト自動化クラウドサービスです。豊富な機能と高いメンテナンス性でリリースサイクルの高速化を支援します。
引用元：https://magicpod.com/

https://www.youtube.com/watch?v=OIOgIKwwFkY

# TestRailとは
>TestRailは、テストケース、テスト結果、テストの進捗状況、不具合の検出状況など、テストに関するものを効率的に管理できる、**Webベースのテスト管理ツール**。 すべての担当者がリアルタイムに最新のテスト進捗状況にアクセスして、テストケースの更新・分類・検索、テスト結果のレポートや進捗分析を簡潔に行える。
引用元：https://cloud.watch.impress.co.jp/docs/news/1320270.html

https://www.gurock.com/testrail/

# テスト結果をTestRailで管理し始めた背景
TestRailで管理しようと考えた理由は以下です。
#### １．メンバー全員が使い慣れている
テスト自動化前から、マニュアルテストのテストケースや実行結果などをTestRailで管理しており、メンバー全員が使い慣れていました。
自動テストの結果をよりスムーズに確認できるよう、TestRailに集約し、テスト自動化担当者以外の人でもテスト結果がいつでも見れる状態にしました。

#### ２．マニュアルテストと自動テストの結果を一つに集約したかった
テスト自動化後は、マニュアルテストと自動テストの実行結果を手動で集約した上で結果報告を行っていましたが、大変面倒な作業でした。
そのため、MagicPodの実行結果をTestRailに連係するようJenkinsに組み込むことで、面倒な作業を効率化しました。

# TestRailで自動テストを管理するメリット
TestRailにMagicPodの実行結果を連係させるようになり、背景にある2つの課題は解決しました。
背景に記載した内容では、「私には必要ない」と思った方も多いと思います。しかし、TestRailを使えば他のメリットも得ることができることに気づきました。
以下が私が考えているメリットです。
個人的には、特に1~3がとても役立っています。

#### １．どのテストが自動化されているのか管理できる
現在私が担当しているサービスでは、リグレッションテストを30%自動化しています。残りの70%はマニュアルテストで毎週実行しています。
そのため、 **「なにが自動化されていて、何をマニュアルテストで実施しなくてはならないのか」** を明確にする必要がありました。
それを解決するために、リグレッションテストケースの項目に、Automated項目を追加し、どのテストケースが自動化済みなのかを管理し、Automaded項目が「Manual」はマニュアルテストで実行し、「Automaded」は自動テストで実行されるようにしています。
また、「リグレッションテストがどれだけ自動化できているか」を計測する際にも使用することができます。

Manual：マニュアルテストで実行
Automated：自動テストで実行
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961957/6fe99007-ab81-57b0-e922-c46670d9436a.png)

#### ２．テスト結果に「失敗原因」などの情報を残すことができる
残念ながら2022/12現在、MagicPodでは [テスト結果にコメントや入力項目の追加などはできません](https://github.com/Magic-Pod/japanese-issue-and-doc/issues/488 "テスト結果に失敗原因などをユーザが入力できる欄がほしい")
しかし、TestRailの結果項目は、自身でカスタマイズすることができます。私は、以下の項目を追加し、テスト結果分析やレポートなどに使用しています。

**CIが自動入力する項目**
* CIのビルド結果URL
* MagicPodの実行結果URL
* アプリバージョン
* OS
* エラーログ　(Failedのみ)

**人が入力する項目**
* Issueのチケット
* 失敗原因
* 失敗原因カテゴリ
  * Test case (設計しているテストケースに問題がある)
  * Test data (自動テストで使用しているテストデータに問題がある)
  * Automation tool (自動テストツールに問題がある)
  * Terminal (実行端末に問題がある)
  * Network (ネットワークに問題がある)
  * App issue (アプリに問題がある)
  * Others (その他)

入力欄を作成したことによって、自動テスト結果分析の内容を実行結果に記載することができるようになりました。
E2Eの自動テストの実行結果は、様々な要因で失敗します。そのため、テスト結果分析はとても大事な工程であり、分析を間違えると「Issueを見逃す」「自動テストを壊す」などが起きてしまいます。
結果分析ログとして、テスト結果に失敗原因を記載するようにし、誰が見てもなにが原因で失敗しているのかわかるようになりました。
また、各テストがどのような原因で失敗しているのか履歴が残るため、「このテストケースは、よく○○が原因で失敗しているね」などもわかりやすくなっています。
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961957/0bdde1fc-52d6-5fe9-e6ac-788813955482.png)

#### ３．不安定なテストを通知させることができる
残念ながら2022/12現在、MagicPodでは [各テストケースごとの実行結果をAPI経由で取得ができません](https://github.com/Magic-Pod/japanese-issue-and-doc/issues/437 "1つのテストの過去の実行結果を専用のWeb APIで取得したい")
しかし、TestRailでは各テストケースごとの実行結果をTestRailの[get_results API](https://docs.testrail.techmatrix.jp/api/reference/results/ "https://docs.testrail.techmatrix.jp/api/reference/results/")で取得することができ、取得した情報を用いて以下のようなことが実装できます。
* 「X回中Y回失敗している」テストケースを通知する
* 「Z回連続で失敗している」テストケースを通知する

自動テストの結果確認を疎かにすると自動テストの意味がなくなってしまいますが、「実行結果を確認し忘れていた」ことを経験したことがある方もいるのではないでしょうか。
不安定な自動テストが多い場合、実行結果の信頼性が薄まり、次第に毎回は見なくなる…ということもゼロではないと思います。
また、実行頻度が多ければ多いほど、実行結果の確認も増え、確認漏れが起きる可能性があります。
そのような経験がある方は、「不安定なテストや連続で失敗しているテスト」を通知する機能があると、確認漏れを減らすことができると思います。

#### ４．テスト結果レポートをカスタマイズできる
残念ながら2022/12現在、MagicPodではテスト結果レポートの項目などを自分でカスタマイズはできません。
しかし、TestRailに結果を連係しておけば、TestRailのREPORTS機能を用いてテスト結果レポートをカスタマイズができます。
各プロジェクトで必要な項目を取捨選択できるのは嬉しいです。
https://docs.testrail.techmatrix.jp/customization/reports/introduction/
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961957/77968d45-1bae-0965-2f2c-60a6f17a93c0.png)

# 実行コード
汎用的に使えるようShellで書いています。
需要があれば公開しますので、ご興味ある方はQiita左上のハートボタンを押してください！50いいねで公開します😁
* 仕組みの詳細や必要な準備について
* MagicPodが出力するXMLから、TestRailのTEST RUNSに実行結果を連係するロジック
* TEST RUNSから「X回中Y回失敗している」テストケース判定するロジック

# まとめ
TestRailで管理するメリットを紹介しましたが、私が担当しているプロジェクトではメリットが多かったためTestRailを使用しています。
今後MagicPodで機能追加され、TestRailを使用せずMagicPodだけで完結できるようになる可能性もあると思います。
個人的には、特に以下がMagicPodでできるようになるととても嬉しいです😁
* テスト結果に「失敗原因」などの情報を残すことができる
* 不安定なテストを通知させることができる

※メリットばかりを紹介しましたが、TestRailとMagicPodの両方でテストケースを書いているため重複して管理することになるデメリットもありますので、必ずしもTestRailで管理する事が良いというわけではありません。