目的
  • ソフトウェアの品質に重大な影響を持つ障害の解決法を識別し、提案する。
  • ソフトウェアの品質を必要レベルにまで改善する変更が確実に完了されるように、その進捗を監視、サポートする。
  • テスト作業を妨害する、またはテスト作業の効果を損なう障害に対するタイムリーな解決法を提案する。
役割:  テスト管理者 
頻度: 通常この作業は、反復ごとに複数回行われます。 . 
手順
入力とする成果物:     結果となる成果物:   
ツール・メンター:   
More Information: 

ワークフローの詳細:   

テスト評価の最新のまとめの検査 ページの先頭へ

目的:  テスト・チームがこれまでに識別した製品品質の問題に関する、最新の評価のまとめを理解する。  

テスト チームが作成したテスト評価のまとめを検査することから始めます。評価情報を反復のテスト計画と比較して、計画された作業のコンテキストでまとめを理解します。あいまいさや懸念事項がある場合は、まとめを作成したテスト チームのメンバーに対して指摘し、解決します。

情報を収集し、ソフトウェアの品質を評価するこれ以降のステップでは、客観的な基準と主観的な基準の両方を取り入れて、バランスの取れた評価を行うようにします。客観的な数値は全体図の一部だけを表すものであり、プロジェクトの現在の「環境」によって補強、説明する必要があることを忘れないでください。逆に、ソフトウェアの品質に関するうわさや主観的な憶測だけに頼ることも避けなければなりません。 チーム・リーダーか、可能であれば個々のチーム・メンバーと話し合い、客観的なデータを補強することをお勧めします。これによって、主観的な評価を取り入れると共に、客観的なデータに対する確信度を判断できます。

選択したテスト結果の別のコンテキストでの検査 ページの先頭へ

目的:  製品の品質に関する評価の最新のまとめを補強するテスト結果をさらに深く理解する。  

テスト評価のまとめに基づいて、選択したテスト結果を別のコンテキストで検査します。テスト評価のまとめで識別された重要な問題を十分に理解したと思えるようになるまで、テスト結果を調べます。

また、自分でデータをレビューし、テスト結果のデータで重要な傾向の見落としがないかどうか探します。一般的に、絶対的な数値を見ることよりも、データに表れている相対的な傾向が意味することを理解することのほうが重要です。ある領域の障害が別の領域の障害にも関係しているなど、データに示されていることを探します。

主要な変更依頼の検査 ページの先頭へ

目的:  最も重要な未解決問題とその解決法について効果的に協議できるようにするための基盤を確立する。  

この作業は、最も差し迫った問題と、それに関連する変更依頼についてだけ行うことをお勧めします。それによって、より数の少ない問題に労力を注ぐことができます。数の少ない問題のほうが、多くの場合、製品の品質に大きな影響を及ぼす場合があります。主要な問題が数多くある場合は、その相対的な優先順位に基づいて、適切な労力を割り当てることをお勧めします。重要度の最も低い問題に注力してリソースを浪費しないようにしてください。ただし、優先順位の低い未解決の変更依頼が数多くある場合は、優先順位の高い少数の変更と同じ程度に、製品の品質に関する重要な記述になります。優先度の低い変更依頼を、それらが示す品質リスクに基づいて、品質の論理的なグループに分けるようにします。これによって、品質に関して行う作業の組み合わせをより明確に定義し、提案できます。

一般的な変更依頼データに見られる重要な傾向を識別します。一般的に、絶対的な数値を見ることよりも、データに表れている相対的な傾向が意味することを理解することのほうが重要です。障害解決率が着実に向上しているなどの好ましい兆候や、長いスパンで見たときには緩やかな上昇の後に下降しているなどといった傾向を見るようにします。解決率の急激な山と谷には特に注意します。山と谷は、生産性を低下させるようなプロセス上、環境上、政治上、その他の問題に開発チームが直面していることを示している場合があります。

メモ: 関連する変更依頼の明瞭さを改善するための機会を設けることもお勧めします。これによって、あいまいさや、感情的な言語と思考を排除します。変更を自分で行った場合は、改善した点について成果物の作成者と話し合い、改善が大切である理由について理解が得られるようにします。

品質のギャップの特定と、それに関連する影響とリスクの評価 ページの先頭へ

目的:  製品の品質に対するリスクと、ソフトウェア開発プロジェクトの成功に対する関連リスクの観点から見た、主要な問題に関する理解を定型化する。  

品質のギャップを特定し、ギャップの原因である各問題に関連する影響とリスクを評価します。リスクの軽減策と緊急時対策を検討し、これらについての初期のアイデアを定型化して、その他のチーム メンバーと協議します。

「完璧な」品質は、間違いなく机上の概念であることを頭に入れてください。 品質を評価し、品質のギャップを特定するときは、現実的で実現可能な「品質基準」を使用するように注意します。 ../workflow/test/co_rqlty.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません概念: 製品の品質を参照してください。

品質のギャップに対処するための必須アクションの識別 ページの先頭へ

目的:  主要な問題を満足のいくように解決するために最低限必要な、現実的なアクションを定義する。  

品質の主要なギャップごとに、軽減策と緊急時対策を検討します。これらの策について初期のアイデアを定型化し、その他のチーム メンバーと非形式的に話し合うことによって、アイデアの理解を深め、検証します。解決法の場合は、オプションを用意することをお勧めします。トレードオフを比較して、特定のコンテキストについて最良の解決法を選択できるからです。

プロジェクト チームが品質の各ギャップに適切に対処できるような、解決法と提案の有効な候補セットの作成に向けて作業します。この作業は、テスト作業が、問題のレポートだけでなく、問題の解決にも貢献していると認識されるようにするために重要です。テスト チームの存在意義を主張し、その他のチーム メンバーから尊敬と協調を獲得する意味で重要です。

主要問題の擁護者の識別と連携 ページの先頭へ

目的:  主要問題を解決するためのサポートを非形式的な方法で獲得し、どのような提案がより受け入れられるかについて理解を得る。  

認めてもらえなかった主張を推し進めることにはやりがいもあります。プロジェクト チームの対応が遅れ、後になって認識し、最終的に本格的に取り組む可能性の高い問題の解決法を決定するには、認めてもらえなかった主張を推し進めるほうが、一般的により効果的です。主な意思決定者と緊密な関係を保ち、これらの主要問題を 1 対 1 の話し合いを通じて非形式的な扱いにすることから始めることを検討します。この方法は、多くの場合、サポートを獲得し、実現可能な解決法を見つけるための有効な方法です。

ときには、開発チーム内で評判の悪い解決法を支持する以外に選択肢がないこともあります。このような状況になりそうな場合は、開発チーム内の誰からサポートを期待できるかを判断し、できる限り価値が明確にわかる解決法をアピールしたり、問題を解決しないことによって発生するさらに悪い状況について明確に説明したりする方法を考えることのほうがもっと重要です。

作業優先順位の検討 ページの先頭へ

目的:  必要な品質に悪影響をもたらすことのない妥当な時間枠の中で実行する適切な解決法を提案する。 

この作業は品質提案の最重要部分です。開発チームの賛同を獲得すると同時に、製品の品質を十分に確保する最適な解決法を検討できるからです。多くの場合、テスト チームは基本的に品質に関するアドバイザーであることを忘れないでください。したがって、特定の解決法を強制しないように注意する必要があります。

ただし、テスト チームが品質の提案者として良い働きをすることも大切です。これには、プロジェクト チームが知りたくないような内容の知らせを伝える役目を担うことも含まれます。優れたテスト チームが、問題や潜在的な解決法に関してできる限りの洞察を行い、各選択肢のトレードオフに関するできる限りの理解を開発作業で活かすことができるのが、この部分です。ある程度は製品の最終顧客の代理人として機能し、顧客にとって最大の利益になる解決法を検討できるようにする必要があります。

作業進捗の監視 ページの先頭へ

目的:  問題の解決を支援し、積極的に関与し、その進捗を監視すること。  

障害とその他の変更依頼は、進行中の基本的な製品開発と機能拡張の流れの中で見失われてしまうことがあります。 その理由として、古くて異常なコードを修正するよりは、「新しいもの」について作業するほうが開発者にとって魅力があることや、ビジネスの価値は、壊れたものを直すことより、何か新しいものを追加することのほうに重きが置かれることが挙げられます。 テスト・チームは、品質の提案者として、プロジェクトが重要な障害修正を経て、完了に達することができるようにする必要があります。

優れたソフトウェア・チームは、障害解決を通じた段階的な品質改善と、段階的な機能拡張のバランスを取ることができます。 テスト・チームは、それほど有効ではなく、逆効果になりかねない「品質監視者」の役割を演じるのではなく、段階的な品質改善を促進、支援するような方法を模索することによって、プロジェクト・チームをサポートできます。

主要問題の適切な解決法の確認 ページの先頭へ

目的:  主要問題の解決法によって、重大な副作用を引き起こすことなく、問題が効果的に解決されることを確認する。  

品質の問題を解決するために開発チームがどのような方法を選択する場合であれ、その解決によって最終的な品質が改善される必要があります。特定の解決法によってもたらされる品質の改善を時間をかけて評価し、元の問題が対処されることと、別の点で品質に悪影響がでないことを確認します。

それ自体に何らかのリスクが含まれる解決法の場合は、最終的な解決のために本格的に時間と労力を費やす前に、初期リリース候補でテストを行うと効果的である場合があります。

結果の評価と検証 ページの先頭へ

目的:  作業が適切に完了していること、結果の成果物が許容できるものであることを確認します。  

作業が完了したら、その作業に十分な価値があったかどうか、単に大量の紙を浪費しただけに終わっていないかどうかを確認しておくことも有益です。 作業成果の質が適正であるかどうかや、その成果がほかのチーム メンバーが今後の作業に対する入力として使用するのに十分有用であるかなどを評価する必要があります。 可能であれば、RUP のチェックリストを使用して、品質と完成度が「十分」であることを確認します。

この作業を入力として使用する下流の作業を担当する人々に、作業の中間レビューに参加してもらいます。これは、それらの担当者からの意見に対処する時間的余裕がある間に行います。 また、主要な入力成果物に照らし合わせて作業を評価し、それらが正確かつ十分に表現されているかどうかを確認する必要もあります。入力成果物の作成者にその観点から作業をレビューしてもらうのも有効です。

RUP が反復的なプロセスであり、成果物は多くの場合、時間の経過と共に発展していくということを忘れないようにしてください。したがって、直後の作業で部分的にしか使用されなかったりまったく使用されなかったりするような成果物を完全に仕上げるのは、一般に不必要なことであり、しばしば非生産的でさえあります。というのも、成果物が使用される前にその成果物を囲む状況が変化する (その結果、成果物が作成されたときの仮定が間違っていたことが明らかになる) 可能性が高く、その場合、すべての努力が無駄になり、再作業のコストが発生するからです。また、プレゼンテーションを何度も繰り返すと、かえって内容の価値を損なう危険があるため、この点にも注意が必要です。プレゼンテーションにプロジェクトの納品可能物として高い重要性と経済的価値があるプロジェクト環境では、管理要員にプレゼンテーション・タスクを実行させることも検討の対象になります。



Rational Unified Process   2003.06.15