同じ予約枠に重複して予約が成立し、窓口の定員を超過する
同一の予約枠へ同時に申込が行われると、重複の判定が機能せず定員を超えて予約が成立します。窓口では予定数を超える住民が来庁し、受付が滞留します。
GENZ, Inc.
自治体の発注担当者へ
窓口予約システムの
自治体の発注担当者へ
窓口予約システムのテストを第三者が一貫して担います
住民操作の経路から所管課ごとの手続き差異まで、確認済みと未確認の範囲を区別した報告書として納品し、稼働可否の庁内手続きに使える判断材料を残します。
支援事例
支援実績5,000件以上
窓口予約システムでよくある不具合
窓口予約システムでは、予約の成立・取消・枠設定の変更といった操作が組み合わさる箇所で不具合が起きやすくなります。ここでは、住民影響が大きく、受け入れ確認で見落としやすい不具合を取り上げます。
同じ
取消済みの予約枠が解放されず、空き枠が埋まったまま残る
住民が予約の取消を行っても、運用管理側の空き枠数が戻りません。取消済みの枠に次の予約が入らず、実際には空いている時間帯を予約できなくなります。
予約枠を縮小した変更が、予約済みの住民の予約を消す
所管課が予約枠を縮小すると、すでに入っていた予約が取り消されます。住民へ通知がないまま予約が失われ、当日の来庁で手続きが受けられません。
予約IDと生年月日の照合が通らず、交付手続きの予約が受け付けられない
交付通知書記載の予約IDと生年月日の照合で、正しい入力値が一致と判定されません。住民は予約を完了できず、窓口への個別の問い合わせが発生します。
住民が完了した予約が、窓口の予約一覧に反映されない
住民側で予約完了の画面まで進んでも、窓口が参照する予約一覧に反映されません。予約した住民が当日に予約なしとして扱われ、手続きの再確認が生じます。
残存した不具合により生じる問題
受け入れ確認で見落とされた不具合は、稼働後に窓口の運用上の問題として表面化します。残存した不具合が窓口と庁内手続きに生じさせる問題を示します。
静的テスト（レビュー）でおさえるべき観点
動作確認の前に、設計書・仕様書の段階で検証範囲の線を引くのが静的テストです。窓口予約システムでは、課ごとの要件差異や本人確認方式の違いが文書に散在します。レビューで照合すべき観点を次に示します。
見直さない場合、枠設定の変更が予約済みデータを壊す操作が検証範囲の外に残り、変更のたびに口頭確認へ依存する状態が続きます。
予約枠の設定仕様と、所管課の受付運用の実態を照合する
予約枠の設定仕様が、窓口ごと・時間帯ごとの実際の受付能力と一致しているかを設計書と運用資料で照合します。繁忙期の枠変更が予約済みデータへ及ぼす作用まで定義されているかを確認します。
確認する資料
- 要件定義書
- 画面設計書
- 運用設計書
見直さない場合、照合失敗時の挙動が未定義のまま実装され、住民が予約できない事象が稼働後に表面化するおそれがあります。
本人確認の照合条件を、手続き種別ごとの要件と照合する
予約IDと生年月日を突き合わせる手続きと、自己申告のみで受け付ける手続きが混在するため、手続き種別ごとの照合条件が要件と一致しているかを確認します。照合失敗時の挙動の定義有無も対象です。
確認する資料
- 要件定義書
- 基本設計書
- 詳細設計書
見直さない場合、未定義の遷移で予約が消える・二重に取れるといった不具合が残り、住民操作の経路を確認済みと言い切れなくなります。
予約の照会・変更・取消の画面遷移を、状態遷移の定義と照合する
住民自身が予約の照会・変更・取消まで操作する構成では、画面遷移の組み合わせが増えます。中断や再操作を含む状態遷移の定義と設計書の記載を照合し、未定義の遷移が残っていないかを確認します。
確認する資料
- 画面設計書
- 状態遷移図
- 詳細設計書
見直さない場合、手続き追加の改修が既存手続きの設定へ影響し、デグレードが稼働後に表面化するおそれがあります。
所管課・手続き種別のマスタ構成を、追加時の設定範囲と照合する
複数の所管課が同一システムを使う構成では、手続き種別やマスタの追加がどの設定範囲へ影響するかを照合します。標準機能の設定で済む範囲と個別開発の境界が文書上で区別されているかを確認します。
確認する資料
- 要件定義書
- 基本設計書
- DB設計書
見直さない場合、旧システムの予約が切替後に参照できず、予約済みの住民が来庁しても受付に出ていない事象が発生するおそれがあります。
旧システムからの予約データの引き継ぎ範囲を、切替計画と照合する
年度切り替えで旧システムから入れ替える場合、旧システムで受け付けた予約の引き継ぎ範囲と切替計画の記載を照合します。引き継がない予約の扱いが計画に明示されているかを確認します。
確認する資料
- 切替計画書
- 移行設計書
- 要件定義書
- 運用設計書
動的テストの設計・実行のポイント
動的テストは、予約の成立から受付までの経路を段階ごとに分け、各段階で確認すべき観点を検証範囲として文書に残す形で設計します。
STEP 01
ユニットテスト枠の上限と日時の境界値を確かめる段階
どう確かめるか
ユニットテストで予約件数と日時の境界値を確かめる
予約枠の受付開始・終了の時刻、枠ごとの受付上限、定員ちょうどと超過の前後といった境界値を項目化し、予約が成立する条件としない条件をユニットテストで確認します。
- 01予約枠の受付開始時刻・終了時刻の前後で申込の可否を確認します
- 02予約枠の受付上限ちょうどと上限超過で予約の成立可否を確認します
- 03年度切り替えの日付をまたぐ予約で日時の扱いを確認します
OUTPUT境界値のテスト項目
STEP 02
統合テスト予約成立から枠消費までの連携を確かめる段階
どう確かめるか
統合テストで予約の成立から枠の消費までの連携を確かめる
住民が予約を確定した時点で枠が消費され、変更・取消で枠が戻る一連の連携を統合テストで確認します。複数課が同一システムを使う構成では課をまたぐ枠の扱いも対象に含めます。
- 01予約の確定と同時に対象枠の残数が減ることを確認します
- 02予約の変更・取消で枠の残数が正しく戻ることを確認します
- 03複数の所管課が同一枠を使う場合の消費の整合を確認します
OUTPUT連携の確認結果
STEP 03
システムテスト住民操作の経路と異常系を通す段階
どう確かめるか
システムテストで住民操作の経路と異常系のテスト観点を通す
予約の申込から照会・変更・取消まで住民が自分で操作する経路を通し、予約IDと生年月日の照合失敗や満員枠への申込など異常系のテスト観点をシステムテストで検証します。
- 01予約IDと生年月日の照合に失敗した場合の画面遷移を検証します
- 02満員の枠への申込と取消直後の再申込の挙動を検証します
- 03スマートフォンのブラウザからの申込・照会・取消の経路を通します
OUTPUT経路と異常系の記録
STEP 04
受け入れテストと回帰テスト既存手続きへの影響を確かめる段階
どう確かめるか
受け入れテストと回帰テストで既存手続きへの影響を確かめる
受け入れテストでは所管課の業務の目で実際の受付運用が回るかを確認し、回帰テストでは改修箇所以外の既存手続きの予約が壊れていないかを確認します。
- 01所管課の窓口担当が当日の受付と呼び出しの運用を画面で確認します
- 02改修後に既存手続きの予約の申込・変更・取消が壊れていないか確認します
- 03枠設定の変更が予約済みデータへ及ぼす影響を確認します
OUTPUT既存手続きへの影響確認
GENZが代行する窓口予約システムのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 受け入れ確認の観点を設計済みの項目として整備
- 確認済み範囲と未確認範囲を区別した提出文書を作成
- ベンダーのテストと重複しない範囲で検証を実施
- 課ごとの手続き差異を一覧化し稼働後の切り分けを短縮
検証範囲を文書で残す第三者検証
窓口予約システムの受け入れでは、何を確認し何を確認していないかが文書に残らないと、稼働可否を庁内へ説明できません。GENZはテスト設計で検証範囲を定め、確認済みと未確認を分けた報告書としてお渡しします。
課ごとの差異からテスト設計
複数の所管課が同一システムを使う構成では、予約の受付方法や本人確認の条件が異なります。差異を一覧に整理し、テスト観点を設計します。
住民操作も検証範囲に入れる
照会・変更・取消を住民がスマートフォンから操作する構成では、発注側で確認できる範囲が限られます。本人確認の照合も検証範囲に含めます。
どちらの体制でも役割が重ならない
ベンダー側にテスト体制がある場合も発注側にある場合も、保守委託やベンダーテストと重複しない範囲へ役割を組み替えて引き受けます。
確認済みと未確認を分けて報告する
レビューから動的テストの設計・実行、報告書の納品までを一連の役務として担い、確認済み範囲と未確認範囲を区別して記録します。
ご相談から納品までの流れ
対象手続きと稼働予定の確認から始め、検証範囲の設計、テスト実施、報告書の納品までを一連で進めます。
対象の手続きと稼働予定をヒアリング
対象の手続き・所管課・稼働予定日を伺い、住民影響のある経路を洗い出します。
検証範囲のテスト設計とお見積もり
経路をもとに検証範囲と優先順位を設計し、必要工数をお見積もりします。
テストの実施と検出事項の共有
設計した項目にもとづき実施し、検出した不具合を再現手順とともに共有します。
報告書の納品と修正後の再確認
確認済みと未確認の範囲を分けた報告書を納品し、修正後の箇所を再度検証します。
更改や受け入れを控えたご担当者様へ
窓口予約システムの検証範囲と優先順位から、ご相談ください
確認済みの範囲と未確認の範囲を区別して残せれば、管理職への説明も稼働後の切り分けも進められます。GENZは検証範囲を設計し、結果を報告書としてお渡しします。