1.1 テストの必要性 ★★
1.1.1 ソフトウェアシステムの状況 ★
ソフトウェアが期待通りに動かないことによる不具合は、大きく分けて以下の4つがある。
- 経済的な損失
- 時間の浪費
- 信用の失墜
- 傷害や死亡事故
1.1.2 ソフトウェアの欠陥の原因 ★★
欠陥に関する用語を以下4つに分類する。
- エラー（誤り）
- 間違った結果を生み出す人間の行為
- フォールト（fault）
- 要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備
- エラーによってプログラムにフォールトが埋め込まれる
- ISTQBでは、バグ、欠陥、フォールトは同義
- 故障（failure）
- コンポーネントやシステムが、期待した機能、サービス、結果を提供できないこと
- 欠陥があっても故障が発生しないこともある（顕在化しない）
- インシデント
- ソフトウェアシステムを実際に使うユーザやテスト担当者が期待する動きと、実際の動きが一致しないこと。
1.1.3 ソフトウェアの開発、保守、運用におけるテストの役割 ★★
1.1.4 テストと品質 ★★
ソフトウェアと品質は、以下の3つの点で関係がある。
- 品質の確保
- 品質の計測
- プロセス改善のための情報提供
1.1.5 テストの十分性 ★★
1.2 テストとは何か ★★
開発担当者が行うデバッグと、テスト技術者が行うテストの違いについて。
1.2.1 テストとは？ ★
- テスト実行前作業
- 計画：準備作業、リソース配分、いつまでにどのような作業をするのかを計画する。テスト終了基準についても決定する。主にテストリーダやテストマネージャが行う。
- テスト条件の選択：テストベースを分析し、何をテストするのかを決定する。主にテスト担当者が行う。
- テストケースの設計：特定したテスト条件を網羅して確認できるようテストケースを設計する。主にテスト担当者が行う。
- テスト実行時の作業
- 実行結果のチェック：テストケースを実行して得られた結果の確認。主にテスト担当者が行う。
- テスト終了基準の検証：計画時に決定した終了条件を満たしているかを検証する。主にテストマネージャが行う。
- テスト結果の報告：実施結果、インシデントの対応結果、終了基準の達成度合いなどについて、ステークホルダに報告する。主にテストマネージャが行う。
- テスト実行後の作業
- テストウェアの整理：テストプロジェクトが終了したときに、テストウェアの整理を行い資産化し、次回のテストプロジェクトに引き継ぎ、良いスパイラルを回していく。
- 全体を通して行われる作業
- コントロール：テストの進捗管理、テストカバレッジや終了基準の達成状況のモニタリングなど。主にテストマネージャが行う。
1.2.2 テストの目的 ★
- 欠陥の検出
- 対象ソフトウェアの品質レベルが十分であることの確認
- 意思決定のための情報の提示
- 欠陥の創りこみの防止
- 製品がリリースされるまでのテスト
- 開発でのテスト（コンポーネントテスト、統合テスト、システムテスト）：多くの故障を発見して、ソフトウェアの欠陥を特定して修正することが目的。
- 受入テスト：システムが期待通りに動作し、要件に合致することの確認。
- 保守テスト：ソフトウェアの変更時（機能追加、インシデント対応など）に、新たな欠陥が潜んでいないかを確認することが目的。
- 運用テスト：信頼性、可用性などのシステム特性を確認することが目的。
1.2.3 デバッグとテスト ★★
デバッグ≠テスト
- テスト
- 欠陥から発生する故障を発見することを目的
- デバッグ
- 故障の原因を突き止め、解析し、取り除く一連の開発の活動
1.3 テストの7原則 ★★
- テストは「欠陥がある」ことしか示せない
- 全数テストは不可能
- 初期テスト
- 欠陥の偏在
- 殺虫剤のパラドックス
- テストは条件次第
- 「バグゼロ」の落とし穴
1.4 基本的なテストプロセス ★
1.4.1 背景
テストケースの抽出やテスト手順の作成を、テストを実施しながら同時並行的に行う → 行き当たりばったりなテストになるのでダメ！
テストプロセス全体の主要なアクティビティは以下の通り。
- 計画とコントロール
- 分析と設計
- 実装と実行
- 終了基準の評価とレポート
- 終了作業
上記は直列的に進めることもあれば、分析と設計を行いつつ、仕様が明確なテストケースを同時に作成するといったように、並行して進めることもある。
1.4.2 テスト計画作業とコントロール ★
テスト計画の策定：テストの目的を明らかにする。
コントロール：モニタリング。計画と進捗の乖離の計測、インシデントの発生状況とテストケースの進捗状況から品質分析等。
・テスト計画
- スコープとリスクを特定し、テストの目的を定義する
- テストに対する包括的なアプローチを定義する。これには、テストレベル、開始基準、終了基準などの定義も含む
- 何をテストするか、テスト活動でどのような職務(手段)を実行するか、いつどのようにテスト活動を進めるか、テスト結果をどのように評価するか、いつテストを終わらせるか(終了基準)を決める
- 定義したいろいろな活動にリソースを割り当てる ⇒ テスト環境、人数やスキルセットなど
- テストの分析と設計の活動をスケジューリングする ⇒ 分析材料をそろえる。ブラックボックスなら、要求仕様書や企画書、RFP等。グレー／ホワイトボックスなら、アーキテクチャ定義書、基本／詳細設計書、モデル定義書、データベース設計書等。ただ、ドキュメントが揃っていないことも多いので、ヒアリングしつつ設計を進めることも多い。
- テストの実装と実行、テスト結果の評価にかかる活動をスケジューリングする
・テストのコントロール
- テスト結果の計測と分析
- 進捗、テストカバレッジ、終了基準のモニタリングと文書化
- 欠陥修正の開始
- 意思決定
1.4.3 テストの分析と設計 ★
テストの分析：テストを行う為の情報、つまりテスト対象の性質や品質、特徴などが記されたテストベースを収集したうえで、情報の取捨選択、再収集、新たに作成するなどを検討する。
テスト設計：分析を経たうえで、どのようなテストをどのような手段で実施すべきかというテスト戦術を検討する。
ここまでで、テストの大・中項目を定義するイメージ
- テストベース(例えば、要件、ソフトウェア完全性レベル(リスクレベル)、リスク解析レポート、アーキテクチャ、設計、インタフェース仕様)をレビューする
- テストベースやテスト対象のテスト容易性を評価する
- テストアイテム、仕様、動作、ソフトウェアの構造などの分析に基づいて、テスト条件を識別し優先順位を付ける
- 高度なテストケースを設計し、優先順位を付ける
- テスト条件やテストケースをサポートする上で必要なテストデータを識別する
- テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する
- テストベースとテストケースの間で双方向のトレーサビリティを作成する ⇒ トレーサビリティマトリクス、要求管理ツール、ALM(Application Lifecycle Management)ツールを導入する
1.4.4 テストの実装と実行 ★
実際にテストを実施するための手順や確認項目の詳細となるテストケースやテスト手順書、テストスクリプトといったテストウェアへ変換する。テスト環境の構築もここで行う。
- テストケースを決定し、実装し、優先順位を付ける
- テスト手順を開発し、優先順位を付け、テストデータを作成する。場合によってはテストハーネスを準備し、テストの自動実行スクリプトを書く
- 効率良くテストを実行するため、テスト手順をベースにしてテストスイートを作る
- テスト環境を正しくセットアップしたことを確認する
- テストベースとテストケースの間で双方向のトレーサビリティを確認し更新する
- 計画した順番に従い、テスト手順を人力、もしくはテストツールで実行する
- テストの実行結果の記録を取り、テスト対象のソフトウェア、テストツール、テストウェアのIDとバージョンを記録する
- 実行結果と期待する結果を比較する
- 両者が一致しない場合、インシデントとして報告し、原因(コード、テストデータやテストドキュメントの欠陥、テスト実行手法の誤りなど)を解明するためにインシデントを分析する
- 実行結果と期待する結果が一致しないケースごとに、テスト活動を繰り返す。例えば、修正が正しいことを確認するため、前回不一致となったテストケースを再実行(確認テスト)したり、改訂版のテストケースや元のテストケースを実行したり、変更していないプログラム部分に新たな欠陥が入り込んでいないことや、欠陥修正により陰に隠れていた欠陥が現れないことを確認したりする(回帰テスト)
1.4.5 終了基準の評価とレポート ★
- テスト結果の記録をテスト計画作業で定義した終了基準と比較する
- 追加テストが必要か、あるいは定義した終了基準を変更するべきかを判断する
- ステークホルダにテストサマリレポートを書く
1.4.6 終了作業 ★
- 計画にある成果物がリリースされたかをチェックする
- インシデントレポートを終了(クローズ)させるか、もしくは未対策の欠陥を変更記録に載せる
- システムを受け入れるために文書を作成する
- 次回も使えるように、テストウェア、テスト環境、テストのインフラストラクチャをまとめ、文書に記録する
- テストウェアを保守部門に引き渡す
- 次回のリリースやプロジェクトのために教訓とすべきことをまとめる
- その情報をテストの成熟度を改善するために利用する
1.5 テストの心理学 ★★
1.5.1 独立性を確保したテスト ★★
ソフトウェアのテストには、以下2種類があり、目的と効果が異なる。
- 開発担当者が自ら行うテスト ⇒ 多くのコードの中の欠陥を見つけることが期待できる。先入観や時間的猶予の不足等が影響。
- テスト担当者によるテスト ⇒ 先入観や思い込みなどのバイアスを排除できる。理解に時間がかかる。
1.5.2 独立性の度合い ★★
- ソフトウェアを作成した本人がテストを設計する(独立性が最も低い) ⇒ 先入観による影響を最も受けやすい
- 開発担当者とは別の人(開発チームの人)がテスト背系する(独立性が低い) ⇒ レビュー効果程度
- 開発担当者とは別の部署の人(例えば独立したテストチーム)またはテストの専門家(例えばユーザビリティテストまたは性能テストの専門家)がテスト設計する(独立性が高い)
- 開発担当者とは別の会社の人がテスト設計する(すなわち、外部のテスト会社へ委託や、外部団体の認証を受ける)(独立性が最も高い)
1.5.3 テストの目的の明確さ ★★
「欠陥を見つける=テスト」と考える人が多いが、「ソフトウェアが目的を果たしている」ことを確認することが多い。テストの目的を明確にすることが重要。
1.5.4 欠陥のフィードバックとコミュニケーション ★★
テスト担当者と開発担当者は立場上の優位性に差はない。
エラー、欠陥、故障を見つけても、開発者からは避難と受け取られることもあるので、優れたコミュニケーションスキルが必要。
1.5.5 テスト担当者と開発担当者の心理の違い ★★
テスト担当者と開発担当者の温度差はなくす必要がある。コミュニケーションや関係を改善する方法は以下。
- テスト担当者と開発担当者は敵対者ではなく、同じ品質のゴールを掲げたシステムの開発にたずさわるチームであることを再認識する。
- プロダクトに対する指摘は、中立で、事実を中心にして実施し、欠陥を作りこんだ担当者を非難する方向に行かないようにする。例えば、客観的かつ事実に基づいたインシデントレポートを書いたり、見つけたことをレビューしたりする。
- 他人の気持ちや反応を理解するように努力する。テスト担当者と開発担当者の置かれている状況を相互に理解して、協調して問題に対応するよう努力する必要がある。具体的には、テスト担当者の立場なら開発担当者の欠陥の対応が円滑に進むように、インシデントが故障かどうかの切り分け、故障の再現性の確認、故障発生環境の提供などの状況を判断しながら行っていくことなどが該当する。
- 自分の言ったことを他人が理解し、他人の言ったことを自分が理解していることを円滑なコミュニケーションを通じて確認する。
次のような情報は、開発担当者に欠陥の処置を促す動機付けになる。
- 故障が与える影響度(影響の範囲や重要度)が明確になっている
- 故障の再現手順が正しく報告されている
- 故障の内容が理解しやすい適切な表現を用いた報告が行われている
1.6 行動規範 ★★
- 公人 – 認定されたソフトウェアテスト担当者は、常に公人として行動しなければならない
- 顧客と雇用主 – 認定されたソフトウェアテスト担当者は、常に公人として行動しつつ、顧客や雇用主に最大限の利益をもたらさなければならない
- プロダクト – 認定されたソフトウェアテスト担当者による成果物(自身がテストしたプロダクトやシステムに関するもの)は、プロフェッショナルとして高いレベルのものでなければならない
- 判断 – 認定されたソフトウェアテスト担当者によるプロフェッショナルとしての判断は、誠実なものであり、かつ自身でなしたものでなければならない
- マネジメント – 認定されたソフトウェアテストマネージャ及びリーダは、ソフトウェアテストのマネジメントに対する倫理的なアプローチに同意した上で、これを推進しなければならない
- 専門職としての地位 – 認定されたソフトウェアテスト担当者は、公共の利益に寄与することで、専門職としての地位向上に努めなければならない
- 同僚 – 認定されたソフトウェアテスト担当者は、同僚に対し公正かつ協力的でなければならず、ソフトウェア開発者と協調しなければならない
- 自身 – 認定されたソフトウェアテスト担当者は、生涯その専門性を磨くための学習を続けるとともに、実践の場でも倫理的なアプローチを広めなければならない
Follow me!
