見出し画像

狼少年化していたMagicPodの自動テストの健全化

岡浩司(ektoji)

こんにちは、くふうAIスタジオでQAエンジニアをしている岡です。
トクバイアプリの開発において狼少年化していたMagicPodの自動テストの健全化の取り組み事例をご紹介します。


狼少年化していたMagicPod

トクバイアプリの開発時、ビルド毎にMagicPodを一括実行しています。
しかし、テスト自体の問題による失敗が多発しており、「テストが失敗した！」と通知しても、「またか。失敗しているけど本当に問題があるわけではないだろうから多分大丈夫だろう」と考えられていました。
これによりMagicPodは「狼少年」のように信頼を失っていました。
誤報を繰り返すことで災害時の避難率が下がることを狼少年効果と言うようですが、ここでは「狼少年化」と表現しています。

狼少年化の要因

1.テストデータ準備バッチが不安定

コンテンツに掲載期間の概念があり、テストの再現性(冪等性)を持たせるために毎日未明にテストデータ準備のバッチを実行していましたが、バッチの失敗で、正常にテストできずに失敗することがありました。

2.特定UIコンポーネントの不備

トクバイの特定のUIコンポーネントの実装がMagicPodの実行環境と相性が悪く、不定期で失敗するテストがありました。

3.実装変更に起因するテスト破壊

MagicPodの特性上、実機のキャプチャをしてテストを動かすので、実装を変えた時に壊れます。ただし、失敗すべきでない時に失敗しているため、本当に対処すべきエラーが埋もれやすくなっていました。

4.MagicPodのテスト結果のモニタリングの属人化

誤報率が高いため、「失敗したらまずメンテナーで見て、問題があれば知らせる」というフローになっていました。このことは、メンテナー以外は関心を持つ必要がなく、メンテナー以外が問題を正しく把握できないという状況を招きました。

5.ヘルススコアは体感的な「なんとなくやばい」と一致していない。

最近、自動化が成功しているかの指標であることがわかりました。ここを確認するのは見当違いでした。

MagicPodのアナリティクス上のヘルススコア

狼少年はどうすれば助かったのか

誤報を繰り返し狼少年化したMagicPodがスモークテスト（基本的な動作確認を行う簡易テスト）としての信頼を得るようにしたいのですが、MagicPodの実際の問題を解決する前に狼少年が救われるにはどうしたらよかったかを考えてみます。

仮説としては、普段から自分が嘘をついてしまうことを認め「これは嘘だが、狼が来た。」等と近所の人に冗談混じりで話していれば良好な関係が気づけて狼に立ち向かうことができたかもしれないとします。
狼少年に対する周囲の評価は、「興味を引くために嘘をつくが、嘘をついていることを必ず申告する哀れな少年」になっていたかもしれません。
実際に狼が来た時に「狼が来た。今度は嘘じゃないです」と言えば、多少は信じてもらえた可能性がありそうです。

MagicPodのエラー結果への信頼性の注入

1.Slack上でエラーのトリアージ結果を可視化

MagicPodの結果をTestrail等のテスト管理ツールに反映して、そこからテスト結果についてのモニタリングができれば理想ですが、月額を開発チームに全員に載せて費用対効果があるかは当社では微妙でした。

トリアージされたかをまず、MagicPod上にテスト結果のメモを残し、Slack上のWebhookに対するリアクションすることでエラーに対してモニタリングされていることがわかるようにします。

MagicPod上にテスト結果のメモを2024年1月から残せるようになったのでメモとして残すようにします。テスト結果一覧上メモが表示されるので、過去起きた問題なのか、新規の問題なのか、多少見通しが良くなります。

テストの実行結果上で一覧化されている

MagicPod テスト結果の通知はSlackに来るのでそのSlack通知に絵文字で:magicPod:リアクションすることで状況をSlack上で可視化します。

Slack通知に対する監視状況の可視化

2.検知とメンテナンスを分離し、検知を民主化する

明らかにUI実装が変わってロケータを録り直す場合についても、見つけてすぐ治せればいいのですが、テスト自体が不安定だったりしていてすぐに解決方法がわからないものもあります。
見つけたらそのまま直すまでの流れをセットでメンテナーが行っていたのですが、見つけたら、既存の問題か判別してNotionに情報登録するまでを分担作業にしました。

```mermaid
graph TD
		A'' --> A1

subgraph Slack前
	A[Slack上に失敗または要承認通知発生] 
	A  --> AA{Slackにリアクションがある}
	AA --> |No|A''[確認対応する人が :eyes:等でリアクション]
end
subgraph Slack後
	C3[Slack上の失敗または要承認通知に完了リアクションする]
end

subgraph Notion	
	B[Notion登録有無の確認]
	C{Notionタスク登録有無}
    C -->|有り| C1[Notionタスクのコメントにテスト結果のURLを記録]
    C1 --> C2[Notionタスクの期限の終了日を当日まで伸ばす]
    C2 --> C2'[該当週のレポートに掲示されるか確認する]
    C2' --> C3
    C -->|無し| D[Notionにタスク登録]
    D --> E[タスク登録結果がSlack通知される]
    E --> C2'
end


subgraph MagicPod
		A1[MagicPod実行結果の確認] 
		A1 --> A2[過去実行結果の参照]　
		A2 --> X{類似エラー有無}
		B
		X -->|有り| Z[MagicPodの結果に過去コメントをコピペ]　
		Z -->B
		X -->|無し| Y[MagicPodの結果に新規のコメントをする] 
end
		Y --> Y1{テストの問題か} 
		Y1 --> |Yes| B 
		Y1 --> |不明| Y2[最新の「デバッグ版」で再現確認] 
		Y2 --> Y3
		Y3{アプリのバグか}　
		Y3 --> |No|B
		Y3 --> |Yes|アプリエンジニアへ報告 --> B
    B --> C


```

3.定期的にレポートする

問題が直近、発生しているかどうか。対応したかどうか。テストを追加したかどうかを定期的に報告する形にしてエンジニアが情報を認識しやすくしました。
Notionに登録した情報をそのままレポート化するテンプレートに載せてわかりやすくすることで、問題とその対応状況を追跡しやすくなっています。

レポート一部抜粋

狼少年は信頼を獲得したのか

依然としてFlakyは残り続けていますが、失敗の意味がわかるようになった為、以前よりチームがMagicPodに対する理解を示すようになりました。実際にテストの失敗になっていた一部実装の修正をエンジニアが提案してくれるきっかけにもなっています。

MagicPod自体は日々便利になっていますが、つい先日の更新でも生成AIによるテストケース全体や修正の要約機能が実装されたので、こちらも併用できればと考えています。

あまりシステマティックなやり方ではありませんが、エラーが起きた時のメンテナーの絶望感や孤独感も軽減しましたので、似たような悩みを抱える方のご参考になれば幸いです。

この記事が気に入ったらサポートをしてみませんか？