必須項目を空のまま送信でき、訪問先が未入力の受付データが登録される
必須チェックの設定漏れがあると、訪問先が空のまま登録されます。通知を受けた担当者は誰が来たか判断できず、来訪者を待たせます。
GENZ, Inc.
受付アプリの導入担当者様へ
受付アプリの
受付アプリの導入担当者様へ
受付アプリの検証を第三者の視点で
総務が設定した受付アプリは、ベンダーの保証範囲外に自社固有の運用フローが残ります。GENZは検証範囲を文書で定義し、テスト設計から報告まで伴走します。
支援事例
支援実績5,000件以上
受付アプリでよくある不具合
社内の確認では想定どおりの操作しか試されず、受付アプリの不具合は来訪者の初回操作ではじめて表面化します。総務・情シスが設定した範囲で起きやすい不具合を、よくある形で整理しました。
必須項目を
目的別ボタンの選択と通知先の対応が入れ替わり、別の部署へ通知が届く
目的別ボタンと通知先の紐づけ設定が誤ると、別部署へ通知が届きます。被訪問者は来訪に気づかず、来訪者が受付に取り残されます。
異動した被訪問者が宛先に残り、通知が誰にも届かないまま受付が完了する
人事異動で通知先を更新しないまま運用を続けると、宛先が不在となります。受付は完了しても通知が誰にも届かず、来訪者対応が滞ります。
退館操作のない入館記録が残り、入退館が突合しない
退館操作が来訪者任せの運用では、入館だけの記録が残ります。入退館記録が突合せず、点検時に在館状況を説明できなくなります。
アプリ更新後に受付画面の入力欄が隠れ、来訪者が途中で操作を止める
アプリやOSの更新で表示が変わると、入力欄が画面外へ隠れることがあります。来訪者は操作の途中で止まり、受付を完了できません。
残存した不具合により生じる問題
検証を経ずに稼働した受付アプリの不具合は、社内に留まらず来訪者の体験と事業の評価へ直結します。放置した場合に生じる問題を順に整理します。
静的テスト（レビュー）でおさえるべき観点
受付アプリの不具合は、動かして初めて見えるものだけではありません。設定値やルールの記述を、画面を動かす前に文書同士で照合する静的テストによって、抜けを事前に検知できます。ここでは照合すべき観点を整理します。
来訪者の初回操作で入力が止まり、受付に案内役がいないまま放置されるおそれがあります。
受付画面の項目定義書と、来訪者対応の運用ルールを照合する
来訪者が入力する氏名・会社名・訪問先の項目定義が、無人化後の運用ルールと一致するかを照合します。項目が足りないと受付が止まり、過剰だと保管する個人情報が増え、点検時の説明が難しくなります。
確認する資料
- 項目定義書
- 運用ルール
- 画面仕様書
通知が届かない状態に気づけず、来訪者が受付で待つ事象が繰り返されるおそれがあります。
目的別ボタンの一覧と、通知先の設定値を漏れなく照合する
目的別のボタンごとに、通知先として設定された個人宛・グループ宛の宛先を一覧と照合します。異動や不在で宛先が無効でも、設定完了の報告では検知できず、来訪者の到着時に通知の不到達が表面化します。
確認する資料
- ボタン一覧
- 通知先設定値
- 組織図・名簿
不具合の原因がベンダー側か自社設定かを切り分けられず、対応が滞るおそれがあります。
ベンダーの標準機能の保証範囲と、自社が設定した範囲の境界を照合する
ベンダーが保証する標準機能と、自社で設定した通知条件や連携の範囲の境界を文書で照合します。境界が定まらないと、不具合が提供元へ確認すべき事象か自社の設定かを切り分けられず、調査が滞ります。
確認する資料
- 保証範囲の文書
- 設定手順書
- 運用フロー図
点検時に保管状況を説明できず、是正対応のコストが発生するおそれがあります。
入退館記録の項目定義と、社内規程の保管期間・削除の条件を照合する
入退館記録の項目定義が、社内規程で定めた保管期間と削除の条件と一致するかを照合します。設定の現状を示す記録がないと、点検のたびに画面を開く確認となり、削除すべき記録と残す記録が混在します。
確認する資料
- 記録項目定義
- 社内規程
- 削除運用手順
連携先の記録が欠けたまま稼働し、入退館の記録として成立しない状態になるおそれがあります。
連携先の API定義と、受付アプリから渡すデータ項目を照合する
入退館管理や来訪者DBとの連携では、連携先のAPI定義と受付アプリから渡すデータ項目を照合します。項目の欠落や型の不整合は設定時に気づきにくく、連携先で記録が欠けた状態として表面化します。
確認する資料
- API定義
- 連携項目一覧
- 連携方式の仕様
- データ形式定義
動的テストの設計・実行のポイント
受付アプリの検証は、入力項目・通知連携・来訪者の操作・更新後の挙動の層に分けて設計し、層ごとにテストの種別を使い分けます。
STEP 01
入力項目のユニットテスト境界値は項目定義にもとづき設定します
どう確かめるか
入力項目のユニットテストを、文字種と文字数の境界値で確かめる
氏名・会社名・訪問先の各項目で、文字種と文字数の境界値を設定し、受け付ける入力と拒否する入力を確認します。確認が抜けると、長い会社名や外字を含む氏名で受付が止まります。
- 01氏名・会社名・訪問先の文字種の許容範囲を確認します
- 02各項目の文字数の境界値で受付の可否を確認します
- 03未入力・空白のみの入力に対する挙動を確認します
OUTPUT入力項目のテスト項目書
STEP 02
通知・連携の統合テスト宛先の解決から送信までを通しで確かめます
どう確かめるか
受付から通知までの統合テストで、宛先の解決と連携の送信を確かめる
受付の完了を起点に、担当者個人宛・グループ宛・代理者宛それぞれで通知が届くかを検証します。入退館管理や来訪者DBとの連携がある場合は、送信される記録の内容まで確認します。
- 01担当者個人宛の通知が受付完了直後に届くか検証します
- 02グループ宛・代理者宛で通知先の解決が正しいか検証します
- 03入退館管理・来訪者DBへ記録が送信されるか確認します
OUTPUT通知・連携の統合テスト結果
STEP 03
来訪者シナリオのシステムテスト異常系のテスト観点を実機で確かめます
どう確かめるか
来訪者の操作シナリオでシステムテストを行ない、途中離脱と同時到着を確かめる
初回操作の来訪者を想定し、誤操作・途中離脱・同時到着を意図的に発生させて検証します。離脱時に記録がどう残るかは製品ごとに異なるため、実機で確かめます。
- 01初回操作の誤操作で受付が途中で止まらないか検証します
- 02途中離脱時に記録がどう残るかを発生させて検証します
- 03同時到着時に通知と記録が欠けないか検証します
OUTPUT来訪者シナリオの報告書
STEP 04
更新後の回帰テスト更新の都度、同一項目で確認します
どう確かめるか
更新後の回帰テストを実施し、受付画面と通知の挙動の変化を確かめる
アプリ更新・タブレットのOS更新・ブラウザの更新のたびに、受付画面の表示と通知の挙動を確認します。仕様変更を伴わない更新でも挙動が変わるため、同じ項目で回帰テストを実施します。
- 01更新後に受付画面の表示項目が変わっていないか確認します
- 02更新後に通知の宛先と文面が維持されるか確認します
- 03更新前後の差異を不具合票として記録します
OUTPUT更新後の回帰テスト記録
GENZが代行する受付アプリのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- ベンダーの保証範囲と自社の検証範囲を文書で線引きします
- 管掌部長と品質保証担当へそのまま出せる報告書が残ります
- 来訪者の誤操作や通知先不在まで異常系のテスト観点を用意します
- テスト項目書は更新のたびに回帰テストとして使い回せます
受付アプリのテストをGENZへ任せる理由
受付アプリは来訪者が初回に操作し、ベンダーの保証が届かない設定・運用の範囲が残ります。GENZは第三者の視点で検証範囲を文書で線引きし、異常系まで含めたテスト設計から報告まで、今の体制のまま伴走で補います。
設定と運用からテスト設計を起こす
入力項目や通知先など、貴社固有の設定と運用フローを確認し、どこまでを検証範囲とするかを文書で定義したうえでテスト設計を起こします。
受付から記録・連携まで検証する
来訪者の誤操作・途中離脱・同時到着・通知先不在といった異常系のテスト観点を含め、受付の操作から通知・入退館記録・連携までを検証します。
今の体制のまま、足りない工程を伴走で補う
総務主導・情シス兼務の体制を組み替えずに進められるよう、確認の手が足りない工程だけを第三者の視点で伴走しながら補います。
テスト項目書と報告書を納品する
検証した範囲と結果を管掌部長や品質保証担当へそのまま提出できる報告書と、更新時の回帰テストに使い回せるテスト項目書を納品します。
ご相談から納品までの流れ
受付アプリのテストは、ヒアリングから報告書の納品まで、切替日程に合わせて次の流れで進めます。
受付アプリの構成と運用ルールのヒアリング
入力項目・通知先・連携設定と運用ルールを伺い、検証範囲の境界を整理します。
テスト設計とお見積もり
異常系を含むテスト観点を設計し、範囲と工数をお見積もりに示します。
テスト実施と不具合の共有
設計した項目を実施し、不具合は再現手順を添えて不具合票として共有します。
報告書の納品と、修正後の再確認
結果を報告書にまとめて納品し、修正後の回帰テストで挙動を確認します。
無人受付のリリース判断を検証の形に
受付アプリの検証範囲と優先順位をGENZへご相談ください
ベンダーの保証範囲と自社が引き受ける範囲の境界が定まらないままでも、ご相談いただければ、受付アプリの検証範囲の線引き、必要工数の考え方を、文書にできる形で整理してお返しします。