MagicPodのテスト自動化ヘルススコアはどうやって決まるのか

2024年7月5日に行われた【有料プランユーザー限定×オフライン】MagicPodミートアップ ヘルススコアNightでの発表資料です。

Transcript

1. MagicPodのテスト自動化ヘルススコアは どうやって決まるのか MagicPod ミートアップ ヘルススコアNight 2024-07-05
2. 自動テストツール開発歴：15年目 Seleniumコミュニティ主催 Selenium実践入門執筆（共著） About me 伊藤 望 Ito Nozomi 株式会社MagicPod CEO Selenium実践入門 自動化による継続的なブラウザテスト 技術評論社
3. ヘルススコア みなさん活用してますか?
4. 予約サイトのテスト ログインページ 予約サイトのテスト ログインページ 「プロジェクト」の「アナリティクス」タブに表示されるスコア 自動化プロジェクトの健全度合いを測定 「ヘルススコア」とは 「プロジェクト」内の「アナリティクス」タブ
5. 直近1週間の情報をもとに計算 APIを使えば、過去データや4週間スコアなども取得可能 100点満点 80点以上がグリーン、80-50点がオレンジ、50点未満がレッド 「ヘルススコア」とは 80点以上 80-50点 50点未満
6. スコアを上げるための改善アクションも提案 「ヘルススコア」とは 改善ポイント
7. 1 2 1 5 「ヘルススコア」と自動化継続率の関係 ヘルススコアの高いプロジェクトほど自動化が持続 レッドからオレンジに上がると、解約率が 以下に レッドからグリーンに上がると、解約率が 以下に
8. ヘルススコアのメリット 健全度を定量的に測定することで改善できるようになる 改善アクションが一目でわかる チーム全員で共通の物差しを持つことができる
9. 今日のテーマ ヘルススコアの 計算ロジックが知りたい！
10. ヘルススコア 計算ロジック概要
11. 100点満点 80点以上がグリーン、80-50点がオレンジ、50点未満がレッド 1週間・1ヶ月などの単位で計算 ヘルススコア計算ロジック概要 35点 作ったテストは1日1回以上回しているか 35点 回しているテストは成功しているか 20点 メンテナンスしやすいテストの作りか 10点 その他 ざっくり内訳
12. ヘルススコアは、 「テストから信頼性のあるフィードバックを毎日得られ るか」かを測定している 「コスト削減できたか」とか「バグを見つけたか」とかではない 35点 作ったテストは1日1回以上回しているか → テストからフィードバックを早いサイクルで得ているか 35点 回しているテストは成功しているか → テストのフィードバックに信頼性があるか 20点 メンテナンスしやすいテストの作りか → テストのフィードバックの信頼性を持続できる作りになっているか 10点 その他 ヘルススコア計算ロジック概要
13. ヘルススコア 計算ロジック詳細 ※2024年7月時点
14. ヘルススコア計算ロジック詳細 項目 点数 1. 十分な数のテストがあるか 6点 2. 十分な数のメンバーがプロジェクトにいるか 3点 3. 共有ステップを活用しているか 8点 4. 1つのテストが長すぎないか 5点 5. テストが安定するロケーターを使っているか 8点 6. テストを1日1回以上実行しているか 35点 7. テストの失敗率が高すぎないか 35点
15. 1. 十分な数のテストがあるか(6点) ある程度の数がないと、 自動テストで得られるメリットが限定的 20テスト以上で満点
16. 2. 十分な数のメンバーが プロジェクトにいるか(3点) 他のメンバーも巻き込むのが継続の秘訣 所有者含め4人以上で満点 組織の規模によって望ましい人数が 違ってくるのが難しい
17. テスト数の10-20%程度の数の共有ステップ を作っていると満点 満点ラインはテスト数によって変わる テスト数が多いほど必要パーセンテージは 下がる 共通化をしないとメンテナンスが大変になる 3. 共有ステップを活用しているか(8点)
18. エラー切り分けが大変になるので、 不必要に長いテストは避けるべき 4. 1つのテストが長すぎないか(5点) ブラウザテストは300ステップ以上、モバイルアプリテストは200 ステップ以上で長いテスト扱い ブラウザテストの方が1画面あたりの項目量が多くテストも長い 長いテストが全体の10%以内なら満点 長くせざるを得ないテストはあるので、満点ラインはそこまで厳しく してない
19. テストケースが8個未満の場合、一部の項目は満点でも減点される テスト数がそもそも少ない場合に良いスコアが出てしまうのを防ぐため 補正がかかるのは、 「4. 長いテスト」 「5. 安定ロケーター」 「6. テスト実行回数」 「7. テスト 失敗率」の４項目 関係ない項目で「改善ポイント」として「テストケース数を増やす」が出る ことがある 改善ポイント テストケース数による補正
20. 5. テストが安定するロケーターを 使っているか(8点) 複雑なロケーターは画面変更に弱い テスト内で使っているロケーターの80%以上が 安定ロケーターなら満点
21. ただし30文字を超えると不安定扱い テストで使う要素には、アプリ側 で要素を特定できるid・属性・テ キストをつけることを推奨 何が安定したロケーターか 安定ロケーター 不安定ロケーター ・idとaccessibiliy id 他は全て不安定扱い ・ 「#id」のCSSセレクター ・//xxx[yyy='zzz']形式のxpath 属性やテキストで要素が一意に特定されるもの containsやstarts-withもOK -ios class chainやCSSセレクターでも同様のも のはOK
22. 毎日回していないテストは 結局メンテナンスできなくなる 6. テストを 1日1回以上実行しているか(35点) 全てのテスト(または60テスト以上)を1週間のうち4.2日(平均平日日数) 以上一括実行していると満点 多少抜け穴はあり (実行したテスト数 x テスト実行日数) / (作成済テスト数 x 平日の日数)
23. 7. テストの失敗率が高すぎないか(35点) 失敗率が高いのはメンテナンスされていないサイン 一括実行の成功+要確認の割合が90%以上なら満点 要確認はメンテナンス容易なので健全扱い テスト実行回数のスコアが低い場合、それに応じて さらに減点される
24. まとめ 項目 点数 1. 十分な数のテストがあるか 6点 2. 十分な数のメンバーがプロジェクトにいるか 3点 3. 共有ステップを活用しているか 8点 4. 1つのテストが長すぎないか 5点 5. テストが安定するロケーターを使っているか 8点 6. テストを1日1回以上実行しているか 35点 7. テストの失敗率が高すぎないか 35点
25. ヘルススコアを活用して より良いテスト自動化ライフを！