GENZ, Inc.

リリース判定の材料に 予約台帳アプリの品質を、開発とは別の目で確かめる

予約の受付経路、席の在庫、レジや決済との連携。確認範囲は機能追加のたびに広がります。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

予約台帳アプリのテストで見落としが起きやすい場面

予約台帳アプリでは、電話とネット予約の重複、変更や取消の反映漏れ、会計への引き継ぎ漏れ、端末更新後の操作不良、予約が集中する時間帯の表示ずれが、確認の優先順位を下げたまま見落とされやすい場面です。

電話とネット予約が重なったときに席を二重に確保する

電話予約の入力中にネット予約が入ると、同じ席が両方の経路で確保され、来店時にどちらの客を案内するか決められません。

席の二重確保

予約の変更と取消が台帳の席の状態へ反映されない

店舗が取消を端末で処理しても連携先へ届かず、空いた席が埋まらないまま追加の予約を受け付けられなくなります。

連携の反映漏れ

人数やコースの変更が会計側へ引き継がれない

来店後に人数やコースの変更が会計へ伝わらず、提示する金額が予約内容と異なるため、店員がその場で計算しなおすことになります。

会計の金額不一致

端末や基本ソフトウェアの更新後に操作が通らない

端末や基本ソフトウェアの更新後に、タッチで予約を入力する操作が反応せず、営業時間中に台帳へ書き込めない状態が残ります。

更新後の操作不良

予約が集中する時間帯に表示と実データがずれる

予約が集中する時間帯に、画面の空席表示と実データが一致せず、すでに埋まった席を空いているものとして売ってしまいます。

実データの表示ずれ
02 RISK

不具合が営業時間中に表へ出たときに起きること

予約台帳アプリの不具合は、営業時間中の店舗で初めて表へ出ることがあります。影響を受けるのは、来店客を目の前にした店舗の現場です。

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

開発とは別の立場で確かめる観点

開発したチームとは別の立場で、予約の受付から会計までを通して確かめる観点を整理します。開発側の確認は実装の意図に沿って進むため、操作の順序や端末の条件が実際の店舗の運用からずれた場面が抜けやすくなります。

この確認を省略すると、機能追加のたびに流れの継ぎ目で予約の欠落や二重確保が起きるおそれがあります。

予約の受付から来店の消し込みまで通しで確かめる

ネット予約の登録から変更と取消、席の割り当て、来店時の消し込みまでを一連の流れとして確かめます。単機能の確認だけでは、予約が途中の画面で消える、二重に入るといった継ぎ目の事象を見落とします。

確認する資料
  • 予約登録
  • 変更取消
  • 消し込み
この確認を省略すると、連携先の仕様が変わったときに追随できず、特定の経路からの予約だけが台帳へ反映されないおそれがあります。

外部の予約経路と台帳側の席在庫を突き合わせる

外部の予約経路から届いた情報が、台帳の席在庫へ反映されるかを照合します。経路ごとに仕様変更の連絡粒度が異なり、連絡文だけでは確認範囲が定まりません。確認した範囲の記録が判定材料になります。

確認する資料
  • 経路別仕様
  • 在庫反映
  • 変更通知
この確認を省略すると、予約が集中する時間帯に障害が出やすいままとなり、再現条件をつかめない申告が積み上がるおそれがあります。

同時操作と通信が途切れた場面の挙動を確かめる

複数の端末からの同時操作や、通信が途切れた直後の再送で、席の二重確保や予約の欠落が起きないかを意図的に発生させて検証します。営業時間中は再現条件を聞き取れないため、事前に挙動を確認します。

確認する資料
  • 同時操作
  • 通信断絶
  • 再送処理
この確認を省略すると、端末や基本ソフトウェアの更新後に特定の組み合わせで操作できない状態が、店舗からの申告で初めて判明するおそれがあります。

端末と基本ソフトウェアの組み合わせで操作を再現する

店舗が使う端末と基本ソフトウェアの組み合わせごとに、台帳画面の表示と操作を確かめます。組み合わせは増えるため、全数ではなく対象範囲の方針に沿って代表の組み合わせを選び、条件を記録に残します。

確認する資料
  • 端末一覧
  • OS組合せ
  • 表示確認
この確認を省略すると、権限の設定ずれに気づかないまま運用が続き、来店客の情報の取り扱いに関する指摘へ説明できる材料が残らないおそれがあります。

来店客の情報の扱いとスタッフごとの権限設定を確かめる

来店客の情報の表示範囲と、スタッフごとの操作権限が、想定どおりに設定されているかを確かめます。権限の設定ずれは不具合として表れにくく、情報の取り扱いの運用変更への追随が遅れたときに判明します。

確認する資料
  • 権限設定
  • 表示範囲
  • 操作履歴
  • 運用変更
04 TEST DESIGN

テストを外部へ任せるときの進め方

「どこを確認し、どこを確認していないか」をあとから説明できる状態にするには、委託の進め方自体を決めておく必要があります。

STEP 01 対象と範囲を決める委託する範囲と自社に残す確認の境目を決めます。
どう確かめるか

開発の反復に合わせてテストを伴走する形で進める

機能追加や大規模改修のたびに、確認すべき範囲は広がります。リリースの計画にテストを組み込み、開発の反復ごとに伴走して検証します。確認の線引きを担当の記憶に頼らず、計画として置きます。

  • 01対象とするリリースと追加した機能の一覧を整理する
  • 02連携する予約経路と対象となる端末の範囲を先に区切る
  • 03開発側で行なう確認と委託する範囲の境目を決めておく
OUTPUTテスト範囲と優先順位の一覧
STEP 02 テストの設計と観点をすり合わせる店舗の営業時間に即した観点をすり合わせます。
どう確かめるか

対象が大きい場合も範囲を分けて段階的に網羅する

予約の登録から会計までの通し確認は、機能・経路・端末の組み合わせで範囲が広がります。対象を区切って優先順位を付け、分割して網羅します。改修が小さい場合も通し確認の要否を見通します。

  • 01予約の登録から会計までの経路をテストの観点に分解する
  • 02予約が集中する時間帯と同時操作を想定した条件を設定する
  • 03テストの優先順位と必要な工数の考え方を整理して示す
OUTPUT観点へ分解したテスト設計
STEP 03 テストを実施し、見つかった事象を報告する見つかった事象は発生条件とともに報告します。
どう確かめるか

開発とは別の立場で受け入れ判定の材料をそろえる

開発した側が確認も行なうと、判定材料の作成主体と開発主体が重なり、根拠が弱いという指摘に対応できません。開発とは別の立場で範囲を区切って検証し、受け入れ判定へ出せる材料をそろえます。

  • 01合意したテスト設計と観点に沿って項目を順に実行する
  • 02見つかった事象を発生条件と再現手順つきで記録する
  • 03テストの進捗と見つかった事象の一覧を定期的に共有する
OUTPUT発生条件つきの事象一覧
STEP 04 修正後の再テストと結果の引き渡し修正後の再テスト結果を記録として引き渡します。
どう確かめるか

確かめた内容をあとから説明できる形で記録に残す

検証した範囲と結果を記録に残すと、リリース判定や、複数の店舗から申告が重なったときの調査で、何を確認し何を確認していないかを説明できます。稟議で費用の根拠を示す材料にもなります。

  • 01修正が完了した箇所を再テストで確認して記録に残す
  • 02修正が関連する既存機能へ影響していないかを確認する
  • 03検証した範囲と結果を報告書と記録にまとめて引き渡す
OUTPUT再テスト結果の記録
05 RATIONALE

外部へ任せる検証の範囲をどこで区切るか

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

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

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

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

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

専門ノウハウを即戦力で

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

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

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

  • 担当の記憶ではなく設計として確認範囲を線引きできる
  • 端末と予約経路の組み合わせを任せる単位で区切れる
  • 開発主体と別の立場の確認として判定材料を示せる
  • 何を確認し何をしていないかあとから説明できる記録が残る
06 SERVICE

お引き受けできるテストの種類

予約の受付から会計まで、台帳アプリが担う処理は複数の機能と外部サービスの組み合わせで成り立ちます。GENZは開発主体とは別の立場で、機能ごと・連携経路ごと・端末ごとに範囲を区切って検証をお引き受けします。

SVC 01

予約の受付から会計までの機能テスト

予約の登録・変更・取消から席の割り当て、来店時の消し込み、会計への引き継ぎまで、画面での操作が仕様どおりに動くかを検証します。

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

外部の予約経路やレジとの連携テスト

ネット予約サイトやレジ・決済サービスとの間で、予約情報と決済結果が正しく受け渡されるかを、連携先の仕様変更も含めて検証します。

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

端末と基本ソフトウェアの組み合わせ検証

店舗で使うタブレットなどの端末と基本ソフトウェアの組み合わせについて、動作の対象とする範囲の方針に沿って表示と操作を確認します。

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

予約が集中する時間帯の同時操作テスト

予約が集中する時間帯に複数の端末から同時に登録や変更が行われた場合に、席の在庫が二重に確定しないかを意図的に発生させて検証します。

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

お問合せから検証開始までの流れ

どこから区切るか決まっていない段階でもご相談いただけます。対象と優先順位から整理します。

お問合せと現在の状況の聞き取り

問合せフォームまたは電話でご連絡ください。対象のリリース予定を伺います。

確認の対象範囲と進め方のお見積

連携経路と端末の範囲を整理し、進め方と必要工数を見積として提示します。

ご契約とテスト計画・優先順位の確定

ご契約後、確認の境目を合意し、テスト計画と優先順位を確定します。

テストの開始と検証結果のご報告

計画に沿って実施し、結果は記録と報告書にまとめてお渡しします。

開発とは別の立場で、範囲を区切って確かめる

予約台帳アプリのテストについて相談する

ご相談では、予約の受付経路や席の在庫、レジ・決済との連携をどこまで確かめるかというテスト範囲と優先順位、必要な工数の考え方、関連テストの要否まで整理してお返しします。