複数の販売経路から同じ座席が同時に確保され二重予約になる
窓口端末とWeb予約が同一の座席在庫を同時に確保すると、発券後に重複が判明します。旅客への代替手配と返金の費用が発生します。
GENZ, Inc.
テスト設計から担う
予
テスト設計から担う
予約発券システムを第三者視点で検証するテスト支援
予約・運賃・決済・発券・変更取消が連なる構造から検証範囲の線引きを設計し、検証済みと未検証を区別した報告書で、リリース判断の材料を整えます。
支援事例
支援実績5,000件以上
予約発券システムでよくある不具合
予約発券システムは、在庫・運賃・決済・発券・変更取消が一連の取引として連なる構造のため、一箇所の不備が窓口・券売機・Web予約の発券停止に至ります。以下は、更改や機能追加の後に表面化しやすい不具合の型です。
複数の
割引の適用順序により運賃が規程と異なる金額で確定する
割引の適用順序が運賃規程の計算順序と異なると、規程と違う金額で運賃が確定します。日次の精算で差異として検出され、会計処理の修正が必要になります。
決済は成立したまま予約が未確定で残り証票が発行されない
決済の承認と予約確定の間で取引が中断すると、入金済みのまま証票が発行されない状態が残ります。返金と残高の照合が窓口の手作業での対応となります。
取消日時が日付の境界をまたぎ払戻手数料の算定を誤る
取消日時が運賃改定の適用開始日をまたぐと、改定前後どちらの払戻手数料を適用するかが実装の解釈に委ねられ、規程と異なる金額で算定されます。
無効化したはずの証票が改札・入場の読み取りで通る
変更・取消で無効化した証票の情報が改札・入場の読み取り側へ反映されないと、取消済みの証票がそのまま通り、二重利用を検知できません。
残存した不具合により生じる問題
検証で拾い切れなかった不具合は、リリース後に窓口・券売機・精算の業務へ現れます。表面化した不具合が現場と経営に何をもたらすかを整理します。
静的テスト（レビュー）でおさえるべき観点
動作確認の前に、仕様書どうしの食い違いを文書の段階で洗い出します。在庫・運賃・決済・発券が一連の取引として連なるため、定義の不整合は複数の販売経路へ広がります。実行に入る前に照合すべき観点を整理しました。
在庫状態の定義が文書間でずれたまま実装が進むと、同一在庫への同時アクセスで二重予約が発生し、代替手配と返金の費用がかかります。
在庫の状態遷移図とDB設計書の在庫テーブルを照合する
在庫の状態遷移図とDB設計書の在庫テーブルを照合します。複数の販売経路が同一在庫を参照する構造では、予約中・確定・取消の定義が文書間で一致しないと、二重予約や在庫の戻し忘れが実装に残ります。
確認する資料
- 状態遷移図
- DB設計書
- 在庫テーブル定義
計算順序の食い違いを見落とすと、改定後の運賃が誤って計上され、精算差異の調査と会計処理の修正に人手が割かれます。
運賃規程と運賃計算の仕様書の計算順序を照合する
運賃規程と運賃計算の仕様書の計算順序を照合します。割引の適用順と端数処理の位置が規程と仕様書で異なると、特定の区間・券種の組み合わせだけで運賃がずれ、受け入れテストの代表値では拾えません。
確認する資料
- 運賃規程
- 運賃計算仕様書
- 割引適用条件
接続仕様との不整合を残すと、日次精算で差異が続き、原因の所在を決済事業者と切り分ける作業が双方に残ります。
決済事業者の接続仕様とAPI定義の項目・桁を照合する
決済事業者の接続仕様とAPI定義の項目・桁を照合します。金額の桁数・通貨コード・取消期限が接続先の仕様と合わないと、決済は通るのに日次精算で差異が出て、切り分けに双方の工数がかかります。
確認する資料
- 接続仕様書
- API定義
- 精算データ仕様
中断時の状態整合が未定義のままだと、稼働直後に不具合が表面化し、初動対応に開発・運用の人員が張り付きます。
払戻規程と例外処理とエラー発生パターンの記述を照合する
払戻規程と例外処理とエラー発生パターンの記述を照合します。取引の途中で中断した場合に、払戻済み・発券済み・在庫返却のどこまでを戻すかが仕様にないと、状態整合の不具合が稼働後に表面化します。
確認する資料
- 払戻規程
- 例外処理定義
- エラーパターン表
適用開始日の境界値が決まらないままリリースすると、改定前後をまたぐ予約で窓口の手作業対応と案内文の差し替えが発生します。
適用開始日の切り替え条件と境界値の定義を照合する
適用開始日の切り替え条件と境界値を照合します。運賃改定をまたぐ予約（改定前の予約・改定後の乗車）の扱いが文書化されないと、実装者の解釈に委ねられ、リリース後に案内と返金の対応が発生します。
確認する資料
- 改定適用ルール
- 切替条件定義
- 境界値定義
- 適用開始日一覧
動的テストの設計・実行のポイント
動的テストは、運賃の境界値・在庫と決済の連携・同時アクセス・業務シナリオの順に設計し、確かめる内容をテスト計画に固定します。
STEP 01
ユニットテスト運賃・割引の組み合わせを同値分割で絞り込む
どう確かめるか
ユニットテストで運賃計算と払戻計算の境界値を同値分割で確かめる
運賃計算と払戻計算は、区間・券種・割引条件の組み合わせを同値分割で代表値に絞り、適用開始日の前後の境界値を個別に確かめます。絞り込みの根拠を項目書に残し、網羅性を基準で説明します。
- 01運賃規程から区間・券種・割引条件の組み合わせを抽出する
- 02同値分割で代表値を選び、境界値を個別項目に起こす
- 03絞り込みの根拠をテスト項目書に記録する
OUTPUTテスト項目書と同値分割表
STEP 02
統合テスト在庫・決済・発券の受け渡しを取引順に通す
どう確かめるか
統合テストで在庫確保から決済・発券までのモジュール間の連携を確かめる
在庫確保から予約・決済・発券・精算への受け渡しを、取引順に通して検証します。変更・取消の払戻計算と証票の無効化が、会計連携のデータと整合するかをモジュール間の境界で確かめます。
- 01予約確定から発券・精算までの取引シナリオを設計する
- 02変更・取消時の払戻計算と証票無効化の連携を検証する
- 03モジュール間の受け渡しデータの整合を確認する
OUTPUTモジュール間連携の検証結果
STEP 03
システムテスト同時アクセスと取引中断を発生させて検証する
どう確かめるか
システムテストで販売経路からの同時アクセスと異常系のテスト観点を確かめる
窓口端末・自動券売機・Web予約から同一在庫への同時アクセスを発生させ、二重予約や在庫の不整合が起きないかを検証します。取引の中断や通信断の異常系の観点も、この段階で網羅します。
- 01複数販売経路からの同時予約を発生させて検証する
- 02取引途中の中断・通信断の異常系観点を実行する
- 03不具合票に発生条件と再現手順を記録する
OUTPUT同時アクセスの不具合票
STEP 04
受け入れテスト改定日をまたぐ業務シナリオを運用どおりに実施
どう確かめるか
受け入れテストで運賃改定日をまたぐ業務シナリオを運用手順どおりに確かめる
運賃改定日をまたぐ予約など業務ルール上の境界値を含むシナリオを、窓口の運用手順どおりに実施します。残存不具合と未検証範囲の業務影響を整理し、リリース可否の合議に出せる材料にします。
- 01運賃改定日をまたぐ予約の業務シナリオを作成する
- 02窓口の運用手順どおりに受け入れテストを実施する
- 03残存不具合と未検証範囲の業務影響を整理する
OUTPUTリリース判断の根拠資料
GENZが代行する予約発券システムのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 検証範囲の線引きを構造上の根拠とともに示す
- 運賃・割引の組み合わせを境界値で絞り込んだテスト設計
- 既存の開発工程と並行して第三者の視点で検証を重ねる
- 検証範囲と未検証範囲を区別した報告書と証跡を整える
検証範囲を設計から組み立てる支援
改修内容に対してどこまで検証すべきかは、在庫・運賃・決済・発券・変更取消・精算が連なる構造から線を引きます。GENZはテスト設計を起点に、検証範囲と未検証範囲を区別して示します。
テスト設計から組み立てる
運賃・割引の組み合わせや変更取消の状態遷移を洗い出し、テスト項目書の形で検証範囲の根拠をご提示します。
広い検証範囲を分担して担う
テスト計画・テスト設計・テスト実行・報告の各工程を委託できる単位で切り分け、社内に残る作業を明らかにします。
開発と並行して第三者視点で検証
既存の開発工程を止めずに並行して実施します。開発主体と分離した第三者の視点で、ベンダーの自社テストに検証を重ねます。
検証結果と証跡をまとめて納品
報告書には検証範囲と結果の対応を記し、証跡とあわせて納品します。リリース判断の合議や監査への提出に使える形で整えます。
ご相談から納品までの流れ
ご相談から納品まで、開発工程と並行して進めます。各段階で稟議・リリース判断に使える記録が残ります。
ヒアリングと対象システムの確認
更改の時期・改修範囲・販売経路をお伺いし、検証の対象となる機能を整理します。
テスト設計とお見積もりのご提示
運賃・券種の組み合わせを絞り込んだテスト設計とお見積もりをご提示します。
テストの実施と進捗・不具合票の共有
テストを実施して進捗と不具合票を共有し、稟議に使える形で記録を残します。
報告書の納品と修正後の再確認
検証結果と残存リスクを報告書にまとめて納品し、修正後に再確認します。
ご相談・お見積もり
予約発券システムの検証範囲と優先順位をGENZにご相談ください
在庫・運賃・決済・発券・変更取消・精算までの連なりを踏まえ、検証する範囲と未検証とする範囲の線引きからご提示します。現行の開発工程と並行して進める進め方もご案内いたします。