GENZ, Inc.

宿泊施設の情報システム部門 サイトコントローラー連携のテスト設計から第三者検証まで

OTAと販売プランの組み合わせをどこまで検証範囲に入れるか、その判断根拠をテスト設計として確定させるところからGENZが引き受けます。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

サイトコントローラーでよくある不具合

サイトコントローラーは複数のOTAやPMSと連携する分、不具合が起きたときに自社の管理外のシステムまで確認が及びます。ここでは、在庫・料金・予約の連携で起きやすい不具合を挙げます。

在庫を更新してもOTA側が変わらず販売停止が続く

管理画面で売止めや在庫数を更新してもOTA側に反映されないことがあります。反映の単位はOTAごとに異なり、送信の停止箇所を特定できません。

反映遅延

複数OTAで同時刻に予約が成立し、客室数を超える二重予約が発生する

複数のOTAで同時刻に予約が成立すると、客室数を超える予約が確定することがあります。二重予約が起きると宿泊客への代替手配が必要になります。

二重予約

予約の取消を受信しても在庫が戻らず、空室が売られないまま当日を迎える

予約の取消を受信しても在庫へ反映されないことがあります。空室が販売に戻らないまま当日を迎えると、その日の販売機会を失います。

在庫未戻り

連泊や食事条件の組み合わせで、OTAへ送信される料金が設定と異なる

期間・曜日・連泊数・食事条件が重なる料金計算では、設定と異なる金額がOTAへ送信されます。組み合わせが多く、目視での全件確認はできません。

料金の不一致

PMSとサイトコントローラーで客室残数が食い違う

客室在庫の正本をサイトコントローラー側とPMS側のどちらが持つかは構成で異なります。不整合が起きると、どちらの残数が正しいか判断できません。

残数の食い違い
02 RISK

残存した不具合により生じる問題

サイトコントローラーの更改・連携改修で見逃された不具合は、販売・精算・稟議の工程で表面化します。ここでは代表的な問題を挙げます。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

静的テスト(レビュー)でおさえるべき観点

更改や連携改修のテスト設計は、設計書・仕様書のレビューから始まります。実行前の静的テストで仕様の齟齬を摘出しておけば、テスト項目書に載せる範囲の線引きを根拠付けられます。

反映仕様の差異を見落とすと、切替直後に在庫不整合が表面化します

OTA連携仕様と製品仕様を照合する

OTAごとの在庫・料金の反映仕様と製品側の連携仕様を照合し、売止めの反映単位や遅延時間の記述が一致しているかを確認します。ここで差異が残ると、項目書の範囲が根拠なく膨らみます。

確認する資料
  • OTA連携仕様書
  • 製品仕様書
  • インターフェース定義書
設定の食い違いが残ると、販売停止や予約超過のおそれがあります

販売プランと在庫按分の設定を照合する

客室種別・プラン・期間の組み合わせに対して、在庫按分の設定値が販売管理側の運用と一致するかを照合します。設定と運用の食い違いを仕様書上で摘出できれば、実行フェーズでの手戻りを減らせます。

確認する資料
  • 販売プラン定義書
  • 在庫設定一覧
  • 運用ルール資料
端数処理の不一致は、料金表示の差異として宿泊客への対応に至ります

料金計算の仕様書と料金表を照合し、計算順序と端数処理の記述を確認する

期間・曜日・人数などの条件が重なる料金計算は、計算順序と端数処理の記述が仕様書と料金表で一致しているかを確認します。宿泊税など内訳項目のOTAごとの扱いも、この照合で切り分けます。

確認する資料
  • 料金計算仕様書
  • 料金表
  • 制度要件資料
在庫の正本が曖昧なままだと、原因切り分けが停滞し復旧が遅れます

PMS連携の設計書で、客室在庫の正本の所在と連携の実行契機を確認する

PMS側とサイトコントローラー側のどちらが客室在庫の正本を持つか、また予約・在庫の連携がいつ実行されるかを設計書で確認します。ここが曖昧なままだと、不具合時の原因切り分けの入口が立ちません。

確認する資料
  • PMS連携設計書
  • 導入構成図
  • データフロー図
対象外の線引きが記録されないと、承認の場で説明に詰まります

移行対象と対象外の線引きを照合して確認する

既存システムからの移行対象と対象外のデータを定義書上で照合し、検証範囲の外に残るものを明示します。この線引きの記録が、稟議や品質保証の点検で残存リスクを説明する材料になります。

確認する資料
  • 移行計画書
  • 移行対象一覧
  • 検証範囲定義書
  • 残存リスク一覧
04 TEST DESIGN

動的テストの設計・実行のポイント

設定機能から連携、予約シナリオまで、工程ごとに検証範囲を分けて順に設計します。

STEP 01 設定機能のユニットテスト境界値の取り方は料金計算の条件に合わせて選定します
どう確かめるか

在庫・料金の設定機能を、宿泊日と在庫数の境界値でユニットテストする

売止め・料金調整の設定機能を、宿泊日の前後と在庫数の境界値で検証します。在庫残数が尽きる直前と直後、料金切替日の前後を項目に含め、計算結果が設定どおりかを確認します。

  • 01在庫数と宿泊日の境界値を洗い出し、項目書に反映します
  • 02売止め操作と料金変更の設定値を入力条件として整理します
  • 03期待結果を計算仕様にもとづいて定義し、実行します
OUTPUT境界値を含むテスト項目書
STEP 02 OTA・PMS連携の統合テスト連携先ごとの反映仕様を一覧にして照合します
どう確かめるか

OTAおよびPMSとの連携を、送信内容と受信結果の照合で統合テストする

OTAごとに反映の単位と遅延時間が異なるため、サイトコントローラーから送信した在庫数・販売可否・料金と、各連携先の受信結果を一件ずつ照合し、差異の発生箇所を特定します。

  • 01OTAごとの反映単位と遅延時間を確認し、照合基準を定めます
  • 02PMSとの間で在庫の正本がどちらにあるかを確認します
  • 03送信内容と受信結果の差異を件単位で記録します
OUTPUT送信内容と受信結果の記録
STEP 03 予約シナリオのシステムテスト異常系の観点は発生条件を特定してから設計します
どう確かめるか

予約処理の順序を入れ替え、異常系の観点を確かめる

予約の新規・変更・取消の到着順序を意図的に入れ替えて発生させ、在庫の計上と重複の有無を確かめます。実運用で起こりうる順序の乱れに対して、取り込み処理がどう動くかを検証します。

  • 01予約の新規・変更・取消の順序パターンを設計します
  • 02順序を入れ替えて発生させ、在庫計上の結果を検証します
  • 03二重予約や取消漏れが生じる条件を特定します
OUTPUT順序入れ替えの実行結果
STEP 04 受け入れテストと回帰テストリリース判断に使う基準を事前に合意します
どう確かめるか

繁忙期の販売シナリオで受け入れテストを実施し、是正後に回帰テストを実施する

販売管理の担当者が実際に行なう在庫配分と料金設定のシナリオで受け入れテストを実施し、検出された不具合の是正後に影響範囲へ回帰テストを実施します。

  • 01販売管理の業務シナリオを受け入れテストの項目へ展開します
  • 02是正された不具合の影響範囲を特定し、回帰テストを実施します
  • 03残存する不具合票とリリース判断の基準を照合します
OUTPUT受け入れ・回帰テスト結果
05 RATIONALE

GENZが代行するサイトコントローラーのテスト

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • OTAと販売プランの組み合わせをテスト技法で絞り込みます
  • PMSと自社予約エンジンをまたぐ連携部分まで検証します
  • 検証範囲・残存リスク・証跡を揃えた報告書を作成します
  • 販売を止められない期間を前提に、検証の順序と実施時期を調整します
06 SERVICE

OTA連携の検証範囲から設計するテスト支援

サイトコントローラーの検証で問われるのは、OTAと販売プランの組み合わせのどこまでを範囲に入れるかの根拠です。GENZはテスト設計から引き受け、第三者の視点で範囲の妥当性を整理します。

SVC 01

テスト設計から検証範囲を絞り込む

要件・設計書のレビューからテスト設計を起点に、テスト技法でOTAと販売プランの組み合わせを絞り込みます。範囲の外も根拠つきで記述します。

リスク要因と優先順位を示す無文字の図解。
SVC 02

予約基盤をまたぐ連携も検証する

売止め・料金調整を担うサイトコントローラーと現場オペレーションを担うPMSの境界で、予約・在庫のデータの受け渡しを検証します。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

既存体制と切替時期に合わせて伴走

既存のテスト体制への途中参加やスプリントとの並行実施に対応します。繁忙期や切替日の制約に合わせ、検証の順序と実施時期を組み替えます。

計画から報告までの流れを示す無文字の図解。
SVC 04

検証の範囲と結果を証跡つきで報告する

検証範囲・実施した技法・結果・残存リスク・証跡を揃えた報告書を提出します。稟議や品質保証の点検にそのまま出せる形式です。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

ご相談から納品までの流れ

ご相談から報告書の納品まで、既存のテスト項目書を引き継ぐか設計から作り直すかも含めて進めます。

ヒアリング:前提条件の確認

対象のOTA数・連携先システム・切替日の制約・成果物の形式を確認します。

テスト設計と見積もりのご提示

検証範囲と優先順位を設計し、範囲の外に残すものと見積もりをご提示します。

テストの実施と結果の共有

検証用環境でテストを実施し、不具合票と進捗を共有しながらご確認いただきます。

報告書の納品と是正後の再確認

検証範囲と結果を証跡つきの報告書として納品し、是正後の再確認まで対応します。

テスト設計の起点をGENZが引き受けます

サイトコントローラーの検証範囲と優先順位をGENZへご相談ください

ご相談では、対象のOTA数と販売プランの組み合わせをもとに、検証範囲の絞り込みと優先順位、必要工数の考え方を整理した素案をお渡しします。稟議と品質保証の点検に出せる形です。