組織変更日をまたぐ申請が、旧組織の承認経路のまま止まる
切り替え日前に旧経路で出された申請が、新しい承認経路の対象外となり、誰にも通知されないまま止まります。
GENZ, Inc.
ソフトウェアテスト
グループウェアの
ソフトウェアテスト
グループウェアの設計書から画面挙動まで第三者が検証します
機能が同居し権限が横断するグループウェアでは、更新のたびに検証範囲の線引きが課題になります。GENZはテスト設計から第三者の視点で支援します。
支援事例
支援実績5,000件以上
グループウェアでよくある不具合
グループウェアはスケジュール・掲示板・ワークフロー・設備予約が同一の基盤に同居し、権限が機能を横断するため、組み合わせの条件で不具合が残ります。リリース後に表面化しやすい例を挙げます。
組織変更日を
権限グループの設定変更が、掲示板とファイル共有で見え方が食い違う
権限グループの変更が掲示板には反映されてもファイル共有に反映されず、閲覧できる範囲が機能ごとに異なる状態が残ります。
確定した設備予約が、Web画面とアプリで別の内容で表示される
Web画面で確定した予約がアプリ側に反映されず、別の時間帯の予約として表示され、利用者が来訪して初めて不整合が判明します。
承認依頼の通知が届かないか、同じ依頼が重複して届く
アプリ側のプッシュ通知の設定条件と電子メールの送信条件が一致せず、承認依頼が承認者へ届かない、または重複して届きます。
同一時間帯の会議室が二重に予約され、どちらも確定として残る
同一時間帯の空き判定がWeb画面とアプリで別々に行われ、双方で予約が確定として登録され、当日に利用者同士で重複が判明します。
残存した不具合により生じる問題
検証範囲から漏れた観点は、リリース後に不具合として表面化します。全社員が毎日使うグループウェアでは、その影響が経営コストとして現れます。
静的テスト（レビュー）でおさえるべき観点
グループウェアは権限が機能横断で効く構造のため、設計書の記述だけでは不具合の範囲を読み切れません。実装前のレビューで、定義書同士の照合から観点を確かめます。
経路定義と組織情報の不整合を見逃すと、組織変更日をまたぐ申請が承認されずに止まり、手作業での対応となるおそれがあります。
承認経路の定義を、組織階層と役職の一覧と照合する
ワークフローの承認経路は、組織階層と役職の情報を参照して決まります。設計書の経路定義と最新の組織・役職の一覧を照合し、旧経路から新経路へまたがる申請の扱いを確認します。
確認する資料
- 承認経路一覧
- 組織階層一覧
- 役職権限一覧
権限定義の抜けが残ると、所属外の利用者へ掲示板やファイルが公開される、または必要な参照ができない状態が本番で発生するおそれがあります。
権限グループの定義を、機能ごとの公開範囲の設定と照合する
権限グループの定義は、掲示板・ファイル共有など機能ごとの公開範囲の設定と照合します。機能をまたいで同一の属性で制御されるため、所属外・役職違いで閲覧範囲が反映されない定義を検出します。
確認する資料
- 権限設定一覧
- 公開範囲一覧
- 機能設定一覧
境界値の規定がないまま実装が進むと、想定外の入力で申請が保存されない・誤った値のまま承認へ回る不具合が受け入れ段階まで残るおそれがあります。
申請フォームの項目定義を、入力の許容範囲と境界値の規定と照合する
申請フォームの項目定義と、入力の許容範囲・境界値の規定を照合します。設計書に境界値の規定がない項目は、異常系のテスト観点が項目書へ載らないまま実装へ進むため、定義の抜けとして指摘します。
確認する資料
- フォーム定義書
- 入力仕様書
- 境界値規定書
連携項目の対応漏れがあると、組織変更の反映が承認経路へ届かず、切り替え当日に旧経路のまま申請が流れるおそれがあります。
人事システム連携の仕様と項目対応を照合する
人事システムとの連携仕様と項目対応を照合します。組織変更日に合わせた切り替えで、連携項目の欠落や変換の不整合が残ると承認経路へ反映されないため、項目対応表の段階で確認します。
確認する資料
- 連携仕様書
- 項目対応一覧
- 切替手順書
アプリ側とWeb側の差異を仕様で拾わないと、リリース直後に表示や通知が合わない報告が利用部門から入り、問い合わせが情報システム部門へ集中するおそれがあります。
アプリ画面の仕様を、Web画面の機能一覧と表示項目の対応で照合する
アプリ画面の仕様とWeb画面の機能一覧・表示項目を対応づけて照合します。設備予約などアプリ側で表示・登録できる機能がWeb側の定義と合うかを確かめ、通知経路の差異も仕様の段階で洗い出します。
確認する資料
- アプリ仕様書
- Web機能一覧
- 表示項目対応表
- 通知設定一覧
動的テストの設計・実行のポイント
機能が同一の基盤に同居するため、機能単位の一覧では権限と組織階層をまたぐ組み合わせが抜けます。工程ごとに検証範囲を分けます。
STEP 01
ユニットテスト承認経路・予約重複の判定を境界値で確認します
どう確かめるか
ユニットテストで、承認経路の判定と予約の重複判定を同値分割と境界値で確かめる
ワークフローの承認経路の判定と設備予約の重複判定は、同値分割と境界値で条件を分けて検証します。組織階層と役職の組み合わせを網羅し、経路の切れ目で承認が止まらないことを確かめます。
- 01承認経路の判定条件を同値分割で分類する
- 02役職・階層の境界値で承認の成否を検証する
- 03設備予約の重複判定の境界値を検証する
OUTPUT判定ロジックの確認結果
STEP 02
統合テスト人事連携と通知送信を連携単位で検証します
どう確かめるか
統合テストで、人事システムからの取り込みと通知の送信を連携単位で確かめる
人事システムからの組織・役職情報の取り込みと、プッシュ通知・電子メールの送信を連携単位で検証します。連携先との境界で不整合が起きやすく、単独の確認では差異が残るためです。
- 01人事システムからの組織情報の取り込みを確認する
- 02プッシュ通知と電子メールの送信を検証する
- 03連携先との境界でのデータの不整合を確認する
OUTPUT連携単位の検証結果
STEP 03
システムテスト権限別のシナリオで申請から反映まで確認します
どう確かめるか
システムテストで申請から一覧反映までを権限別シナリオで確認
申請の提出から承認、一覧への反映までを、一般利用者・承認者・管理者の権限別シナリオで確認します。機能をまたいで同一の属性で権限が制御される構造のため、権限違いでの動作差異を拾います。
- 01一般利用者の権限で申請から反映まで確認する
- 02承認者・管理者の権限で操作範囲の差異を検証する
- 03組織変更日前後にまたがる申請の扱いを検証する
OUTPUT権限別シナリオの結果
STEP 04
受け入れテストWebとアプリを業務手順どおりに確かめます
どう確かめるか
受け入れテストで、Web画面とアプリを業務手順に沿って確かめる
利用部門の業務手順に沿って、Web画面とスマートフォンアプリの双方で操作を確認します。画面の見た目の確認に寄らず、権限違いの利用者での動作と異常系の観点を手順に組み込みます。
- 01Web画面で業務手順どおりの操作を確認する
- 02アプリ側の表示と通知をWeb画面と突き合わせる
- 03権限違いの利用者と異常系の観点を確認する
OUTPUT業務手順での確認記録
GENZが代行するグループウェアのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 検証範囲の線引きを根拠とともに社内で説明できます
- Web画面とアプリの両経路で表示と権限を検証します
- 設計の抜けを第三者の視点で指摘できます
- 検証した範囲と残存不具合が報告書に残ります
構造からテスト設計を起こすGENZの支援
スケジュール・掲示板・ワークフローが同一の基盤に同居し、権限が機能を横断する構造では、機能ごとの確認だけでは検証範囲を線引きできません。GENZはこの構造を踏まえ、何を検証し何を検証しないかを整理します。
システムの構造からテスト設計を起こす
機能の組み合わせと権限グループ、組織階層への依存から検証範囲を設計します。境界値も含め、線引きの根拠を社内で説明できる形で残します。
画面とアプリ、権限別の表示まで検証します
同じデータを扱うWeb画面とスマートフォンアプリの両経路を検証範囲に含め、表示・通知・権限の反映が両方で一致することを確認します。
QA兼務の体制でも分担はそのまま
設計書のレビューから入る形、実行を担う形、既存チームと並行する形を選べます。期日が固定の場合は、実施できる範囲に絞った提案を行います。
判断に使える検証報告書を納品
検証した範囲と検証しなかった範囲、残存不具合を報告書の形で納品します。リリース可否の報告とシステム監査の双方に使える粒度で記録します。
ご相談から納品までの流れ
ご相談から報告書の納品まで、段階を追って進めます。成果物を共有し、検証範囲を擦り合わせて進行します。
ヒアリング
対象のグループウェアの構成、更新の内容、期日、既存のテスト体制を伺います。
テスト設計と見積もり
機能の同居と権限の横断を踏まえ、検証範囲と見積もりを提示します。
テストの実施と結果の共有
Web画面とアプリの両経路で検証を進め、不具合票を随時共有します。
報告書の納品と修正後の再確認
検証範囲と結果を報告書として納品し、修正後は回帰テストで確認します。
テスト範囲の整理から始められます
グループウェアの検証範囲と優先順位をGENZにご相談ください
期日が決まっている段階でも、検証範囲の線引きが固まる前にご相談いただけます。対象機能の棚卸しから範囲と優先順位の考え方、必要工数の見立てまで、第三者の視点で整理してお渡しします。