制限時間の管理に不整合があり、終了時刻を過ぎた解答が受理される
端末側のタイマーとサーバー側の時刻に不整合があると、終了時刻を過ぎた解答が受理されます。制限時間の仕様が一意に定まっていない場合に起きます。
GENZ, Inc.
試験配信システムの
CBT試験アプリの
試験配信システムの
CBT試験アプリの品質をGENZが第三者視点で検証します
認知行動療法ではなく、コンピューターを用いた試験（CBT）が対象です。再実施が難しい試験回に向けて、受け入れテストと回帰テストをGENZが分担します。
支援事例
支援実績5,000件以上
CBT試験アプリでよくある不具合
CBT試験アプリでは、制限時間の管理、受験再開、出題、合否判定、表示の各機能で、試験の公平性に関わる不具合が起きることがあります。当日一度しか実施できない条件ほど、リリース前の検証が必要です。
制限時間の
受験を再開すると直前の解答が未解答になる
通信断や端末障害から受験を再開した際、送信済みの解答が復元されず未解答になることがあります。再開の要件どおりに解答が保持されるかを検証します。
問題バンクからの出題で、同一受験者に同じ問題が重複して出題される
問題バンクの抽選条件が不足していると、同一の受験者に同じ問題が重複して出題されます。出題数と配点が試験要項どおりかを登録ごとに確認します。
合格基準の境界値にあたる得点で、合否判定の結果が仕様と一致しない
合格基準の境界値にあたる得点で、仕様上は合格が不合格と判定されることがあります。配点表と合格基準をもとに、境界値の前後で合否判定を検証します。
端末やブラウザによって図版や数式が表示されない
図版や数式を含む問題は、端末やブラウザの種類によって表示されないことがあります。受験者の利用環境を想定した動作確認で検出します。
残存した不具合により生じる問題
リリース前に止められなかった当日限りの不具合は、運営費・説明責任・外部評価へ順に現れ、CBT移行そのものの可否へ戻ってきます。
静的テスト（レビュー）でおさえるべき観点
動的テストの前に、設計書と仕様書の段階で矛盾を検出するレビューが有効です。CBT試験アプリでは、試験要項が人による運用を前提とし、制限時間の管理や受験再開の仕様が一意に定まらない箇所が残りやすいためです。
出題条件の不整合が当日の試験回で表面化し、出題の差し替えや試験の中止判断に至る。
試験要項と問題バンクの出題条件の設定を照合する
試験要項に記載された出題数、出題範囲、問題の抽選条件が、問題バンク側の設定値と一致するかを照合します。要項が運用担当者の経験を前提にしている場合、設定が一意に定まらないおそれがあります。
確認する資料
- 試験要項
- 問題バンク設定
- 出題条件定義
合否判定の誤りが成績通知後に判明し、合否の訂正と受験者への通知、結果利用者への説明が必要になる。
配点表・合格基準と採点ロジックの計算順序を照合する
配点表と合格基準が、採点ロジックの計算順序と一致するかを照合します。選択式の自動採点と記述式の手動採点が混在する場合、合算の順序と丸めの扱いが仕様上あいまいだと、合否判定の誤りが起きます。
確認する資料
- 配点表
- 合格基準
- 採点仕様書
自動提出の動作が端末ごとに異なり、制限時間内の解答が送信されない受験者が発生し、救済措置の判断を迫られる。
画面設計書と制限時間の表示・自動提出の仕様を照合する
画面設計書の制限時間の表示と、試験終了時の自動提出の仕様を照合します。端末側とサーバー側のどちらの時刻を正とするかが設計書で定まっていないと、自動提出の動作が端末ごとに異なるおそれがあります。
確認する資料
- 画面設計書
- 機能仕様書
- 自動提出仕様
予約・決済・成績データの連携不整合により、受験者が受験できない、成績が結果利用者へ届かない事象が発生する。
連携仕様書と予約・決済・成績データの項目定義を照合する
受験申込、予約、決済、成績データの提供が外部システムと連携する場合、連携仕様書と各システムの項目定義を照合します。項目名や形式の不整合が残ると、データが正しく連携されないおそれがあります。
確認する資料
- 連携仕様書
- 予約システム定義
- 成績連携定義
受験再開時に解答データを復元できず、再試験の実施と返金という形で当該期の収支への影響が発生する。
データベース設計書と解答データの保存単位・履歴の保持要件を照合する
解答データの保存単位と履歴の保持要件が、データベース設計書に反映されているかを照合します。受験再開（レジューム）を支える保存粒度が不足していると、解答が復元できないおそれがあります。
確認する資料
- DB設計書
- 解答データ定義
- 履歴保持要件
- レジューム要件
動的テストの設計・実行のポイント
CBT試験アプリの動的テストは、採点と合否判定、外部連携、業務シナリオ、受け入れと回帰の工程に分けて設計します。
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が代行するCBT試験アプリのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 試験回の日程内で受け入れテストの実行工数を外部へ移せます
- 試験要項と配点表を起点にテスト観点を設計できます
- 当日の影響の大きさで検証範囲の優先順位を決められます
- テスト項目書と報告書を社内説明と監査の記録に使えます
試験回の本番に備えるGENZのテスト支援
試験回の日程は変更できず、再実施も難しい前提があります。GENZは受け入れテストと回帰テストを分担し、出題から採点、成績通知までをリリース前に検証します。既存の品質保証体制のうち不足する工程を補います。
試験要項と配点表を起点にテスト設計を行なう
画面仕様だけでなく、試験要項と配点表、合格基準を起点にテスト観点を導き、採点と合否判定の正しさを業務の根拠に沿って検証します。
出題から成績通知までを検証範囲に含める
出題、解答の送信と保存、採点と合否判定、成績通知に加え、同時受験が集中する時間帯のパフォーマンステストまでを検証範囲に含めます。
既存の品質保証体制に不足する工程を分担
ベンダー側テストと重複しないよう、現在の体制と役割分担を確認したうえで、受け入れテストと回帰テストの実行工数をGENZが引き受けます。
検証結果を報告書にまとめて提出する
テスト設計書、テスト項目書、不具合票、報告書を成果物として提出し、工程ごとの検証範囲を社内説明や監査の照会に使える記録として残します。
ご相談から納品までの流れ
受け入れテストの工数が足りないと判明した段階から、報告書の納品までの進め方を工程ごとにご説明します。
試験制度と対象範囲のヒアリング
試験要項と当日の運用手順を聞き取り、検証の対象範囲を確定します。
テスト設計と見積もりの提示
重複しない検証範囲を整理し、必要工数と成果物を添えて見積もりを提示します。
テストの実施と進捗・不具合の共有
実行状況を週次で共有し、検出した不具合を不具合票で開発リーダーへ渡します。
報告書の納品と改修後の再確認
残存不具合をまとめた報告書を納品し、改修後に回帰テストで確認します。
CBT試験のリリース前検証を整理する
CBT試験アプリのどこから検証するか、GENZへご相談ください
出題から解答の保存、採点と合否判定、同時受験のパフォーマンステストまで、どこを検証すべきかを整理します。テスト範囲と優先順位、必要工数の考え方は初回のご相談で確認できます。