点呼の記録が保存されたつもりのまま欠けている
点呼の入力完了後に保存処理が失敗しても、画面上は正常に見えます。乗務員が閉じたあとで記録の欠落が判明し、利用企業の記録不備へつながります。
GENZ, Inc.
開発から独立した検証
運行管理アプリの
開発から独立した検証
運行管理アプリの点呼・日報・動態を第三者の視点で検証します
自社で作り自社で確認する構造のままでは、リリース判定の根拠を説明できません。GENZはテストの設計から関与し、上程に使える記録まで整えます。
支援事例
支援実績5,000件以上
運行管理アプリのテストで範囲から漏れやすい領域
運行管理アプリは点呼・日報・動態管理を束ねる分、不具合は利用企業の業務記録へ残ります。法令上の記録が欠ける不具合ほど、手元の実機や正常系の確認だけでは見つからない領域に潜みます。漏れやすい領域を挙げます。
点呼の
アルコール測定機器から値を受け取れない場合の振る舞いが定まっていない
アルコール測定機器との接続が切れた際に、値なしで登録できるのか止めるのかが決まっていないと、測定未実施のまま点呼が完了します。
通信が切れた区間の位置情報が復帰後にずれる
通信が切れた区間の位置情報を復帰後にまとめて送信する仕様では、記録上の時刻と実際の位置がずれ、走行経路の確認で矛盾として表れます。
日報の集計値と乗務の実績が一致しないまま出力される
日報の集計は、乗務を跨いだ入力や修正後の再集計でずれが生じやすい箇所です。集計値と実績が一致しないまま出力されると、利用企業の帳票が誤ります。
免許証の期限や点検の期日の通知が対象者へ届かない
免許証の期限や車検の期日を知らせる通知は、対象者の条件設定や端末側の通知許可に依存します。届かないまま乗務が続くおそれがあります。
検証が届かないまま公開したあとに起きること
検証が届かない領域に不具合が残ったまま公開すると、利用企業の法令対応、現場の継続利用、自社の開発計画の順で影響が表面化します。
運行管理アプリの検証で私たちが確かめる観点
運行管理アプリは、点呼・アルコールチェック・日報・動態管理をひとつに束ねる分、確かめる観点が機能の数だけ増えます。GENZは、記録が業務と法令の基準で使える状態にあるかという軸で観点を整理して検証します。
未確認の端末で点呼の記録が送信できず、朝夕の点呼時間帯に問合せが集中するおそれがあります。
端末とOSの組み合わせごとの表示の崩れと操作の可否
乗務員が使う端末の機種とOSの版は利用企業ごとに異なり、手持ちの実機では組み合わせを覆えません。会社支給か個人所有かで対象範囲が変わるため、実機を用意して表示の崩れと操作不能を確認します。
確認する資料
- 対象端末表
- OS版一覧
- 画面仕様書
切断中の記録が失われたまま復帰すると、点呼記録と日報に欠損が残るおそれがあります。
通信が切れた状態からの復帰と切断中の記録の再送
運転中は通信が切れる区間があり、切断中の記録の保持と復帰後の再送の仕様は製品ごとに異なります。意図的に通信を切った状態で点呼と日報を入力し、復帰後に欠損なく送信されるかを検証します。
確認する資料
- 再送仕様書
- 保持期間定義
- 通信環境条件
記録項目の不足がそのまま保存されると、利用企業側の法令対応に波及するおそれがあります。
法令で求められる記録項目が過不足なく保存されているか
運転日報は法令で記入と管理が求められる記録であり、項目の不足は利用企業側の記録不備へつながります。点呼記録・アルコールチェック結果・日報の各項目が、求められる形式で保存されるかを確認します。
確認する資料
- 記録項目一覧
- 要件定義資料
- 保存形式仕様
機器が応答しない場合の振る舞いが決まっていないと、検証の設計を始められないまま改修が進むおそれがあります。
アルコール測定機器と接続する部分の異常時の振る舞い
アルコール測定機器や位置情報の取得は、アプリ単体では条件を作りにくい連携部分です。接続方式は製品ごとに異なるため、機器が応答しない状態を発生させて検証し、異常時の記録の扱いを確認します。
確認する資料
- 機器接続仕様
- 異常系条件表
- 連携手順書
権限の境界が崩れると、他の乗務員の氏名や位置情報が表示されてしまうおそれがあります。
利用企業と権限ごとに見える記録の境界が保たれているか
運行管理者は記録を確認し、乗務員は自分の点呼と日報を入力します。権限ごとに見える記録の境界が崩れると、他の乗務員の氏名や位置情報が漏れます。利用企業と権限の組み合わせで表示範囲を検証します。
確認する資料
- 権限定義表
- 利用企業設定
- 画面権限仕様
- データ分離条件
テストの外部委託をどう組み立てるか
検証の範囲をどこまで外へ出すかは、開発の進行と期日の制約で決まります。委託の組み立てを型として示します。
STEP 01
対象の範囲と前提を確認する対象の範囲と前提を確認し、検証の条件を揃えます。
どう確かめるか
開発のスプリントが進む間に並行して検証する
開発のスプリントが進む間に検証を並行させ、実装の完了を待たずに範囲を分けて実行します。期日が外部で決まる改修でも、検証の期間を確保したまま進められます。
- 01品質保証の責任者が対象の機能と端末の範囲を指定する
- 02開発リーダーと仕様の前提と未確定の条件を突き合わせる
- 03対象の定義書に沿って検証の範囲と前提を文書へ書き出す
OUTPUT企画書：スコープ
STEP 02
テストの計画と観点を設計するテストの計画と観点を設計し、範囲の根拠を示します。
どう確かめるか
対象の範囲を固定して回帰テストを継続して預ける
対象の機能と端末の組み合わせを固定し、回帰テストを継続して引き受けます。機能追加のたびに積み上がる確認作業を、都度の発注ではなく継続する形で外へ出せます。
- 01機能追加と法令に沿った改修の周期に合わせて観点を設計する
- 02検証の範囲と優先順位をテスト計画として書き起こす
- 03異常系の条件と機器連携の観点をテスト設計へ反映する
OUTPUTSUT定義：委託
STEP 03
実機で実行し、不具合を報告する実機で実行し、検出した不具合を報告します。
どう確かめるか
公開前に対象の範囲を広げて集中的に検証する
公開前の期間に対象の範囲を広げ、規模の大きい対象でも網羅の度合いを確保して実行します。リリース判定の場で、どこまで確認したかを範囲として説明できます。
- 01テスト担当者が指定の端末とOSの組み合わせで実行する
- 02検出した不具合を再現条件と影響範囲を添えて報告する
- 03開発リーダーが修正し、修正版を再テストで確認する
OUTPUT開発リーダーと連携
STEP 04
結果を整理し、次の改修へ引き継ぐ結果を整理し、次の改修へ引き継ぎます。
どう確かめるか
検証の記録をあとから参照できる証跡の形へ整える
実施した範囲と結果を、稟議や監査であとから参照できる証跡として整理します。検証の内容を説明する材料が、上程の場でそのまま使える形で残ります。
- 01実施した範囲と結果を一覧と証跡の形へ整理して残す
- 02未解決の不具合と残した範囲を次の改修へそのまま引き継ぐ
- 03品質保証責任者がリリース判定資料をまとめて上程する
OUTPUTテスト結果の受け取り
運行管理アプリの検証を担当する私たちの体制
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 開発から独立した立場で検証範囲を設計しなおす
- 指定の端末とOSの組み合わせを実機で確認する
- 機能追加のたびの回帰テストを継続して引き受ける
- 判定の場で使える範囲設計と実施記録を納める
GENZが提供するテストサービス
GENZは、運行管理アプリを提供する事業者様に向けて、開発主体から独立した立場でテストの設計から実行と記録の整備までを担います。点呼や日報が束ねる確認範囲を整理し、リリース判定に使える状態へ整えます。
テスト計画とテスト設計の支援
対象機能と端末・OSの組み合わせから検証範囲の切り分けを設計し、何を確認し何を確認していないかを説明できる根拠を作ります。
実機を使った機能テストの実行
ご指定いただいた端末とOSの組み合わせを実機で実行し、結果を一覧としてお返しします。手持ちの実機で覆えない範囲を補います。
回帰テストの継続実施と自動化の支援
範囲を固定した継続委託の形で回帰テストを実施し、開発の進行を止めずに検証を並行させます。定型化した確認は自動化の支援も可能です。
検証の記録を証跡として整備する支援
実施した範囲と結果を証跡として整理し、稟議や監査で説明できる記録の形へ整えます。範囲の設計と実施の記録を揃えてお渡しします。
お問合せから検証を開始するまでの流れ
ご相談から検証開始まで、対象範囲の確認、お見積、データ取り扱いの取り決めの順で進めます。
お問合せと検証したい課題の共有
検証したい機能や端末の組み合わせ、抱えている課題をご共有いただきます。
対象範囲の確認とお見積の提示
対象範囲と優先順位を整理し、必要工数とお見積を提示します。
契約とテストデータの取り扱いの取り決め
テストデータの種類や保管条件を取り決め、模擬データの要否を確認します。
検証の開始と定例での進捗報告
検証を開始し、定例で進捗と不具合を報告します。開発チームと連携します。
運行管理アプリの検証体制のご相談
運行管理アプリの検証体制について相談する
相談の段階で、対象となるテスト範囲の切り分け、優先順位、必要工数の考え方、連携テストの要否を整理してお返しします。社内での上程に使える材料を、そのままお渡しします。