点検区分の境界にあたる引き渡し日の物件が抽出から漏れる
点検周期の判定が引き渡し日からの経過期間に依存し、境界値で抽出条件に不整合が起きます。定期点検の案内が届かず、入居者の申し立てで判明します。
GENZ, Inc.
受付から請求までの
アフターサービス管理システムの
受付から請求までの
アフターサービス管理システムのテストを第三者視点で代行
製品選定の後に残るのはテスト工程の体制です。GENZは点検周期や契約満了日の業務ルールからテスト項目書を起こし、工程別の検証範囲と優先順位を提示します。
支援事例
支援実績5,000件以上
アフターサービス管理システムでよくある不具合
アフターサービス管理システムの不具合は、点検周期の判定や保守契約の満了日処理、モバイル端末との連携など個別仕様に集中し、受け入れテストで検出されず、稼働後に表面化して案内漏れや請求の再処理へつながります。
点検区分の
受付から手配への引き継ぎで作業指示が二重登録される
受付した修理依頼を手配側へ引き継ぐ処理で、再登録を防ぐ仕組みがないと二重登録が検知されません。二度の手配で日程と請求に不整合が残ります。
通信断のとき作業報告が保存されず明細が欠落する
通信が不安定な現場では、モバイル端末からの作業報告が送信に失敗したまま保存されません。写真や使用部品の明細が欠落し、作業実績を確認できません。
保守契約の満了日をまたぐ請求で、対象期間が重複して計上される
保守契約の満了日をまたぐ請求で、対象期間の区切り方が個別仕様に依存します。同じ期間が前後の請求へ重複して計上され、入金消込との差異が残ります。
機器マスタの更新が修理履歴に反映されず照合できない
機器マスタの更新と修理履歴の参照先が別に管理されていると、更新が履歴側へ反映されません。納入機器情報の照合に手作業が混在し、工数が増えます。
残存した不具合により生じる問題
受け入れテストで検出されなかった不具合が稼働後に表面化すると、点検案内の漏れ、請求差異、監査証跡の欠落が継続収益と業務の信頼へ影響します。
静的テスト（レビュー）でおさえるべき観点
開発段階で設計書の記述が曖昧なまま実装へ進むと、点検周期の判定や契約満了日の扱いの解釈の相違がテスト段階で表面化します。実装前のレビューで照合すべき観点を整理します。
点検対象の抽出誤りにより、案内の漏れや無償・有償の誤判定が発生するおそれがあります
点検周期と無償・有償の区分を保証規定と照合する
定期点検の対象抽出条件と、保証期間内の無償対応・期間外の有償対応の区分が、保証規定と設計書の記述で一致しているかを照合します。判定基準の記述がないと対象抽出の結果が業務の期待と合いません。
確認する資料
- 保証規定書
- 機能設計書
- 点検マスタ定義
作業の手配が滞留し、入居者への連絡が遅れて再訪問の工数が発生するおそれがあります
受付から修理完了までの状態遷移を業務フロー図と画面設計書で照合する
修理の受付、手配、作業実施、報告登録、完了までの状態遷移が、業務フロー図と画面設計書で定義されているかを確認します。差し戻しの扱いが画面側へ反映されないと、手配の引き継ぎで滞留が起きます。
確認する資料
- 業務フロー図
- 画面設計書
- 状態遷移表
機器情報と修理履歴の照合に手作業が残り、更新漏れが点検計画へ反映されないおそれがあります
納入機器と修理履歴のキー設計を移行要件と照合する
納入機器情報と修理履歴を結ぶキーの設計が、旧システムからのデータ移行要件と整合しているかを照合します。キーの粒度が機器単位と部位単位で不一致だと、機器情報の更新が履歴側へ反映されません。
確認する資料
- DB設計書
- 移行要件定義書
- データ移行計画書
請求の計上に差異が残り、無償対応の費用増と再処理の工数増が発生するおそれがあります
保守契約の料金計算順序を請求仕様書と照合する
保守契約の請求金額を求める計算順序と、契約満了日をまたぐ場合の日割りや更新の扱いが、請求仕様書の記述と一致しているかを照合します。定義が曖昧なままだと請求の計上に不整合が残ります。
確認する資料
- 請求仕様書
- 保守契約管理表
- 会計連携定義書
現場の端末で作業報告を保存できず、原因調査が責任の所在の議論へ向かうおそれがあります
端末と基幹のAPI定義を権限設計と突き合わせる
モバイル端末と基幹側を結ぶAPI定義と、フィールド作業員・協力会社ごとの権限設計を突き合わせて確認できる状態かを確かめます。権限の境界が定義に明記されないと、端末で作業報告を保存できません。
確認する資料
- API定義
- 権限設計書
- 端末操作手順書
- 認証設定一覧
動的テストの設計・実行のポイント
ユニットテストから受け入れテストまでの各工程で、点検周期や契約満了日の境界値、受付から請求までの連携を検証します。
STEP 01
ユニットテスト境界値と個別仕様の解釈を確定させる工程です
どう確かめるか
ユニットテストで点検周期と契約満了日の境界値を、同値分割と境界値分析で検証する
点検周期と保守契約の満了日処理は、解釈の相違が残りやすい箇所です。ユニットテストで同値分割と境界値分析を適用し、点検周期が切り替わる前後の日付と満了日当日・翌日の挙動を検証します。
- 01点検周期の判定が切り替わる境界値の前後で対象抽出結果を検証します
- 02保守契約の満了日当日と翌日で請求対象の扱いを検証します
- 03同値分割で正常・異常の各区分の代表値を網羅します
OUTPUT境界値の不具合を早期検出
STEP 02
統合テスト機能間のデータ連携を確かめる工程です
どう確かめるか
統合テストで受付から請求までの連携を検証する
統合テストでは、修理受付から作業手配への引き継ぎ、作業報告の請求への反映、会計システムとの連携処理を通しで検証します。機能をまたぐデータの受け渡しの不整合を検出します。
- 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へご相談ください
点検周期や保守契約の満了日といった業務ルールからテスト設計を起こし、検証範囲と優先順位を工程単位で整理します。体制を組み替えずに参加します。