テストエンジニアの備忘録だよっ

いろんなノウハウを残すためのブログです。

JSTQB テスト用

間違えた問題系

■テストタイプ

・機能テスト:「何をするのか」のテスト

・非機能テスト:「どのように動作するのか」のテスト

・構造テスト:構造をどの程度網羅したかのテスト

回帰テスト:テスト済みのプログラムを何度もテスト

■仕様ベースのテスト設計技法の特徴

モデルから体系的にテストケースを作成する技法

■要件カバレッジ

テストカバレッジとしては仕様ベースのテスト設計技法

■テストサイクルモデル

テストレベルの分析や設計は開発作業の完了後に実施すべきではない。同時に行うことが望ましい

■モデルベースアプローチ

信頼度成長曲線などの故障率や使用法に関する統計的情報を使う確率的テスト

■テストケース実行のメトリクス

実行/未実行のテストケース数=テストケースの消化に関するメトリクス

合格/不合格のテストケース=欠陥密度に関するメトリクス

合格のテストケース数/未実行のテストケース数ではメトリクスが成立しない

 

 

----追記----

自分がまだきちんと理解していない箇所を記載

テストオラクル:テストにおいて、ソフトウェアの実際の結果と比較するための予想結果を決定するソース」と定義される。

テストハーネス:テストアイテムであるコンポーネントを実行するドライブ、そのコンポーネントが呼び出すほかのコンポーネントの代わりをするスタブで構成されている

テストウェア:ドキュメント、スクリプト、予想結果、セットアップやファイル、データベース、テスト環境、利用されるソフトウェアなどテスト計画、設計、実行が行われるテストプロセス中に生み出される成果物。テスト計画書、テストベース、テストケース、テストスイート、テスト手順、テスト環境などテストに関するすべての成果物を指している

 

テストケース仕様:テストケースを記述するドキュメントでアイテム群、入力定義、出力定義、環境要求、手順に関する特別な要求が含まれる

テストケース手順:テスト手順を記述したドキュメントで特別な要求、手順のステップが含まれます

 

テストレベル:一緒に編成されてマネジメントされるテストアクティビティの集まり、プロジェクトの責務と紐づく

テストタイプ:一つ以上の品質特性にテストの照準を合わせたテストアクティビティの集まり

テストフェーズ:プロジェクトマネジメントのフェーズでテストアクティビティの集まり

 

性能テスト:レスポンスの早さ、トランザクションの処理能力など性能のテスト

ロードテスト:同時に使用するユーザ数やトランザクション量を高めることによりコンポーネントやシステムの負荷を高め、その振る舞いのテスト

 

 

 

JSTQB 6章 テスト支援ツール

テストツール

・テストツールは「テストのマネジメント」「テスト設計」「テスト実行」などテスト全般を支援するツールを指す

・テストツールには6つの大分類がある

  • テストマネジメントの支援用ツール
  • 静的テスト支援ツール
  • テスト仕様の支援ツール
  • テスト実行と結果記録の支援ツール
  • 性能・モニタリング支援ツール
  • 特定のテストに対する支援ツール

テストマネジメントの支援用ツール

テストマネジメントツール:テストプロセスのテスト計画、テストモニタリング、テストレポート、テストコントロールを支援する

要件マネジメントツール:要求仕様を登録し、開発の優先順位、個々の要求の状況記録、要求仕様や要求一覧のレポート出力の機能を有する

インシデントマネジメントツール:インシデントを登録し、対応する優先順位、個々のインシデントの状況記録、インシデントの内容やインシデント一覧のレポート出力の機能を有する。インシデントではなくバグや欠陥を対象としたバグトラッキングツールや欠陥追跡ツールもある

構成管理ツール:製品に紐づく要求仕様書や設計書などのドキュメント、ソースコード、システムを構成するコンポーネント、データなどの構成要素を構成管理ツールのリポジトリに保管し、バージョン管理やトレーサビリティの維持をする

静的テスト支援ツール

レビューツール:レビュープロセスで行われるレビューの計画や進捗の記録、レビューでのコメントの記録や共有、レビューのチェックリストやガイドラインを提供する。レビューは静的テスト技法であるので、テストマネジメントの支援用ツールではなく静的テスト支援ツールに分類されている

静的解析ツール:コーディング規約を遵守しているかチェックするツール、コンポーネントやWebサイトのリンク構造や依存関係を分析・チェックしビジュアルに表示をするツールなどが該当する

モデリングツールUMLモデリングツール、データモデリングツールなど設計でモデルの整合性をチェック・維持できる機能を有する

テスト仕様の支援ツール

テスト設計ツール:テストケースやテスト手順の設計を支援するツールを指し、テストアイテムの仕様からテストケース、入力データ、予想結果などテストケース仕様を生成できる機能を有する

テストデータ準備ツール:データベース、ファイル、転送データなどテストで使用するテストデータを生成する

テスト実行と結果記録の支援ツール

テスト実行ツール:テストケースやテスト手順を登録し、テストを自動あるいは半自動で実行する。ユーザインターフェースのテストで操作手順を記録し、その操作を再現するようなツールをキャプチャプレイバックツールと呼ぶ

ユニットテストフレームワークツール:テストハーネスを含むコンポーネントテストのためのフレームワークを提供する

テスト比較ツール:ユーザインターフェースの振る舞いや、データベースのテーブル、ファイルなどのテスト結果を予想結果や以前のテスト結果と比較する

カバレッジ測定ツール:プログラムを実行するとソースコードのどこの部分が実行され、どこの部分が実行されていないかを示してくれたり、カバレッジを表示する機能を有する

セキュリティツール:Webサイトの開発であれば、想定されるサイバー攻撃を実際に行ったり、静的に解析し、脆弱性を測定する機能を有する

性能・モニタリング支援ツール

動的解析ツール:実際にプログラムを実行したときに発生するメモリリークや配列を超えた参照などを発見する機能を有する

性能テストツール、ロードテストツール、ストレステストツール:非機能要求として要求されている使用条件を再現して、実行しているソフトウェアの動作をモニタリングし、レポートする機能を有する

モニタリングツール:OSのログ、ヒープメモリなどシステムリソースの使用状況の推移、ディスクの空き容量の推移、ネットワークのトラフィックの推移など、OSが用意しているコマンドや、本番運用で使われる運用監視ソフト、ネットワークアナライザーなどが含まれる

特定のテストに対する支援ツール

データ品質評価:データが仕様通りで完全にそろっており、目的のデータにコンバージョンやマイグレーションが可能かを評価する

プローブ効果

・テストツールによって、実行のタイミングや結果が実際と異なること

 

  1. 追記

■テスト自動ツールの説明

Script言語を使用してテストを自動実行する

パイロットプロジェクトの目的

ツールの詳細仕様を学習する

JSTQB 5章 テストのマネジメント

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

テスト戦略:組織やプログラムなどプロジェクト横断的に立てた戦略

テストアプローチ:テスト戦略を具体化して、プロジェクトに特化した戦略

・代表的なテストアプローチ

  • 分析的アプローチ:リスクの高いところを分析し、そこを重点的にテストするリスクベースドテストなど
  • モデルべースアプローチ:統計モデルなどに基づきテストを進めるテストアプローチ
  • 方法論的アプローチ:テストや欠陥発見の方法論に基づいてテストを進めるアプローチ
  • プロセス準拠アプローチ、標準準拠アプローチ:採用している開発プロセスや業界固有の標準に準拠してテストを進めるアプローチ
  • 動的で経験則に基づいたアプローチ:テスト技術者が自分の経験に基づきテストを進めるアプローチ
  • コンサルテーションベースのアプローチ:テストチーム以外の技術や業務のエキスパートのアドバイスやガイドラインに従ってテストを進めるアプローチ
  • 回帰的アプローチ回帰テストを積極的に効率的に行ってテストを進めるアプローチ

テストマネジメントプロセスと厚生管理

テスト実行中のマネジメント:テストモニタリング→テストレポート→テストコントロールで進められる

テストモニタリング:消化したテストケース数、テストケースの合否結果など、スケジュールや予定コストとの比較などテストの進捗状況を調べる

テストレポートモニタリングした結果と評価を、テストサマリレポートにドキュメント化する

テストコントロール:テスト報告をもとに、今後計画されているテストに対して是正を行う

構成管理:プロジェクトや製品のライフサイクルの間に、ドキュメント、ソースコード、システムを構成するコンポーネント、データなどの構成要素を統合し、バージョン管理やトレーサビリティを維持する

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

プロジェクトリスク:プロジェクトのマネジメントやコントロールに関連するリスクのことで、プロジェクトがプロジェクト計画やテスト計画を遂行できないリスク

プロダクトリスク:開発するソフトウェアやシステムに直接的に関連するリスクのことでソフトウェアが機能要求や非機能要求を満たしていないなど品質に関するリスク

テストに必要な役割

テストリーダ:テストマネージャやテストコーディネータとも呼ばれ、テスト計画やテストマネジメントプロセスに必要な作業や構成管理を用意する

テスト担当者:テストリーダが立てたテスト計画に沿ってテストを準備、実行する

 

追記

■テスト計画

テスト計画書の概要

・テスト計画識別番号:文書番号

・はじめに:テスト目的や戦略、どうテストするか。参照する文献や関連する標準を記述

・テストアイテム:テスト対象のバージョン

・テストすべき機能:テストすべき機能をリストアップする

・テストしない機能:テストしない機能を列挙し理由を記述する

・アプローチ:どのようなアプローチでテストするか記述

・テストアイテムの合否判定基準:合否とテスト終了する基準を記述

・中止/再開基準:中止する基準、また再開する基準を記述

・テスト成果物:テストで作成するドキュメントをリストアップ。テスト計画書も含む

・テストのタスク:準備も含めて必要な作業を記述

・環境要件:テストを実施する環境について記述

・責任範囲:テストに関わる関係者との責任範囲を記述

・要員計画とトレーニング計画:テストに必要なスキル、要員計画を立てる

・スケジュール:テストのマイルストーンを記述

・リスクと対策:テストに関わるリスクと対策について記述

・承認:計画を承認する人の名前を記載

■テスト工数の見積もりの説明

作業の担当者が工数を見積もる

■欠陥情報

欠陥密度=欠陥の数÷プログラムの規模

■テストレポート

・テストサマリレポート識別番号:管理番号、管理対象のため、構成管理も行う

・要約:テストで行った作業全般の要約を掲載。簡潔にする

・変更:テスト計画立案後、テスト実行、終了までに発生した変更内容を記述

・総合評価:テスト作業自身の評価を記述。テスト計画に沿って行えたか分析する

・結果の要約:要約を記述、発見したインシデントについて解決、未解決について記述

・評価:全体の評価を記述

・承認:テスト活動に関わったすべての関連者を承認者として記載し、責任の所在を明確化する

■テスト構成管理の対象

・テスト対象となるソフトウェア

・動作環境

・テストウェア(データなど)

・欠陥

・テスト結果

・ドキュメント

■インシデントレポートの構成

・テストインシデントレポートの識別番号:文書番号

・概要:発生したインシデントを簡潔にまとめる

・詳細

ログの作成日付、作成した組織、作成者、承認、現在の状況

テストケース仕様のID番号など参照情報

期待した結果と実際の結果

異常

日時

実行手順

環境

再現手順

テスト担当者

オブザーバー

・影響範囲

 インシデントの範囲、重要度、有千住に

 ステークホルダーの利益に対してどの程度影響を与えるか

 

JSTQB 4章 テスト設計技法

 

テスト設計技法

仕様ベースのテスト設計技法:テストアイテムの仕様に基づいてテスト設計する技法

構造ベースのテスト設計技法:仕様を実現したテストアイテムの内部構造に基づいてテスト設計する技法

経験ベースのテスト設計技法:テスト担当者の経験に基づきテスト設計をする技法

ブラックボックステスト設計技法:仕様ベースのテスト設計技法と同義である

ホワイトボックステスト設計技法:構造ベースのテスト設計技法と同義である

仕様ベースのテスト設計技法

同値分割法:数値など入力データが取り得る値を仕様上同様に扱えるもの(同値クラス)に分けて、テストケース数を経た素テスト設計技法

境界値分析同値クラス間の境界からテストケースを導き出すテスト設計技法

デシジョンテーブルテスト:テストアイテムのデシジョンテーブルに表されているルールからテストケースを導き出すテスト設計技法

状態遷移テスト:テストアイテムの状態遷移図や状態遷移表からテストケースを導き出すテスト設計技法

ユースケーステストユースケースのシナリオを元にテストケースを導き出すテスト設計技法

構造ベースのテスト設計技法

ステートメントカバレッジステートメントに着目し、ステートメントの実行をどの程度網羅できるかという観点でテストケースを作成するテスト設計技法。100%のテストが行われたとき、テストアイテムのすべてのステートメントが実行されたと言える。

デシジョンカバレッジ:ブランチカバレッジと同義でプログラム内の分岐に着目し、分岐をどの程度網羅できるかという観点でテストケースを作成するテスト設計技法。デシジョンカバレッジが100%のテストが行われたとき、テストアイテムすべての分岐の論理式が真のとき、偽のときの両方が実行されると言える

経験ベースのテスト設計技法

エラー推測:ソフトウェア開発でありがちな誤りをテスト担当者が推測してテストケースを作成する技法

探索的テスト:テストアイテムの仕様がなかったり不十分であるときに正しいであろう仕様を推測してテストケースを作成したり、テスト期間が限られているときに公式なテストと平行してテスト担当者の知識や経験でテストケースを作成するテスト設計技法である

 

---追加要素---

 

テスト条件とテストケースの関係

テストケースはあるテスト条件を網羅するために設計したものである

テスト実行スケジュールを策定する上で考慮すべき事項の組み合わせ

テストの目的に基づいた優先順位、回帰テストでテスト実行する内容

テスト設計技法のカテゴリになるもの

・経験ベースのテスト設計技法、仕様ベースのテスト設計技法、構造ベースのテスト設計技法

JSTQB 3章 静的技法

テスト技法

動的テスト技法:実際にテストアイテムを実行してテストする。テストアイテムが要求仕様通りの結果にならないことやメモリリークの発見に向いている

静的テスト技法:テストアイテムを実行することなくテストする。要求仕様の誤りや漏れやコーディング規約に沿ってないことの発見に向いている

レビュー:レビューも静的テスト技法の1つである

レビューの種類

非公式レビュー:特に決まったやり方があるわけではない。レビューアの技法に大きく依存する

ウォークスルー:シナリオに沿ってシナリオに含まれる関連するグループを机上で実行する。目的はソフトウェアの内容を学習、理解、欠陥を見つけること

テクニカルレビュー:同僚や技術のエキスパートが参加し、あらかじめ定義されたプロセスで実施される。目的はディスカッションすること、判断を下すこと、ほかの方法を評価すること、欠陥を見つけること、技術的な問題を解決すること、仕様や規則に準拠していることをチェックすること

インスペクション:インスペクションのプロセスは形式的に進められる。目的は、欠陥の発見だけでなく、プロセス改善を目的にする場合もある

公式レビューの活動

計画:役割へ担当者を割り当てて、レビュー対象範囲を決定する

キックオフ:レビューの開催に先立って、参加者にレビュー対象のドキュメントを配布し、レビューの目的など概要を説明する

個々の準備:レビュー対象のドキュメントについて議論したり、議論の結果を記録する。より公式なレビューでは、議事の結果や議事内容を議事録に残す

再作業:修正することになった欠陥を修正する

フォローアップ:欠陥が対処されたかを確認する

レビューの必要な役割

マネージャ:レビューに関するマネジメントを行う。実施するレビューの種類を決定し、それぞれの実施スケジュールを立て、レビューが適切に実施されているかを管理する

モデレータ:担当したレビューを取り仕切り、推進する。レビューの成否はモデレータを担当する人の取り仕切りの上手・下手に拠る

作成者:レビュー対象のドキュメントに責任を持つ人

レビューア:ある特定の技術に詳しかったり、業務のバックグラウンドを持つ人で、レビュー対象の欠陥など気が付いたことを示したり、述べたりする

書記:レビューで取り上げたすべての課題、問題点、未解決事項を議事録に記録する

 

---追加要素---

 

ツールによる静的解析

コードそのものの欠陥検出、保守性の改善、学習効果による欠陥予防などの効果がある。ユーザビリティに対する指摘はツールでは不可

JSTQB 2章 ソフトウェアサイクルを通じてのテスト

テストレベル、テストフェーズ、テストタイプ:ソフトウェアライフサイクルで行われテストを異なる観点でテスト分類した用語

テストカバレッジ:テストアイテム内部構造に対して考えられるすべてのテストケースに対して実施するテストスイートやテストケースの網羅度のこと

■テストレベル

テストレベル開発プロセス、システムの規模、アーキテクチャ、テストタイプによって適切なテストレベルが定義され、プロジェクトマネジメントの計画を立てたり、進捗を測る単位

コンポーネントテスト:分離してテストが可能な単位の欠陥を摘出し、正しく作動することを検証するテスト。プログラミングと合わせて実施することが多く、インシデントレポートを書かずにすぐに修正していくことが多い

結合テストコンポーネント間のインターフェース、OS、ファイルシステム、ハードウェアなどシステムの異なる部分同士の相互処理、あるいはシステム間のインターフェースなどの検証するテスト。

システムテスト:プロジェクトが開発したシステムが要求を実現できていることを確認するテスト。

たとえば、業務フローが要求された効率で正しく実行できるか検証する。

テスト環境は限りなく実際に使われる環境に近くなければならない。

受け入れテスト:誰から誰が受けいれるかで4種類のテストがある

  • ユーザ受け入れテスト:ユーザがシステムを受け入れる
  • 運用受け入れテスト:システム運用部署がシステムを受け入れる
  • 契約受け入れテスト、規定受け入れテストシステム開発を依頼した側が契約に基づいてシステムを受け入れる
  • アルファテスト、ベータテスト:テストケースを定義することなく自由に使ってもらい、テストカバレッジでカバーしていない範囲やテストできなかった非機能要求を評価する。

アルファテスト:開発組織の場所で実施されるが開発チームによって実施されない

ベータテスト:顧客あるいは潜在顧客の場所で彼ら自身がテストする

テストフェーズ

テストフェーズ:要求定義フェーズ、設計フェーズ、実装フェーズなどと同様にあくまで開発プロジェクトのフェーズである

シーケンシャル開発モデルを採用しているプロジェクト:統合テストフェーズ、システムテストフェーズ、受け入れテストフェーズといったようにテストレベルとテストフェーズが1対1に対応することもある

イテレーティブ-インクリメンタル開発も照すを採用しているプロジェクト:テストフェーズとテストレベルは対応していない

テストタイプ

テストタイプ:テストすべき要求の種類やソフトウェアの構造などでテストを分類したもの

機能テストブラックボックステストセキュリティテストや相互運用性テストは機能テストの一種

非機能テスト:性能テスト、ロードテスト、ストレステスト、使用性テスト、保守性テスト、信頼性テスト、移植性テストがある

構造テスト:テストアイテム内部の構造に着目して内部動作をテストする。ホワイトボックステスト。実際にテストアイテムを実行してテストするので先に機能テストを実施したほうがよい

再テスト:確認テストと同義。判明した欠陥が正しく修正されたかを確認するテスト。

回帰テスト:欠陥の修正によってその修正で新たな欠陥が生まれたり、顕在化していなかったほかの欠陥を検証するためにテストケースやテストスイートを繰り返し実行するテストのこと

 

 

----追加要素---

 

コンポーネントテストの説明

性能テストなどの非機能テストを実施する

統合テストの説明

テスト担当者は統合計画の構造や影響を理解すべき

統合テストで用いるテストベース

アーキテクチャ、ワークフロー、ユースケース

システムテストの説明

システムテストのスコープは、マスターテスト計画およびレベルテスト計画で定義される

受け入れテストの説明

法律や安全基準などに合致しているかを検証するテストがある

構造テスト

制御フローグラフを用いて、テスト設計を行う。このテストは構造テストの目的の為に行う

JSTQB 1章 テストの基礎

基本用語
エラー、誤り:人間の動作の誤りを指す
バグ、欠陥、フォールト:故障を引き起こすコンポーネントやシステムの欠陥を指す
故障コンポーネントやシステムが期待される結果とならないことを指す
インシデント:障害のことで、原因がバグによるものだけに限らず調査が必要とされるようなイベントを指す
テストアイテム:テスト対象。IEEE829では関連するドキュメントとしてテストアイテム送付レポートが標準化されている
テストベース:テストの根拠となる要求仕様書などのドキュメントを指す
テストケース:テストの為に入力値、実行前の状態、予想結果、実行後の状態を定義したもの
テスト条件コンポーネントやシステムで1つ以上のテストケースによって検証できるアイテムやイベントを指す
テストスイート:関連するテストケースの集まりを指す
テスト手順:テストを実行する為の手順
テスト環境:テストを行う為に必要なハードウェア、計測機器、シュミレータ、ソフトウェアツールを指す
テストハーネス:テストを行う為に必要なスタブやドライバからなる環境を指す
テストオラクル:テスト結果を比較するための予想結果を決定するもので、現行システムを指す
テストウェア:テストに関するものすべての成果物を指す
テストプロセス:テストが計画とコントロール→分析と設計→実装と実行→評価とレポート→終了作業と勧められる
IEEE829:テスト計画書、テスト設計仕様、テスト結果記録、インシデントレポート、テストサマリレポートのドキュメントが標準化されている

テストの7原則
原則その1:テストは欠陥があることしか示せない
原則その2:全数テストは不可
原則その3:初期テスト
原則その4:欠陥の偏在
原則その5:殺虫剤のパラドックス
原則その6:テストは条件次第
原則その7:「バグゼロ」の落とし穴

ソフトウェアライフサイクル
ソフトウェアライフサイクル
ソフトウェアの一生という意味で、ソフトウェアを企画してから廃棄されるまでの期間を指す。この活動をソフトウェアサイクルプロセスと呼ぶ
V字モデル:開発ライフサイクルの活動の前後関係とテストベースとテストの対応関係を表すモデル
ライフサイクルモデル:シーケンシャル開発モデルとイテレーティブインクリメンタル開発モデルがあり、テストのアプローチが異なる
シーケンシャル開発モデル:V字モデルに沿って順番に進めるライフサイクルモデルである
イテレーティブ-インクリメンタル開発モデル:V字モデルを繰り返すライフサイクルモデルである

 

----追加要素----

 

ソフトウェアサポートにかかるコスト

ソフトウェアが意図したとおりに正しく動作しないことにより、起こる問題として経済的な損失がある

サポート業務の中でも、特にクレーム受付や製品回収にかかるコストである

ソフトウェア設計、ソフトウェアテスト設計にかかるコスト

開発コストになる

ソフトウェア構成管理にかかるコスト

開発コストでもあり、保守にかかるコストになる

納期のプレッシャーによって起こる事象

エラー、誤りで起こる

テストの充分性を決める為に考慮すべきリスク

リリース後に、技術の課題が残ってしまうリスク、開発者が退職してしまうリスク、安全性に問題が残るリスク、仕様変更が入るリスク

テストメンバーの作業割り振り

テスト実行前作業

テストマネージャー:テスト計画

テストリーダ:テスト計画

テスト担当者:テスト条件の選択、テスト設計、

テスト実行時

テストマネージャ:テスト終了基準の検証、テスト結果の報告

テスト担当者:実行時のチェック

テスト実行後の作業

テスト担当者:テストウェアの整理

全体を通して行われる作業

テストマネージャ:テストコントロール

 

テスト計画

・スコープとリスクを特定し、テストの目的を定義する

・どのようにテストをすべきか、プロジェクトや規格のゴールに沿ったテスト目的を定める

・テストの目的を達成したか、完了するかどうかの定義を決める、この基準はステークホルダー間で合意を得ることができるものでなけれなならない

・どのようにテストを進めるか、テスト結果を評価するか、終了基準を決める

・テスト実施場所、動作環境、テスト対象のバージョン、テストツールなど活動にリソースを割り当てる

ブラックボックスなら要求仕様書、企画書、RFPなどのドキュメントを用意する

ホワイトボックスならアーキテクチャ定義書、基本設計書、詳細設計書、モデル定義書、データベース設計書など用意し、テスト分析と設計の活動をスケジューリングする

・テストケース作成、テスト環境の整備といった工数など、テストの実装と実行や、事前準備、データや設定値などの復旧処理、インシデントにかかる工数などテスト結果の評価にかかる活動をスケジューリングする。これらはテスト担当者が見積もりを行う。

・テストコントロール

・テスト結果の計測と分析

・進捗、テストカバレッジ、終了基準のモニタリングと文書化

・欠陥修正の開始

・意思決定

テスト分析と設計

・テストベースをレビューする

・テストベースやテスト対象の基礎や標準といったものさしを用いるかどうかテスト容易性を評価する

・テスト条件を識別し、優先順位をつける

・テストケースを設計し、優先順位をつける

・テスト条件やテストケースをサポートする上で必要なテストデータを識別する

・テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する

・テストベースとテストケースの間で双方向のトレーサビリティを作成する

テスト実装と実行

・テストベース、リスク解析レポート、アーキテクチャ、設計をレビューする

・テスト者の主観によって結果が左右されないようにものさしを定義する

・テストアイテム、仕様、動作、ソフトウェアの構造などの分析に基づいてテスト条件を識別し優先順位を付ける

・テスト条件(テスト要件)を網羅するようにテスト技法を用いて設計する。

テスト設計の視点例

ユーザ指向:テスト対象を利用する視点でみる

フォールト指向:欠陥を見つけるため

要件指向:要件の妥当性を見つけるため

設計指向:設計通りにテスト対象が動作するかを見る

・テスト条件やテストケースをサポートする上で必要なテストデータを識別する

・テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する

・テストベースとテストケースの間で双方向のトレーサビリティを作成する

テスト実装と実行

・テストケースを決定し、実装し、優先順位を付ける

・テスト手順を開発し、優先順位を付け、テストデータを作成する。場合によったはテストハーネスを準備し、テスト自動実行スクリプトを書く

・効率よくテスト実行するため、テスト手順をベースにしてテストスイートを作る

・テスト環境を正しくセットアップしたことを確認する

・テストベースとテストケースの間で双方向のトレーサビリティを確認し更新する

・計画した順番に従い、テスト手順を人力、もしくはテストツールで実行する

・テスト実行結果の記録を取り、テスト対象のソフトウェア、テストツール、テストウェアのIDとVerをエビデンス(証拠)を記録する

・実行結果と期待する結果を比較する

・両社が一致しない場合、インシデントとして報告し、原因を解明するためにインシデントを分析する

・実行結果と期待結果が一致しないケース毎にテスト活動を繰り返す

確認テスト:前回不一致となったテストケースを再実行

回帰テスト:変更していない部分に新たな欠陥がはいりこんでいないか確認する

終了基準の評価とレポート

終了基準の評価は以下の3つのタスクになる

・テスト結果の記録をテスト計画作業で定義した終了基準と比較する

:要件や仕様に対するカバレッジが十分なテスト実施したか等。

・追加テストが必要か、あるいは定義した終了基準を変更すべきか判断する

:終了基準を満たしていない場合はさらに追加テストが必要かどうか判断する

ステークホルダーにテストサマリーレポートを書く

:テストレベルを終わらせた後に直接的/間接的に影響を受ける関係者に近況報告をする

終了基準

終了作業は以下の7つから構成されている

・計画にある成果物がリリースされたかをチェックする

・インシデントレポートを終了させるか、もしくは未対策の欠陥を変更記録に載せる

・システムを受け入れるために文書を作成する

・次回も使えるように、テストウェア、テスト環境、テストのインフラストラクチャをまとめ、文書を記録する

・テストウェアを保守部門に引き渡す

・次回のリリースやプロジェクトのために教訓とすべきことをまとめる

・その情報をテストの成熟度を改善するために利用する

 

テストプロセスの主要な作業

計画とコントロール、分析と設計、実装と実行

ソフトウェアサポートにかかるコスト

ソフトウェアが意図したとおりに正しく動作しないことにより、起こる問題として経済的な損失がある

サポート業務の中でも、特にクレーム受付や製品回収にかかるコストである

ソフトウェア設計、ソフトウェアテスト設計にかかるコスト

開発コストになる

ソフトウェア構成管理にかかるコスト

開発コストでもあり、保守にかかるコストになる

納期のプレッシャーによって起こる事象

エラー、誤りで起こる

テストの充分性を決める為に考慮すべきリスク

リリース後に、技術の課題が残ってしまうリスク、開発者が退職してしまうリスク、安全性に問題が残るリスク、仕様変更が入るリスク

テストメンバーの作業割り振り

テスト実行前作業

テストマネージャー:テスト計画

テストリーダ:テスト計画

テスト担当者:テスト条件の選択、テスト設計、

テスト実行時

テストマネージャ:テスト終了基準の検証、テスト結果の報告

テスト担当者:実行時のチェック

テスト実行後の作業

テスト担当者:テストウェアの整理

全体を通して行われる作業

テストマネージャ:テストコントロール

 

テスト計画

・スコープとリスクを特定し、テストの目的を定義する

・どのようにテストをすべきか、プロジェクトや規格のゴールに沿ったテスト目的を定める

・テストの目的を達成したか、完了するかどうかの定義を決める、この基準はステークホルダー間で合意を得ることができるものでなけれなならない

・どのようにテストを進めるか、テスト結果を評価するか、終了基準を決める

・テスト実施場所、動作環境、テスト対象のバージョン、テストツールなど活動にリソースを割り当てる

ブラックボックスなら要求仕様書、企画書、RFPなどのドキュメントを用意する

ホワイトボックスならアーキテクチャ定義書、基本設計書、詳細設計書、モデル定義書、データベース設計書など用意し、テスト分析と設計の活動をスケジューリングする

・テストケース作成、テスト環境の整備といった工数など、テストの実装と実行や、事前準備、データや設定値などの復旧処理、インシデントにかかる工数などテスト結果の評価にかかる活動をスケジューリングする。これらはテスト担当者が見積もりを行う。

・テストコントロール

・テスト結果の計測と分析

・進捗、テストカバレッジ、終了基準のモニタリングと文書化

・欠陥修正の開始

・意思決定

テスト分析と設計

・テストベースをレビューする

・テストベースやテスト対象の基礎や標準といったものさしを用いるかどうかテスト容易性を評価する

・テスト条件を識別し、優先順位をつける

・テストケースを設計し、優先順位をつける

・テスト条件やテストケースをサポートする上で必要なテストデータを識別する

・テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する

・テストベースとテストケースの間で双方向のトレーサビリティを作成する

テスト実装と実行

・テストベース、リスク解析レポート、アーキテクチャ、設計をレビューする

・テスト者の主観によって結果が左右されないようにものさしを定義する

・テストアイテム、仕様、動作、ソフトウェアの構造などの分析に基づいてテスト条件を識別し優先順位を付ける

・テスト条件(テスト要件)を網羅するようにテスト技法を用いて設計する。

テスト設計の視点例

ユーザ指向:テスト対象を利用する視点でみる

フォールト指向:欠陥を見つけるため

要件指向:要件の妥当性を見つけるため

設計指向:設計通りにテスト対象が動作するかを見る

・テスト条件やテストケースをサポートする上で必要なテストデータを識別する

・テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する

・テストベースとテストケースの間で双方向のトレーサビリティを作成する

テスト実装と実行

・テストケースを決定し、実装し、優先順位を付ける

・テスト手順を開発し、優先順位を付け、テストデータを作成する。場合によったはテストハーネスを準備し、テスト自動実行スクリプトを書く

・効率よくテスト実行するため、テスト手順をベースにしてテストスイートを作る

・テスト環境を正しくセットアップしたことを確認する

・テストベースとテストケースの間で双方向のトレーサビリティを確認し更新する

・計画した順番に従い、テスト手順を人力、もしくはテストツールで実行する

・テスト実行結果の記録を取り、テスト対象のソフトウェア、テストツール、テストウェアのIDとVerをエビデンス(証拠)を記録する

・実行結果と期待する結果を比較する

・両社が一致しない場合、インシデントとして報告し、原因を解明するためにインシデントを分析する

・実行結果と期待結果が一致しないケース毎にテスト活動を繰り返す

確認テスト:前回不一致となったテストケースを再実行

回帰テスト:変更していない部分に新たな欠陥がはいりこんでいないか確認する

終了基準の評価とレポート

終了基準の評価は以下の3つのタスクになる

・テスト結果の記録をテスト計画作業で定義した終了基準と比較する

:要件や仕様に対するカバレッジが十分なテスト実施したか等。

・追加テストが必要か、あるいは定義した終了基準を変更すべきか判断する

:終了基準を満たしていない場合はさらに追加テストが必要かどうか判断する

ステークホルダーにテストサマリーレポートを書く

:テストレベルを終わらせた後に直接的/間接的に影響を受ける関係者に近況報告をする

終了基準

終了作業は以下の7つから構成されている

・計画にある成果物がリリースされたかをチェックする

・インシデントレポートを終了させるか、もしくは未対策の欠陥を変更記録に載せる

・システムを受け入れるために文書を作成する

・次回も使えるように、テストウェア、テスト環境、テストのインフラストラクチャをまとめ、文書を記録する

・テストウェアを保守部門に引き渡す

・次回のリリースやプロジェクトのために教訓とすべきことをまとめる

・その情報をテストの成熟度を改善するために利用する

 

テストプロセスの主要な作業

計画とコントロール、分析と設計、実装と実行