ヒャッハー!ふっくら太郎です。

ソフトウェアテストやその他諸々について、適当に書いています。

JSTQB Advanced Level シラバス(テストマネージャー)を読む その5.テストマネジメント編①

こんちは。パスポートサイズのふっくら太郎です。 

 

2017年8月26日(土曜)に実施されるJSTQB AdvancedLevel試験 テストマネージャー受験に向け、短期集中で、JSTQB Advanced Level シラバス(テストマネージャー)についての記事を上げていきたいと思います。

今回は、「テストマネージメント」の「2.2 状況に応じたテストマネジメント」を読み解きたいと思います。 (「2.1 イントロダクション」は特に記載事項なし)

[JSTQB AdvancedLevel テストマネージャー シラバス]

・ISTQBテスト技術者資格制度
 Advanced Level シラバス 日本語版 テストマネージャ Version2012.J03

http://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J03.pdf

 

 

2.1 イントロダクション

特にナッシング!

2.2 状況に応じたテストマネジメント

  • テストマネージャの職務は、テストプロセスを計画・コントロールして、深刻な故障を防ぎ、プロジェクト成功に貢献すること。
  • テストプロセスの計画・コントロールは、プロダクトライフサイクル、開発成果物に合わせて、適切な活動と成果物を含むテストプロセスを準備して、活動期間を通じてコントロールすること。

2.2.1 テストステークホルダについて

  • テスト活動、テスト成果物、または最終のテスト対象、成果物の品質に関心を持ち、直接的、または間接的に影響を与える人々。

   主なテストステークホルダと役割

   ・開発者(開発リーダ、開発マネージャ、システムアーキテクト、データベース

    設計者など)

    →欠陥の修正など、テスト結果に対して何かしら対応を行う人。

   ・マーケティングアナリスト、ビジネスアナリスト、上級管理職(プロジェクトマ

    ネージャなど)、プロジェクトスポンサ

    →テストカバレッジの定義、テスト結果のレビュー、結果に対する意思決定

     を行い、ソフトウェアに必要な品質レベルを決定する人。

   ・プロジェクトマネージャ

    →プロジェクトを成功に導くための管理を行う人。

   ・テクニカルサポート、顧客サポート、およびヘルプデスクのスタッフ。

    →ユーザと顧客をサポートを行い、リリースしたソフトウェアに問題があれ

     ば、故障の情報を提供してくれる人。

   ・直接的、関節的ユーザ

    →ソフトウェアを使用する。または、ソフトウェアが提供するサービスを利用

     する人。

  • テストマネージャは、以下について理解する必要がある。これを怠ると、テストプロセスの有効性と効率性が最適化できない場合がある。

   ・ステークホルダとテストの関係、ステークホルダのニーズ。

   ・ソフトウェア開発ライフサイクル活動と成果物。

2.2.2 その他のソフトウェア開発ライフサイクル活動と成果物

  • ソフトウェアテストは、ソフトウェア開発ライフサイクルの中で行う活動のため、開発者と協力し、開発成果物の品質を高めて行かなければならない。
  • ソフトウェア開発ライフサイクルに対して、テストマネージャ次の活動を行う。

   ・要求エンジニアリングおよび要求管理。

    →テストマネージャは要件変更を認識し、変更した内容に合わせて、テストを

     対応させる。

   ・プロジェクトマネージメント

    →テストマネージャは、テストアナリストと協力し、スケジュール要件とリソ

     ース要件をプロジェクトマネージャに伝える。

   ・構成管理、リソース管理、および変更管理。

    →テストマネージャは、テストチームと協力して、テスト対象の構成管理、バ

     ージョン管理を行うための運用方法を検討、実行する。

   ・ソフトウェア開発と保守。

    →テストマネージャは、開発マネージャと協力して、欠陥マネージメントに参

     加し、各テストのリリース計画を調整する。

   ・テクニカルサポート。

    →テストマネージャはテクニカルサポートマネージャと協力して、テスト終了

     作業時にテスト結果を提供する。また、テストプロセス改善のため、運用時

     に発生した故障(市場問題、品質苦情)を分析する。

   ・テストマネージャは、技術ドキュメントマネージャと協力し、テストに必要な

    技術ドキュメントを提供する。また、ドキュメントに記載された欠陥のマネー

    ジメントを行う。

2.2.3 テスト活動とその他のライフサイクル活動の連携

  • ソフトウェアテストは、使用される開発モデルに関係なく不可欠な要素である。主な開発モデルとそれに伴うテストプロセスの関係は次の通り。

   ・シーケンシャルモデル (ウォータフォールモデル、V モデル、W モデルなど)

               →所定の工程で予定している活動、成果物の作成が完了してから、次工程の作

     業に移行する開発モデル。テスト設計、実装は、関連する開発工程と連動し

     て行う。詳細は過去記事参照。

 

gokushiteki-softtest.hatenablog.com

 

   ・ラピッドアプリケーション開発(RAD)、ラショナル統一プロセス(RUP)な

    どのイテレーティブモデルまたはインクリメンタルモデル。

    →各開発モデルの概要は過去記事参照。テストについては、プロジェクト開始

     時に上位レベルのテスト計画と分析を、プロジェクト計画とビジネス分析、

     または要求分析を行い並列で実行する。

     詳細なテスト計画、分析、設計、実装については、各イテレーション開始時

     に重複して行う。各テストレベルはできるだけ早期に開始し、より上位の後

     続するテストレベルが開始された後も、継続して行う場合がある。

 

gokushiteki-softtest.hatenablog.com

 

   スクラムエクストリームプログラミング(XP)などのアジャイル

    →2~4週間の間隔で成果物の作成と活動を完了させ、イテレーションを反復

     する。テストはイテレーション内で開発プロセスと重複して実施する。

     アジャイル開発でのテストマネージャの役割は、直接的なマネージメントか

     ら、技術アドバイザとしての役割に変化する。

   ・スパイラルモデル。

    →プロジェクトの早期に、プロトタイプ (試作ソフトウェア)を作成して、実行

     可能性の確認と設計、実装方法を決定する。要素技術開発等で用いられる開

     発モデルで、プロトタイプに対してテストを行い、技術的課題を検出する。

     主な技術課題を解決した後、シーケンシャルモデル、またはイテレーティブ

     モデルに移行する。 

  • テストマネージャは、テストプロセスと開発プロセスを適切に連動させるため、各開発モデルについての理解が必要になる。ISTQBが示すV字モデルのシステムテストに対するテストプロセスは次の通り。

   ・プロジェクト計画と同時にシステムテストの計画を始め、テスト開始から終了

    までテストコントロールする。

   ・システムテスト分析および設計は、要求設計から、外部設計、内部設計までの

    開発プロセスと平行して行う。

   ・システムテストの実装は、単体テスト結合テスト開始と合わせて行われるこ

    とが多く、システムテスト開始直前まで実装が完了しない場合がある。

    また、外部設計時に連動して早期のタイミングで行われることもある。

   ・結合テスト完了後、システムテストを実行する。終了基準を満たすまで継続す

    る。

   ・システムテスト終了基準の評価およびシステムテスト結果のレポートは、シス

    テムテスト実行を通じて行う。

   ・システムテスト終了作業は、システムテスト終了基準に合致し、試験終了後に

    開始する。(場合によっては、受け入れテスト完了後まで遅れることもある)

  • イテレーティブライフサイクルまたはインクリメンタルライフサイクルでは、テストを反復しても実施タイミングで実施範囲が異なる場合がある。
  • イテレーティブライフサイクルまたはインクリメンタルライフサイクルでは、計画変更に伴い予定しているテストプロセスの範囲が変わる場合がある。
  • イテレーティブライフサイクルでは、チームが使用する開発ライフサイクルにテスト実行とレポートが影響される場合がある。(イテレーション完了時にレビューとテストレポートを行う/行わないなど) イテレーションごとにテスト管理の上、問題の把握と改善を行い、次イテレーション時に同様の問題を再発させないことが重要。
  • テストマネージャは、テスト計画やプロジェクト計画において、組織、プロジェクト、および成果物に対する要求に応じて、追加のテストレベルを定義できる。追加するテストレベルについては、既存のテストレベル同様、テストの目的や対象範囲、テストベース、開始・終了基準、成果物、テスト技法など・・・を明確に定義しなければならない。

2.2.4 非機能テストのマネジメント

  • 非機能テストを実施しない場合、リリース後に深刻な品質問題が発生することがあるため、テストマネージャはテストコストを考慮の上、非機能テストを計画、実施しなければならない。
  • 非機能テストは複数あり、全てのテストがテスト対象に対して適しているとは限らない。
  • テストマネージャは非機能テストについて専門知識を持つテクニカルテストアナリストと協力し、必要な非機能テストの選定、計画をしなければならない。
  • 非機能テストの主な考慮事項として、次のような項目がある。

   ・ステークホルダの要件

   ・必要なツールの選定

   ・テスト環境

   ・組織的要因

   ・セキュリティ

  • 非機能に関する重要な欠陥を早期に検出するため、非機能テストはリスクに応じて優先度付けし、他のテストと平行して実施する。
  • プロトタイプを用いる開発モデルの場合、システム設計時に、プロトタイプに対して非機能要件のテストを行うことで、開発中に重要な欠陥の検出が可能になる。
  • イテレーティブライフサイクルでは、仕様変更を考慮したテストフレームワークの構築を考慮しなければならない。単一イテレーションよりテスト設計・実装の活動時間の方が掛かるため、イテレーションから独立して計画・実行することを考慮する。

2.2.5 経験ベースのテストのマネジメント

  • 経験ベースのテストは、他のテスト技法では見逃す欠陥の検出や、他の技法の完全性のチェックに効果をもたらす。
  • 経験ベースのテスト (特に探索型テスト)を用いた場合、記述式テストと異なり、テストケースが無いため、エビデンスの記録と目標とするカバレッジの決定が困難になる。テストマネージャはこれら課題について注意が必要。
  • 経験ベースのテスト (特に探索型テスト)の管理方法として、テスト担当者に対して、テストチャータ、テスト条件の説明、テスト作業時間の指定を行い、テスト担当者の活動範囲、各々のテスト担当範囲を明確にしてやる。
  • 探索的テスト開始前に、テスト担当者はテスト対象についての学習、実施するテストについての検討、テスト準備を行う。テスト実行中は、発見した欠陥の情報を記録する。テスト完了後は、発生した欠陥の報告、分析を行い、今後の探索テストの方向性を決める。

まとめ (というか所感)

  • 項、節で取り上げられている内容については、一般的なものが殆どだったので、「1.テストプロセス」と比較して読みやすかった。(あの章だけ異常に分かりにくいだけかもしれない)