徒然なるままに

学習メモがメインです

JSTQBFL5章テストマネジメントでの学び

はじめに

3章引き続き5章を読んでみましたので、今回もシラバスの内容で「これ大事だな」と思うもの独断と偏見で記述しています。また、「特に大事だな」と思うものboldにしています。

tagoaskubeya.hateblo.jp

シラバス内容抽出

テスト組織

独立したテスト

  • ある程度の独立性を確立すると、開発者とテスト担当者の間の認知バイアスの違いによって、テスト担当者はより効果的に欠陥を発見できる。ただし、独立性は熟知していることの代わりにはならない。
  • ほぼすべての種類のプロジェクトにおいて、複数のテストレベルのいくつかでは独立したテスト担当者がテストを行うのがよい。開発担当者は自分たちの仕事の成果の品質をコントロールするために、特にローレベルのテストに参加すべきである。

メリット

  • 独立したテスト担当者は、開発担当者とは異なる背景、技術的視点、バイアスを持つため、開発担当者とは異なる種類の故障を検出する可能性が高い
  • ベンダーの独立したテスト担当者は、契約元の会社にある(政治的な)圧力なしに、テスト中のシステムについて正直に客観的な態度で報告できる。

デメリット

  • 開発チームから隔絶されると、協力関係の欠落、開発チームへのフィードバック提供の遅延、開発チームとの対立を招くことがある。
  • 独立したテスト担当者は、ボトルネックとして見られることがある。
  • 独立したテスト担当者にテスト対象の情報などの重要な情報が伝わらないことがある。

テスト担当者のタスク

テストレベル 一般的なテスト担当者
コンポーネントテストレベルやコンポーネント統合テストレベル 開発担当者
受け入れテストレベル ビジネスアナリスト、特定の分野の専門家
システムテストレベルやシステム統合テストレベル 独立したテストチーム
運用受け入れテストレベル 運用担当者またはシステム管理者

テストの計画と見積り

テスト計画書の目的と内容

  • プロジェクトやテスト計画が進行するに従い、入手できる情報が多くなり、具体的な情報をテスト計画書に含めることができる。テスト計画は継続する活動であり、プロダクトのライフサイクル全体を通して行う。

テスト戦略とテストアプローチ

  • テスト戦略は、プロダクトまたは組織のレベルでのテストプロセスに関する汎用的な考え方を提供する。
  • 適切なテスト戦略は、テスト戦略を複数組み合わせて構築する。
  • テストアプローチは、テスト技法、テストレベル、テストタイプの選択や、開始基準と終了基準(またはそれぞれ準備完了(ready)の定義と完了(done)の定義)を決めるための出発点である。

テスト戦略の種類

  • 分析的
    • いくつかの要因(要件やリスクなど)の分析に基づく。分析的アプローチの例としては、リスクベースドテストがある。
  • モデルベースド
    • プロダクトで必要な特性を表すモデル。例えば、機能、ビジネスプロセス、内部構造、非機能特性(信頼性)などに基づいてテストを設計する。モデルの例は、ビジネスプロセスモデル、状態モデル、信頼度成長モデルなど。
  • 系統的
    • 事前に定義した一連のテストケースまたはテスト条件を体系的に使用する。
  • プロセス準拠
    • 外部のルールや標準を使用してテストの分析、設計、実装を行う。
  • 指導ベース(コンサルテーションベース)
    • 外部の人から(テストチームの外部または組織自体の外部のステークホルダー、ビジネスドメインの専門家、技術的専門家から)の助言、ガイダンス、指示に基づいてテストを行う
  • リグレッション回避
    • 既存では実現されていた能力のリグレッションを避けることが目的。このテスト戦略には、既存のテストウェア(特にテストケースやテストデータ)、高度に自動化されたリグレッションテスト、および標準テストスイートの再利用が含まれる。
  • 対処的
    • 他の戦略とは異なり、テストは事前に計画されず対処的にテストを行う。先に実行したテストの結果により得られた知識に応じて、テストを設計および実装する。対処的戦略では、探索的テストを一般的に使用する。

テスト実行スケジュール

  • テストケースやテスト手順を作成(テスト手順は可能な限り自動化)し、テストスイートにまとめた後、テスト実行スケジュールを作成してテストを実行する順序を定義する。

テスト見積もりの技術

  • メトリクスを活用する
    • 以前の類似したプロジェクトのメトリクスや、典型的な値を基にしてテスト工数を見積る。
  • 専門家の知識を基にする
    • テストのタスクの所有者の経験、または専門家による見積りを基にしてテスト工数を見積る。ワイドバドデルファイ見積り技法などが例となる。

テストのモニタリングとコントロール

  • テストモニタリング
    • テスト活動に関する情報を収集して可視化し、フィードバックをかけること
  • テストコントロール
    • 収集、報告されたテストの実施結果を基にガイドや補正のアクションをすること(テストの優先度を見直したり、テストのスケジュールの変更など)である

テストで使用するメトリクス

  • メトリクスは各テスト活動の期間中、および終了時に収集できる、以下の項目を評価する。

    • 計画したスケジュールや予算に対する進捗
    • テスト対象の現在の品質
    • テストアプローチの十分性
    • テスト目的に対するテスト活動の効果
代表的なテストメトリクス
  • 計画したテストケースの準備が完了した割合(または、計画したテストケースを実装した割合)
  • 計画したテスト環境の準備が完了した割合
  • テストケースの実行(例えば、実行/未実行のテストケース数、合格/不合格のテストケース数、そして/または合格/不合格のテスト条件数)
  • 欠陥情報(例えば、欠陥密度、検出および修正した欠陥数、故障率、確認テスト結果)
  • 要件、ユーザーストーリー、受け入れ基準、リスク、コードのテストカバレッジ
  • タスクの完了、リソースの割り当てと稼働状況、工数
  • テストに費やすコスト(現状のコストと、継続して欠陥を見つけていくメリットと比較した場合のコスト、もしくは継続してテストを実行していくメリットと比較した場合のコストなど)

構成管理

目的:プロジェクトやプロダクトのライフサイクルを通じて、コンポーネントやシステムの完全性、テストウェア、およびそれら相互の関係を確立し、維持すること。テスト計画にて構成管理の手順やインフラストラクチャー(ツール)を識別し、実装すべきである。

  • 全テストアイテムのバージョン管理して、変更履歴を残し各アイテム間を関連付ける。
  • テストウェアの全アイテムを一位に識別してバージョン管理して各アイテム間を関連付ける。また、テストアイテムのバージョンとの関連付けを行い、テストプロセスを通してトレーサビリティを維持できる。
  • 識別したすべてのドキュメントやソフトウェアアイテムは、テストドキュメントに明確に記載してある。

リスクとテスト

リスクの定義

リスクは、将来に否定的な結果となる事象が起きる恐れを含む。リスクのレベルは、そのような事象が起きる可能性とその影響(事象による結果がもたらす損害)で決まる。

プロダクトリスクとプロジェクトリスク

  • プロダクトリスク
  • プロジェクトリスク
    • プロジェクトの目的達成に悪影響を与えるもの。

リスクベースドテストとプロダクト品質

テスト時に必要な工数についてどこに重点を置くかを決定するために、リスクを使用する。テストは、期待しない事象が発生するリスクを減らしたり、その影響を少なくしたりするために使用する。また、どのテストをいつから開始するかを決定し、さらなるテストが必要な領域を識別するために使用する。

リスクベースのアプローチを採用すると、プロダクトリスクを軽減する予防的措置を講じられる。このアプローチではリスク分析を行い、プロダクトリスクを識別し、各リスクの発生する可能性と発生した場合の影響を評価する。この活動を通して得られるプロダクトリスクの情報を、テスト計画、仕様化、テストケースの準備と実行、テストのモニタリングとコントロールに役立てる。プロダクトリスクを早期に分析することは、プロジェクトの成功に貢献する。

リスクベースのアプローチでは、プロダクトリスク分析の結果を使用して以下を行う。

  • 適用するテスト技法を決める。
  • 実施するテストレベルおよびテストタイプを決める(例えば、セキュリティテストやアクセシビリティテスト)。
  • テストを実行する範囲を決める。
  • 重大な欠陥をなるべく早い時期に検出するため、テストの優先順位を決める。
  • テスト以外の活動でリスクを減らす方法があるか検討する(経験の少ない設計者に教育を実施するなど)。

リスクベースドテストでは、プロダクトリスクの分析を行うために、プロジェクトのステークホルダーの総合的な知識や洞察力を必要とする。プロダクトが故障を起こす可能性を最小にするため、リスクマネジメントでは、以下のように、きちんと決まったアプローチを備えている必要がある。

  • どこが上手くいかないか(リスク)を分析する。定期的に再評価する。
  • リスクの重要度を決める。
  • 重大なリスクを処理する方法を実装する。
  • リスクが実際に事象として発生した場合に備えてコンティンジェンシープランを作る。

欠陥マネジメント

  • テストの目的の1つは欠陥を検出することであるため、テスト時に見つかった欠陥は記録を残す必要がある。
  • 検出したすべての欠陥を調査し、発見や分類から解決にいたるまで追跡する必要がある。すべての欠陥を解決にいたるまでマネジメントするために、組織で欠陥マネジメントのプロセスを定め、ワークフローと分類の規則を設ける必要がある。
  • テスト担当者は、欠陥として報告する偽陽性の数を最小限にする必要がある。
  • 欠陥レポートの目的
    • 開発担当者や他の関係者に対して、発生したあらゆる期待に反する事象についての情報を提供す る。また、必要に応じて、もしくは問題を解決するために、具体的な影響を識別して、最小の再現テストで問題の切り分けを行い、欠陥の修正ができるようにする。
    • テストマネージャーに対し、作業成果物の品質や、テストへの影響を追跡する手段を提供する開発プロセスとテストプロセスを改善するためのヒントを提供する。
    • 開発プロセスとテストプロセスを改善するためのヒントを提供する。

感想

テストの計画について

テスト計画は作ってそれをずっと守るわけではない。わかっている情報や知っている情報が出てきてそれを取り入れてテスト計画は成長する。

この考え方はPMBOKにも出てくるのローリングウェーブ計画法で反復計画法の一つでしょうか。予測がつきにくい将来の作業はより上位のレベル(大まかなレベル)でとらえて計画し、詳細レベルは後できめる考え方です。 テストの計画は一度決めてそれを守るのではなく、後から柔軟に変更して良いものだと思えるようになり、変更しなければならないときに「成長するものだから変えましょ」と言いやすくなりました。

※成長する考え方、ローリングウェーブ計画法はマインドマップから始めるソフトウェアテストにも記載されていました。

むずかしそうなとこ

構成管理にドキュメントも、テストアイテムも、テストアイテムもすべて管理するべき〜の様に記載されてます。
べき論で言えばすべて管理したほうが良いし、管理したい。実際のところ、時間がなかったり、めんどくさくなったり、手間をかけて得られる結果が少なく感じてしまったり...すべて管理するのは難しそうだなと感じました。(難しく考えすぎ?)
簡単にできるツールや仕組みを知りたいところです。

欠陥マネジメント

検出したすべての欠陥を調査し、発見や分類から解決にいたるまで追跡する必要がある。すべての欠陥を解決にいたるまでマネジメントするために、組織で欠陥マネジメントのプロセスを定め、ワークフローと分類の規則を設ける必要がある。

したほうが良いことではあるとは思う。が...これはかなりハードルが高そう。組織においてすべての欠陥を解決するまで規則やプロセスを定める苦労と、定めることで開発スピードが遅くなることへの懸念が思い浮かびました。

リスクのレベル

リスクのレベルは、そのような事象が起きる可能性とその影響(事象による結果がもたらす損害)で決まる。

否定的な結果が起きる可能性×影響で覚えました。未来に対して考えるという点では見積もりと同じなのかなと。リスクを考えるときはテスト見積もりの技術にある、メトリクスを活用する専門家の知識を基にする しか無いのかな...と考えています。

リスクばかり考えて否定的な考えばかりするのは違うので、リスクリスク!と感情的に可能性だけを考えるのではなく、影響も含めて受容できるリスクも考えていきたいです。