毎朝の自動テスト結果をKickRailで確認する

こんにちは、QAチームのNです。

先日、社内テスト管理ツール「KickRail」についての記事が公開されました。

テスト管理ツール「KickRail」を内製した話

この記事では、川村さんがKickRailを立ち上げてくれた背景や、Qaseからの移行、MCP連携まで含めた全体像が紹介されています。

今回はその続きとして、KickRailという土台に、PlaywrightとPostmanで毎晩実行している自動テストの結果をどう載せていったかを書きます。

なぜ集約したかったのか
全体像
Playwright結果をファイル単位で見る
実装でつまずいたところ
- 古いRunに新しい結果が入る
- 結果ファイルが大きすぎる
Postman結果もKickRailへ
集約して変わったこと
やってよかった設計
まとめ

やったことを一言でいうと、GitHub ActionsやSlack通知に散らばっていた毎晩の自動テスト結果を、QAが毎朝見るテスト管理画面に集めました。

なぜ集約したかったのか

kickflowでは、複数の自動テストを毎晩定期実行しています。この記事では、この毎晩の定期実行をnightlyと呼びます。

そのうち、今回KickRailに集約したのは次の2つです。

種類	見ていること	規模感
Playwright	ブラウザ上でユーザー操作に近い流れを確認するE2Eテスト	シナリオファイル500本超を20シャード並列で実行
Postman	APIのUnit / Integration / Rate Limitなど	collection / folder単位で実行

これまでも、GitHub Actionsの結果やSlack通知、PlaywrightのHTMLレポートを見ることで、テスト結果は確認できていました。

ただ、日々のQA運用としては「確認口が多い」ことが少しつらくなっていました。

Playwrightでは、毎朝次のようなことを確認したいです。

500本超のシナリオが、今日の実行で確実にPassしているか
NGになったものを確認漏れなく拾えているか
retry後に通ったものや、再実行で通る一時的な失敗として手動確認済みにしたものが分かるか

もちろん、既存の通知で何も見えていなかったわけではありません。 PlaywrightはSlack通知で成功/失敗の概要や、失敗したシナリオは分かるようになっていました。

ただ、Slack通知は「その1回の結果」を見るには便利な一方で、500本超のシナリオを一覧しながら、どれがPassでどれがFailなのかを確認するには少し見づらさがありました。

PostmanはPlaywrightとは別の通知として流れていて、エラーがあったときはGitHub Actionsのログまで見に行く必要がありました。

Slack通知やGitHub Actionsは、実行結果を知る場所としては便利です。でも、QAが毎朝見るには少し散らばっています。

QAとして見たいのは、「今日のRunは全部確認できたか」「NGを見落としていないか」「再実行してOKだったものはどれか」です。

それなら、手動テストと同じようにKickRail上で見られるようにしたいと考えました。

全体像

今回作った流れは、大きく3つです。

GitHub Actions nightly
  ├─ Playwrightを20シャードで実行
  │   ├─ results.jsonを軽量化
  │   └─ KickRailのPlaywrightタブへ登録
  │
  ├─ Playwright retry
  │   └─ 直近のnightly Runへ追記だけ行う
  │
  └─ Postman collection run
      └─ KickRailのAPI Testsタブへ登録

Playwrightは、ファイル単位で結果をKickRailに登録しています。

Postmanは、collection / folder単位の実行結果をKickRailのAPI Testsタブに登録しています。

KickRail側では、手動テストと同じ感覚で、Passed / Failed / Skipped / Blocked / 再実行OK / 手動確認OK / 未実施のようなステータスを扱えるようにしました。

これにより、単なるCI結果ではなく、「QAとしてどう判断したか」まで残せます。

Playwright結果をファイル単位で見る

Playwrightの結果は、.spec.tsファイル単位でKickRailに登録します。

ファイルパスをもとにハッシュ化したexternal_idを作り、1つのRun内では同じファイルが1行になるようにしています。

ファイル名や画面表示名ではなく、ファイルパスをもとにIDを作ることで、CIから同じケースに紐づけやすくしています。

ステータスは、PlaywrightのJSONレポートを集計して決めます。

ファイル内に1つでも失敗したテストがあれば failed
retry後に通ったものは、retry結果を残したうえで最終的な確認ステータスとして passed
すべてskipなら skipped

ここでは、CIで自動判定できる結果と、QAが確認してから決めたい判断を分けて扱えるように、ステータスを用意しました。

CIからは passed / failed / skipped を登録します。その後、QAがKickRail上で「再実行OK」「手動確認OK」「Blocked」などに変更できるようにしました。

自動判定だけで閉じず、人の判断を残せるようにしたのがポイントです。

実装でつまずいたところ

実装では、いくつかハマりました。ここでは特に効いたものを2つだけまとめます。

古いRunに新しい結果が入る

当初は「最新のActiveなnightly Run」に結果を追記していました。すると、前日以前のRunがActiveのままだったときに、今日の結果が古いRunに入ってしまいます。

対策として、Playwright同期の動きを2つに分けました。

モード	使う場面	動き
create-or-append	nightly本体	当日のActive Runがあれば追記、なければ新規作成
append-only	retry	直近のnightly Runに追記だけする。新しいRunは作らない

さらにKickRail側でも、新しいnightly Runを作るときに、前日以前のsource = nightlyのActive Runだけを自動でCompleteにするようにしました。手動Runやブランチ確認用Runまで閉じないようにしたのがポイントです。

結果ファイルが大きすぎる

もう1つ大きかったのが、KickRail同期ステップに到達しない問題です。

ある日のnightlyで、report mergeジョブがディスク容量不足でランナーごと落ちていました。同じジョブの後続ステップに置いていたため、if: always()を付けていたKickRail同期処理にも到達できませんでした。

一因は、Playwrightのresults.jsonが想像以上に重かったことです。失敗時のスクリーンショットなどがbase64で入り、HTMLレポート用の成果物などと合わせてディスク容量を圧迫していました。

一方で、KickRail同期に必要なのは、主にstatus / duration / retry結果などの限られた情報です。そこで、シャードごとにresults.jsonを軽量化してからartifactにし、同期も独立したkickrail-syncジョブに分けました。

削ったのは、KickRail同期に不要なスクリーンショットなどの添付データ、ログ、詳細ステップ情報などです。あるシャードでは、数十MBあったファイルが数十KBまで小さくなりました。 HTMLレポートとKickRail同期は、別の経路にした方が扱いやすかったです。

Postman結果もKickRailへ

Playwrightとは別に、PostmanのAPIテスト結果もKickRailに登録しています。

Postman側は、collectionとfolderを指定して実行し、JSONレポートをKickRailのAPI Testsタブへアップロードします。

Postman collection run
        ↓
folder-run.json を出力
        ↓
upload-to-kickrail.sh でアップロード
        ↓
KickRail API Testsタブに登録

Postmanのレポートも、そのまま送ると大きくなりがちです。

そこで、成功したリクエストの詳細なbodyなどは残さず、失敗時も調査に必要な範囲だけに絞るようにしました。

ここでも、全部を保存するのではなく、毎朝の確認と原因調査に必要な量だけを扱うようにしています。

集約して変わったこと

今は、毎朝の確認でKickRailを開けば、PlaywrightとPostmanの結果を同じKickRail上で確認できます。

見えるようになったのは、単なるpass/failだけではありません。

Runごとの結果
ファイル単位の失敗
NGの確認状況
retryや手動確認を含めた判断
担当者
DoneになったRun
APIテストの失敗詳細

これまでGitHub Actions、HTMLレポート、Slackを行き来していたものが、QAの確認画面に寄ってきました。

もちろん、詳しいログやスクリーンショットを見るときはGitHub ActionsやHTMLレポートを見ます。

やってよかった設計

今回やってよかったと思っているのは、このあたりです。

設計	よかったこと
nightlyとretryでモードを分ける	retryが独立Runを作らなくなった
前日以前のnightly Activeだけ自動Complete	古いRunへの上書きを防げた
results.jsonを軽量化	同期用artifactが小さくなった
同期ジョブを独立させる	report mergeの失敗に巻き込まれにくくなった
Postmanレポートを必要な情報に絞る	必要な情報だけ残せた
人の判断ステータスを残す	「再実行OK」「手動確認OK」を共有できる