2022.01.17

SHIFTが考える理想的なテストリソース量とは？2つの観点とフェーズにおける算出方法について解説

著者株式会社SHIFT　マーケティンググループ

お役立ち資料

Introduction

ソフトウェア開発において、品質を担保するために必要なソフトウェアテスト。今回は、その実施について各テストフェーズにおける理想的なテストリソース量を算出するための考え方についてご紹介いたします。

理想的なテストリソース量とは

「理想的なテストリソース量」は開発ボリューム、仕様の複雑度、動作保証するOSなどのさまざまな条件によって変動します。そのため、テストに必要な条件を正確に洗い出すことが理想的なテストリソース量を出すことに繋がります。
考え方によってはテストリソース量を限りなくゼロにすることができれば理想のようにも感じますが、多種多様な機能が存在するシステムにおいてテストリソース量を減らしすぎると十分なテストができずにリリース後に大きな障害が発生することにもなります。そのため、「品質」と「リソース」のバランスをとりながら進めていくことがポイントとなります。

株式会社SHIFTでは、この重要なソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

ソフトウェアテストのよくある質問はこちらをご覧ください。
＞＞ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説のページへ

テストリソース算出において顧客と押さえるべき観点とは？

テストリソース算出には各テストフェーズのインプットが揃っていることがテストリソース算出の確度をあげるためにも大切なポイントとなります。
テストフェーズごとに必要なインプットは異なりますが、以下のⅤ字モデルを例に考えると単体テスト~受入テストまでの各テストフェーズで対となる工程の仕様書、設計書がリソースの算出には必要となります。

図A:V字モデル

※参照:ソフトウェア開発とは　種類や手法、開発の流れやコツについてわかりやすく解説

また、各テストフェーズのインプット情報を基に、テストの方向性について顧客と意識合わせも必要です。今後、機能単位のテストの濃淡を判断する材料にもなり、リソース算出にも影響しますので、ヒアリングの際には以下の点を明確にするのがよいでしょう。

＜ヒアリングすべき点＞
□重要な機能、画面について
□ロジックが複雑な機能、画面について
□過去に不具合がよく出ている機能、画面について　など

ヒアリングした結果、品質リスクの高い機能については、テストの濃度を増やすためにテストケース数の増加の検討や、アドホックテストを実施することでリスクを軽減することが可能です。
ただし、上記の対応によりテストリソースが増加するため、品質リスクの低い機能についてはテストケース数を減らすなどの対策をすることでテストボリュームの調整をし、リソースと品質のバランスを保つことが可能となります。

リソースの算出とリスク検討について

リソースの検討を進める際にプロジェクトで発生し得るリスクについても考慮する必要があります。
まずはリスクとしてよくあるケースを考えてみます。

＜プロダクトリスク＞
□品質要求が定まっていないため、テストすべき水準が定まらず、隅々までテストをしてしまい、リソースが不足する
□仕様が曖昧なため、仕様認識齟齬が発生し、テストケースの再修正および再テストが発生する
□仕様変更が度々発生することで、テストケースの再作成が求められる　など

＜人的リスク＞
□業務知識や経験がテスト水準に達成しておらず、テスト設計、テスト実行に時間を要する　など

すべてのリスクを抑えていくことはむずかしいですが、テスト計画の段階であらかじめリスクを考慮しておくことができればリソースの算出をする際の検討材料にすることができます。また、プロジェクト開始時に抽出できるリスクについてはプロジェクトメンバー、顧客と共有をし、リスクの責任範囲を明確にしておくことも大切です。
責任範囲を明確にすることでリスク発生時の責任の所在がわかるため、対策の初動が早くなり、対策に充てるリソース配分も行いやすくなるメリットがあります。

フェーズごとの理想のリソース量について

ではこれまでの内容を踏まえて、各テストフェーズでの理想とされるリソース量を考えていきます。リソース量を算出するにあたり「タスクを出し切ること」も焦点となるため、各テストフェーズのテストスコープについて、テスト設計、テスト実行をするメンバーが共通の認識をもっている必要があります。

単体テスト・結合テスト・総合テスト

各テストフェーズについては以下のようなスコープのわけ方になります。

＜単体テスト＞
「関数単位でロジック上の不具合を検出する」という目的でテストを行います。
＜結合テスト＞
「関数間のインターフェース、サブシステム間のインターフェースについて不具合を検出する」という目的でテストを行います。
＜総合テスト＞
「メインシステムを動かして要求仕様に関する不具合を検出する」という目的でテストを行います。

図B：テストフェーズごとのスコープ

また、これまでの内容を踏まえて各テストフェーズのリソース量の考え方については以下のようにまとめることができると思います。

図C：テストフェーズごとのタスクに応じたリソース量の考え方

テスト管理

テスト管理については大きくわけて以下の内容に振りわけすることができます。
□進捗管理（スケジュール立案、進捗報告作成、ミーティング)
□品質管理（各種レビュー、不具合の管理）
□変更管理（仕様変更管理、仕様変更の影響度確認)
□不具合管理（不具合の集計、改修後確認の計画立案)

管理工数については明確に正解という基準はありませんが、以下を意識したうえで工数を出すことがポイントとなります。
①管理業務のフォローができるメンバーが管理者以外にプロジェクトにいるかどうか
②メンバーのスキル、経験を踏まえて、メンバーフォローに充てる工数がどの程度必要か
③不測の事態が起きた際のバッファをどの程度考慮しておくか

仕様把握

仕様把握については、各種上流工程の仕様書、設計書の確認以外にも、開発環境をテスト開始前に使用できる場合は、開発環境で仕様確認する時間も込みで工数、リソースの算出を行います。

テスト計画

テスト設計については、「重点機能」「ロジックの複雑度の高い機能」「過去不具合の多く出ている機能」「それ以外の機能」でそれぞれ1ケース当たりテスト設計時間を算出し、ケース数の見積り、リソースの算出をします。
具体的なテスト設計手法については単体テスト、結合テスト、システムテストの各ページを参照ください。

テスト実行

テスト実行については1ケース当たりのテスト消化時間、不具合発見時の起票時間、不具合の改修後確認の時間は少なくとも考慮する必要があります。不具合の改修後確認の時間は不具合数に応じて変動をしますが計画段階で不具合発生率を見積っておくことが大切です。
不具合発生率については、過去のプロジェクトで発生した不具合率を参考にすることで、精度をあげることが可能です。

準備

テスト実行に必要な準備についても洗い出しが必要です。例えばOSごとにスマートフォン端末を複数準備する、テストデータの準備、テストの制約事項の確認、テストケースの消化順番の検討など、テストを滞りなく進めるために必要な準備工数を出す必要があります

リスク

リスクについては想定できているものはなるべく洗い出しておくことが望ましいです。
前段で記載した内容はごく一部のケースであり、実際の現場ではその場の状況に応じて多数のリスクが存在します。すべてのリスクが必ず顕在化するわけではないため、それぞれのリスクについて危険度と優先順位をつけていき、発生する可能性が高い事象から順に対応策を練ることがテストフェーズでのリソースの最適化にもつながっていきます。

上記の各タスクでの検討、リソース量の算出した後にリソース量の妥当性を確認したい場合は、過去の類似プロジェクトでのテスト実績がある場合に限り、当時のテスト計画、テスト実績を参考にすることで妥当性の精度をあげることが可能だと思います。

ソフトウェアテスト入門講座

※ご登録いただくとその場で無料動画の視聴が可能です。
株式会社SHIFTが運営するソフトウェアテスト・品質保証の人材育成を手掛けるヒンシツ大学のお試し講座「ソフトウェアテスト入門」をご視聴いただけます。ソフトウェアテストの目的、役割といった基礎知識を学びたい方におすすめの入門動画です。

ダウンロード

まとめ

テストフェーズにおけるリソース量について押さえるべきポイントについて記載いたしました。リソースというと、上流工程の各種仕様書、設計書に従って工数の見積りを行い、リソースの算出をするということに焦点が向きがちですが、可視化されている情報（上流工程の仕様書、設計書)以外のタスク、リスクをしっかりと抽出できるかどうかが大事です。
一朝一夕で身につくことではないため、繰り返し、見積りやリソース算出の経験を積むことでぜひ、理想のリソース量の算出が身につけられるようになっていただければと思います。

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

SHIFTが考える理想的なテストリソース量とは？2つの観点とフェーズにおける算出方法について解説

Introduction

理想的なテストリソース量とは

テストリソース算出において顧客と押さえるべき観点とは？

リソースの算出とリスク検討について