MagicPod Web APIを利用し、MagicPod一括実行結果と手動テスト結果を統合する

株式会社スタンバイ QAグループ（Quality Assurance Group）の樽井です。

「自動テストは広範囲で失敗しているが、手動テストではどの機能が影響を受けているのかわからない…」

リグレッションテストの際、こんな状況に陥ったことはありませんか？
私達のチームでは、この自動テストと手動テストの結果が分断されていることが、問題発見の遅れや、不具合の見逃しリスクにつながっていました。

本記事では、MagicPod Web APIを使ってどのように解決したのか、その具体的な取り組みをご紹介します。
MagicPod導入について興味のある方は、過去記事の「スタンバイ QAのテスト自動化導入（MagicPod）」をご確認下さい。 techblog.stanby.co.jp

なぜテスト結果を統合するのか

モバイルアプリ（以降App）のリグレッションテストは、MagicPodによる自動テストとQA担当者による手動テストを併用しています。リグレッションテストの各項目には、MagicPodシナリオ（以降シナリオ）のIDが紐づけられており、どのシナリオがどの項目を担っているかを把握するに留まっていました。
ここでのリグレッションテスト（回帰テスト・退行テスト）は、ソフトウェアの機能追加や不具合修正、環境変更などのプログラム変更によって、それまで正常に動作していた機能に新たな不具合が発生していないか確認するテストを指します。

API利用以前のリグレッションテスト

問題は、シナリオ一括実行で複数シナリオが失敗した際、影響範囲の特定に多大な時間がかかっていたことでした。

手動テストは一項目ずつ実施するため、リグレッションテストの項目上で、どの機能がNGであったかすぐに分かります。しかし、MagicPodの一括実行結果は、ツール上でどのシナリオが失敗したか分かりますが、それが具体的にどの機能への影響を意味するのか、即座に判断するのは困難でした。

特に広範囲で失敗している場合、それがインフラの問題なのか、共通コンポーネントのデグレなのか、はたまたテスト環境の不調なのか…。原因を切り分けるために、ひとつひとつの実行結果ログを追い、開発者にヒアリングし… という非効率な調査が発生していました。

この調査の遅れは、不具合の発見が遅れるリスクに直結します。自動テストと手動テストが独立しすぎているこの状況をなんとかしたいと考え、両者のテスト結果を統合し、一目で比較できるようにすることを決めました。

MagicPod Web APIの利用

スタンバイでは、リグレッションテストをスプレッドシートで管理しているため、MagicPodヘルプセンターの「MagicPodが提供するWeb APIの使用方法」を参考に、シナリオ一括実行結果をスプレッドシートへ出力することにしました。
MagicPod Web APIをどのように活用していくのかはまだ検討段階のため、所々既存システムを利用し、最小限のコード作成としています。