入力チェックが要件と食い違い、境界値で誤った値が登録される
設計書と設定値が照合されないまま構築が進むと、上限・下限の境界値で誤った入力がそのまま登録され、帳票や集計へ不正な値が流れます。
GENZ, Inc.
設定と仕様の照合を
ローコード業務アプリの
設定と仕様の照合を
ローコード業務アプリのテストを第三者視点で代行します
ローコード開発ツールの業務アプリは、画面や分岐条件がGUI上の設定値として保持されます。GENZは第三者の視点で設定と要件の照合からテストまで担います。
支援事例
支援実績5,000件以上
ローコード業務アプリに多い不具合
ローコード開発ツール上のアプリは、画面項目や分岐条件が設定値として保持されるため、コードレビューでは見つからない設定の誤りがそのまま本番へ出ます。内製で多い不具合の形を整理します。
入力チェックが
分岐条件の誤りで金額帯の境界で承認経路が切り替わらない
承認ワークフローの分岐条件が要件と食い違うと、金額帯の境界で承認経路が切り替わらず、上長承認を経ない申請が通ってしまいます。
権限設定の漏れで他部署のデータが見えてしまう
部署や役職ごとの権限の割り当てに漏れがあると、参照不可であるべき他部署のデータが画面に表示され、情報管理の監査指摘につながります。
連携失敗が通知されず反映漏れが残る
基幹システムとの連携が失敗した際に通知の設定がないと、送信漏れに誰も気づかず、既存システム側に反映されないデータが残ります。
設定差で画面と帳票の集計値が合わない
画面側と帳票側で集計条件の設定が異なると、同じ期間のはずの数値が合わず、月次締めのたびに原因の確認作業が発生します。
残存した不具合により生じる問題
リリース後に残存した不具合は、連携先への誤データの送信、月次処理での重複や漏れ、変更記録の欠落として表面化し、訂正と監査対応の負荷を生みます。
静的テスト（レビュー）でおさえるべき観点
ローコード開発ツールでは画面・帳票・ワークフローがGUI上の設定値として保持されるため、コードのレビューに代わり、要件・業務ルール・社内規定と設定値を照合する静的テストが有効です。照合の観点を整理します。
照合されないままだと、要件と不整合の画面のまま構築が完了し、受け入れの場で「そういう意味ではなかった」とやり直しになります。
要件の記述とツール上の画面定義・項目構成を照合する
要件の記述と、ツール上の画面項目・項目の並び・必須指定を一対一で照合します。設計書と設定値が別々に存在しやすく、口頭の合意だけで構築が進むと、要件と不整合の画面のまま完成します。
確認する資料
- 要件定義書
- 画面遷移図
- 画面項目一覧
照合されないままだと、誤った入力を防げず、誤った計算結果や帳票がそのまま業務で使われ、訂正が手作業での対応となります。
入力チェックの条件を業務ルールの型・桁・範囲・項目間の整合と照合する
入力チェックの条件について、型・桁数・値の範囲・項目間の整合を業務ルールと照合します。境界値の条件が要件と不整合だと、誤ったデータが登録され、帳票の誤りとして表面化します。
確認する資料
- 業務ルール一覧
- 入力チェック仕様
- 帳票レイアウト定義
照合されないままだと、権限のない承認や二重承認が可能な状態のまま公開され、内部統制の不備として監査で指摘されます。
ワークフローの分岐条件と承認者の割り当てを職務権限の規定と照合する
ワークフローの分岐条件と承認者の割り当てを、職務権限の規定と照合します。金額帯の分岐条件が規定と不整合だと、権限のない担当者が承認できる状態となり、内部統制上の不備として監査で指摘されます。
確認する資料
- 職務権限規定
- ワークフロー定義
- 承認経路一覧
照合されないままだと、誤った項目の対応づけで連携データが送信され、連携先システム側のデータ訂正と再送対応が発生します。
連携定義の項目の対応づけを既存システムのDB設計書と照合する
既存システムとの連携定義について、項目の対応づけ・桁・コード体系を、連携先のDB設計書と照合します。対応づけの誤りは製品側では検出できず、連携先への誤データ送信として表面化します。
確認する資料
- DB設計書
- 連携定義書
- 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回帰テストの範囲定義
GENZが代行するローコード開発ツール向けテストの種類
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 画面・ワークフローの境界値と異常系まで網羅したテスト観点
- 要件の記述と設定値を突き合わせる第三者による設計書照合
- 監査・内部統制へ提出できる形で残るテスト実施の記録
- ツール更新時の検証範囲を絞り込む回帰テストの設計
シナリオ単位で検証するテスト支援
ローコード開発ツール上のアプリは、画面項目・分岐・権限・帳票がGUI上の設定値として保持されます。GENZは設定値と要件の照合を起点に、業務シナリオ単位でテストを設計し、開発と並行して検証を進めます。
設定値の要件照合からテスト設計を起こす
要件の記述とツール上の設定値を突き合わせ、入力チェックや分岐条件の不整合を洗い出した上で、境界値と異常系を含むテスト設計へつなげます。
業務シナリオ単位で検証範囲を設計する
申請・承認・帳票出力といった業務の流れを単位に検証範囲を決め、ツール更新時には影響を検知できるシナリオを絞り込む判断軸を示します。
内製体制を止めずに並行してテスト
内製の開発サイクルを止めず、設定作業と並行してテストを進めます。作った本人以外の第三者の視点を、人員を増やさずに体制へ組み込めます。
テスト項目書と報告書を納品
何をテストし何をテストしなかったかが読み取れるテスト項目書と報告書を納品し、内部統制の点検や社内説明の材料としてご利用いただけます。
ご相談から納品までの流れ
内製アプリについて、設計書が整っていない状態からでも、ご相談から報告書の納品まで次の流れで進めます。
ヒアリング｜現状をうかがう
対象アプリの設定状況と運用の実態をうかがい、検証が必要な範囲を整理します。
テスト設計と見積もりのご提示
テスト観点と検証範囲の優先順位を設計し、見積もりとあわせてご提示します。
テストの実施と結果共有
第三者の視点でテストを実施し、正常系と異常系の結果を共有します。
報告書の納品と再確認
テスト項目書と報告書を納品し、監査へ提出できる形の記録として再確認します。
内製アプリの検証範囲の整理から始めます
ローコードで作ったアプリの検証範囲と優先順位を、GENZにご相談ください
ご相談いただくと、対象アプリのテスト範囲の切り分け、リリース判断に直結する優先順位、ツール更新時の回帰テストの要否を、GENZが第三者の視点で整理してお返しします。