GENZ, Inc.

実装側とは別の立場で 施設管理アプリのテストを第三者に任せる

ベンダーの報告だけでリリース可否を判断していませんか。実装側とは別の立場で、屋外や通信状態を含む利用場面をたどり、確認した範囲と未確認の範囲を記録します。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

施設管理アプリのテストで見落とされやすい箇所

施設管理アプリの受け入れ確認では、屋内の正常系手順は追えても、現地の通信環境や拠点の追加、権限の分岐、端末の版差異といった利用場面が見落とされがちです。公開したあとの停滞につながりやすい箇所を挙げます。

通信が届かない場所で入力した巡回記録が残らない

電波が届かない機械室や屋外の設備で入力した巡回記録が、再接続時に同期されず欠落するおそれがあります。通信を遮断して一時保持の方式を検証します。

屋外の通信環境

設備台帳と点検履歴の紐づけが拠点の追加で崩れる

拠点や設備が追加されると、既存の設備台帳と点検履歴の紐づけが崩れ、集計や履歴の参照ができなくなるおそれがあります。追加を伴う手順で確認します。

設備台帳の管理

不具合の受付から完了報告までの承認の分岐が抜ける

受付から一次判断、修繕手配、完了報告の承認まで分岐が多く、承認が抜けたまま完了扱いになるおそれがあります。分岐ごとに権限を検証します。

権限と承認の分岐

端末や基盤の版が変わると撮影した画像や帳票が表示されない

端末やOS、基盤の版が更新されると、撮影した画像や帳票が表示されなくなるおそれがあります。版の異なる実機を用意し、表示と出力を確認します。

端末の版差異

予約と解錠の時刻がずれ、現地で入室できない

予約の開始時刻と解錠の時刻がずれると、利用者が現地で入室できません。時刻の境界や予約変更の直前操作を含めて、連携部分の動作を検証します。

外部システム連携
02 RISK

不具合を残したまま公開した場合に起きること

受け入れ確認が主要な手順の追認に留まると、通信が不安定な場面の不具合を残したまま公開することになります。現場で起きる事象を示します。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

第三者の視点で確認するテストの観点

施設管理アプリの確認は、実装側のテストとは切り離した観点で進める必要があります。ここでは、第三者の視点で検証する際に押さえておきたい観点と、見落とした場合に現場で起きる事象を整理します。

分岐の操作が確認されないままリリースされると、現場で起票の差し戻しが機能せず、スタッフが電話と紙で運用を回し始め、アプリに記録が残らなくなります。

現場の利用場面をたどるテストシナリオの網羅性の確認

点検の巡回から不具合の起票、修繕完了の報告まで、現場スタッフが端末を操作する一連の流れをシナリオとして追います。主要な手順だけの確認では、起票後の差し戻しや二重登録といった分岐が抜け落ちます。

確認する資料
  • 業務フロー図
  • 操作手順書
  • 画面一覧
台帳と帳票の項目のずれを見逃すと、点検記録の一部が台帳へ登録されず、点検の実施をあとから示す資料を作りなおす工数が発生します。

設備台帳と点検帳票の項目とデータの整合性の確認

設備台帳の項目と、点検時に入力する帳票の項目が対応しているかを照合します。拠点ごとに手順が異なる場合、台帳側の項目名と入力画面の表記のずれが記録の欠落を生み、あとから集計が合わなくなります。

確認する資料
  • 設備台帳定義
  • 帳票レイアウト
  • 項目対応表
通信が不安定な場所での確認を省くと、現地で入力した記録が同期時に欠落し、欠落に気づいた現場がアプリへの入力自体を控えるようになります。

端末の環境と通信状態の組み合わせを網羅した確認

iOSとAndroidの両端末、OSの版、屋外や通信が不安定な場所での操作を組み合わせて確認します。通信が届かない場所で入力した記録が再接続時に欠落なく同期されるかは、実機で検証します。

確認する資料
  • 対象端末一覧
  • OS対応表
  • 同期仕様書
連携先との境界を確認しないまま運用が始まると、予約情報や解錠の連携が不整合を起こし、利用者からの通報として初めて不具合が表面化します。

外部の仕組みと接する境界での受け渡しの挙動の確認

予約や入退の仕組み、電子錠など外部の連携先との境界で、データの受け渡しが意図どおりに行われるかを検証します。連携先の試験環境の有無を確かめ、確認できる範囲とできない範囲を分けて記録します。

確認する資料
  • 連携仕様書
  • 試験環境情報
  • 連携先一覧
権限と移行データの確認を省略すると、意図しない利用者が記録を変更できる状態が残り、移行漏れの履歴は次の更改の前提を狂わせます。

権限と承認の分岐、そして移行したデータの確認

利用者の追加や権限変更が、閲覧・入力・承認の各操作に正しく反映されるかを確認します。更改の際に既存の台帳や点検履歴を移行する場合は、移行前後で件数と内容が一致することを照合します。

確認する資料
  • 権限設定表
  • 利用者一覧
  • 移行計画書
  • 移行元データ
04 TEST DESIGN

テストの外注で引き受ける範囲と進め方

GENZはテスト計画の作成から実行、結果の報告までを第三者として引き受け、確認した範囲と未確認の範囲を分けて示します。

STEP 01 対象のアプリと業務の範囲を確認する現場の業務手順の聞き取りから始めます。
どう確かめるか

対象範囲を定めるテスト計画とテスト設計の作成

点検・巡回・修繕受付の機能要件と対象端末、対象工程を整理し、帳票やワークフローの分岐をどこまで確認対象に含めるかの線引きを、計画と設計の段階で文書に落とします。

  • 01点検・巡回・修繕受付の現場での業務手順を聞き取る
  • 02設備台帳の項目と利用者ごとの権限設定の範囲を整理する
  • 03確認の対象とする端末とOSの版、外部の連携先の一覧を作る
OUTPUTテスト計画書とテスト設計書
STEP 02 テストの観点と範囲を合意する確認対象の線引きを文書で合意します。
どう確かめるか

端末と通信の条件を含むテストケースの実装と実行

端末とOSの組み合わせや通信状態を踏まえたテストケースを用意し、テスト環境で実行します。通信が届かない場所での記録の保持と再接続時の同期も、設計資料にもとづく確認項目に含めます。

  • 01確認対象に含める機能と帳票の分岐を範囲案にまとめる
  • 02通信状態の変化や端末の版差異を含む観点をテスト項目に落とす
  • 03確認しない範囲とその理由を文書に明記して合意する
OUTPUTテストケースと実施結果
STEP 03 テストを実施し、不具合を報告する不具合は発生条件付きで報告します。
どう確かめるか

発生条件を添えた不具合の記録と再現手順の整理

不具合が起きた際の発生条件、端末、通信状況、連携先の状態を並べて記録します。再現手順を添えた報告は、原因がアプリ側・端末側・連携先のどこにあるかを切り分ける材料としてそのまま使えます。

  • 01テスト環境でテストケースを実行し、結果を記録する
  • 02不具合ごとに発生条件と再現手順を整理して報告する
  • 03原因の切り分けに必要な端末と通信状況の情報を添える
OUTPUT不具合報告と再現手順
STEP 04 修正の確認と最終の報告をまとめる次の改修時に参照できる記録を残します。
どう確かめるか

確認した範囲と未確認の範囲を分けた結果の報告

確認した範囲と確認していない範囲を区別した報告書をまとめます。リリース判断の上程資料や、品質管理部門からの質疑への回答に、そのまま添えられる形で提出します。

  • 01修正された不具合を発生時と同じ条件で再度確認する
  • 02確認済みの範囲と未確認の範囲を分けた報告書を作る
  • 03次の改修時に参照できる記録としてまとめて引き渡す
OUTPUT確認範囲と結果の報告書
05 RATIONALE

施設管理アプリの検証を第三者として担う体制

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 開発ベンダーとは独立した第三者の視点で検証します
  • 端末とOSの組み合わせや通信状態まで含めたテスト設計を用意します
  • テストケースの作成から実行、不具合の整理まで一括で引き受けます
  • 確認した範囲と未確認の範囲を次の改修で参照できる記録に残します
06 SERVICE

GENZが提供するテストのメニュー

GENZは、施設管理アプリの開発や選定は請け負わず、実装した側とは別の立場でテストを設計し、実施と報告まで引き受けます。巡回や修繕手配といった利用場面をたどり、確認した結果をあとから追える記録に残します。

SVC 01

開発と伴走して実施するテスト

改修の進行に合わせて、実装が固まった機能から順にテストを実施します。リリース直前に確認が集中せず、手直しの判断を早い段階に置けます。

リスク要因と優先順位を示す無文字の図解。
SVC 02

広域の施設管理システム網羅テスト

点検・修繕・予約・入退管理にまたがるシステムでも、端末とOSの組み合わせや権限と承認の分岐まで含めて設計し、網羅して確認します。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

受け入れの前に第三者として実施する検証

受け入れ確認の直前に、実装側とは別の立場で検証します。ベンダーの報告とは独立した結果が、リリース可否の合議で説明の材料になります。

計画から報告までの流れを示す無文字の図解。
SVC 04

あとから追える形でのテスト記録の整備

確認した範囲と未確認の範囲を、あとから追える形で記録して残します。上程の場での質疑への回答や、次の改修時の判断材料として使えます。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

ご相談から開始までの流れ

テスト外注のご相談は、確認できていない範囲の共有から始まります。稟議に使う資料もあわせて整えます。

お問合せと確認できていない範囲の共有

確認できている範囲と追い付いていない部分を聞き取り、整理の起点とします。

対象範囲の確認とお見積の提示

確認する範囲と外す範囲を切り分け、工数の根拠を添えたお見積を提示します。

社内での説明に使う資料の準備

確認済みと未確認の区分や現場工数の軽減見込みなど、上程に使う材料を整えます。

ご契約の締結とテスト実施の開始

成果物と検収条件を契約の文言に落とし、ご契約後にテストを開始します。

第三者によるテスト検証のご相談

施設管理アプリのテストの範囲から、ご相談ください

どこまで確認し、どこを未確認とするか。テストの範囲と優先順位、必要な工数の考え方を、実装側とは別の立場で整理してお返しします。まず現状をお聞かせください。