Vietnamese
Englishテストの組織
①独立したテスト
自分で書いた文章には、誤字や表現の間違いがあっても、自分ではなかなか気づけないことが多いです。そのため、文書の誤りを見つけるには、作成者以外の人に読んでもらうことが効果的です。これは、作成者が気づきにくい表現の不自然さや思い込みによる誤りを、他者が指摘しやすくなるからです。この仕組みは、ソフトウェア開発における開発者とテスト担当者の関係性にも似ています。この節では、テストマネジメントの観点から、テスト組織の形態、それぞれの利点と課題、独立したテストを行う技術者の役割について解説します。
プロジェクトにおけるテスト作業には、さまざまな役割の人々が関わります。主にテスト担当者が実施しますが、開発担当者がテストを行うこともあります。また、システムのオーナーやユーザーがテストに参加するケースもあります。テスト担当者が独立性を持つほど、欠陥を効率的に発見しやすくなります。たとえば、システムのオーナーがテストを実施すれば、自分が求めた通りにソフトウェアが動作しているかを確認できますし、ユーザーがテストを行えば、使いやすさや実用性を検証できます。
一方で、開発担当者とは異なる独立したテスト担当者がテストを行うと、開発者が抱きやすい先入観や確証バイアスといった心理的要因に左右されずに検証が可能です。また、専門知識を持つ独立したテスト担当者は、テストやレビューに対するモチベーションを高め、効率的な実施を支援します。ただし、独立性が高いことと、テスト対象への深い理解があることは別の問題です。たとえば、開発担当者はコードの内部構造に精通しているため、コードレベルの欠陥を多く見つけられることも事実です。
独立したテストチームの効果は、テストチームの形態やテストのレベルに応じて異なります。そのため、テストマネジメントには、最大限の効果を発揮できるテストチームを組織することが求められます。
以下では、組織におけるテストの独立性の度合いを、低いレベルから高いレベルの順に説明します。
独立したテスト担当者がいない場合（開発者が自身のコードのみをテストするケース）
開発者は、自分が作成したソフトウェアの内部構造を誰よりも深く理解しています。このため、自らテスト設計を行うことで、多くの欠陥を見つけられる可能性があります。しかし、もし設計書を誤解してプログラムを作成していた場合、自分自身ではその誤りに気づけないことがあります。また、開発者が自分のコードをテストする場合、先入観や確証バイアスの影響を受けやすいという課題もあります。
プロジェクトチーム内の他者によるテスト（同僚によるレビューやテストを含む）
プロジェクトチーム内で、開発チームとは別のテスト担当者がテストを実施したり、開発者が自分以外の同僚の成果物をテストしたりする場合を指します。このような担当者は同じプロジェクト内の技術者であるため、ソフトウェアの内部構造や仕様をよく理解しており、効率的に欠陥を発見することが期待されます。ただし、納期やコストなどの制約によるプレッシャーを強く受けるため、完全な独立性を確保するのは難しい状況です。
組織内に設置された独立したテストチーム（プロジェクトの管理下にないテスト部門）
開発者が属するプロジェクトに依存しないテストチームによってテストが実施される場合を指します。このようなチームは、プロジェクトの納期やコストに関する制約の影響を受けにくく、より客観的に品質を評価できます。たとえば、品質保証部門が行う品質評価は、この形式に該当します。
顧客や専門技術者による独立したテスト
この形式では、顧客やユーザーコミュニティから派遣されたテスト担当者や、特定のテスト分野に特化した専門家がテストを実施します。ユーザー視点に立ったテストでは、ソフトウェアが顧客の要件を満たしているかを確認でき、プロジェクトの影響を受けにくい点が利点です。また、特定の分野に精通した専門技術者によるテスト（例：使用性テストやセキュリティテスト）では、高度な技術を用いて品質要件を効率的に検証できます。
独立したテスト担当者は、組織外部の一員として活動し、オンサイト（インソーシング）またはオフサイト（アウトソーシング）で業務を行います。これらの担当者は、他の事業部門やテスト専門の外部企業に所属し、開発者とは異なる視点からテストを実施します。このような独立性は、開発プロジェクトにおいて不具合や欠陥を検出するための動機を明確にし、高い効果をもたらすことが期待されます。特定のテストレベルでは、専門性を持つ独立した担当者による実施が推奨されます。
ただし、テストをすべてテスト担当者に任せるのではなく、開発者もプロダクトの品質向上に関与するべきです。特に低レベルのテストでは、開発者の知識と経験が有効に活用される場合があります。テスト担当者の関与方法は、開発プロセスに応じて異なります。ウォーターフォール型開発では、開発者が順次成果物を作成する中で、独立したテスト担当者がその成果物に基づいて高い専門性でテストを実行します。一方、アジャイル開発では必要最小限の成果物しか作成されないことがあるため、テスト担当者がチームの一員として参加することが重要です。この場合、各サイクルの終了時にテストが実施され、品質を段階的に確認しつつ機能を拡張していくプロセスが取られます。したがって、プロセスの違いに応じて適切なテスト担当者の役割を理解することが必要です。
独立したテストの利点として、開発者とは異なる視点や技術的背景を持つことから、異なる種類の不具合を発見しやすい点が挙げられます。また、仕様作成や実装時にステークホルダーが行った仮定を検証し、説明を求めたり反証したりすることで、早期の欠陥検出に貢献します。さらに、ソフトウェアの内部構造に縛られず、利用者の視点で懸念事項を指摘する能力も持っています。
一方で、独立したテストには欠点も存在します。開発チームとの連携が不足すると、情報共有の遅延や対立が生じる可能性があり、また、開発者の品質に対する責任感が低下する懸念もあります。さらに、テスト担当者がボトルネックと見なされ、リリース遅延の原因とされることもあります。特に、テスト担当者が必要な情報を十分に得られない場合には、進捗が滞るリスクもあります。
これらの課題を克服するためには、開発チームとテストチームが協力し、密な連携を保つことが求められます。テストは開発者とテスト担当者がそれぞれの観点から行うべきであり、開発者がテストに全く関与しない場合、品質に対する意識の低下や欠陥の放置につながり、リリースの遅延や経済的損失を引き起こす可能性があります。独立性とは物理的な距離を置くことではなく、両者が共通の目標である高品質な開発を意識し、協働することが重要です。
ソフトウェア開発においては、独立したテストの利点を活かしつつ、その欠点を理解し適切に対応することで、より効果的なテストプロセスを実現することができます。
②テストマネージャーのタスク
テストマネージャーは、テストプロセス全体の責任を担い、その指導力を発揮してテスト活動を統括し、プロジェクトを成功へと導く役割を果たします。この役割は、プロのテストマネージャーをはじめ、プロジェクトマネージャー、開発マネージャー、品質保証マネージャーなど、さまざまな担当者が担うことがあります。
テストマネージャーの主要な業務は、プロジェクト全体を見渡してテスト計画を立て、それをもとにテスト活動をモニタリングし、必要に応じて調整することです。プロジェクトの規模が大きくなると、その負担を軽減するために複数のテストチームが編成され、それぞれのチームがテストリーダーによって率いられることがあります。場合によっては、リーダー役がテスト担当者の中から選ばれることもあります。
テストリーダーの主なタスクは次の通りです。組織のテストポリシーや戦略の作成やレビュー、プロジェクトの背景を考慮したテスト目的やリスクの理解に基づく計画の立案、テスト計画書の作成と更新、プロジェクトマネージャーやプロダクトオーナーとの調整、テストの進行状況の監視と報告、計画の修正やテストコントロールの実施など、多岐にわたります。また、欠陥管理システムの導入支援やテスト環境の構築、適切なメトリクスの導入、ツール選定とその活用支援、テスト担当者のスキルアップやキャリア促進なども重要な業務に含まれます。
さらに、テストマネージャーはプロジェクトで採用するソフトウェア開発ライフサイクルモデルに合わせて役割を調整する必要があります。アジャイル開発の場合、一部のタスクはチーム内で分担され、日々のテスト作業はチームメンバーが担います。一方、大規模な開発組織では、複数のチームにまたがるタスクや組織の人事関連業務は、開発組織外部のテストマネージャーが担当することが多く、そのような役割を担う人物はテストコーチと呼ばれることもあります。
テストコーチは、外部から必要なスキルを持つ人材をアサインする、またはチーム間の調整を行うミーティングを主導するなど、組織全体の連携や効率向上を支援します。このように、テストマネージャーの役割は、プロジェクトの規模や開発手法に応じて柔軟に変化しながら、テストプロセス全体の品質を保証する重要な役割を果たします。
③テスト担当者の役割
テスト分析や設計、テストの自動化、そして特殊なテスト実行（例：セキュリティテストや性能テスト）は、それぞれの分野に熟練した技術者が担当するのが理想です。テストのレベルやソフトウェアの品質リスクに基づいて、専任のテストチーム以外の担当者がテストを実施する場合もあります。例えば、コンポーネントテストや統合テストにおいてホワイトボックステストを実施する際には、内部構造に精通した開発者が担当することが一般的です。また、ユーザー受け入れテストや運用受け入れテストでは、実際の利用者やその環境に詳しいエキスパートが実施することが多く、運用受け入れテストについては、運用担当者やシステムアドミニストレーターが行うことになります。
テスト担当者の主な役割は以下の通りです。
・テスト計画をレビューし、改善に貢献する
・要件、ユーザーストーリー、受け入れ基準、仕様、モデル（テストベース）を分析、レビュー、評価して試験性を高める
・テスト条件を特定し文書化し、テストケース、テスト条件、テストベースの間でトレーサビリティを確立する
・テスト環境を設計し、セットアップと検証を行う（システムアドミニストレーションやネットワークマネジメントと連携することが多い）
・テストケースとテスト手順を設計・実装する
・テストデータを作成・取得する
・詳細なテスト実行スケジュールを立てる
・テストケースを実行し、その結果を評価し、期待通りでない場合は逸脱を記録する
・適切なツールを使用してテストプロセスを効率化する
・必要に応じてテストを自動化する（開発者やテスト自動化専門家の協力が求められることもある）
・性能効率、信頼性、使用性、セキュリティ、互換性、移植性といった非機能的特性を評価する
・他の担当者が作成したテストケースをレビューする
テスト対象の特性によっては、テスト設計や実行に関する知識に加えて、対象システムの知識やビジネスドメインの専門的なスキルが必要になる場合があります。このような場合には、対象の専門知識やドメインスキルを持つエキスパートが担当することがより効果的です。
テストの計画
テスト計画を「納期から逆算したスケジュールを書いたもの」と認識している人がいます。確かにスケジュールはテスト計画の重要な要素ではありますが、それだけでは不十分です。本節では、単に日程を作成するだけでなく、目的を明確にし、多様な制約を考慮することで初めてテスト計画として成り立つことを解説します。
テスト計画は目的に応じて策定されます。主に、プロジェクト全体のテストを対象とするマスターテスト計画と、個別に立てられるテスト計画の2種類に大別されます。個別のテスト計画は、システムテスト計画や受け入れテスト計画のようにテストレベルごとに作成される場合や、性能テスト計画やセキュリティテスト計画のようにテストタイプごとに作成される場合があります。
マスターテスト計画は、複数のテストレベルを統括する計画です。この計画は、独立した文書としてまとめられることもあれば、プロジェクト計画書の一部として記載されることもあります。一方で、個別のテスト計画は、それぞれ独立した文書として作成されるのが一般的です。
テストアイテム
何をテストするのかを記載します。以下のような項目がテストアイテムに該当します。
・システム
・サブシステム
・コンポーネント
・ユニット
・システム間のインターフェース
・サブシステム間のインターフェース
・コンポーネント間のインターフェース
テスト範囲
テストを行うフィーチャーと、実施しないフィーチャーを記載します。テストを実施しないフィーチャーについては、実施しない理由も併せて記載する必要があります。
確認テストおよびリグレッションテスト
確認テストおよびリグレッションテストを実施する条件を記載します。
テスト計画では、確認テストやリグレッションテストがテストサイクルとして扱われる場合があります。また、変更後に実施するリグレッションテストのレベルを定義することもあります。
テスト計画書の内容の進化
テスト計画は一度作成したら終了ではなく、プロジェクトの進行に応じて発展させていくものです。プロジェクトが進むにつれ、テスト計画に反映可能な情報が増え、計画内容がより詳細になります。テスト実行中もリスクの変化を認識し、スケジュールの調整などを行いながら、計画に反映させていきます。
テスト計画はプロダクトのライフサイクル全体を通して継続的に行われる活動です。プロダクトのライフサイクルとは、プロジェクト完了後に保守フェーズへ移行し、最終的に廃棄されるまでを指します。保守フェーズにおいてもテスト計画の活動は継続されます。
テスト計画の考慮事項
テスト計画を策定する際には、様々な要素を考慮する必要があります。例えば、以下のような項目があります。
・組織のテストポリシーおよびテスト戦略
・採用している開発ライフサイクルや手法
・テスト範囲
・テストの目的
・リスク
・制約事項
・重要度と優先度
・テストの容易性
・利用可能なリソース
テスト実施に時間や手間がかかる設計になっているテストアイテムが存在する場合、その分の手間をスケジュールに反映させる必要があります。また、テストアイテム間で実行の重要度や優先度に差がある場合は、それに応じたスケジュールを作成しなければなりません。
テスト計画の活動
テスト計画では、次のような活動を行います。
・テスト範囲を決める
・テスト目的を決める
・リスクを洗い出す
・テストアプローチを検討し、定義する
・次に挙げる事柄を決める
・何をテストするか
・さまざまなテスト活動でどのような人的リソース他のリソースが必要か
・どのようにテスト活動を進めるか
・次に挙げる活動をスケジューリングする
・テスト分析
・テスト設計
・テスト実装
・テスト実行、および終了基準の評価
・テストのモニタリングやコントロールに使用するためのメトリクスを選ぶ
・テストドキュメントに関して、次に挙げる事柄を決める
・テストドキュメントの詳細レベル
・テストドキュメントの種類とそれらの構造
・使用するテンプレートやサンプルドキュメント
・テスト活動の予算を決める
・ソフトウェアライフサイクル
※確認テスト：