チーム単位など複数人でMagicPodを使用する場合、導入初期に運用ルールを定めることをお勧めします。ここでは運用ルールの例を紹介します。
また、MagicPodの運用面に関して紹介いただいているユーザー様のブログもございますので、ぜひご覧ください。
テストケース作成・更新
- テストケース作成方針を定める
- 作成するテストケースの優先度づけを行いましょう。最初は10テストケース程度作成し、その後はヘルススコアをグリーンに保ちながら徐々にテストケースを増やすと良いでしょう。
- 大幅な変更が予定されている画面についてはテストケースを追加しないことをお勧めします。
- テストケース更新方針を定める
- 画面・機能に変更があった際、いつテストケースを更新するかを決めましょう。事前に開発者から変更点が共有される仕組みを整えておくと効率的にテスト失敗理由の調査ができます。
- テストケース更新時は履歴機能で記録を残す
- レビュアーを決め、テストケース作成・更新時はブランチ機能、履歴機能を用いてレビューする
コメント/空行ルールを決める
- UI要素の命名規則を決める
- 「領域(3)」「ボタン(1)」などの要素を特定できない命名は、テストケースの内容把握が困難になるため望ましくありません。何の要素であるか一目で分かる名前をつけるようにしましょう。
- 共有ステップ化する条件を決める
- ログイン処理は複数のテストケースで使用されるため、共有ステップ化すると良いでしょう。
- 2個以上のテストケースで使用される5行以上のステップは共有ステップ化する、などの条件を定めている事例もあります。
テストケース管理
- テストケースの命名規則を決める
- テストケースの説明欄に記載する内容を決める
- UI整理ルールを決める
- ラベル運用ルールを決める
- フォルダ運用ルールを決める
- ブランチ運用ルールを決める
定期実行
- テスト実行スケジュールをチーム内で共有する
- クラウド端末/ブラウザに空きがある時間を可視化することをお勧めします。
定期実行用のユーザーアカウントを作成する
- 定期実行の設定を変更する際に共有するルールを設ける
- 定期実行の設定を別のメンバーが変更してしまった結果、意図せずテストが失敗するといった問題を未然に防ぐことができます。
テスト結果の確認
- 定期実行したテスト結果をいつ誰が確認するか定める
- Slack通知、メール通知を設定することをお勧めします。
- 参考：テスト結果を通知する
- フレーキー(結果が不安定)なテストへの対応方法を決める
- 「Flaky」ラベルを付与し、定期実行対象から一時的に除外する、MagicPodサポートに問い合わせる等の方法がございます。
- 参考：テストの安定性を向上させるには
開発者との連携
- テスト失敗原因の調査やテスト安定化のためアプリ開発者と連携する体制をつくる
組織・プロジェクト
- 権限管理方針を定める
- プロジェクト別にメンバーを管理する必要がある場合、早めに権限管理機能を有効化しましょう。
- 離任時にユーザー削除を行うルールを設ける
- (エンタープライズプラン契約者限定) 組織専用ユーザーや接続元IPアドレス制限でセキュリティ面を強化する
その他
- 毎週ヘルススコアを確認する
- MagicPod Web APIを用いてSlackなどで通知する方法もお勧めです。
新メンバーへのオンボーディング方法を決める