入札単価や日予算の変更が配信側へ反映されず、変更前の設定で配信が続く
管理アプリで変更した入札単価や日予算が配信基盤へ反映される前に入札処理が実行されると、変更前の設定で配信が続き、意図しない広告費を消化します。
GENZ, Inc.
独立した第三者検証
広告配信と
独立した第三者検証
広告配信と管理アプリのテストをGENZが代行
入札・配信・計測の仕様照合から回帰テストまで、外部接続先を含む検証範囲を実装から独立した立場で設計し、リリース判断へ提出できる報告と証跡をお渡しします。
支援事例
支援実績5,000件以上
DSPと管理アプリでよくある不具合
DSPの管理アプリと配信基盤では、設定変更の反映遅延や外部接続先との解釈差に起因する不具合が起きやすくなります。いずれも配信の継続・停止や集計値へ影響し、発見が遅れると広告主への報告のやり直しが発生します。
入札単価や
停止操作後も配信が続き予算超過が起きる
停止操作の通知が配信モジュールへ届かない場合や遅延した場合、停止後も入札応答が返され続け、日予算や月次予算を超えた消化が発生します。
再送分を二重取り込みし、実績が重複計上される
接続先から再送されたデータを再送分と識別せず取り込むと、同じ配信実績が二重に計上され、集計値と広告主への請求額が実績より大きくなります。
入札応答が時間の上限を超えて不応札となり、対象の広告枠へ配信されない
入札応答は応答時間に上限のある同期処理のため、内部処理の遅延で上限を超えると不応札となり、対象の広告枠への配信機会そのものが失われます。
日付の区切りの解釈差で実績が前日に計上される
集計側と接続先で日付の区切りの解釈が異なると、当日分の実績が前日へ計上され、日次の消化額とレポートの値が一致しなくなります。
残存した不具合により生じる問題
テストで検出できずリリース後へ残った不具合は、広告費の集計値、広告主への報告、監査での説明へ影響し、開発部門だけでは収まらない問題になります。
静的テスト（レビュー）でおさえるべき観点
入札・配信・集計が別モジュールに分かれるDSPでは、モジュール間の連携の不整合がユニットテストの範囲で表面化しません。レビュー工程で設計書間の不整合を検出すると、受け入れテスト以降の手戻りを抑えられます。
経路による挙動の差異が運用の中で蓄積し、設定変更の結果が経路ごとに異なる状態が残ります。
画面仕様とAPI定義を項目名・単位・必須で照合する
管理アプリとブラウザ向け管理画面の双方から同じ設定変更ができる場合、画面仕様書とAPI定義で項目名・単位・必須の扱いを照合します。片方の変更が他方へ反映されず、経路間の不整合が蓄積します。
確認する資料
- 画面仕様書
- API定義
- 項目一覧
運用の操作が設計の想定外の状態を作り、配信停止や再開の操作が意図どおりに反映されない事象が起きます。
入札と配信停止の状態遷移を、設計書と運用手順書の双方で照合する
入札の有効・無効や配信停止の状態遷移で、設計書と運用手順書の記述に差異があると、運用担当が設計の想定外の状態を作ります。遷移条件と禁止操作を両文書で照合し、矛盾を実装前に解消します。
確認する資料
- 設計書
- 運用手順書
- 状態遷移表
配信実績と請求額の不整合が繰り返され、広告主への報告のやり直しと課金根拠の説明不能に至ります。
広告費の計算順序と丸めの規定を、DB設計書と請求仕様で照合する
広告費の集計値は、計算順序と丸めの規定がDB設計書と請求仕様で一致していないと、同じ配信実績から異なる金額が算出されます。丸めを行なう工程を文書上で固定し、請求額との突合手順も確認します。
確認する資料
- 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回帰テスト範囲の根拠資料
DSPテストの種類
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 入札応答の時間超過を発生前に検知できる
- 管理アプリと管理画面の二重経路を漏れなく検証する
- 外部接続先との不整合をリリース前に発生させて検証する
- 課金集計値の算出過程の証跡を監査へ示せる
第三者の視点で担うGENZの検証支援
実装を担う受託先が検証まで完結する体制では、報告を確かめる第三者がいません。GENZは実装から独立した立場で仕様の照合からテスト設計、回帰テストの範囲選定まで担い、リリース判断へ提出できる報告を作成します。
仕様の照合からテストを設計する
テスト項目書が未完了の段階からご依頼いただけます。入札・配信・集計の仕様書をもとに、GENZがテスト観点の整理から着手します。
接続先まで含めて検証する
管理アプリの操作に加え、広告枠の供給側システムや第三者計測基盤との接続まで検証範囲に含められます。線引きは相談の初期に明示します。
既存の開発体制に合わせて伴走する
開発のスプリントと並行してテストを実施し、不具合票の運用や品質保証の体制に合わせて進めます。実装側のベンダーとは独立して動きます。
報告書と証跡を納品
回帰テストの対象を選んだ基準を記録に残し、リリース判断の会議や査閲でそのまま提出できる報告書と証跡を納品します。
ご相談から納品までの流れ
広告配信プラットフォームの検証は、ヒアリングから報告書の納品まで、貴社の開発体制と連携しながら進めます。
ヒアリング
管理アプリと配信基盤の構成、外部接続先の仕様、改修の範囲を確認します。
テスト設計と見積もりのご提示
テスト項目書の方針と検証範囲の線引きを示し、見積もりを提示します。
テストの実施と不具合票の共有
統合テストから受け入れテストまで実施し、不具合票を貴社の形式で共有します。
報告書の納品と修正後の再確認
結果と残存リスクを報告書にまとめ、修正版の回帰テストで再確認します。
検証範囲の線引きを社内で説明できる状態へ
検証の範囲と優先順位をGENZにご相談ください
外部接続を含む検証範囲の切り分けや回帰テストの優先順位にお悩みのご担当者様は、GENZへご相談ください。対象範囲と工数の目安を整理し、リリース判断へ提出できる形でお渡しします。