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

by MagicPod

Slide 1

Slide 1 text

MagicPodのテスト自動化ヘルススコアはどうやって決まるのか MagicPod ミートアップヘルススコアNight 2024-07-05

Slide 2

Slide 2 text

自動テストツール開発歴：15年目 Seleniumコミュニティ主催 Selenium実践入門執筆（共著） About me 伊藤望 Ito Nozomi 株式会社MagicPod CEO Selenium実践入門自動化による継続的なブラウザテスト技術評論社

Slide 3

Slide 3 text

ヘルススコアみなさん活用してますか?

Slide 4

Slide 4 text

予約サイトのテストログインページ予約サイトのテストログインページ「プロジェクト」の「アナリティクス」タブに表示されるスコア自動化プロジェクトの健全度合いを測定「ヘルススコア」とは「プロジェクト」内の「アナリティクス」タブ

Slide 5

Slide 5 text

直近1週間の情報をもとに計算 APIを使えば、過去データや4週間スコアなども取得可能 100点満点 80点以上がグリーン、80-50点がオレンジ、50点未満がレッド「ヘルススコア」とは 80点以上 80-50点 50点未満

Slide 6

Slide 6 text

スコアを上げるための改善アクションも提案「ヘルススコア」とは改善ポイント

Slide 7

Slide 7 text

1 2 1 5 「ヘルススコア」と自動化継続率の関係ヘルススコアの高いプロジェクトほど自動化が持続レッドからオレンジに上がると、解約率が以下にレッドからグリーンに上がると、解約率が以下に

Slide 8

Slide 8 text

ヘルススコアのメリット健全度を定量的に測定することで改善できるようになる改善アクションが一目でわかるチーム全員で共通の物差しを持つことができる

Slide 9

Slide 9 text

今日のテーマヘルススコアの計算ロジックが知りたい！

Slide 10

Slide 10 text

ヘルススコア計算ロジック概要

Slide 11

Slide 11 text

100点満点 80点以上がグリーン、80-50点がオレンジ、50点未満がレッド 1週間・1ヶ月などの単位で計算ヘルススコア計算ロジック概要 35点作ったテストは1日1回以上回しているか 35点回しているテストは成功しているか 20点メンテナンスしやすいテストの作りか 10点その他ざっくり内訳

Slide 12

Slide 12 text

ヘルススコアは、「テストから信頼性のあるフィードバックを毎日得られるか」かを測定している「コスト削減できたか」とか「バグを見つけたか」とかではない 35点作ったテストは1日1回以上回しているか → テストからフィードバックを早いサイクルで得ているか 35点回しているテストは成功しているか → テストのフィードバックに信頼性があるか 20点メンテナンスしやすいテストの作りか → テストのフィードバックの信頼性を持続できる作りになっているか 10点その他ヘルススコア計算ロジック概要

Slide 13

Slide 13 text

ヘルススコア計算ロジック詳細 ※2024年7月時点

Slide 14

Slide 14 text

ヘルススコア計算ロジック詳細項目点数 1. 十分な数のテストがあるか 6点 2. 十分な数のメンバーがプロジェクトにいるか 3点 3. 共有ステップを活用しているか 8点 4. 1つのテストが長すぎないか 5点 5. テストが安定するロケーターを使っているか 8点 6. テストを1日1回以上実行しているか 35点 7. テストの失敗率が高すぎないか 35点

Slide 15

Slide 15 text

1. 十分な数のテストがあるか(6点) ある程度の数がないと、自動テストで得られるメリットが限定的 20テスト以上で満点

Slide 16

Slide 16 text

2. 十分な数のメンバーがプロジェクトにいるか(3点) 他のメンバーも巻き込むのが継続の秘訣所有者含め4人以上で満点組織の規模によって望ましい人数が違ってくるのが難しい

Slide 17

Slide 17 text

テスト数の10-20%程度の数の共有ステップを作っていると満点満点ラインはテスト数によって変わるテスト数が多いほど必要パーセンテージは下がる共通化をしないとメンテナンスが大変になる 3. 共有ステップを活用しているか(8点)

Slide 18

Slide 18 text

エラー切り分けが大変になるので、不必要に長いテストは避けるべき 4. 1つのテストが長すぎないか(5点) ブラウザテストは300ステップ以上、モバイルアプリテストは200 ステップ以上で長いテスト扱いブラウザテストの方が1画面あたりの項目量が多くテストも長い長いテストが全体の10%以内なら満点長くせざるを得ないテストはあるので、満点ラインはそこまで厳しくしてない

Slide 19

Slide 19 text

テストケースが8個未満の場合、一部の項目は満点でも減点されるテスト数がそもそも少ない場合に良いスコアが出てしまうのを防ぐため補正がかかるのは、「4. 長いテスト」「5. 安定ロケーター」「6. テスト実行回数」「7. テスト失敗率」の４項目関係ない項目で「改善ポイント」として「テストケース数を増やす」が出ることがある改善ポイントテストケース数による補正

Slide 20

Slide 20 text

5. テストが安定するロケーターを使っているか(8点) 複雑なロケーターは画面変更に弱いテスト内で使っているロケーターの80%以上が安定ロケーターなら満点

Slide 21

Slide 21 text

ただし30文字を超えると不安定扱いテストで使う要素には、アプリ側で要素を特定できるid・属性・テキストをつけることを推奨何が安定したロケーターか安定ロケーター不安定ロケーター・idとaccessibiliy id 他は全て不安定扱い・「#id」のCSSセレクター・//xxx[yyy='zzz']形式のxpath 属性やテキストで要素が一意に特定されるもの containsやstarts-withもOK -ios class chainやCSSセレクターでも同様のものはOK

Slide 22

Slide 22 text

毎日回していないテストは結局メンテナンスできなくなる 6. テストを 1日1回以上実行しているか(35点) 全てのテスト(または60テスト以上)を1週間のうち4.2日(平均平日日数) 以上一括実行していると満点多少抜け穴はあり (実行したテスト数 x テスト実行日数) / (作成済テスト数 x 平日の日数)

Slide 23

Slide 23 text

7. テストの失敗率が高すぎないか(35点) 失敗率が高いのはメンテナンスされていないサイン一括実行の成功+要確認の割合が90%以上なら満点要確認はメンテナンス容易なので健全扱いテスト実行回数のスコアが低い場合、それに応じてさらに減点される

Slide 24

Slide 24 text

まとめ項目点数 1. 十分な数のテストがあるか 6点 2. 十分な数のメンバーがプロジェクトにいるか 3点 3. 共有ステップを活用しているか 8点 4. 1つのテストが長すぎないか 5点 5. テストが安定するロケーターを使っているか 8点 6. テストを1日1回以上実行しているか 35点 7. テストの失敗率が高すぎないか 35点