プロジェクトマネージャーのchakiです。某企業のECサイトリニューアルプロジェクトで受入れテスト（UAT）を担当した時のことをご紹介します。
◆プロジェクトマネジメントへの期待値と支援領域
プロジェクトのミッションは、クライアントのECサイトリニューアルを成功へ導くことです。プロジェクトはキックオフからローンチするまで、さまざまなフェーズがあります。今回は以下のフェーズをグッドパッチが支援しました。
支援領域
A：グッドパッチがフェーズのリードを行った領域 ／ B：グッドパッチがプロジェクト並走した領域
普段、クライアントはパートナー会社と協力し、ECサイトの運用や機能追加を行っています。しかし大規模なデザイン変更やプラットフォーム切り替えを伴うプロジェクトはクライアントにとって初めてでした。グッドパッチはクライアントに寄り添い、プロジェクトを並走しました。
プロジェクトの関係各社
経緯
クライアント側で大規模なデザイン変更やプラットフォーム切り替えを伴うプロジェクトの受入れテストのナレッジが十分になかったため、受入れテストのケイパビリティがあるグッドパッチでリードすることとなりました。
◆今回の受入れテストの観点
リニューアルプロジェクトで実施したことは「メイン導線のUIの変更」と「プラットフォーム一部変更」です。画面だと以下の領域がそれに当たります。
- トップページ
- 商品を探す各種ページ
- 商品の詳細を表示する各種ページ
- 商品の購入を行う各種ページ
具体的に受入れテストで確認すべき観点は以下と整理しました。
| 1. 新UIが適用されているか | |
|---|---|
| 新UIが適用されているか | |
| 写真やイラストが鮮明な表示であるか | |
| アニメーションが適用されているか | |
| 動的要素でデザイン崩れがないか | |
| 2.機能が正しく動作しているか（特に動的ページ） | |
| URL、タイトルタグ、パン屑が正しく挙動しているか | |
| 動的共通コンテンツが正しく表示・動作しているか | |
| 静的共通コンテンツが正しく表示・動作しているか | |
| 画面内に表示されている各機能が動作するか、表示速度が適切か | |
| エラーやブランク時など適切な表示がなされるか | |
| キャンペーン、ABテスト、数値検証、入稿業務、時限発火など、各機能が挙動し運用に支障が出ないか | |
| 3. サイト内でのリンク先が正しいか、リンク切れが発生していないか | |
| ヘッダー・フッターのリンク集に誤りがないか | |
| 新規ページへダイレクトアクセスできるか、ページ内でリンク切れがないか | |
| 動的ページ（カテゴリや商品ページ等）へダイレクトアクセスできるか、ページ内でリンク切れがないか | |
| サイトマップページにダイレクトアクセスできるか、ページ内でリンク切れがないか | |
| 閉鎖したページは404の表示になるか | |
| 4. お客さまに各種サービスを提供するにあたり、機能全般が正しく動作しているか | |
| シナリオ1：トップページからカテゴリをたどり商品を初購入、マイページで履歴を確認 | |
| シナリオ2：ログイン状態からキーワード検索で商品を確認、お気に入りに入れる、前回のポイントを利用して購入、マイページで履歴を確認 | |
| シナリオ3：購入商品が届かないので、メールから購入履歴を確認し、問い合わせをする | |
| 5. お客さまに各種サービスを提供するにあたり、情報のデグレが発生していないか | |
| 4回前（4週間前）リリースした情報が反映されている | |
| 3回前（3週間前）リリースした情報が反映されている | |
| 2回前（2週間前）リリースした情報が反映されている | |
| 前回（1週間前）リリースした情報が反映されている | |
◆受入れテストのその後
受入テストの観点ができたのち、以下の内容をクライアントやシステム開発会社とすり合わせながらリリースまで遂行しました。
観点を作成した後の流れ
- 受入れテスト観点をクライアント内ですり合わせ
- テストケースへの落とし込み（550ケース）
- 受入れテストの前提条件の設計（テスト環境、前工程の終了状況、データの登録状態など）
- テストケースの担当割りとスケジュール日程作成
- 不具合検知時の開発連携方法の手配
- 受入れテストの実施
- 不具合の起票と、不具合の消化状況レポート
- クライアントとリリース判定
- リリース
結果として、受入れテストは5名体制で4日間で完了しました。不具合を起票し、リリースできる状態に持っていくまではさらに3週間ほどかかりました。 致命的なもの、デバイス起因、今回実装で手を入れていない画面への影響など、幅広く検知することができました。
◆まとめ
受入れテストは納品検収の一部となることもあるため、基本的には発注元となるクライアント企業側にて実施されることが多いと思います。一方でクライアントだけで実施することに不安を感じられる企業も多いと考えています。
グッドパッチはクライアント側に立つため、受入テストをクライアントと共に行うこととなりました。受入テストで致命的な不具合検知ができたので、品質を高めることにも貢献できました。
デザインやシステムを作るだけでなく、ユーザーに提供し利用してもらう（なんならリピートしてもらう）までがひとくくりと考えているので、品質は重んじるべきと考えています。 個人的なこだわりも入っていますが、これからも品質重視で邁進していきます。
