連携の遅延中に売り止めが反映されず、同じ客室が二重に予約される
PMSやサイトコントローラーとの在庫同期が遅延すると、売り止めの反映が間に合わず、販売済みの客室へ予約が入り、二重販売となります。
GENZ, Inc.
宿泊施設担当者様へ
予約エンジンの
宿泊施設担当者様へ
予約エンジンの料金と在庫連携を第三者がテスト検証
予約エンジンの改修後、確認済みと未確認の範囲を分けて説明できないままリリース判断を迎えていませんか。GENZは検証範囲の線引きを成果物としてお渡しします。
支援事例
支援実績5,000件以上
予約エンジン（システム）でよくある不具合
予約エンジンの不具合は、在庫・料金・連携・取消処理のどこで起きるかで影響の出方が変わります。ここでは、宿泊施設の運用で表面化しやすい不具合を、発生する処理の単位で整理します。
連携の
税とサービス料の計算順序が異なり、表示した総額と確定額が相違する
宿泊税やサービス料の計算順序と端数処理が施設の料金規程と一致しないと、予約画面の総額と確定額に差異が生じます。フロントで返金対応が発生します。
取消料率が切り替わる日時をまたぐと取消料が規程と異なる
取消料率が変わる日時をまたいだ取消で、適用される料率が規程と異なる場合があります。取消料の過不足が発生し、差額調整の手間が増えます。
与信が失敗した予約の在庫が返却されず、販売可能数が目減りする
決済の与信が失敗した予約で在庫の返却処理が働かないと、販売可能な客室が残っているのに売れない状態が続きます。販売機会の損失として収支へ出ます。
予約の備考が文字数超過や文字コードの不整合で欠落し、現場へ伝わらない
予約時の備考欄で文字数超過や文字コードの不整合が起きると、内容が欠落したまま現場へ届きます。特記事項が伝わらず、当日の対応に支障が出ます。
残存した不具合により生じる問題
予約エンジンに残存した不具合は、フロントの手作業・返金コスト・リリース判断の根拠という形で宿泊施設の運営へ出ます。
静的テスト（レビュー）でおさえるべき観点
コードを動かす前に、規程類と設計書の不整合を検知するのが静的テストです。リリース前のレビューでは、料金・取消料・在庫・連携・決済の各領域について、照合する文書と確認する観点を整理します。
計算順序の不整合を検知できないと、宿泊税やサービス料が規程と異なる金額で表示されたままリリースされ、返金対応が発生するおそれがあります。
料金規程と料金設定の設計書を照合し、加算項目の計算順序を確認する
宿泊税・入湯税・サービス料の加算順序と端数処理は、自治体の制度と施設の料金規程に依存します。料金規程と料金設定の設計書を照合し、計算順序の定義が一致しているかを確認します。
確認する資料
- 料金規程書
- 料金設定設計書
- 計算順序の定義
境界値の定義が曖昧なままだと、取消日の前後で規程と異なる取消料が計上され、ゲストへの説明がつかなくなるおそれがあります。
取消料規程と設計書を照合し、適用区分の境界値の定義を確認する
取消料の適用区分は、取消日と宿泊日の間隔で切り替わります。取消料規程と設計書を照合し、境界値となる日付で適用区分が正しく定義されているかを確認します。
確認する資料
- 取消料規程書
- 取消料の設計書
- 適用区分の定義
方針とAPI定義が一致しないまま接続すると、在庫の二重販売や売り止めの反映漏れが起き、手作業での対応となるおそれがあります。
在庫按分の方針書とAPI定義の照合点を確認する
OTAと共通在庫にするかチャネル別に割り当てるかは、施設の販売方針で決まります。方針書とAPI定義の照合点を洗い出し、在庫数の授受の仕様が方針と一致しているかを検証します。
確認する資料
- 在庫按分方針書
- API定義書
- 在庫の授受仕様
連携項目の漏れを検知できないと、予約データの一部がPMSへ反映されず、リリース直後に現場での確認作業が増えるおそれがあります。
PMS連携項目を設計書と照合する
PMSとの在庫・料金の同期方式は、接続の個別仕様に依存します。連携項目一覧を設計書と照合し、送信する項目と更新間隔の定義に漏れがないかを確認します。
確認する資料
- 連携項目一覧
- PMS連携設計書
- 更新間隔の定義
与信失敗時の在庫の扱いが未定義のままだと、決済が完了しない予約で在庫が占有され、販売機会を失うおそれがあります。
決済の接続仕様書と設計書を照合し、与信失敗時の在庫の扱いを確認する
与信に失敗した予約の在庫を保持するか返却するかは、決済代行事業者の接続仕様に依存します。接続仕様書と設計書を照合し、失敗時の在庫の扱いが定義されているかを確認します。
確認する資料
- 決済接続仕様書
- 決済の設計書
- 与信処理の定義
- 失敗時の在庫扱い
動的テストの設計・実行のポイント
予約エンジンの動的テストは、料金計算と在庫更新の単位から連携経路、業務シナリオ、受け入れと回帰まで段階的に設計します。
STEP 01
ユニットテスト組み合わせを境界値で絞り、工数を抑えます。
どう確かめるか
料金計算と在庫更新のユニットテストを、境界値分析で設計する
料金計算と在庫更新を対象に、日付・部屋タイプ・人数の組み合わせを境界値分析で絞り込みます。取消料の計算順序と端数処理を正解値と照合し、全組み合わせを試さずに確認範囲を確定します。
- 01料金計算の境界値と加算項目の計算順序を設計します。
- 02在庫更新の単位処理を正解値と照合します。
- 03取消料計算と在庫返却のタイミングを検証します。
OUTPUT境界値のテスト項目書
STEP 02
統合テスト経路ごとの結果が原因切り分けの根拠になります。
どう確かめるか
PMS・決済・サイトコントローラーとの統合テストを、経路ごとに実施する
PMS・サイトコントローラー・決済代行との接続を、在庫同期・料金連携・与信と返金の経路ごとに検証します。不整合が出た際に原因の帰属を切り分けられるよう、経路単位で結果を残します。
- 01PMSとの在庫・料金の同期を経路別に検証します。
- 02決済代行との与信・売上確定・返金を検証します。
- 03サイトコントローラー経由の予約データ授受を確認します。
OUTPUT連携経路別の検証結果
STEP 03
システムテスト予約者の操作から現場の受領まで通します。
どう確かめるか
検索から予約確定・変更・取消までのシステムテストを、業務シナリオで通す
検索から予約確定、変更、取消までを業務シナリオとして通し、通知メールの到達と在庫の返却まで確認します。画面単体ではなく、現場が予約データを受け取るところまでを範囲に含めます。
- 01検索から予約確定までのシナリオを通します。
- 02変更・取消の操作と通知メールの到達を確認します。
- 03取消後の在庫返却が現場の画面へ反映されるかを確認します。
OUTPUTシナリオ通過記録
STEP 04
受け入れテストと回帰テスト確認済み範囲をリリース判断へ直結させます。
どう確かめるか
受け入れテストと回帰テストで、既存プランへの影響とリリース可否を確認する
切替日の前に、確認した範囲と未確認の範囲を分けてリリース可否の材料をまとめます。プラン改定や料金テーブル更新のたびに回帰テストを実施し、既存プランへの影響を検知します。
- 01確認範囲と未確認範囲を分けてリリース判断材料を作ります。
- 02プラン改定・料金テーブル更新後の回帰テストを実施します。
- 03残存リスクとテスト結果を稟議・監査へ出せる形で残します。
OUTPUTリリース判断材料
GENZが代行する予約エンジンのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 確認する範囲と確認しない範囲を分けたテスト項目書が残ります。
- ベンダーのテストと重複しない範囲に第三者検証の対象を絞れます。
- 費用と検証範囲の対応がわかる資料を稟議に使えます。
- 料金・プランの正解値一覧が、設定変更時の照合基準になります。
第三者の視点で検証範囲を書き出すGENZの支援
ベンダーのユニットテストと統合テストが済んでいても、受け入れ側で確認した範囲を説明できないままでは、リリース判断の材料になりません。GENZは第三者の視点で検証範囲を書き出し、テスト項目書としてお渡しします。
料金と在庫の運用からテスト設計へ
料金・在庫・宿泊プランの正解値を予約ご担当者様と整理し、テスト設計の照合基準として一覧化します。
検証する範囲と、しない範囲
ベンダーが実施済みのユニットテストと統合テストを前提に、第三者が担うテストを切り分け、確認しない範囲も明記します。
今の体制のまま並行して検証できます
情報システムご担当者様の推進業務に合わせ、新たな部署を設けずに検証の工程を挿し込み、並行して進めます。
不具合票と報告書を、監査にも使える形で納品
不具合票と結果報告書をテスト単位で整理して納品します。稟議やシステム監査の求めにも同じ資料で応じられます。
ご相談から納品までの流れ
切替日が先に決まる進行でも、検証範囲の確定と並行して実施できるよう、相談から納品までを四段階で進めます。
ヒアリング
予約エンジンの構成と連携先、切替日を伺い、検証対象の全体像を整理します。
テスト設計と見積もり
検証範囲に優先順位を付けてテスト項目を設計し、工数と費用の目安を提示します。
テストの実施と結果の共有
テストを実施し、不具合票と進捗を共有しながら、結果を担当者様へ報告します。
報告書の納品と再確認
監査でも参照できる形で報告書を納品し、残存リスクと再テストの要否を示します。
まずは検証範囲の整理からご相談ください
予約エンジンのどこまでを検証するか、GENZにご相談ください
検証範囲の線引きが固まらない段階でもご相談いただけます。検証範囲と優先順位、必要工数の考え方、関連テストの要否をテスト項目書の形でお渡しし、稟議の材料としてご利用いただけます。