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

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

JSTQB Advanced Level シラバス(テストマネージャー)を読む その3.テストプロセス編②

 こんちは。安定の四十肩、ふっくら太郎です。

 

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

今回は、「テストプロセス編」の続きで、「1.3 テスト分析」、「1.4 テスト設計」、「1.5 テスト実装」を読み解きます。

 

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

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

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

 

 

1.3 テスト分析

   ・並行で作業しても良い。

   ・統合しても良い。

   ・反復しておこなっても良い。

  • テスト分析は、テストベース、テスト目的、プロダクトリスクを分析して、「何をテストするのか」をテスト条件として定義する活動。
  • テスト条件はテストの終了基準の判定に用いることが可能。「テストベース・目的・プロダクトリスク」⇔「テスト条件」⇔「テスト成果物」間はトレーサビリティーがとれる状態になっていなければならない。
  • テスト条件の詳細度合を決めるため様々な要因について考慮しなければならない。

2012 年度版 Advanced Level シラバス 日本語版 - テストマネージャ P.12参照

  •  詳細にテスト条件を指定すると多数のテスト条件に分かれることがある。
  •  詳細にテスト条件を指定した場合、メリット・デメリットがある。

   ・メリットは、詳細化することで成果物の粒度、開発ドキュメント(など)との

    トレーサービリティーを細かく管理できる。進捗管理、コントロールを正確

    に行える。

   ・デメリットは、詳細化することにより作業時間が増える。保守が困難。

    チーム全体で形式化のレベルを定義・共有しなければならない。

 

  • 詳細にテスト条件を指定した場合、特に効果が見られるケース

   ・工数やコストの都合、チェックリストなど簡易なテスト設計書しか無い場合。

   ・開発成果物をテストベースとして使用できない場合。

   ・プロジェクトが大規模、複雑、または高リスクなため、単純にテストケースと

    開発成果物を結び付けてもモニタリング、コントロールができない場合。

  • 低い詳細度でテスト条件を指定できるケース

   (テストケースとテストベースの関係が明白で、抽象化の必要がないケース?)

   ・コンポーネントレベルのテスト

   ・複雑性の低いプロジェクト

   ・受け入れテスト

1.4 テスト設計

  • テスト設計はテスト条件をどの様にテストするのか定義する活動。
  • テストケースはテストベースに直接、または、テスト条件を介して関連付けられる。
  • テストケースは、テスト目的との適応度、プロジェクトの成功度合いの判断に使用できる。
  • テストレベル毎に、定義したテスト条件に従い、テスト計画で決めたアプローチを使用してテストケースを設計する。
  • 上位テストレベル(システム・受け入れテスト?)では、テスト分析と設計を分けて行うことが多く、下位テストレベル(単体・結合)では分析・設計を統合して活動することが多い。
  • 実行する必要があるテストを反復的アプローチを使用して作成する場合は、テストデータの作成など、テスト実装で予定している活動を設計で行う。テスト条件のカバレッジを最適化して、上位、低位レベルのテスト設計が行える。(複数のテストレベルのテスト条件を整理(住み分け)することで並行でテスト設計できるってことだろうか?)

1.5 テスト実装

  • テスト実施出来るように、テストケース、テスト手順、テストデータを作成する活動。
  • テストアナリスト(テスト要件管理、テスト計画のタスク化、テストに関する技術フォローをする人)が体系立ててテストケース作成の優先度を決める。
  • テスト実行を開始する最終チェックを行う。テスト環境、データが揃っていることの確認、テストケースの記述、及びレビューが全て完了していることを確認する。
  • テスト実装時の作業の詳細度は、テスト成果物の詳細度に影響する。回帰テスト等で継続的に使用する場合は、テスト担当者に関係無く実行結果が一意になるようにテスト手順を詳細に記載する必要がある。
  • テストが法規制や安全基準に準拠する場合は、テストが適合していることをエビデンスで示す必要がある。
  • テストマネージャーは、テストの実行予定を考慮して事前に計画化が必要。リスクや優先度を検討した上で、テスト環境やデータ、テスト対象装置の事前準備をしておく。
  • 早期にテスト実装した場合はリスクが伴うことがある。アジャイル開発の場合、開発中にコードが変わってしまい、実装済のテストスクリプトが使えなくなることがある。膨大な時間を要するテスト実装を行う前に、開発プロセスを確認し、テスト実装が可能か事前確認が必要。
  • 早期のテスト実装にはメリットもある。開発中に実装済のテストケースやスクリプトを開発者に提供することで、ソフトウェア仕様の問題点や必要とされる動作を早いタイミングで認識することができる。

 まとめ

  • テスト設分析は、テストで行いたいことをテスト条件に抽象化して分類する作業。分類化することで、テストと開発プロセスや成果物の体系を把握したり、テストの妥当性、方針の抜け漏れが確認できる。(いきなり設計に入ると、粒度が細かすぎて俯瞰で見ることができなくなる)
  • テスト設計はテスト条件を具体的にどの様に確認するかを決める作業。複数のテストレベルで設計作業を進めることで、テストの住み分けも設計時に行える。
  • テスト実施できるように、テストケースにテスト手順や合否基準を落とし込んだり、データを作成する作業。また、本工程で、テスト実施についてのリスクやスケジュールを明確にしておく。