目次


テスト管理のベスト・プラクティス

ソフトウェア・テスト作業をよりよく行うために

Comments

後編「テスト管理のベスト・プラクティス」

テスト管理に関するアドバイス

以下はソフトウェア・テスト管理を向上させるための一般的なアドバイスです。

早い段階でテスト管理活動を開始する

これは言うまでもないアドバイスのように思われるかもしれませんが、この概念を本当に実行しているソフトウェア・プロジェクトはほとんどないのが実状です。必要なテスト資源を早い段階で確認するのは簡単で特に珍しいことではありませんが、テスト分析活動の多く (重要な優先度の高いテスト・ケースの識別など) も早期に開始できることであり、可能な限りそうすべきです。イベント・フローを得るのに十分なユースケースが早期に作成されれば、そこからテスト手順を引き出すことができます。プロジェクトでユースケースの要件を使用しない場合でも、初期の要件の検証からテストを引き出すことが可能です。テストをできる限り早期に作成することは、このあと必ず生じる時間の制約を軽減するのに役立ちます。

反復的にテストする

ソフトウェア・テストは、プロジェクト・ライフ・サイクル全体の早い段階から有用なテスト成果物や結果を生み出す、反復的なプロセスであるべきです。これはテスト・プロセスを早期に開始するという最初のアドバイスに沿ったものです。反復的なテスト・プロセスを採用すれば、早い段階でテスト管理に注目せざるを得なくなります。テスト管理では、反復のさまざまな成果物や資源を整理することによって、このプロセスをガイドします。このようなリスクをベースにしたアプローチによって、プロジェクトのスケジュールに起こりそうな変更、遅延、その他の予期しない障害を最も効果的な方法で処理できます。

テスト成果物を再利用する

1 つのプロジェクト内、または複数プロジェクト全体のテスト成果物を再使用することにより、テスト・チームの効率を大幅に向上させることができます。これにより、時間の制約や資源の制約による圧力が大幅に緩和されます。再利用可能な成果物には、テスト自動化オブジェクトだけでなく、テスト手順やその他の計画情報も含まれます。成果物を効果的に再利用するために、テスト管理では、特定のプロジェクトに使用されるさまざまなテスト関連情報をうまく整理し、記述しなければなりません。再利用するためには、必ず成果物の生成時に事前の考慮が必要です。これはテスト管理全般に当てはまる原則です。

要件ベースのテストを使用する

テストは 2 つの一般的なアプローチに分類することができます。

  • 何かが期待どおりに動作するかどうかを検証する
  • 何かを壊す原因となるものを突き止める

後者の調査的なテストは、予測困難なシナリオやエラーを引き起こす状況を発見するために重要ですが、基本的な要件の検証は、おそらくテスト・チームが実行する最も重要な査定であるといえます。 要件ベースのテストは、アプリケーションやシステムの主な検証方法で、従来の要件とユースケースの要件の両方に適用されます。要件ベースのテストはどちらかといえば調査的なテストよりも客観的で、さらにそれ以外の利点もあります。ソフトウェア開発チームの他の担当者は、調査的なテストの結果を疑問視したり、場合によっては非難することもありますが、要件を直接検証するために入念に作成されたテストには、異議を唱えることができません。もう 1 つの利点は、必要なテスト作業の計算が容易になることです (残り時間しか使用できない調査的なテストとは対照的です)。 また、要件ベースのテストは、テスト・カバレッジなど、有用な品質メトリックスとして使用できるさまざまな統計を提供することができます。要件からテスト・ケースを引き出す作業、そしてさらに重要なことには、変更の発生時にそれらの関係を追跡する作業は、ツールで対処すべき複雑な作業となる可能性があります。RequisitePro と ClearQuest のテスト管理機能は、このようなニーズに対応する、すぐに使用可能なソリューションです。 このプロセスの制約は、効果を上げるには十分なシステム要件と堅実な要件管理計画が必要であるという点です。一方、調査的なテストは、臨機応変なものになる可能性があります。ソフトウェア開発チームの他の担当者に依存することは少なく、これが場合によっては、要件の検証という重要な作業に重点を置かないテスト作業につながる可能性があります。優れたテスト作業には種々のアプローチが含まれるべきですが、要件ベースのテストをないがしろにするべきではありません。

遠隔地のテスト資源を活用する

資源の不足を軽減したり、とにかく人材を最大限に活用するには、資源の存在する場所に関係なく、可能な限りあらゆる資源を活用するべきです。最近では、資源は複数の地理的場所の存在する可能性が高く、海外に存在することも多くあります。ただし、遠く離れたテスターとテスト管理に参加するその他の担当者を最大限に活用するには、注意深く効果的な調整が必要となります。これを効率的に行うには多くの技術的課題が存在する可能性があるため、適切なツールを使用することが必要です。ClearQuest MultiSite のテスト管理機能は、地理的に分散したテスト調整の複雑さをシンプル化するためのツールです。 Web クライアントやデータの自動複製機能を使用する必要性について考えてみましょう。この 2 つは遠隔地の担当者とのコラボレーションを可能にするソリューションです。前者は単純で比較的容易ですが、特に世界中からアクセスする場合は、ネットワーク遅延の制約が生じる可能性があります。ユーザーの数や機能を限定したリモート・アクセスであれば、これは優れたソリューションです。ただし、異なる場所の多数の担当者が全体的な仮想テスト・チームを構成する状況では、仕事のスピードを最大化するために、ローカルのサーバーにデータをコピーする必要があります。この場合、各場所のデータを自動的に同期させるための、容易でシームレスな方法も必要となります。ClearQuest MultiSite がテスト管理に不可欠である理由はここにあります。

柔軟なテスト・プロセスを定義・実施する

優れた反復可能なプロセスは、プロジェクトの現在の状況を理解するのに役立ちます。また、予測が可能になることにより、目標を定めやすくなります。しかし、プロジェクトが異なればテスト作業の具体的なニーズも異なるため、ワークフローを自動化するテスト管理プロセスは、柔軟でカスタマイズ可能であることが必要です。プロセスは反復可能であるべきですが (予測可能性を提供するため)、さらに重要なことは、改善を可能にしておくという点です。プロセスは、変化するニーズを応じて最適化できるように、反復型プロジェクトの期間中の調整を含めて、簡単に手直しできなければなりません。 ワークフローによってプロセスを定義してチーム・メンバーをガイドしても、そのプロセスが実行不可能であるならば意味がありません。プロセスをどの程度強力に実行する必要があるかは、組織やプロジェクトによって異なります。現在では多くの組織のソフトウェア・プロジェクトが、SOX や HIPPA などのさまざまな規制を順守する必要に迫られています。一部には、変更、プロジェクト履歴、その他、たとえば電子署名などの厳格なコンプライアンス検証の監査能力を必要とする組織もあります。プロジェクトのテスト管理において厳格なプロセスを実施する必要があるのか、簡単な方法でよいのかに関わらず、何らかのプロセスを定義・実施するための仕組みが必要となります。このような機能をすべて提供するテスト管理ツールの1つが、ClearQuest のテスト管理機能です。

開発の他の部分と調整・統合する

ソフトウェア・テストは、伝統的に開発の他の部分から大きく切り離されてきました。これは一部には、査定を公正に保ち、開発で見逃された欠陥の発見率を高めるという妥当なニーズのためです。このニーズは特に、設計や実装の要素が見えない人がテスターとして適切である受け入れテストにおいて非常に重要です。しかし、この特定のニーズはソフトウェア・テストの多くの側面の 1 つを表しているに過ぎません。ソフトウェア・テストでは、結局はそうなっている場合が多いのですが、高品質なソフトウェア開発に対する障壁や障害物を作り出すべきではありません。 ソフトウェア・テストは、ソフトウェア開発の他の部分、特に要件管理や変更管理などの規律と統合されるべきです。これには、異なるプロセスのロールや活動間の活発なコラボレーション、重要情報のスムーズな伝達、さらにはこれをサポートする統合ツールが含まれます。このような調整が十分でないと、要件の見逃しや誤解、コードのテスト漏れ、欠陥の見逃し、実際のソフトウェア品質レベルに関する情報の不足によって品質が低下する事態が生じることになります。

状況を伝達する

作業は、その価値が認識されなければ役に立ちません。それがどのように認識されるかは、ステークホルダーに何が伝えられるかによって左右されます。したがって、テスト管理では、関連するすべての情報について包括的かつ適切なレポートを提供しなければなりません。ソフトウェア開発プロジェクトに関与するすべてのチーム・メンバーに対して、継続的なリアルタイムの状況、目標の測定、および結果を、すべて適切な形式で利用できるようにすることが必要です。 また、レポートは従来の単なる静的な文書ではないものにすべきです。常に変更が発生する状況を考えれば、さまざまな形式で容易に更新できるアウトプットを用意して、情報を正しく伝達することが必要です。これによって、プロジェクトのさまざまなロールが、プロジェクトが進行するにつれ必要になる変更に対応する方法を的確に判断できます。 異なるソフトウェア規律からの情報にはまったく相互関係がないということはありません。この記事では、テスト管理や要件・変更・構成管理などのその他の規律と開発の間に重要な関係があることをすでに述べました。したがって、テスト管理からのアウトプットと他のプロジェクト・データを容易に組み合わせられることが必要不可欠です。最新の技術では、すべてのプロジェクト・メトリックスを 1 つのダッシュボードに集約した統合ビューによって、プロジェクトの全体的な状況を確認することが可能になっています。また、テスト、開発、およびその他のプロジェクト成果物間の関係を明確に表示・査定できるツールも提供されています。

目標と結果に重点を置く

プロジェクトの品質目標と、それらを効果的かつ正確に測定する方法を決定する必要があります。テスト管理では、目標、その目標の測定に使用されるメトリックス、関連データの収集方法が定義されます。多くのテスト作業には、明白な完了基準が設定されていない場合があります。継続的な進捗や変更のアウトプットや指標を具体的に定義することによって、テストの活動や作業をより正確に定義できます。テストの具体的な目標とメトリックスを念頭に置くことにより、状況や結果が追跡できやすくなるばかりでなく、終了直前に慌てて必要なレポートをかき集める状況を回避できます。 テスト管理の結果を 1 つの共通リポジトリーまたはデータベースに保存しておくことで、それらの分析や使用が容易になります。また、成果物 (結果を含む) のバージョン管理を促進し、古い情報や無効な情報による問題を回避できます。これらはすべて、プロジェクトのメンバーが進捗を把握し、テスト作業の結果に基づいて決定を下すのに役立ちます。

自動化して時間を節約する

テスト管理にはさまざまな項目があり、その多くが非常に時間のかかる作業です。時間を節約するために、ツールを使用して多くの作業の全体を自動化するか、少なくとも一部を自動化することができます。ワード・プロセッサーやスプレッドシートのような簡単なツールでも大きな柔軟性が得られますが、専用のテスト自動化ツールでは対象が絞られるため、時間節約のメリットも大きくなります。自動化によって大きなメリットが得られる作業は次のとおりです。

  • テストと、要件やその他のテストのモチベーターとの関係の追跡
  • テスト・ケースの整理と再利用
  • テスト構成の文書化と整理
  • 複数のビルドとアプリケーションにわたるテストの実行の計画と調整
  • テスト・カバレッジの把握
  • さまざまなレポート作業

テスト管理に適切なツールを使用し、適切な作業を自動化することは、テストの価値と利点の大幅な向上につながります。

まとめ

ソフトウェア品質を向上させる重要なステップは、テスト管理のプラクティスを旧式の文書ベースの手法から進歩させることです。テスト管理には、テストの計画、作成、実行、レポートなどのさまざまな機能が含まれるだけでなく、ソフトウェア開発作業の他の部分とどのように調和させ、統合するかという問題も関与します。テスト管理には、時間や資源の不足、離れた場所に位置するテスト・チーム、テストをその他の要件や開発と結びつける上での問題、適切な情報のレポートなど、避けがたい困難な課題が数多く存在します。 好材料は、このような課題への対処に役立つ多くのベスト・プラクティスが存在することです。テスト活動を早期に開始し反復的に実施すること、目標と結果に重点を置くこと、開発の他の作業と調整・統合することを実践することにより、テスト作業をソフトウェアの補足作業にするのを避けることができます。テスト成果物の再利用の促進、遠隔地のテスト資源の活用、柔軟なテスト・プロセスの定義と実施、および自動化はすべて、資源の制約を克服するのに役立つプラクティスです。 これらのプラクティスを実装できるツールの 1 つに、ClearQuest のテスト管理機能があります。これは、例えば ClearQuest MultiSite による海外チームとの協業など、具体的な多くの技術ニーズに直接対応できるツールです。このツールはまた、どのようなプロジェクトや組織のニーズに対しても適切なテスト管理ソリューションを構築できる柔軟なフレームワークを提供します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=311676
ArticleTitle=テスト管理のベスト・プラクティス
publish-date=11072006