CRM 本番稼働のための UAT チェックリスト

UAT の前

うまくいかない UAT の多くは、ここでつまずきます。あいまいなスコープ、誰も確認していないスクリプト、使えるアカウントのないテスター。

スコープ

• UAT に含めるプロセスとユーザーストーリーを合意し、含めないものを書き出します。
• プロセスごとに業務部門のオーナー（サインオフする人）を決めます。
• 最初の課題が登録される前に、Critical、High、Medium、Low の意味を合意します。

テストケース

• 業務シナリオごとに 1 つのテストケースを、それをテストする人の言葉で書きます。
• すべてのステップに操作と期待結果を、必要に応じてテストデータを記載します。
• 各テストケースに Must、Should、Could を付け、重要なものから先にテストします。
• 異常系も加えます：誤った値、未入力の項目、適切なロールを持たないユーザーなど。
• スコープ内のすべてのユーザーストーリーに、少なくとも 1 つのテストケースがあることを確認します。
• テスト日の前に、業務部門のキーユーザーにスクリプトをレビューしてもらいます。

テスター

• システムを使うすべてのチームから、日々その業務を行っている人をテスターに選びます。
• 各テスターにグループと自分専用のスクリプトを割り当てます。
• テスト日をテスターの予定表で確保し、日常業務から外します。
• 30 分で説明します：結果の記録方法と課題の登録方法。

環境とテストデータ

• 本番に近いテスト環境を用意します：設定、連携、データ。
• ロールごとにテストアカウントを作成し、それぞれでサインインできることを確認します。
• テストデータを投入します：顧客、製品、価格表、未完了のレコード。
• できる限り、顧客データではなくテストデータを使います。
• テスト期間中に、修正をいつテスト環境へデプロイするかを合意します。

スケジュール

• テスト日をブロック単位で計画し、毎日決まった時間にトリアージを行います。
• 修正後の再テストラウンドの時間を確保します。
• go/no-go 会議の日程を決め、今のうちにステアリングコミッティを招待します。
• Salesforce や Dynamics 365 のリリースカレンダーを確認します。UAT の途中でプラットフォームのリリースがあると、テスト対象が変わります。

開始基準

• システムテストが完了し、そこで見つかった Critical の不具合が残っていない。
• テスト環境、テストアカウント、テストデータの準備ができている。
• 業務部門がテストケースをレビューした。
• すべてのテスターが招待され、一度サインインした。

UAT の最中

1 日を短く保ち、情報を 1 か所にまとめます。そうすれば、問題をその日のうちに見つけ、判断し、修正できます。

デイリースタンドアップ

• 毎日 15 分から始めます：何をテストしたか、何が妨げになっているか、今日は何を予定しているか。
• グループごとの進捗を計画と比べ、必要なところへテスターを移します。

課題の登録

• 問題ごとに 1 件の課題を、ステップ、期待したこと、実際に起きたことを添えて登録します。
• スクリーンショットとレコードへのリンクを添付します。
• 同じ問題が二重に登録されないよう、まず既存の課題を探します。
• 失敗したすべてのステップに、課題か、課題がない理由があることを確認します。

トリアージ

• トリアージは毎日、業務部門と開発チームが一緒に行います。
• 新しい課題それぞれに、重大度、優先度、修正担当者を割り当てます。
• 1 件ずつ判断します：修正する、却下する、または変更要求にする。
• 変更要求は今回のリリースに入れず、バックログに載せます。

再テスト

• 修正がデプロイされたら、課題を見つけたテスターに再テストしてもらいます。
• 各再テストを、どのリリースとビルドで行ったかを記録します。
• 大きな修正の後は新しいラウンドを始め、修正の周辺のプロセスも再テストします。

UAT の締めくくり

UAT は判断で終わります。事実にもとづいて判断し、誰が何を決めたかを記録します。

終了基準

• Must のテストケースがすべて合格している。
• Critical の課題が未解決で残っていない。
• 未解決の High の課題すべてに、業務部門が受け入れる回避策か修正予定日がある。
• スコープ内のすべてのテストケースに結果がある。

サインオフ

• 各プロセスのオーナーにサインオフを依頼します：承認、条件付き承認、または却下。
• すべての条件を、担当者と期限とともに記録します。

Go/no-go

• go/no-go 会議は、記憶ではなく画面に映した数値をもとに行います。
• 判断、条件、判断した人を記録します。

レポート

• スコープに含めたもの、そしてテストしなかったものを明記します。
• グループごと・優先度ごとの結果と、テストしたリリースとビルドを示します。
• 未解決の課題を重大度別に、それぞれの判断とともに一覧にします。
• サインオフを、その条件とともに添付します。
• 本番稼働後の最初の数週間に想定されるリスクと回避策を挙げます。

本番稼働の後

• テストケースは残しておきます。次の CRM リリースの回帰テストになります。
• 記憶が新しいうちに、次の UAT で変えるべきことを書き出します。