ECサイトの全面リニューアルにあたり、公開前の機能テストと、既存機能への影響を確認する回帰テストをお引き受けしました。開発メンバーだけでは手が回らなかった購入フロー周辺を中心に、PC・スマートフォンの両方で検証しています。
ご相談の背景
リニューアルの公開日が先に決まっており、開発の終盤にテスト期間が圧縮されていました。社内にテスト専任の担当者がおらず、開発を担当したメンバーが自分の実装した箇所を確認する状態が続いていたため、「見落としが出ていないか不安がある」というご相談をいただきました。
特に懸念されていたのは、決済とクーポン適用の組み合わせでした。仕様が段階的に追加された経緯があり、条件の組み合わせが増えたぶん、どこまで確認できているか把握しきれていない状況でした。
実施した内容
最初の1週間で画面仕様書と既存サイトを読み込み、テスト観点の洗い出しからご一緒しました。そのうえで、以下の流れで進めています。
- 購入フロー（カート投入から注文確定まで）を軸にしたテスト項目の作成
- 会員・非会員、クーポンの有無、配送方法の組み合わせによる網羅テスト
- リニューアルで変更していない既存機能に対する回帰テスト
- 主要ブラウザおよびiOS／Androidの実機での表示・動作確認
- 不具合票の起票と、修正後の再テスト
テストケースは最終的に約600件になりました。組み合わせが膨らむクーポン適用の部分は、条件を整理したうえで確認する範囲を絞り込み、限られた期間でも判断に必要な情報が揃うようにしています。
検出した不具合
期間中に報告した不具合は30件強でした。うち公開前の修正が必須と判断されたものは数件で、いずれも単体では気づきにくい条件の重なりで発生するものでした。
- 特定のクーポンと送料無料条件が重なったときに、請求金額の表示が実際の決済額とずれる
- スマートフォンで戻る操作をした際に、カートの数量が更新前の値に戻る
- リニューアル対象外だったお問い合わせフォームで、リンク先が旧ページのまま残っている
3つ目のように、変更していないはずの箇所で起きる不具合は、開発側のチェック対象から外れがちです。回帰テストを別に用意しておく意味が出るのはこうしたケースです。
担当者より
公開日が動かせない案件では、すべてを均等に確認するより、影響の大きい導線から順に潰していく判断が必要になります。今回は購入フローと金額計算を優先度の最上位に置き、そのぶん管理画面側の確認は範囲を限定させていただきました。どこを厚く見てどこを薄くするかは、事前にご相談のうえ決めています。
