申込フォームの入力制限が効かず定員超過や締切後も受付
定員や締切日時の設定が申込フォームに反映されず、定員超過や締切後の申込が受け付けられます。運営側は超過分の参加者へ断りの連絡を入れます。
GENZ, Inc.
検証範囲を決める
ウェビナーシステムの
検証範囲を決める
ウェビナーシステムのテスト代行
ライブ・疑似ライブ・オンデマンドの形式ごとに、どの経路をどこまで確かめるかを先に定めます。第三者の視点で検証し、稟議に添えられる証跡まで残します。
支援事例
支援実績5,000件以上
ウェビナーシステムでよくある不具合
申込フォームの設定を複製して定例開催を続ける運用では、複製元の誤りがそのまま次回へ引き継がれます。申込・視聴・効果測定が一元管理されるため、ひとつの設定不備が下流の処理まで及びます。
申込フォームの
視聴URLが届かない、または別の開催のURLが通知される
申込完了やリマインドのメールに視聴URLが記載されず、または過去開催のURLが通知されます。参加者は当日に入室できず、問い合わせが集中します。
配信開始時刻や視聴期間の判定がずれて視聴できない
疑似ライブの配信開始時刻や視聴期間の判定が設定どおりに動作せず、開始時刻を過ぎても配信が始まらない状態が起きます。参加者は視聴できません。
再入室が重複して集計され、視聴時間の数値が実態と合わない
視聴中に接続が切れて再入室すると、同一参加者の視聴記録が二重に集計されます。視聴時間や参加率が実態より大きくなり、効果測定の報告に使えません。
表記差で同じ参加者が二重登録される
姓と名の間の空白や全角半角の表記差で、同一人物が二重に登録されます。名簿管理やマーケティングオートメーションの連携先でも重複が残ります。
残存した不具合により生じる問題
残存した不具合は開催当日の成立と、その後の営業機会や社内説明の工数に及びます。確認していない経路の不具合は開催後まで判明しません。
静的テスト（レビュー）でおさえるべき観点
動的テストの前に、仕様書や設定画面の記述を照合する静的テスト（レビュー）を行います。申込・配信・連携・集計が一元管理されるため、書類の段階で不整合を摘出することが、検証範囲を説明できる起点になります。
放置した場合のリスク: フォームで取得した項目が方針の利用目的を超え、告知の手戻りと取扱方針への信頼低下が生じるおそれがあります。
申込フォームの項目を同意文言と取扱方針に照合する
申込フォームの各項目を、同意文言と個人情報の取扱方針に照合します。取得する項目が方針の利用目的の範囲に収まっているかを文書上で確認し、過剰な取得や目的外の項目を画面実装の前に洗い出します。
確認する資料
- 申込フォーム定義
- 同意文言
- 取扱方針
放置した場合のリスク: 告知した公開日時に配信が始まらず、申込者の離脱と日程の再設定が発生するおそれがあります。
開催設定の仕様を、告知済みの公開日時・視聴期間と照合する
開催設定の仕様を、告知済みの公開日時・視聴期間と照合します。配信開始時刻の制御や視聴期間の設定が告知内容と一致しているかを文書で確かめ、設定ミスによる公開の不成立を申込受付の前に防ぎます。
確認する資料
- 開催設定仕様
- 告知文面
- 視聴期間定義
放置した場合のリスク: 確認していない経路が記録に残らず、リリース判断の根拠を経路単位で説明できない状態になります。
配信形式ごとの経路図を制御仕様と照合する
ライブ・疑似ライブ・オンデマンドの形式ごとに、申込から視聴までの経路図を制御仕様と照合します。形式によって分岐する経路を文書で網羅し、特定の経路に検証が集中する偏りを設計の段階で正します。
確認する資料
- 経路図
- 配信制御仕様
- 形式別設定表
放置した場合のリスク: 申込項目の修正が連携先へ誤って反映され、下流のフォロー処理まで影響が及ぶおそれがあります。
連携仕様を受け入れ仕様と突合キー定義に照合する
マーケティングオートメーションや名簿管理の連携仕様を、受け入れ仕様と突合キー定義に照合します。どの項目を何で突合するかが文書で定義されていなければ、申込項目の修正の影響を追えません。
確認する資料
- 連携仕様書
- 受け入れ仕様
- 突合キー定義
放置した場合のリスク: 報告数値とログの集計定義が一致せず、効果測定の報告根拠を作り直す工数が都度発生します。
効果測定の集計定義をログ仕様と報告指標に照合する
効果測定の集計定義を、ログ仕様と報告指標に照合します。集計対象の期間や重複視聴の扱いが指標の定義と一致しているかを文書で確かめ、報告数値の根拠を説明できる状態にしておきます。
確認する資料
- 集計定義書
- ログ仕様書
- 報告指標定義
- 視聴ログ項目
動的テストの設計・実行のポイント
申込から視聴までの経路は配信形式ごとに分かれます。工程の単位で検証範囲を区切り、確認した経路を記録に残します。
STEP 01
ユニットテスト入力条件の境界値で不備を洗い出します
どう確かめるか
申込・視聴URL発行の各機能を、入力条件の同値分割と境界値で確かめる
申込フォームの必須項目・文字種・件数上限を同値分割と境界値で区切り、視聴URLの発行とメール送信までを確認します。申込の登録からURL到達まで、経路の入口を確かめる工程です。
- 01申込フォームの必須項目と入力文字種を網羅します
- 02申込件数の上限と境界値前後で登録を確認します
- 03視聴URLの発行と通知メールの到達を確認します
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は、申込・配信・視聴管理・効果測定の各経路について、検証範囲を先に確定させてからテストに入ります。
配信形式の違いからテスト設計へ
ライブ・疑似ライブ・オンデマンドで確かめる経路は異なります。配信開始時刻か視聴期間か、形式ごとの違いからテスト設計を起こします。
検証範囲は申込から効果測定まで
検証範囲は、申込フォームの入力から視聴ログの集計まで、経路単位で定義します。自社の構成に当てはめ、何を対象とするかを先に決めます。
既存の体制に合わせて伴走します
開催日が先に固定される制約に合わせ、運営・開発の進行と伴走して実施します。発注側・ベンダー側いずれの体制にも第三者として入れます。
監査にも使える証跡として報告
検証結果は、稟議や監査でそのまま使える証跡として報告書に残します。配信基盤側と自社設定側の分界も文書で共有します。
ご相談から納品までの流れ
ご相談から報告書の納品まで、開催スケジュールに合わせて段階を追って進めます。
ヒアリング
開催頻度や配信形式、現在の確認方法を伺い、検証が必要な経路を整理します。
テスト設計と見積もり
経路単位・形式単位で検証範囲を定め、工数の根拠がわかる見積もりを示します。
テストの実施と結果の共有
設計した項目に沿ってテストを実行し、不具合票と検証結果を随時共有します。
報告書の納品と再確認
検証範囲と結果の報告書を納品し、次回開催の再確認の進め方を整理します。
まずは検証範囲の整理からご相談ください
ウェビナーシステムの検証範囲と優先順位をGENZにご相談ください
ライブ・疑似ライブ・オンデマンドのどの経路をどこまで検証するかを、開催スケジュールに合わせて整理します。検証範囲と優先順位、必要工数の考え方まで、お打ち合わせの段でお示しします。