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

GENZが確認する検証の観点

GENZは、期限判定・通知・読み取り・システム連携・端末間の挙動という観点で、条件を変えながら挙動を検証し、実施条件と結果の記録を証跡として残します。

境界値の確認が担当者の手作業に留まると、確認済み条件の一覧が残らず、受け入れ側で何を確認すべきかを決められないおそれがあります。

期限判定の境界となる条件の網羅

期限の当日・前日・設定日数前といった境界条件を一覧化し、条件ごとに判定結果を確認します。実装担当の手元確認に依存していた範囲を、第三者の観点で網羅します。

確認する資料
  • 観点表
  • 実施記録
  • 結果一覧
通知の不到達が端末設定や通信状態に起因する場合、原因の切り分けができないまま「アプリが使えない」という評価が現場に広がるおそれがあります。

通知の到達と端末設定の組み合わせ

通知の到達を、端末の日付設定・通知許可・通信状態の組み合わせを変えて検証します。所定のタイミングで届かない条件を特定し、再現手順と併せて記録します。

確認する資料
  • 条件一覧
  • 到達記録
  • 再現手順
未登録品の扱いが仕様として定まらないまま運用が始まると、期限が登録できない品目が現場の運用で吸収され、問題として表面化しないおそれがあります。

バーコード読み取りと商品マスタの照合

バーコード読み取りの成否と、商品マスタとの照合結果を確認します。未登録品が発生した場合の挙動も仕様と照らし合わせ、登録できない品目の条件を洗い出します。

確認する資料
  • 仕様照合表
  • 未登録一覧
  • 成否記録
連携の授受を確認しないまま稼働すると、マスタの更新漏れや送信の欠落に気づけず、本部側の集計と現場の実績が一致しないおそれがあります。

基幹システムと在庫管理システムとの授受の確認

基幹システムとの商品マスタの受領と、期限情報・廃棄情報の送信を、連携の前後で突き合わせて確認します。連携方式と頻度に応じて確認の粒度を決めます。

確認する資料
  • 連携確認表
  • 授受記録
  • 差異一覧
手持ち端末だけの確認でリリースすると、未確認の機種・OSの組み合わせで不具合が残り、追加拠点への展開判断が保留されるおそれがあります。

現場端末の機種とOSの版をまたぐ挙動の確認

拠点ごとに異なる端末の機種とOSの版を対象に、読み取り・判定・通知の挙動を検証します。OS更新後の退行確認も範囲に含め、更新ごとの確認範囲を定めます。

確認する資料
  • 対象端末表
  • 実施記録
  • 退行確認表
  • 更新対応表
04 TEST DESIGN

テスト外注の進め方と成果物

GENZが検証を受託する際の進め方と、各工程でお渡しする成果物を示します。成果物は判定会議や社内稟議に使える形で整えます。

STEP 01 現状の確認と確認済み範囲の棚卸自部門で確認済みの範囲と未確認の範囲を分けます。
どう確かめるか

テスト計画の作成と対象範囲の確定

対象機能、対象端末、連携先、実施するテストレベルを洗い出し、検証の対象範囲を確定させます。未確認の機種やOSの組み合わせが残らないよう、端末管理台帳との突き合わせから始めます。

  • 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のテスト体制

開発側の確認と発注側の受け入れの間に、独立した立場で挙動を確かめる工程を置きます。GENZはテスト計画の作成から設計・実施・報告と証跡整備までを担い、開発の進行を止めずに検証を進めます。

SVC 01

開発のスプリントに並行して進めるテスト

開発のスプリントに合わせ、実装と並行して期限判定・通知・読み取り・連携のテストを進めます。リリース日程を待たずに確認の段取りを組みます。

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

大規模システムを対象とした網羅的な検証

拠点ごとに機種とOS版が異なる端末の範囲まで対象に含め、自部門で持てない端末と工数を補います。確認範囲の決め方から一緒に整理します。

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

開発主体から独立した立場での検証の進行

開発主体とは別の立場で挙動を確認します。誰が検証したかが明確な形で残るため、リリース判断や上長への説明の根拠としてそのまま使えます。

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

監査に備えたテスト証跡の管理

実施した範囲と結果、残存不具合、未確認範囲を証跡として整備します。判定会議と品質監査の両方で参照できる記録の形で残します。

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

相談から着手までの流れ

賞味期限管理アプリの検証をご検討の際は、相談の受付から着手まで、次の流れで進めます。

相談の受付と現状の聞き取り

お問い合わせの後、対象アプリの構成とお困りの範囲を担当者が聞き取ります。

検証範囲の整理と見積もりの提示

聞き取った内容をもとに検証範囲と優先順位を整理し、見積もりを示します。

契約条件と検収条件の確認

作業範囲・成果物の形式・検収の条件を、契約を結ぶ前に双方で確認します。

着手とテストの開始

合意後にテスト環境と対象端末を整え、テスト計画に沿って検証を開始します。

開発主体から独立した検証体制

賞味期限管理アプリのテスト外注はGENZへご相談ください

賞味期限管理アプリの検証を開発ベンダーとは別の立場で実施します。ご相談では、確認すべきテスト範囲、優先順位、必要工数、関連テストの要否を、社内説明に使える形でお渡しします。