退去済みの入居者に契約情報と対応履歴が表示され続ける
権限による表示範囲の制御が仕様に反映されないと、退去済みの入居者に契約情報や対応履歴が表示され続けます。異常系のテスト観点の設計が前提です。
GENZ, Inc.
賃貸管理会社様へ
入居者アプリを
賃貸管理会社様へ
入居者アプリを第三者の視点で検証します
入居者アプリの検証範囲の線引きに根拠がなければ、リリース判断の材料は作れません。GENZはテスト設計から入り、範囲と優先順位を定義して報告書まで納めます。
支援事例
支援実績5,000件以上
入居者アプリでよくある不具合
入居者アプリは、問い合わせ・契約情報の確認・各種手続きをスマートフォンから行えるサービスです。基幹システムとの連携や権限の設定に起因する不具合は、入居者からの連絡で初めて判明します。
退去済みの
断水や点検のお知らせが一部の入居者の端末に届かない
プッシュ通知は端末の通知許可やアプリの起動状態で挙動が変わります。断水や点検の連絡が一部の入居者へ届かず、届かないことを把握できません。
基幹システムで更新した賃料や契約期間がアプリの画面に反映されない
基幹システムとの同期タイミングの差で、賃料や契約期間の表示に不整合が生じます。正常か不具合かの判断基準が仕様になく、テスト項目へ起こせません。
修理依頼に添付した写真が送信されず、入居者側に理由も示されない
修理依頼に添付した写真が送信されず、理由も示されないと、入居者は依頼が届いたか確認できません。管理会社側へ通知が届かないまま滞留します。
管理画面で受付済みにした申請が基幹システムへ記帳されない
管理画面で受付済みにした申請が基幹システムへ反映されないと、契約変更の処理が画面の表示と実データで異なります。連携処理の検証が前提です。
残存した不具合により生じる問題
連携や権限の設定に起因する不具合が残存すると、現場の一次対応の遅れ、投資効果の説明不能、個人情報の事案として事業へ波及します。
静的テスト（レビュー）でおさえるべき観点
画面に現れない条件は、実行前のレビューで検出できます。権限による表示範囲や基幹システムとの同期タイミングは、仕様書と設計書の照合で抜けを洗い出す領域です。見落としやすい観点を照合先の資料とともに整理します。
権限の組み合わせが仕様へ反映されないまま実装が進むと、契約情報が別の入居者へ表示される事象がリリース後に発生するおそれがあります。
権限と表示範囲を契約状態の一覧と照合する
同一世帯の複数利用者、退去済み入居者、物件移管後の入居者について、誰に何が見えるべきかを契約状態ごとに一覧化し、画面の表示仕様と照合します。実装前の突き合わせで異常系の抜けを検出します。
確認する資料
- 権限一覧表
- 画面仕様書
- 契約状態遷移表
同期タイミング差の許容範囲が未定義のままだと、正常な表示のずれを不具合と誤認する問い合わせが運用部門へ届き続けます。
API定義の項目を、基幹システムのDB設計書の項目と照合する
アプリの表示項目とAPIが受け渡す項目を、基幹システムのDB設計書の項目と逐一照合します。同期タイミングの差で値が異なる項目は、正常とみなす許容範囲が仕様上で定義されているかを確認します。
確認する資料
- API定義書
- DB設計書
- 同期仕様書
配信対象の指定単位が曖昧なまま運用が始まると、断水や点検のお知らせが一部の入居者に届かず、問い合わせで初めて判明します。
お知らせの配信対象の指定方法を、物件・棟・住戸の管理単位と照合する
お知らせ配信の対象指定が、物件・棟・住戸のどの管理単位で行えるかを、管理画面の指定方法と照合します。全入居者と一部住戸への配信で設定の分岐が曖昧だと、届かない入居者を検知できません。
確認する資料
- 管理画面仕様書
- 物件台帳
- 配信設定手順書
期限の境界値の扱いが仕様と業務規程で異なると、更新申請が受け付けられない入居者が発生し、電話での個別対応へ戻ります。
申請の受付日時と期限の判定ルールを、契約更新の業務規程と照合する
契約内容の変更申請や更新手続きの受付日時と期限の判定ルールを、賃貸管理部門の業務規程と照合します。更新時期に申請が集中する運用を前提に、締切の境界値の前後での処理を仕様上で確かめます。
確認する資料
- 業務規程
- 申請画面仕様書
- 日時判定仕様
例外パターンに対応するメッセージが未定義だと、入居者には原因が伝わらず、現場では再現情報の足りない申告が積み上がります。
エラーメッセージを例外パターンの網羅表と照合する
申請失敗・通信断・権限外アクセスなどの例外パターンの網羅表を用意し、各パターンのエラーメッセージが定義されているかを照合します。未定義のパターンは、入居者から「使えない」と申告されます。
確認する資料
- 例外パターン表
- 画面仕様書
- エラー定義書
- 運用マニュアル
動的テストの設計・実行のポイント
画面単位の確認では、同期タイミングや権限制御は検出できません。契約状態・連携・業務シナリオ・運用の層ごとに設計します。
STEP 01
ユニットテスト権限と契約状態の組み合わせ表を作成
どう確かめるか
ユニットテストで、契約状態と権限の組み合わせを境界値と同値分割で確かめる
契約状態（入居中・更新手続き中・退去済み）と利用者権限（本人・同一世帯の家族・移管後の入居者）の組み合わせを洗い出し、境界値と同値分割で表示範囲を確認します。
- 01契約状態の遷移パターンを列挙し、各状態で許可される操作を定義する
- 02同一世帯の複数利用者と退去済み入居者の表示範囲を境界値で確認する
- 03入力値の上限・下限・空欄で、申請フォームの振る舞いを確認する
OUTPUT権限別の表示制御を確認
STEP 02
統合テスト同期間隔と再送条件を仕様から抽出
どう確かめるか
統合テストで、アプリと基幹システムの連携を同期の間隔と再試行の条件で確かめる
基幹システムの契約データとアプリの表示が一致するか、同期の間隔と再送の条件を変えて検証します。更新申請の後に旧情報が表示される条件や、再試行で申請が二重に登録されないことを確かめます。
- 01基幹システムとの同期タイミングを変え、表示の不整合が起きる条件を特定する
- 02通信断と再試行で、申請データの重複・欠落がないかを検証する
- 03連携エラー時に入居者へ表示されるメッセージの内容を確認する
OUTPUT基幹連携の不整合を検知
STEP 03
システムテスト更新時期の申請集中を業務シナリオへ反映
どう確かめるか
システムテストで、申請から記帳までの業務シナリオを端末・OS別に確かめる
問い合わせの送信から管理画面での受付、修理依頼の承認まで、現場の業務シナリオを通しで実行します。iOSとAndroid、OSバージョン別に通知の到達と画面表示を確かめます。
- 01修理依頼から写真添付、管理画面での受付までを通しで検証する
- 02iOS・AndroidとOSバージョン別に、プッシュ通知の到達を確かめる
- 03契約変更申請の集中する更新時期を想定した負荷条件で動作を確かめる
OUTPUT端末・OS別の動作を検証
STEP 04
受け入れテスト・回帰テスト回帰範囲の根拠を社内説明用に文書化
どう確かめるか
受け入れテストと回帰テストで、現場の運用手順と既存機能への影響を確かめる
リリース前に現場の運用手順どおりに操作できるかを受け入れテストで確かめます。OS更新や機能追加のたびに回帰テストで既存機能への影響を確認し、仕様変更がない改修でも範囲を削りません。
- 01現場の問い合わせ担当が行なう日次の操作手順を、その手順どおりに確認する
- 02OSのメジャーバージョン更新後も、既存機能が変わらず動くか回帰テストで確かめる
- 03検証した範囲と残したリスクを、リリース判断の材料として整理する
OUTPUT既存機能への影響を確認
GENZが代行する入居者アプリのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 端末・OSの組み合わせまで検証範囲を根拠づけて決められる
- 基幹システムとの同期や権限の表示範囲をテスト項目に起こせる
- OS更新ごとの回帰テスト範囲が定義され、工数を計画に組み込める
- 検証した範囲と残したリスクを区別した報告書で稟議を通せる
入居者アプリの検証をGENZへ依頼する理由
どこまで検証すれば足りるかの根拠を社内で示せないまま、リリース判断を迫られる状況が続いています。GENZは入居者アプリの構造からテスト設計を起こし、検証範囲の線引きを外部の基準で裏づけます。
システム構造からテスト設計を起こす
基幹システムとの同期タイミングや権限による表示範囲など、画面の操作だけでは起こせない条件までテスト項目として設計します。
異常系や端末環境まで検証します
iOSとAndroidの端末・OSの組み合わせや、プッシュ通知の到達条件を意図的に発生させて検証します。
既存のテスト体制に合わせます
発注側主導・ベンダー主導のいずれの体制にも合わせ、開発ベンダーの自社テストと重複しない受け入れテストの側を担います。
検証範囲と残存不具合を分けたテスト報告書
検証した範囲と検証していない範囲、残存不具合とその影響を分けたテスト報告書を納品し、リリース判断の材料としてご提出いただけます。
ご相談から納品までの流れ
ご相談から報告書の納品までの各段階で検証範囲と進め方を確認し、リリース判断の材料を整えます。
ヒアリング
アプリの構成と改修範囲、ベンダーとの分担を伺って検証範囲を整理します。
テスト設計とお見積もり
テスト項目と端末・OSの組み合わせを設計し、見積もりと期間を提示します。
テストの実施と進捗の共有
設計したテストを実施し、不具合票と進捗を日次で共有します。
報告書の納品と修正後の再確認
検証範囲と残存不具合を分けた報告書を納品し、修正後に該当箇所を検証します。
検証範囲の設計からご相談いただけます
入居者アプリの検証範囲と優先順位から、GENZにご相談ください
基幹システムとの連携、権限による表示範囲、端末とOSの組み合わせ。入居者アプリの構造からテスト設計を起こし、検証範囲と優先順位を、リリース判断の材料として使える形でお渡しします。