JSTQB Fundation Level 受験勉強記事
単語
テストの独立性
独立性のレベルが低いほど、ソフトウェアの内部を熟知しているため、コードに含まれる欠陥を発見しやすくなるが、先入観やテスト以外の要因の影響を受けやすくなる。
独立性のレベルが高いほど、重要度の高い故障を発見しやすくなるが、テストの専門的な知識や視点を備えている必要がある。
Back to Backテスト
モデル(仕様)と実装されたコードの振舞いが同一であることを検証する。
ロードテスト
負荷を増加させ、コンポーネントやシステムがどの程度負荷に耐えられるかを判定する。
ストレステスト
予測または仕様化した負荷、もしくはメモリやサーバなどのリソースの可用性を低減したときの限界、または、それを超えた条件でシステムやコンポーネントを評価するテスト。
IEEE1008
米国国家規格 Standard for Software Unit Testingの規格番号。
IEEE1012
米国国家規格 Standard for Verification and Validationの規格番号。
テストレベル
一緒に編成されたりマネジメントされるテストアクティビティのグループ。プロジェクトの責務と紐付く。
V字モデルとテストレベルは次の4つ。
・コンポーネントテスト(ユニットテスト)
・結合テスト
・システムテスト
・受け入れテスト
テストタイプ
1つ以上の品質属性と関連付くコンポーネントやシステムのテストに照準を合わせたテストアクティビティのグループ。
テストベッド
テスト環境と同義。
テストマネジメントの支援ツール
・テストマネジメントツール
・要求マネジメントツール
・インシデント管理ツール
・構成管理ツール
テストウェア
文書、スクリプト、予想結果、セットアップやクリーンアッププロシージャ、ファイル、データベース、テスト環境、利用されるソフトウェアなど、テストの計画、設計、実行が行われるテストプロセス中に生み出される成果物。
デシジョンテスト
ホワイトボックステスト設計技法の一つ。判定を実行するテストケースを設計する。
デシジョンテーブルテスト
ブラックボックステスト設計技法の一つ。デシジョンテーブルにある入力と刺激(原因)の組み合わせを実行するテストケースを設計する。
デシジョンテーブル
入力と刺激(原因)、及び、対応する出力と処理(結果)の組み合わせを示す表。テストケースの設計に利用できる。
インスペクション
経験を積んだモデレータ(作成者ではなく)が進行を主導する公式性の高いレビュー。
形式の決まったフォローアッププロセスがある。
プロセス改善を目的としたり、ドキュメントを読む人を加えることもある。
レビューのフェーズ
計画 => キックオフ => 個々の準備 => レビューミーティング => 再作業 => フォローアップ
エラー
間違った結果を生み出す人間の行為。エラーがバグを生む。
故障
欠陥のあるプログラムを実行したときに、実行すべきこと(あるいは実行してはならないこと)を正しく実行できないこと。
故障の原因
ソフトウェア、システム、ドキュメントの欠陥と環境条件(ファームウェアのご動作やハードウェアの構成変更)などが考えられる。ドキュメントの欠陥があってもそれが故障にはならない。
インシデント
ソフトウェアシステムを実際に使うユーザやテスト担当者が期待する動きと実際の動きが一致しない事象。
コンポーネントテスト
構造テスト(ホワイトボックステスト)がよく行われていますが、機能テストや非機能テストも行うことがあります。
システムテスト
運用環境まわりの欠陥が内在するリスクを軽減するために、実際に使用する環境または運用環境と可能な限り同じ環境でテストすべきです。
スコープは、マスターテスト計画およびレベルテスト計画で定義される。
ブラックボックステストが主眼となるため、ステートメントカバレッジなどのホワイトボックステストの基準を終了基準に設定するべきではない。
探索的テスト
他の形式的なテスト技法の実施後に補完的に行うことで効果が大きくなります。
テストアイテム・テスト条件・テストケース
テストアイテム => テスト条件 => テストケース
テスト設計技法
以下の3つ。
・仕様ベース(ブラックボックステスト)
・構造ベース(ホワイトバックステスト)
・経験ベース
プロジェクトリスク
プロジェクトを遂行する際に影響を与えるリスク。「ヒト、モノ、カナ」のどの観点にも潜んでいる。
プロダクトリスク
ソフトウェアやシステムで失敗する可能性のある領域。
テストが漏れたことにより発生しうる損失や損害に対するリスク。
V&V(verification and validation、検証と妥当性確認)
検証(verification):決めたことを漏れや誤りなく実施しているか。
妥当性確認(validation):ユーザーが欲しいソフトウェアか。
テストオラクル
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。
オラクルは、実在する(ベンチマーク用の)システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
テスト設計仕様書
様式に、テスト対象のフィーチャ、テストアプローチ(テスト戦略)の改良点、合否基準が記述されるドキュメント。