プッシュ通知が対象の住民に届かない、または対象外の住民に届く
配信条件の設定と住民の登録情報が一致しないと、通知が届くべき世帯に届かず、制度の申込期限を過ぎてから住民が気づく事態になります。
GENZ, Inc.
自治体アプリの
自治体アプリの
自治体アプリの
自治体アプリのテスト設計から実行までGENZが担います
検証範囲の定め方に悩むご担当者様へ。検証範囲と残る不具合を、庁内の説明に使える形に整理して納品します。
支援事例
支援実績5,000件以上
自治体アプリでよくある不具合
申請・通知・認証・掲載情報をひとつのアプリに集約するほど、機能間の連携で起きる不具合が増えます。ここでは、受け入れテストで見落とされやすく、公開後に住民からの連絡で表面化する不具合を挙げます。
プッシュ通知が
本人確認が完了しないまま申請が送信済みと表示される
認証の処理が完了していないのに送信済みと表示されると、住民は申請が通ったと信じて待ち、受付側に記録が残っていないため、期限後に不備が判明します。
端末や画面の大きさによって申請フォームの入力項目が表示されない
端末の画面サイズによって入力項目や送信ボタンが表示されないと、その端末の住民は申請を完了できず、公開後の問い合わせで初めて条件が特定されます。
申請状況の表示が、連携先の受付状況と一致しない
アプリの申請状況が連携先の受付状況と一致しないと、住民は受付済みの表示のまま窓口へ来庁し、アプリで完結する前提の業務設計が成り立ちません。
掲載期間が終了した制度の案内が住民の画面に残る
掲載期間の終了処理が画面に反映されないと、受付が終わった制度の案内を見た住民が申請の準備を始め、窓口で受け付けられない不利益が生じます。
残存した不具合により生じる問題
受け入れテストで不具合を見落としたまま公開へ進むと、その影響は住民の利用の場面で表面化します。残存した不具合が引き起こす問題を整理します。
静的テスト（レビュー）でおさえるべき観点
動作テストの前に、仕様書どうしの不整合をつぶすのが静的テストです。自治体アプリでは申請・通知・認証・掲載情報が集約されるため、書類間の照合で発見できる不具合が多く残ります。
項目の不整合を見落とすと、住民が入力した申請内容が既存システムへ反映されない不具合が公開後に表面化し、窓口での再受付に戻る運用を強いられるおそれがあります。
要件定義書の申請項目と画面設計書の入力項目を突合する
要件定義書に記載された申請項目と、画面設計書の入力項目が一致しているかを突合します。項目の抜けや名称の不整合は、申請データが既存システムへ渡らない不具合の原因になります。
確認する資料
- 要件定義書
- 画面設計書
- 申請項目一覧
受け渡し項目の定義の差異を見落とすと、連携先で取り込みエラーが発生し、申請が受け付けられない状態が続くおそれがあります。
連携仕様書の受け渡し項目と既存システムの項目定義を照合する
連携仕様書の受け渡し項目と、住民記録や申請受付など既存システム側の項目定義を照合します。型や桁数の違いは、連携時の取り込みエラーとして表面化します。
確認する資料
- 連携仕様書
- 項目定義書
- IF一覧
抽出条件の不整合を見落とすと、健診やワクチンの案内が対象の住民へ届かず、受診機会の喪失という住民の不利益につながるおそれがあります。
通知の配信条件と対象者の抽出条件を仕様の間で照合する
通知の配信条件と、対象者の抽出条件を仕様の間で照合します。年齢や属性の境界値で条件が食い違うと、届くべき住民へ通知が届かない事象につながります。
確認する資料
- 通知仕様書
- 抽出条件書
- 配信基盤仕様
権限設計と規程の不整合を見落とすと、権限外の職員が個人情報を参照できる状態が残り、議会や監査への説明資料を作り直す事態になるおそれがあります。
権限設計と個人情報の取り扱いの規程を照合する
管理機能の権限設計と、個人情報の取り扱いを定めた庁内の規程を照合します。担当課ごとの参照・更新権限が規程と合わないまま公開すると、監査で説明できない状態になります。
確認する資料
- 権限設計書
- 情報管理規程
- 運用体制図
アクセシビリティの不整合を見落とすと、高齢者や障害のある住民が申請を完了できない画面が残り、利用の定着が進まない状態が続くおそれがあります。
アクセシビリティの基準と画面設計書の表示仕様を照合する
アクセシビリティの基準と、画面設計書の表示仕様を照合します。文字サイズやコントラスト、読み上げへの対応が仕様に反映されていないと、高齢の利用者が操作できない画面が残ります。
確認する資料
- アクセシビリティ基準
- 画面設計書
- 表示仕様書
- 基準適合表
動的テストの設計・実行のポイント
動的テストは、ユニット・統合・システム・受け入れの各段階で検証範囲を分けて設計し、線引きを説明できる形にします。
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が代行する自治体アプリのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 対象と対象外を文書で示し、検証範囲の基準を持てます
- テスト項目書の作成から実行、不具合票の管理まで任せられます
- 構築したベンダーと別の視点でテスト設計を点検できます
- 更新ごとの回帰テストが定型化され、手作業での確認から離れられます
住民向けアプリの検証を第三者の視点で担うGENZ
自治体アプリの受け入れテストを、構築に関与しない第三者の視点でGENZが担います。検証範囲を文書として定め、検証の結果と残る不具合を、庁内のリリース判断に使える形でお渡しします。
設計書と業務の流れからテストを設計
設計書と、申請から掲載までの業務の流れをもとにテスト設計を行い、テスト項目書を作成します。実行と不具合票の管理までを代行します。
申請から掲載までの検証範囲
申請・プッシュ通知・公的個人認証・掲載情報の接点ごとに確かめる対象を分け、端末や利用環境の違いを含めて検証範囲を設計します。
既存の推進体制に合わせて伴走する
ベンダー側の品質保証配置と発注側の推進体制のどちらにも入り、進め方に合わせて伴走します。構築した側と別の視点でテスト設計を点検します。
不具合票と検証範囲を報告書で納品
不具合票と検証範囲を報告書にまとめて納品します。管理職への説明や監査への対応に、そのまま使える資料です。
ご相談から納品までの流れ
受け入れテストは、ヒアリングから報告書の納品まで順に進め、公開日までの進行に合わせて調整できます。
ヒアリングと対象範囲の確認
アプリの構成と連携先、公開までの日程を伺い、検証範囲の境界を決めます。
テスト設計と見積もりのご提示
テスト設計を行い、テスト項目書の骨子と工数、費用をご提示します。
テストの実施と結果の共有
テストを実行し、不具合票を起票して重さと件数を週次で共有します。
報告書の納品と修正後の再確認
検証結果を報告書として納品します。修正後は回帰テストで再確認します。
公開日が近いほど、検証範囲の決定を早めます
検証の範囲と優先順位をGENZにご相談ください
検証範囲の切り方、優先順位の付け方、公開日までに必要な工数、既存システムとの連携で要る関連テストを、GENZが整理してお渡しします。管理職への説明にそのままお使いいただけます。