受付日時の起点が誤り、対応期限が翌日の日付で算出される
対応期限の算出が自社の営業日・休日ルールに従わず、期限超過のアラートが遅れて出ると、回答期限を過ぎても画面で気づけない事象が起きます。
GENZ, Inc.
発注側でもベンダーでもない
クレーム管理ソフトを
発注側でもベンダーでもない
クレーム管理ソフトを第三者視点で検証します
クレーム管理ソフトの検証範囲と優先順位を、第三者の視点で線引きします。受け入れテストの設計から報告までを担い、リリース判断と監査に残る材料を提供します。
支援事例
支援実績5,000件以上
クレーム管理ソフトでよくある不具合
クレーム管理ソフトでは、受付から是正処置・集計までを同一の記録単位で扱う製品が多く、承認段階や期限計算、外部連携といった自社独自のルールとの間で、画面操作の確認だけでは検出できない不具合が生じます。
受付日時の
重大度の閾値に接する申し立てで、承認段階を経ずに完了できる状態になる
重大度や金額の境界値に接する申し立てで承認段階が分岐せず、承認者を通さず完了状態になると、監査で説明できる証跡が残りません。
移行した過去の記録と新規の記録で、集計レポートの件数が合わない
移行した過去の記録と新規登録の記録で集計基準が異なると、レポートの件数に差異が生じ、原因の切り分けに現場とベンダーの工数が取られます。
外部システムへの連携が再送され、同一の原因情報が二重に登録される
外部システムへの連携が再送されると同一の原因情報が二重に登録され、集計値が膨らんで他部門の信頼を損なう事象が起きます。
フォーム受付の内容が文字化けし原因未分類で保存される
Webフォーム経由の受付内容が文字化けして原因分類が付かないまま保存されると、集計対象から漏れ、発生傾向の分析ができなくなります。
残存した不具合により生じる問題
受け入れテストで業務ロジックの境界値まで検証できないままリリースすると、期限計算や承認分岐、集計の不整合が稼働後に表面化します。
静的テスト（レビュー）でおさえるべき観点
受け入れテストの項目書に業務ロジックの条件が入らない原因の多くは、仕様書の記述と社内の運用ルールが設計段階で照合されていないことにあります。実行前のレビューでおさえるべき観点を整理します。
照合を省略すると、対応期限の計算が自社の営業日と一致せず、受け入れテストで期限超過の判定を確認できないままリリースされます。稼働後にエスカレーションが発動せず、一次回答が遅延するおそれがあります。
対応期限の算出規則を、休日カレンダーと運用ルールの定義と照合する
受付日時を起点とする営業日計算や休日の扱い、エスカレーションの閾値は製品ごとに異なります。仕様書の記述を自社の休日カレンダーと受付部門の運用ルールに照合し、期限計算の前提の一致を確認します。
確認する資料
- 仕様書
- 休日カレンダー
- 運用ルール
承認分岐の条件が権限規程と一致しないまま実装が進むと、重大クレームが管掌役員の承認を経ずに完了扱いとなります。是正処置の承認の証跡が残らず、監査で記録の不備を指摘されるおそれがあります。
承認段階の分岐条件を、権限規程の重大度区分と金額の閾値と照合する
是正処置の承認段階の数と承認者の決定規則は、製品標準か個別設定かが対象システムにより分かれます。仕様上の分岐条件を権限規程の重大度区分と金額の閾値に照合し、段階の抜けを確認します。
確認する資料
- 仕様書
- 権限規程
- 承認フロー図
項目の対応付けに漏れがあると、移行した過去の受付記録と新規の受付記録が混在する状態で集計値が合わなくなります。原因の切り分けに現場とベンダーの双方の工数が取られ、修正コストが短期で計上されます。
移行の項目対応を旧新の定義と照合する
旧システムから移行する記録と新規登録の記録の項目の対応関係は案件ごとに定まります。項目の統合・分割・既定値の補完について、移行仕様書と旧新の項目定義を照合し、対応付けの漏れを洗い出します。
確認する資料
- 移行仕様書
- 旧項目定義
- 新項目定義
集計の基準日と単位が報告様式と一致しないと、部門横断で参照されるレポートの数値を他部門が信頼しなくなります。クレーム情報の一元化による設計・生産・調達へのフィードバックが回らず、導入目的が達成されません。
集計の基準日と単位を報告様式と照合する
集計期間の区切り（受付日基準か完了日基準か）と紐づけ単位（製品別・原因分類別）はシステムごとに異なります。帳票定義と報告様式を照合し、他部門へ提出する数値との一致を確認します。
確認する資料
- 帳票定義
- DB設計書
- 報告様式
連携項目の欠落や再送方式の未定義を見落とすと、稼働後に連携データの欠落が判明し、運用・設定・実装のどこに原因があるかの合同調査が必要になります。リリース前の検証範囲の記録が残っていなければ、調査と並行して説明のための作業が発生します。
外部連携の項目と再送方式を定義書と受け入れ条件で照合する
外部システム（CRM・生産管理・ISO文書管理）との連携方式と頻度は構成により異なります。API定義やファイル連携の仕様を連携先の受け入れ条件と照合し、項目の欠落と再送方式を確認します。
確認する資料
- API定義
- 構成図
- 連携先仕様
- 受け入れ条件
動的テストの設計・実行のポイント
クレーム管理ソフトのテストは、テストレベルごとに狙いを分け、期限算出のロジックから業務シナリオへ確認範囲を重ねます。
STEP 01
ユニットテスト業務ロジックの境界値を単体で検証します
どう確かめるか
期限算出と承認分岐の条件を、境界値分析と同値分割でユニットテストする
期限の営業日計算や重大度・金額による承認段階の分岐は、境界値分析と同値分割で条件を切り出します。閾値の前後と休日をまたぐケースを項目化し、個別仕様どおりの処理を検証します。
- 01期限算出の閾値前後と休日またぎの条件を洗い出します
- 02承認段階の分岐条件を重大度・金額別に網羅します
- 03同値分割で代表値を選び入力パターンを絞ります
OUTPUT境界値のテスト項目書
STEP 02
統合テスト画面をまたぐ処理と連携を確認します
どう確かめるか
受付から承認・完了までの状態遷移と外部連携を、統合テストで確かめる
受付から一次回答、原因分析、是正処置の承認、完了までの状態遷移を確認します。CRMや生産管理、ISO文書管理との連携がある場合は、データの受け渡しも統合テストの対象に含めます。
- 01受付から完了までの状態遷移パターンを確認します
- 02外部システムとのデータ連携の受け渡しを検証します
- 03承認差し戻し時の状態と通知の動作を確認します
OUTPUT状態遷移と連携の確認結果
STEP 03
システムテスト移行データ込みの集計値を照合します
どう確かめるか
移行データを投入した集計・レポートの件数を、システムテストで照合する
移行した過去の記録と新規登録の記録を混在させた状態で、集計・レポートの件数と金額を照合します。移行時の項目の統合や既定値の補完が集計値へ与える影響を、帳票の出力結果で確認します。
- 01移行データと新規データを混在させて集計します
- 02帳票の件数・合計値を移行仕様書と照合します
- 03集計期間の区切りと紐づけ単位の定義を確認します
OUTPUT集計値の照合結果
STEP 04
受け入れテストと回帰テスト業務シナリオと更新後の回帰を行います
どう確かめるか
現場の業務シナリオでの受け入れテストと、更新後の回帰テストを実施する
受付部門に業務シナリオでの受け入れテストを実施してもらい、不具合票を集約します。リリース後はパッチ適用やマスタ変更のたびに、影響範囲に応じた回帰テストを実施します。
- 01現場の業務シナリオで受け入れテストを実施します
- 02不具合票を集約しリリース判断の材料を作ります
- 03更新・パッチ適用後の回帰テスト範囲を決めます
OUTPUT受け入れ・回帰テスト結果
GENZが代行するクレーム管理ソフトのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 業務ロジックの境界値まで含むテスト項目書を設計します
- 検証範囲と優先順位を根拠つきで線引きします
- 件数と多様性のあるテストデータを用意します
- ベンダーのテスト工程に接続する形で受け入れテストを進めます
業務ロジックに沿う検証設計の支援
受け入れテストでは、画面の操作確認に留まり、対応期限の計算や承認分岐といった業務ロジックまで検証が及ばない状況が生じます。GENZは検証範囲を線引きし、テスト設計から報告までを発注側の立場で支援します。
業務ロジックを起点にテスト設計します
対応期限の計算、承認分岐、再発防止との紐づけ、集計の条件を、境界値と異常系のテスト観点まで含めて項目書へ設計します。
検証する範囲と対象外を根拠とともに線引き
限られた日程の中で検証する範囲と対象外とする範囲を、業務への影響を根拠に線引きし、優先順位とともに示します。
既存のテスト工程に接続
ベンダーのテスト工程が進行する中へ、発注側の受け入れテストとして接続します。テストデータの用意まで含めて対応します。
判断と監査に使える報告書を納品
検出した不具合だけでなく、検証した範囲と対象外とした範囲が残る報告書を納品し、リリース判断と監査で参照できる形にします。
ご相談から納品までの流れ
クレーム管理ソフトの受け入れテストは、ご相談から納品まで段階を分けて進めます。
対象システムと日程のヒアリング
対象の機能範囲と個別仕様、受け入れテストの日程をお伺いします。
範囲確定とテスト設計・見積もり
検証範囲とテスト観点を整理し、重複しない線引きと見積もりを提示します。
テストの実施と不具合票の共有
項目書に沿ってテストを実施し、不具合票と切り分けの材料を共有します。
報告書の納品と修正後の再確認
残存リスクを記した報告書を納品し、修正後は回帰テストで再確認します。
無料相談・見積もり受付中
クレーム管理ソフトの検証範囲と優先順位を、GENZにご相談ください
対象機能の洗い出しから検証範囲の線引き、優先順位の決め方、必要工数の考え方まで、初回のご相談で整理いただけます。回帰テストなど関連テストの要否もあわせてご案内します。