ポータルごとの必須項目が欠落したまま入稿データが生成される
ポータルごとに必須項目が異なるため、変換仕様の管理が追いつかないと、欠落したまま入稿データが生成され、受け付け側でエラーとなります。
GENZ, Inc.
ポータル連動の検証
不動産の
ポータル連動の検証
不動産の一括掲載システムを第三者の視点で検証
ポータルごとの入稿仕様の差分を起点に、変換処理のユニットテストから掲載結果の照合を含む受け入れテストまで、検証範囲の決め方と実行を第三者の視点で支援します。
支援事例
支援実績5,000件以上
物件掲載管理システムでよくある不具合
物件情報の入力から各ポータルへの入稿・掲載結果の照合までの間で、変換仕様の差分や更新連動の漏れを起因とする不具合が起きます。ここでは、ユニットテストから受け入れテストで確認すべき代表的な不具合を挙げます。
ポータルごとの
面積・賃料の単位変換で値が不整合のまま送信される
面積や賃料の単位変換の条件がずれると、入力値と異なる金額・面積のまま送信され、誤った条件の掲載内容がそのまま公開されます。
取り下げが連動せず、成約済みの物件が掲載され続ける
成約済みへの変更や取り下げの連動が対象外のまま運用されると、契約終了後の物件が掲載され続け、反響対応と訂正の費用が発生します。
画像の点数制限と容量の上限を超え、一部の画像が反映されない
ポータル側の画像点数や容量の上限を超えたデータを送信すると、一部の画像だけが反映されず、目視で確認しないと気づけない状態になります。
文字コードの変換で物件名・住所の一部が別の文字で表示される
文字コードの変換で物件名や住所の一部が別の文字へ置き換わると、検索結果の表示と登録内容に差異が生じ、照合で初めて判明します。
残存した不具合により生じる問題
入稿エラーの切り分けや掲載結果の照合が確立しないまま運用を続けると、不具合は現場の個別対応に吸収され、事業レベルの損失として表面化します。
静的テスト（レビュー）でおさえるべき観点
動的テストの前に、仕様書・設計書同士の静的な照合で検出できる不整合があります。変換処理は入稿仕様の改定と製品改修で繰り返し変更されるため、文書間の差異が残りやすく、レビューの観点を先に定めます。
仕様書に書かれない運用上の条件が後から判明し、リリース直後の入稿エラーとして表面化するおそれがあります。
ポータル各社の入稿仕様書と項目マッピング表を照合する
ポータル各社は必須項目・画像点数・文字数を個別に定めており、その差分が変換処理の分岐要件になります。入稿仕様書の改定内容と項目マッピング表を照合し、改定が反映されていない項目を検出します。
確認する資料
- 入稿仕様書
- 項目マッピング表
- 改定履歴
実装で決まった仕様が設計書へ反映されないまま進むと、レビューの基準となる正本が定まらず、解釈の誤りを検出できないまま残るおそれがあります。
DB設計書の項目定義と変換処理の入出力を照合する
変換処理の入力は物件管理側の項目定義に依存します。DB設計書の項目定義と変換処理の入出力を照合し、設計書へ反映されないまま実装で決まった仕様を洗い出し、レビューの正本を定めます。
確認する資料
- DB設計書
- 変換仕様書
- 項目定義一覧
エラー応答の扱いが方式ごとに異なるままだと、原因が自社の変換処理かポータル側の受け入れ条件かの切り分けに時間がかかり、暫定対応が手作業での対応となるおそれがあります。
API定義とCSVの転送仕様を、入稿エラーの応答の扱いと照合する
入稿の方式にはAPI定義に沿う連携とCSVによる転送が混在します。各方式の応答の扱いとエラーの返却形式を照合し、エラー時に原因の切り分けができる記録が残るかを確認します。
確認する資料
- API定義書
- CSV転送仕様
- エラー応答表
取り下げや成約済みへの変更が連動しないポータルでは、成約済み物件が掲載され続け、反響対応と訂正連絡の費用が発生するおそれがあります。
登録・更新・取り下げの状態遷移を業務フロー図と照合する
登録・更新・取り下げの連動範囲は製品により異なります。状態遷移の定義と業務フロー図を照合し、取り下げや成約済みへの変更がどのポータルで連動するかを文書上で一致させます。
確認する資料
- 業務フロー図
- 状態遷移表
- 画面遷移図
境界値の条件が未検証のままだと、文字数や画像点数の超過が受け入れテストの段階で集中して指摘され、リリース判断の材料が期限直前まで揃わないおそれがあります。
文字数・画像点数・桁数の上限を境界値の条件と照合する
文字数・画像点数・桁数の上限はポータルごとに異なり、超過時の扱いが入稿エラーの原因になります。上限値とその前後の境界値の条件を照合し、ユニットテストで確認すべき値を特定します。
確認する資料
- 入稿仕様書
- 境界値一覧
- テスト項目書
- エラーケース表
動的テストの設計・実行のポイント
ポータルごとの変換仕様の差異を、テスト設計から受け入れテストまでの各工程で段階的に検証する進め方を整理します。
STEP 01
テスト設計設計変更と同時に項目書を更新します
どう確かめるか
項目マッピングを同値分割と境界値で整理し、テスト項目書を作成する
ポータルごとの必須項目・文字数・画像点数の差分を洗い出し、項目マッピングを同値分割と境界値で整理します。組み合わせが増えると項目書が設計の後追いになるため、改修と同時に更新します。
- 01ポータルごとの必須項目と制約の差分表を作成する
- 02変換項目を同値分割と境界値でグループ化する
- 03項目書を設計変更へ追従させる更新運用を決める
OUTPUTテスト項目書
STEP 02
ユニットテスト境界値の超過をこの段階で検知します
どう確かめるか
変換処理の単位で、単位換算と文字コードの入出力をユニットテストで検証する
変換処理の単位で、面積の単位換算と丸め処理の期待値、文字コードの入出力を検証します。文字数や画像点数の境界値の超過をここで検知できれば、受け入れテストでの指摘の集中を防げます。
- 01単位換算と丸め処理の期待値を検証する
- 02文字コードと禁止表現の入出力を検証する
- 03文字数・画像点数の境界値で送信結果を確認する
OUTPUTユニットテスト結果
STEP 03
統合テスト原因の切り分けが記録に残ります
どう確かめるか
物件登録から入稿エラーの受領までの連携を統合テストで検証する
登録・更新・取り下げの状態遷移を、API連携とCSV転送が混在する経路で検証します。入稿エラーの返却内容を記録し、原因が自社の変換処理かポータル側の受け入れ条件かを切り分けます。
- 01登録・更新・取り下げの状態遷移を検証する
- 02API連携とCSV転送の双方の経路を検証する
- 03入稿エラーの返却内容から原因箇所を記録する
OUTPUT統合テスト結果と不具合票
STEP 04
受け入れテストと回帰テスト確認範囲を説明できる状態にします
どう確かめるか
掲載結果の照合を受け入れテストで実施し、既存ポータルへ回帰テストを実施する
実データで各ポータルの掲載結果を照合し、確認した範囲と未検証の範囲を区別して記録します。あわせて既存ポータルへ回帰テストを実施し、改修が他の連動先に影響していないことを確認します。
- 01実データで各ポータルの掲載結果を照合する
- 02確認済み範囲と未検証範囲を分けて記録する
- 03既存ポータルへの回帰テストで副作用を確認する
OUTPUT受け入れ結果と照合記録
GENZが代行する一括掲載システムのテストの種類
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- ポータル別の変換分岐を境界値まで検証するユニットテスト
- 掲載・更新・取り下げの連動を検証する統合テスト
- 各ポータルの掲載結果を照合する受け入れテスト
- 連動先の追加で生じる副作用を確認する回帰テスト
仕様差分から起こすテスト設計支援
ポータルごとに入稿仕様が異なる一括掲載システムでは、仕様改定のたびにテスト項目の見直しが発生します。GENZは仕様の差分を起点にテスト設計を組み立て、検証の実行から報告書の納品までを第三者の視点で担います。
入稿仕様を起点にテスト設計
ポータル別の必須項目や文字数の差分をテスト項目へ対応づけ、境界値を含む項目書として整理します。改定の期限に合わせて検証を進められます。
変換から掲載照合まで一貫して担う
変換処理のユニットテストから、物件登録から送信までの統合テスト、掲載結果の照合を含む受け入れテストまで、工程をまたいで検証します。
既存の運用に合わせて伴走する
品質保証の体制が兼務でも独立部門でも、テスト項目書と不具合票の運用に合わせて伴走します。社内で表面化しない仕様の解釈違いも指摘します。
判断に使える証跡を報告書で納品
検証した範囲と検証していない範囲を区別した報告書を納品します。リリース判断や監査対応、外注費の稟議に同じ資料で説明できます。
ご相談から納品までの流れ
ご相談から報告書の納品まで、段階を分けて進めます。各段階で何を確認し、何をお渡しするかを示します。
連動仕様と現状のテスト項目書のヒアリング
入稿仕様と改定履歴、現行のテスト項目書をお預かりし、検証対象を整理します。
テスト設計と見積もりのご提示
テスト設計を行い、検証範囲・工数・期間を見積もりとしてご提示します。
テストの実施と不具合票の共有
テスト項目に沿って検証を実施し、不具合は不具合票で随時ご共有します。
報告書の納品と修正後の再確認
検証結果と証跡を報告書として納品し、修正反映後の回帰テストまで行います。
第三者検証のご相談
一括掲載システムの検証範囲と優先順位をGENZにご相談ください
ポータル別の入稿仕様の差分を起点に、どこまでを検証範囲とすべきか。GENZにご相談いただければ、検証範囲の整理と優先順位づけ、必要工数の考え方を稟議に使える水準でお示しします。