aretan.jp

利害関係者のコミットメント¶

利害関係者のコミットメントと積極的な関与は、効率的なコミュニケーションや協力関係を作るための大事な条件となる。

コントロールレベル¶

• 利害関係責任者を決定し(必ずしも文書化の必要はない)、テスト担当者に周知している。
• テストリソースに対する予算は、利害関係責任者が認めるものであり、交渉も可能である。
• 利害関係者は、コミットしたリソースを実際に手配している。
• 利害関係責任者は、文書化されたプロダクトリスク分析(テスト戦略のインプット)に対する責任を持つ。

効率化レベル¶

• 関連するすべての利害関係者を定義して(必ずしも文書化の必要はない)、テスト担当者に周知している。
• 利害関係者は、積極的にテストプロセスやテスト対象の品質に関する情報を入手している。
• 利害関係者は、テストプロセスに影響を与える側面について積極的に行動を起こしている。これには、テスト対象のテスト作業へのリリース順序やプロジェクトスコープの変更が含まれる。

最適化レベル¶

• テストプロセスを改善するときは、提供するリソースへの学習時間の増加が伴うことをライン管理者層が認識している。
• 利害関係者は、ソフトウェア開発や要件管理といった仕事の進め方をテストプロセスに合うよう適応させる意識がある。
• 利害関係者による仕事の進め方をテストプロセスの要求に適用させる方法は、テスト組織と利害関係者の双方によって評価されている。

関与の度合い¶

テスト作業がプロジェクトに深く関与すると、開発当初からプロダクト品質が向上しやすくなり、テスト活動がプロジェクトのクリティカルパス(所要時間が最長の経路)に残ることを避けられる。

コントロールレベル¶

• 最初のテスト活動として、テストの任務、スコープ、取り組み方について、早い段階での利害関係責任者と交渉している。
• テスト活動をプロジェクトのクリティカルパスにしないよう、テスト実行よりも前の早い次期に開始している。
• プロジェクト計画において、テストプロセスとその他のプロセスの依存関係を考慮できるように、テスト担当者が計画に関与している。
• テスト担当者は、プロジェクト全体のプロジェクトリスクの分析と軽減策の立案に関与している。

効率化レベル¶

• テスト担当者は、変更要求やテストベースの変更による影響分析およびリスク分析に積極的に取り組んでいる。
• テスト担当者は、欠陥の影響分析に積極的に取り組んでいる。
• テスト担当者は、テスト対象が記述されているテストベースのテスト容易性をレビューするだけでなく、そのテストベースの最適化に積極的に関与している。

最適化レベル¶

• テストチームがプロジェクトの評価に関与している。テストプロセスから学んだ教訓を貴重なものであると評価して、その後のプロジェクト(の準備)に利用している。
• 該当するすべての開発活動で、テストチームが重要な位置付けであると認め、高く評価している。

テスト戦略¶

テスト戦略とは、工数やリソースをテストプロセスへ最適に割り振るための指針である。

コントロールレベル¶

• 利害関係責任者は、文書化したテスト戦略に合意している。
• テスト戦略は、プロダクトリスク分析に基ずいている。
• テストレベル、テストタイプ、テストカバレッジ、テストの深さは、(組織で画一的ではなく)リスク分析の結果によって異なっている。
• 再テストや回帰テストについて、シンプルな戦略を決定している。

効率化レベル¶

• 関係するすべての利害関係者が、定義された(かつ文書化された)テスト戦略に合意している。
• テストカバレッジにおけるテストレベルやテストタイプの重複やギャップについて、十分に検討されている。
• テスト戦略には適切なテスト設計技法を含めている。

最適化レベル¶

• テスト戦略の作成プロセスを定期的に評価して、必要に応じて将来に向けて順応させている。
• 本番環境で起きたインシデントのメトリクスによって、テスト戦略を評価している。

テスト組織¶

テスト組織は、テストリソース、テスト関連成果物およびテストサービスに関するプロジェクトのニーズを満たす。

コントロールレベル¶

• テストサービスの責任を持つ人(あるいは部署)の所在を人々が認識している。
• テスト組織において、コントロールおよび説明責任の体制がある。
• テストのタスクや責任が定義(および文書化)され、それらは人や組織内の各部署に割り振られている。
• クライアントから見て、テスト組織におけるテスト関連のプロダクトやサービスが明確である。

効率化レベル¶

• テストサービスを提供する異なる人員や部署が、テスト作業について意識合わせを行っている。
• テスト組織は、合意したテストリソースおよびサービスをプロジェクトに提供している。
• テスト組織をどこにどのように位置付けするかについて、熟慮した選択がなされている。
• テストポリシーに則っている。

最適化レベル¶

• テスト組織のプロダクトおよびサービスが定期的に評価されており、費用効果がある場合は、新しいサービスを追加している。
• テスト組織は、テストに貸された任務の成否に関する説明責任を持つ。
• テスト組織のパフォーマンスを、定期的に外部サプライヤあるいは類似するテスト組織と比較している。

コミュニケーション¶

明確なコミュニケーションにより、期待に対して関係者間の共通理解と協力が得られる。

コントロールレベル¶

• 各チームメンバーは、下された決定と内部進捗を把握している。
• テストチームは、関連情報を利害関係者から積極的に収集している。
• テストチームがコミュニケーションで合意して、決定した時点へさかのぼることができる。
• テストチームは利害関係者と共に、進捗、プロダクト品質、リスクについて慎重に検討し、潜在的な遅延があれば、先を見越して警告を出す。

効率化レベル¶

• テストチームは、どの情報をどの利害関係者と共有すべきかを特定できている。
• テストチームは、その他の利害関係者と共に該当する会議に参加している。
• テストチームは、利害関係者と適切な形式でコミュニケーションできるようにさまざまなコミュニケーション手段を用意している。

最適化レベル¶

• テストプロジェクト期間中や終了後に、コミュニケーションの効率に関する実践事例や学んだ教訓を今後に生かすよう評価している。
• 組織は新しいコミュニケーション手段が活用できることを調査し、活用方針を策定している。

報告¶

報告は、利害関係者の意思決定プロセスやテストプロジェクトの状況を把握するための重要な知見を提供する。

コントロールレベル¶

• 報告には、時間とコスト、結果とリスクなどの側面が含まれている。
• 報告の頻度や内容が、意思決定プロセスの利害関係者の基本要求に合致している。
• 報告は書面によって行われている。

効率化レベル¶

• 効率的な意志決定に必要な利害関係者の報告要求を満たすことと、提供するための作業量のバランスが取れている。
• 報告書には、テストプロセスの進捗やプロジェクトリスクを考慮して、テストの傾向と、テストプロジェクトからの推奨事項が含まれている。
• 報告書には、テストのゴールやプロダクトリスクに関して、テストの傾向と、テストプロジェクトからの推奨事項が含まれている。

最適化レベル¶

• 報告は、現状あるいは将来のテストプロセスやSDLCの改善に利用するデータや測定値を提供している。
• ソフトウェアプロセス改善用のデータや測定値をテストプロジェクト終了時にライン組織に渡している。

テストプロセス管理¶

テストプロセス管理は、与えられた時間とコストとリソースの中で、テストに課せられた任務の遂行を最大化する。

コントロールレベル¶

• テスト計画をテストプロジェクトの開始時に作成している。テスト計画には少なくとも、テストの任務、テストスコープ、テスト計画、および役割と責任について記載している。
• テスト計画を利害関係責任者と合意している。
• 各テスト活動を監視しており、必要に応じて計画を調整している。
• テスト計画は関連する利害関係者の合意も得ている。

効率化レベル¶

• (予想される)テスト計画からの逸脱について、利害関係責任者や他の利害関係者と協議している。
• テスト計画の調整を文書に残している。
• テストリードは、人員の(再)配置を任されている。

最適化レベル¶

• テストプロセス管理は、(テスト組織により)内部的に、そして利害関係者により定期的に評価されている。
• 過去のテストプロジェクトから学んだ教訓をテストプロセス管理の改善に利用している。

見積もりと計画¶

見積もりと計画の技法を適切に利用すると、テストプロセスの計画や見積もりが予測可能で信頼のおけるものになる。

コントロールレベル¶

• テスト作業の見積もりには、比率のような単純な技法を用いている。
• テスト活動ごとに、活動期間、必要なリソース、活動期間に作る成果物の指標がある。特定すべき活動は、テストケースの定義、実行、テスト計画、管理がある。
• 各テストフェーズやテスト活動間の依存関係を、テスト計画に記載している。テストフェーズとテスト活動に、ある程度の重複は許容してよい。
• テストの見積もりやテスト計画の作業について、利害関係責任者と協議している。

効率化レベル¶

• できる限り正確であるよう、最低でも2つ以上の見積もり技法を用いている。
• 正式な技法を用いて、テストフェーズやテスト活動の見積もりや計画作業を行っている。
• 見積もりや計画作業を支援するために、メトリクスを用いている。
• テスト計画には、テストベースのテスト容易性レビューとテストプロジェクトの評価を含んでいる。

最適化レベル¶

• テスト計画には、テストウェアの今後の再利用に向けた保守活動が含まれている。
• 見積もりの技法や規律を、組織レベルで保守している。
• 規定された見積もり技法のカギとなる数値やデータが、組織レベルで提供されている。

メトリクス¶

メトリクスを使った定量的な観察は、客観性を与える。

コントロールレベル¶

• テストプロセスでは、テストプロジェクトの見積もりや管理のためにメトリクスを定義して、利用している。
• メトリクスに必要なインプットは統一した形式で記録され、定義されたメトリクスは体系的に保管されている。
• メトリクスに対するインプット(データ)は、正確であり、かつ確認可能である。

効率化レベル¶

• 必須データの収集、分析、価値の評価に必要な工数を、そこから得られる利点に対して測定している。
• メトリクスの収集作業が、テストプロセスの進捗や品質を良くすることと矛盾していない。
• テストプロセスでは、テストプロセスの効率性を測定するためのメトリクスを定義して活用している。
• 分析したメトリクスから導き出された結論について利害関係者と話し合い、結論に基づいて対処している。

最適化レベル¶

• メトリクスが情報ニーズにどのように貢献するかを監視している。
• 情報ニーズの変化に対応して、メトリクスを新しくしたり最適化している。

欠陥管理¶

欠陥管理とは、個人レベルとグループレベルの両方で、根本原因分析やガイドラインを利用して欠陥に対処することである。

コントロールレベル¶

• 欠陥ライフサイクルを(再テストを含めて)定義して、適用している。
• 各欠陥について、固有のID、関連するテストケースID(あてはまる場合)、欠陥報告者、日付、重要度カテゴリ、説明(欠陥再現手順、期待する結果と実際の結果)、欠陥ステータスを記録している。
• 欠陥を処理するために、責任者を決めている。
• 欠陥のアセスメントと解決に関与する人々が、欠陥管理ツールにアクセスできる。

効率化レベル¶

• 欠陥の管理ツールが、欠陥の状態遷移に関する承認フローを遵守させる効力を持っている。
• 欠陥のログを残したり、欠陥の状況を追跡するすべての人々は、同じ欠陥管理ツールを利用しているか、あるいは複数の欠陥管理ツールをシームレスに接続させて利用している。
• 欠陥管理を広範囲なレポートに役立てている。言い換えると、いろいろな方法でレポートを選択したりソートしたりできる。
• 多くの情報を記録して、傾向を特定している。記録する情報とは、欠陥、サブシステム、優先度、プログラムとそのバージョン、テストベースとそのバージョン、根本原因、すべてのステータス移行と問題解決者などである。

最適化レベル¶

• ライン組織やプロジェクト管理から、欠陥管理の一連のガイドラインが提供されており、各テストプロジェクトで利用されている。
• 欠陥管理の責任が、テストプロセスに必要なデータを提供するライン組織あるいはプロジェクト組織にある。
• 欠陥が共通の属性のために分析され、今後の欠陥を予防する観点から提案が出されている。

テストウェア管理¶

テストウェアの管理によって、テストの成果物間や、テストの成果物と関連する設計文書間の一貫性が確保できる。

コントロールレベル¶

• テストベースとテスト対象およびすべてのテストウェアを、名前とバージョンで特定している。
• 各テストケースを、テストベース文書に明白な方法で関連付けている。
• テストチームは、テストウェアの管理下のすべてのアイテムにアクセスできる。
• テストウェア、テストベース、テスト対象の扱い方が明確に規定され、テストチームに伝えられている。

効率化レベル¶

• テストベースとテスト対象およびすべてのテストウェアを、名前とバージョンで参照できる。
• テストケースと要件のトレーサビリティが確保されている。
• テストウェア管理は、論理的な保管構造と、役割および権限の構造によって支えられている。

最適化レベル¶

• テストプロジェクト終了後にどのテストウェアを保持するかをテストプロジェクト開始時に合意し、テストプロジェクト実施中に見直している。
• 再利用に備えたテストウェア保持に関するガイドラインが入手可能な状態にあり、テストウェアの再利用を測定している。
• プロジェクト終了時に保守に引き渡すテストウェアが、保守されないテストウェアと用意に分離できる。

手法の実践¶

明文化したテスト手法は、テストプロジェクトの方向を定めるための支援となる。

コントロールレベル¶

• テストプロセスは、明文化されたテスト手法に従っている。テスト手法には、一連のテスト活動、テストプロジェクトの成果となるテストプロダクト、作業の途中で発生する追加要求について記述している。
• テスト手法は、プロジェクトが用いている開発手法に適合している。
• テストプロジェクトにとって、実装したテスト手法が実用的なものであると認識されている。

効率化レベル¶

• テスト手法には、うべてのテスト活動に関するゴールと役割、および用いるべき技法と事前条件が明文化されている。
• 完全かつ包括的なテンプレートの一式が、テスト手法の一環として提供されている。
• テスト手法の各要素について、必須/条件付き/任意のいずれかが記録されている。
• 必須と条件付きの要素について、実践事例がある。

最適化レベル¶

• テストチームは、テスト手法について組織的にフィードバックしている。
• 実装したテスト手法を継続的に強化し、改善している。

テスト担当者のプロ意識¶

テスト担当者のプロ意識に含まれるものは、期待するレベルのテスト活動に必要となる適切なスキル、力量、自立心、機能、知識である。

コントロールレベル¶

• テスト担当者は、テストに特化したトレーニングを受けているか、または体系的なテストを実行した現場経験を積んでいる。
• テスト担当者は、採用したテスト手法に理解があり、実際に使っている。
• テストチームは、必要となる業界知識、ビジネス知識、技術知識などの専門知識を有している。
• 従業員の業務評価では、テスト担当者の特定のテストスキルや一般的なIT能力について定期的に評価している。

効率化レベル¶

• テスト担当者がテストの資格を持っている(TMap NEXT, ISTQBなど)。
• テスト担当者が、なぜその技法を選択したのか論理的根拠を説明できる。
• テストに関わる要因は、プロジェクトの他のスキルグループと良好な関係を築き、自信の仕事を楽しんでいる。
• テストのタスクが期待どおりに定義され、割り振られ、実行されている。

最適化レベル¶

• テスト担当者は、SIGやテストセミナーに積極的に参加したり、論文を読むなどして、スキルを保つための最新の情報を常に取り入れている。
• テストの職務が、組織の人事管理、もしくは個人のキャリア開発の一部になっている。
• テスト担当者は、テストの仕事に対する責務と説明責任を持ち、プロセスの継続的改善に努めている。

テストケース設計¶

テストケース設計とは、テスト戦略に沿って欠陥が検出できるようにテスト実行を導くものである。

コントロールレベル¶

• テストケースを論理レベルで記録している。
• テストケースには「開始時の状況」「変更プロセス=実施するテストアクション」「予測される結果」の説明事項を含む。
• テストケースにシステムの詳細な振る舞いを記述することで、テストベースのどの箇所がテストの対象であるかが把握できる。

効率化レベル¶

• テストケースは、テスト組織の同僚が見ても理解でき、保守できるものになっている。
• テストケースによって達成できるテストベースのカバレッジレベルが明確である。
• テストケース設計に正式なテスト設計技法を用いている。
• テストケースが設計できないような品質特性のテスト作業には、チェックリストを用いている。

最適化レベル¶

• 次のフェーズ(次のテストレベルや本番)で発生した欠陥を分析し、テストケースの正確性や有効性の向上につなげている。
• テストケースそれぞれの妥当性と保守性についてチェックし、評価している。
• テスト設計技法を、将来さらに再利用るために評価し、調整をしている。

テストツール¶

テストツールは、特定のテスト活動を加速させる。

コントロールレベル¶

• テスト活動を進めるため、またはテストゴールを達成るために必要なテストツールが利用可能であり、テストチームは実際にそれらを利用している。
• 利用しているテストツールに関するノウハウがいつでも入手できる。
• 購入部門を含めた全員が、有益なテストツールを検討している。

効率化レベル¶

• 現状で利用しているテストツールは、テスト作業をより速く、より低コストで、より良いものにし、テストプロセスを現場でより扱いやすくするために採用されている。
• テストツールは、テスト担当者が必要だと思ったときにいつでも使える。
• テストプロセスで導入された各テストツールに対して、ビジネスケースを作成している。
• これらのテストツールの利用が、テストプロセスに組込まれている。

最適化レベル¶

• ツールポリシーを策定し、既存のテストポリシーとの同期を保っている。
• 専門知識、実践事例、テストツールプロダクトを収集し、今後のプロジェクトのために公開している。
• テストツールの実装とテストツールポリシー実装に関してビジネスケースに記載されたゴール達成について、テストツールを定期的に評価している。

テスト環境¶

テスト環境は、各テストレベルのゴールを念頭において明確に設計し、実装および保守をする。

コントロールレベル¶

• テスト環境に対する要件を文書化している。
• テスト環境を提供する部署との作業合意を得ている。合意に、タスクや責任を盛り込んでいる。
• 期限までに、テストチームがテスト環境を利用できる状態になっている。
• テスト環境に対する変更が計画される場合、テスト管理者は随時連絡を受けている。

効率化レベル¶

• テスト環境は、事前に作成したチェックリストを用いて検収している。
• テスト環境の論理設計と機能設計をしている。その中で、アプリケーション、システム、コネクション、スタブやドライバ(モックアップ)の利用について明記している。
• テスト環境の提供部署は、テスト管理者やテスト環境の専門家から正式に検収を受けたテスト環境の技術設計を納品している。
• テスト環境の提供部署との合意に、SLAの特性が含まれている。

最適化レベル¶

• テスト環境の所有権を持つ部署が明確に定められている。
• テスト環境の利用に関して標準契約に定めている。
• テスト環境が対象範囲内か範囲外かに関して、サービスカタログに記載している。

出典¶

TPI NEXT® ビジネス主導のテストプロセス改善