テストケースの採番が重複し、要件との対応が取れない
Excelから移行したテストケースは担当者ごとに採番が重複し、要件との対応付けができません。母数が信頼されず、未検証の要件が残ります。
GENZ, Inc.
テスト管理ツール
テスト設計から
テスト管理ツール
テスト設計から実行まで第三者の視点で検証します
テスト管理ツールを導入しても、入力規約の設計と検証範囲の決定は社内に残ります。GENZは第三者の視点で、既存の体制のままテスト設計から実行まで担います。
支援事例
支援実績5,000件以上
テスト管理ツールでよくある不具合
テスト管理ツールの導入後に起きる不具合の多くは、製品の欠陥ではなく、採番規約・状態の定義・連携設定・権限設計の段で埋め込まれた運用上の不備です。移行と運用の開始直後に表面化しやすい不具合を取り上げます。
テストケースの
実行結果の状態値が未定義のまま登録され、消化率が実態と乖離する
未実行と実行中の区別が入力規約で定義されないまま登録が進むと、消化率に実態との差異が生じます。リリース判断の根拠には使えません。
課題管理ツールとの連携で不具合票が二重に残り、残件が重複計上される
課題管理ツールと連携した不具合票が双方に残ると、残件が重複して計上されます。収束状況の集計が実態より悪く見え、リリース可否の合議が進みません。
CSV一括登録で日本語が化け、書き出しても戻らない
CSVの一括登録で日本語が文字化けすると、書き出して修正しても元の形式へ戻せません。Excel資産の移行が止まり、手作業での対応が発生します。
権限の設定漏れで、外部アカウントから対象外のプロジェクトが参照できる
外部の支援者へ発行したアカウントの権限設定が漏れると、対象外のプロジェクトまで参照できます。監査で指摘され、権限を見直す手戻りが発生します。
残存した不具合により生じる問題
入力規約や指標の定義が統一されないまま運用を続けると、集計値と証跡の信頼性が損なわれ、リリース判断や監査対応の土台が崩れるおそれがあります。
静的テスト（レビュー）でおさえるべき観点
指標の定義が案件ごとに異なるままでは、ツールを導入しても集計値は比較できません。導入前のレビューでは、帳票類の定義どうしを照合し、不整合を入力規約の段階で潰しておく観点が要になります。
採番が統一されないまま移行すると、要件カバレッジの対応が取れず、集計した件数が母数として信頼されない状態がツール上でも続きます。
入力規約とテストケースの採番規則を、要件一覧の識別子と照合する
要件側の採番が統一されていないと、要件とテストケースの対応が取れず、要件カバレッジの視覚化が機能しません。採番規則を要件一覧の識別子へ合わせておくと、移行後も対応関係を機械的に追えます。
確認する資料
- 入力規約書
- 採番規則書
- 要件一覧
状態値の区別が定義されないままでは、進捗の集計値が実態と乖離し、リリース判断の根拠が揃わないまま日程優先の意思決定が繰り返されるおそれがあります。
実行結果の状態値の定義を、集計の定義（消化率の分母）と照合する
未実行・実行中・完了の区別が入力規約にないと、消化率の分母が担当者ごとに変わります。状態値の定義を集計の定義と照合しておけば、リリース判断に用いる数値の作られ方を説明できます。
確認する資料
- 状態値定義書
- 消化率の定義
- 集計規約書
参照範囲が曖昧なまま外部アカウントを発行すると、外注先へ検討対象外の案件情報まで見える状態が残り、権限の設計をやり直す手戻りが発生します。
権限設計書を、プロジェクトの区分と外部アカウントの参照範囲と照合する
権限設計書の記述が案件の区分と不整合のままでは、外部の支援者へ発行するアカウントの参照範囲が曖昧に残ります。権限の段階設計と案件区分、外部アカウントの参照範囲を照合し、文書上で固定します。
確認する資料
- 権限設計書
- 案件区分表
- 外部権限表
不具合票の正本が定まらないままでは、ツールとJiraの残件数に差異が残り、消化率と収束状況を同じ画面で示す資料を作れません。
API定義と不具合票の正本・同期方針を照合する
不具合票の正本がツールとJiraのどちらか定まっていないと、残件の集計値が二系統に分かれ、収束状況を同じ画面で示せません。API定義と同期方針を照合し、正本の所在と反映の方向を決めます。
確認する資料
- API定義書
- 不具合票仕様
- 同期方針書
添付規約が監査の要件と不整合のままでは、年次の監査対応と原因調査のたびに計画外の収集工数が発生し、テスト設計へ投じる時間が減ります。
エビデンスの添付規約を、保存期間と監査の提出単位の要件と照合する
エビデンスがツール外の共有フォルダに散在すると、監査のたびに収集作業が発生し、本番不具合を遡る照合にも時間がかかります。添付規約を保存期間と提出単位の要件へ照合すれば、手戻りを減らせます。
確認する資料
- 添付規約書
- 保存期間表
- 監査要綱
- 提出単位表
動的テストの設計・実行のポイント
テスト管理ツールの検証では、登録から集計までが自社の運用に合うかを工程ごとに確かめます。各工程の論点を整理します。
STEP 01
ユニットテスト境界値と異常な入力値を網羅します
どう確かめるか
ユニットテストで、テストケースの登録と更新の入力値を境界値で確かめる
テストケースの登録と更新を、採番・粒度の異なる入力値と境界値で確かめます。担当者ごとに様式が異なるExcel資産を取り込んだとき、母数として集計に耐える形で保存されるかを確認します。
- 01テストケースの採番と状態の入力値を境界値で確かめる
- 02Excel資産の取り込みで様式差が吸収されるか確かめる
- 03登録と更新の権限エラーが検知されるか確かめる
OUTPUT登録・更新の網羅性
STEP 02
統合テスト既存の課題管理ツールとの往復を確かめます
どう確かめるか
統合テストで、課題管理ツールとの不具合票の往復を双方向で確かめる
既存のJira・Redmineとの間で、不具合票の登録と状態更新が双方向に反映されるかを確かめます。片方向しか連携しない設定では、残件の集計に差異が生じ、リリース判断に使えません。
- 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認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 採番規約と状態定義が部門内で統一され、集計値が実態を示します
- Excelの既存資産を粒度の基準に沿って整備し、移行できます
- 実行結果とエビデンスを相互参照し、監査提出と原因調査に使えます
- 指標の定義が維持され、過去プロジェクトとの比較を継続できます
体制を変えずテスト設計から任せられる
テスト管理ツールを導入しても、入力規約の設計と検証範囲の決定は社内に残ります。GENZは第三者の視点でテスト設計から実行までを担い、既存のプロジェクト体制と報告の経路を組み替えずに入ります。
定義を起点にテスト設計を組む
テストケースの採番規約や、未実行・実行中・完了の状態の定義から設計し、第三者の視点でテスト設計の成果物をツールへ登録します。
検証範囲を優先順位で網羅
要員が足りない前提で、外注する範囲と社内に残す範囲の優先順位を示し、大規模システムの検証範囲を網羅します。
既存の報告経路を変えずに実行
スプリントと並行してテストを進める体制で支援します。発注側が発行するアカウントでツールへ登録し、既存の報告の経路は変えません。
使えるエビデンスとして報告
システム監査への提出と本番環境の不具合の原因調査の両方で使える形にエビデンスを揃え、発注側の規約に沿って実行結果とともに残します。
ご相談から納品までの流れ
ご相談から報告書の納品までの流れを整理しています。既存の体制に沿って進める形をご確認いただけます。
ヒアリング
対象システムとテスト体制、検証範囲の前提を伺い、課題を整理します。
テスト設計と見積もり
テスト設計の方針と対象範囲、優先順位を示し、見積もりを提出します。
テストの実施と結果の共有
テストを実行し、結果と不具合票を規約に沿って登録し、進捗を日次で共有します。
報告書の納品と再確認
実行結果とエビデンスをまとめた報告書を納品し、関連テストの要否を示します。
ご検討中の企業様へ
テスト管理ツールの検証範囲と優先順位をGENZへご相談ください
テスト管理ツールを導入しても、検証範囲の決定と優先順位づけは社内に残ります。GENZは第三者の視点で範囲と優先順位を整理し、必要工数の考え方と関連テストの要否までお示しします。