配車の依頼が特定の条件の組み合わせでだけ成立しない
エリアや時間帯、決済方法の組み合わせによってだけ依頼が通らず、確認した条件では成立するため、不具合として拾われないまま公開へ進みます。
GENZ, Inc.
改修に確認が追いつかない
配車アプリの
改修に確認が追いつかない
配車アプリのテストを、第三者の検証チームへ外注する
機能追加の度に確認範囲が広がる配車アプリ。外部の検証チームが観点の設計から見直し、業務フローを端から端まで覆います。
支援事例
支援実績5,000件以上
配車アプリの開発現場で不具合はどう現れているか
配車アプリでは、迎車場所と行き先の指定から配車、降車後の精算までを一続きで処理します。改修のたびに回帰の範囲が削られると、流れの途中でだけ成立しない事象が残り、リリース判定が口頭補足に頼る状態になります。
配車の
迎車の位置と地図の表示がずれたまま乗務員へ届く
迎車位置のピンと乗務員側に届く地点情報がずれたままだと、車両の到着が遅れ、乗車を待つ利用者が直前でキャンセルしてしまう原因になります。
精算の結果がアプリの表示と管理画面で食い違う
アプリの精算金額と運行管理の管理画面の金額が一致しないと、現場では電話での確認と手計算での帳尻合わせが発生し、業務工数が恒常的に増えます。
提供エリアの境界付近で受け付けの可否が揺れる
提供エリアの境界付近で受け付け可否が揺れると、利用者には呼べる場所なのに依頼が成立せず、原因を特定できないまま問合せ対応へ回ります。
端末の機種や通信環境の差で再現しない事象が残る
端末の機種差や通信環境の差で一度だけ起きる事象は、再現しないことを理由に様子見へ回され、切り分けの記録が残らないまま次回も同じ判断になります。
確認が追いつかないまま公開したときに起きること
回帰範囲を削ったまま公開を重ねると、不具合は利用者の画面から乗務員の端末、運行管理の現場へと順に現れ、最後は開発計画と投資判断まで届きます。
第三者の目でテストの設計を点検する観点
テストの設計は、作った担当者自身が点検するだけでは抜けに気づけません。配車の業務フローと改修の単位に沿って、第三者の目で確かめるべき観点を順に整理します。
要件と受け入れ条件の対応を確かめないまま進むと、要件に含まれる機能が誰にも確認されず、公開後に利用者側で動かない形で見つかります。
機能追加の要件と受け入れの条件が対応しているか
機能追加の要件と、受け入れで合格とみなす条件が漏れなく対応しているかを確かめます。要件にあって受け入れ条件にない項目は、誰も確認しないままリリースへ進みます。
確認する資料
- 要件定義書
- 受入基準書
- 観点対応表
業務フローの端から端までを覆えていないと、配車の依頼から成立までの経路に不具合が残り、利用者が乗車前に離脱するおそれがあります。
確認の範囲が配車の業務フローを端から端まで覆っているか
テスト観点が、利用者の依頼から配車の成立、迎車、精算までの業務フロー全体を端から端まで覆っているかを確かめます。実施件数の多さは、網羅の証拠にはなりません。
確認する資料
- 業務フロー図
- テスト仕様書
- 網羅対応表
外部サービスとの連携部分に確認の残りがあると、決済や地図の仕様が変わった際に追随できず、アプリで精算や迎車場所の指定ができなくなります。
外部サービスとの連携部分の確認が残っていないか
決済・地図・通知など外部サービスとの連携部分に、確認の残りがないかを確かめます。外部側の仕様変更は自社の改修とは別のタイミングで起きるため、範囲から外れると検知が遅れます。
確認する資料
- 連携仕様書
- 外部IF一覧
- 結合試験表
再現手順と証跡の粒度が揺れると、リリース判定会議での判断が口頭補足に依存し、あとから判断の根拠を説明できなくなります。
不具合の再現手順と証跡をあとから第三者が追えるか
不具合の再現手順と証跡が、あとから第三者が追える粒度で残っているかを確かめます。記録の粒度が回ごとに揺れると、リリース判定が担当者の口頭補足に依存します。
確認する資料
- 再現手順書
- 実行記録
- 不具合管理票
回帰の範囲が更新されないままだと、改修で影響を受けた箇所が確認されず、公開直後の事象として現れ、端末差で再現しないまま様子見の扱いになります。
回帰テストの範囲が改修のたびに更新されているか
回帰テストの範囲が、改修のたびに見直されているかを確かめます。初期に作った範囲のまま実行が続くと、新しく追加した機能の周辺が確認されないまま蓄積します。
確認する資料
- 回帰範囲表
- 改修影響一覧
- 差分の記録
- 更新履歴表
GENZが提供するテスト支援の内容
改修のたびにずれ込むテスト工程をGENZが受け持ちます。開発への伴走、大規模範囲の代行、第三者としての運営、証跡の整理です。
STEP 01
現状のテストの進め方を確認する観点表と実施記録の所在を確認します
どう確かめるか
機能追加のスプリントに伴走してテストを進める
機能追加のサイクルに合わせ、要件の確定段階からテスト観点の作成に入ります。開発の終盤へ作業が寄らないよう、配車から精算までの業務フロー単位で観点を組み立て、自社実施との重複を避けます。
- 01既存のテスト観点表と実施記録を集め、抜けの有無を点検します。
- 02開発チームとベンダーの報告様式を確認し、粒度の揺れを洗い出します。
- 03回帰テストの範囲が最後に更新された時点を確かめます。
OUTPUT業務フロー全体を覆う観点表
STEP 02
検証の範囲と観点を決める業務フロー単位で網羅の範囲を決めます
どう確かめるか
大規模なシステムのテスト範囲をまとめて受け持つ
管理画面・乗務員端末・外部サービス連携を含む大規模な範囲をまとめて受け持ちます。端末機種と通信環境の組み合わせを揃えてから、手元で再現しない事象も条件を特定して検証します。
- 01配車の依頼から精算までの業務フローに沿って観点を作成します。
- 02端末機種と通信環境の組み合わせを対象範囲として定めます。
- 03自社での実施と外部委託の範囲を文書で切り分けます。
OUTPUT自社との切り分け済み範囲表
STEP 03
テストを実施して結果を報告するテスト結果は粒度を揃えた一覧にします
どう確かめるか
第三者の視点で検証の工程を計画から運営する
発注側とも受託側とも異なる第三者の視点で、テストの計画から実施、結果の集約まで工程を運営します。リリース判定会議へ上程する材料は、回ごとに粒度の揃った一覧として用意します。
- 01決めた観点に沿ってテストを実施し、手順と結果を記録します。
- 02未解決の事象は再現手順と発生条件を添えて一覧にします。
- 03結果をリリース判定へ使える形に集約して報告します。
OUTPUT粒度の揃った実施結果一覧
STEP 04
改修後の確認まで引き継ぐ修正した箇所の確認まで証跡に残します
どう確かめるか
テストの結果と手順を証跡として整理して残す
実施した観点、手順、結果、改修後の確認を、証跡としてひとつの形に整理して残します。システム監査や稟議の場で求められた際に、再編集なしで提出できる状態にします。
- 01修正が適用された箇所を意図的に発生させて検証します。
- 02改修の影響を受けた範囲へ回帰テストの対象を更新します。
- 03確認の結果を証跡へ追記し、次の改修へ引き継ぎます。
OUTPUT監査へそのまま出せる証跡
第三者の検証チームの体制と進行の組み立て
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 改修の頻度に合わせ、外部の要員でテストの実施量を確保します。
- 自社で持つ範囲と外部へ渡す範囲を、着手前に文書で切り分けます。
- 第三者が観点の偏りを点検し、網羅の状況を示す材料を残します。
- 記録と証跡が残るため、稟議の説明を翌年度も同じ形で使えます。
配車アプリで対応するテストの種類
配車アプリの検証は、利用者の画面だけを追うと割当の判定や現場端末の不整合を見落とします。依頼から精算までの機能、管理画面との連携、集中時の性能、乗務員端末・車載機の実機までを一続きで確認します。
利用者向けアプリの機能テスト
迎車場所と行き先の指定から乗車後の精算まで、iOS・Android双方の操作と表示を検証します。
配車の割り当てと管理画面の連携テスト
割り当ての受信から迎車・降車の状態更新までを追い、管理画面の監視・調整と齟齬なく連携するか検証します。
利用が集中する時間帯を想定した性能テスト
利用が集中する条件を意図的に発生させ、依頼の欠落・割当遅延・状態更新の取りこぼしが起きないか検証します。
乗務員端末と車載機を含む実機テスト
乗務員端末・車載機の実機で割当受信と状態更新を確認し、現場で起きた症状の切り分けに使える記録を残します。
相談から検証の開始までの流れ
配車アプリの改修範囲や現場の運用状況を伺い、テストの対象と体制を整理したうえで検証の開始までを進めます。
相談の内容とテストの対象を確認する
改修の範囲や乗務員端末の運用状況を伺い、テストの対象となる機能を確認します。
検証の範囲と工数の見積を提示する
配車ロジックや外部サービス連携を含めた検証の範囲と、必要な工数を提示します。
契約とテストの計画を作成する
受託側と発注側の作業の切り分けを文書で固定し、テストの計画を作成します。
検証を開始し、定例で報告する
検証を開始し、実施状況と残存事象を定例で報告します。
テスト範囲の整理から始められます
配車アプリの検証体制について相談する
テスト範囲の区切りと優先順位、必要工数の見立てから、配車ロジックや乗務員端末を含む関連テストの要否まで、ご相談の段階で整理します。稟議やリリース判定会議の材料にそのまま使えます。