GENZ, Inc.

宿泊施設運営企業様へ セルフチェックインと連携まわりのテストを設計から報告まで代行

不具合はPMSの予約照合・スマートロックの鍵発行・事前決済をまたぐ箇所で起きます。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

セルフチェックインアプリでよくある不具合

アプリ単体の動作確認では拾えない不具合の多くは、PMSとの予約照合・スマートロックの鍵発行・事前決済という連携の境界で発生します。リリース判断の材料とするために、実際に起きた不具合の形を整理しました。

同姓同名の別予約と照合され、別の宿泊者の予約でチェックインが完了する

予約番号以外のキーで照合すると、同姓同名の別予約でチェックインが完了します。宿泊者は入室できず、フロントでの手作業となります。

予約照合

チェックイン完了表示でも電子鍵が出ず入室できない

チェックイン完了と表示されても、スマートロックへの鍵発行APIの応答が失敗していると電子鍵が届きません。宿泊者は客室前で入室できません。

鍵発行

決済結果の通知が遅延し、宿泊者の再操作で同一予約に二重計上が発生する

決済結果の通知が遅延すると、宿泊者が未完了と判断して再度決済を実行し、同一予約に二重計上が発生します。返金処理と照合作業が施設側に残ります。

決済

パスポート写しの未取得で宿泊者名簿の記載が欠ける

パスポート読み取りをスキップできる導線が残ると、宿泊者名簿の記載事項と写しが欠けたまま保存されます。後から判明すると記録の遡及整備が必要です。

宿泊者名簿

清掃完了前から鍵が有効になり未清掃の客室に入れる

PMSの清掃ステータスと鍵の有効化条件が連携していないと、清掃完了前に鍵が有効になります。宿泊者が未清掃の客室へ入室し、部屋替えが発生します。

PMS連携
02 RISK

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

見落とされた不具合は、リリース後に手作業での対応・返金と照合作業・名簿記載の欠落として表面化し、現場と情報システム部門の工数が割かれます。

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

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

実行テストの前に、設計書・仕様書・運用手順書を読み合わせて観点の漏れを潰します。セルフチェックインアプリはPMS・スマートロック・決済をまたぐ構成のため、文書同士の不整合をこの段階で検出します。

照合キーの不整合を見逃すと、同一予約への重複操作が別宿泊者として処理され、二重の鍵発行や二重決済が発生するおそれがあります。

予約データの照合キーが一意に特定できるか確認する

予約サイト・OTAから取り込んだ予約を、アプリ側がどのキーで宿泊者と照合するかを仕様書で確認します。照合キーが複数定義されていると、同一予約の重複操作をどちらに結びつけるかで不整合が起きます。

確認する資料
  • 予約照合仕様書
  • API定義書
  • 予約取込設定
鍵の有効期間と清掃運用の不一致を見逃すと、清掃中の客室へ宿泊者が入室できてしまい、現場の混乱と宿泊者の評価の低下につながるおそれがあります。

鍵の有効期間の開始・終了時刻を客室清掃の運用手順書と照合する

鍵発行の有効期間は、設計書の時刻定義と、清掃中の客室への入室可否を定めた運用手順書の記述が一致しているかを照合します。開始時刻に不整合があると、清掃中の客室へ宿泊者が入室できます。

確認する資料
  • 鍵発行仕様書
  • 運用手順書
  • 清掃計画表
必須判定の漏れを見逃すと、宿泊者名簿の記載事項やパスポートの写しの取得が欠落し、是正対応と記録の再整備に中長期の工数を要するおそれがあります。

宿泊者情報の入力項目と必須判定の漏れを確認する

宿泊者名簿の記載事項とパスポートの写しの取得項目について、入力画面の必須判定と保存設計を確認します。任意項目に設定されていると、取得漏れが稼働後に判明し、記録の遡及整備に人手を要します。

確認する資料
  • 入力項目定義書
  • 必須判定一覧
  • 名簿保存設計
計算順序と境界値の未検証を残すと、誤った宿泊税額で事前決済が計上され、返金処理と照合作業が発生するおそれがあります。

決済金額の計算順序を料金プランと宿泊税の課税条件の定義と照合する

宿泊料金・宿泊税・事前決済の計算順序を、料金プラン定義と課税条件の文書で照合します。課税対象となる料金の境界値が改修規模の小ささを理由に未検証のまま残ると、誤った税額で計上されます。

確認する資料
  • 料金プラン定義
  • 課税条件文書
  • 計算順序設計
状態遷移の不一致を見逃すと、アプリで完結しない宿泊者がフロントへ流れ、手作業での対応が増えて省人化の効果が得られないおそれがあります。

アプリと管理画面の状態遷移を設計書と照合する

事前チェックイン済み・当日手続・鍵発行済みの各状態で、アプリと管理画面の状態遷移が設計書どおり一致しているかを確認します。不一致があると、一覧画面と宿泊者のアプリ表示に差異が生じます。

確認する資料
  • 状態遷移図
  • 画面設計書
  • 管理画面仕様
  • チェックイン定義
04 TEST DESIGN

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

検証は、画面単位の確認から始め、PMS・スマートロック・決済の連携、業務シナリオの通し、負荷条件の順に組み立てます。

STEP 01 画面・機能単位の検証境界値と同値分割でテスト項目を絞り込む
どう確かめるか

境界値と同値分割で宿泊者情報と事前決済の画面挙動を確かめる

課税境界や入力桁数の境界値を特定し、同値分割で代表値を選びます。氏名・住所・職業の名簿記載事項と、訪日外国人のパスポート読み取り、事前決済のトークン保持を画面単位で確認します。

  • 01名簿記載事項の入力項目と必須制御を確認します
  • 02パスポートの読み取りと写しの保存を確認します
  • 03宿泊税の計算順序と課税境界の値を検証します
OUTPUT画面単位の不具合の特定
STEP 02 連携部分の検証ベンダーの統合テストと範囲を区別する
どう確かめるか

三つの連携を異常系も交えた統合テストで確かめる

アプリのチェックイン導線、PMSのルームアサイン、スマートロックの鍵発行、事前決済が同一の宿泊者を指すかを照合します。通信断や二重送信の異常系を(意図的に)発生させて検証します。

  • 01PMSの予約照合とルームアサインの対応を検証します
  • 02鍵発行の成否と通信断時の挙動を検証します
  • 03決済結果と予約・鍵発行の整合を照合します
OUTPUT連携照合の検証結果
STEP 03 業務シナリオの通し検証現場の宿泊者行動をシナリオへ反映する
どう確かめるか

事前チェックインから退館までをシナリオテストで通す

前日の事前チェックインから当日の鍵受領、滞在中の追加決済、チェックアウトまでを一通り通します。アプリで完結しない宿泊者がフロントへ流れた際の名簿補完と鍵の再発行までを範囲に含めます。

  • 01事前チェックイン済みと当日手続の混在を通します
  • 02深夜到着や操作中断からの再開を確認します
  • 03チェックアウトと返金処理の流れを確認します
OUTPUT業務シナリオの通し確認
STEP 04 負荷条件下の受け入れ検証リリース判断の根拠となる記録を残す
どう確かめるか

同時アクセスを再現し引き継ぎまで確かめる

チェックイン時間帯の同時アクセスを想定した負荷条件で受け入れテストを行います。応答の遅延やエラーに加え、アプリで完結しない宿泊者のフロントへの引き継ぎが成立するかを確認します。

  • 01集中アクセス時の応答とエラー率を測定します
  • 02鍵発行のみ失敗する状態の検知を確認します
  • 03フロントへの引き継ぎ手順の成立を確認します
OUTPUT負荷条件下の受け入れ記録
05 RATIONALE

GENZが代行するセルフチェックインアプリのテスト

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

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

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

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

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

専門ノウハウを即戦力で

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

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

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

  • 自社の構成に合わせた検証範囲の線引きが決まる
  • 連携システムをまたぐ照合観点が一覧でそろう
  • テスト設計から実行・報告までの工程を一括で任せられる
  • リリース判断に使える報告書が一式にまとまる
06 SERVICE

連携の境界から検証範囲を引くGENZの支援

不具合は、アプリ単体よりもPMSの予約照合・スマートロックの鍵発行・事前決済をまたぐ箇所で表面化します。GENZは連携の境界から検証範囲を設計し、テストの実施から報告書の納品まで一括でお引き受けします。

SVC 01

連携の境界からテスト設計を起こします

アプリ・PMS・スマートロック・決済の接続点を洗い出し、どこまでを検証範囲とするかをテスト設計の起点として整理します。

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

宿泊者の到着条件ごとに検証範囲を決める

前日の事前チェックイン・深夜到着・アプリで完結しない場合など、宿泊者の実際の行動を反映したシナリオで検証します。

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

開発ベンダーを止めずに第三者が検証します

ベンダーが実施したユニットテスト・統合テストの十分性を第三者の視点で評価し、開発の進行を止めずに検証だけを追加します。

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

テスト項目書と不具合票をまとめて納品します

検証範囲・実施結果・残存不具合を束ねた報告書を納品し、社内説明とリリース判断にそのまま使える形でお渡しします。

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

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

アプリ・PMS・スマートロック・決済の構成に合わせ、検証範囲の整理から報告書の納品まで進めます。

導入構成と連携先のヒアリング

連携先の構成と運用条件を伺い、検証の対象と前提を整理します。

検証範囲のテスト設計と見積もりのご提示

ベンダーの検証範囲と重ならない領域に優先順位を付け、見積もりをご提示します。

テストの実施と不具合票の随時共有

異常系のテスト観点も含めて検証し、不具合票を随時お渡しします。

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

監査や稟議の説明に使える形式で報告書を納品し、修正後の動作を確認します。

検証範囲の相談から始める

セルフチェックインアプリの検証範囲と優先順位から相談する

セルフチェックインアプリのリリース予定日が決まった企業様は、株式会社GENZへご相談いただけます。PMS・スマートロック・決済を含む検証範囲の整理と優先順位づけを提示します。