JSTQB認定テスト技術者資格 Foundation Level試験対策 個人用メモ
試験対策問題を解いてわからなかった部分をシラバスから抜粋して以下に備忘録として記載する。
随時更新。
※順番とか形式をまとめたい。。。
●独立したテストの利点
- 先入観がないため、異なる結果を見つけられる。
- システムの仕様策定中や実装中に想定通りかを検証できる。
●独立したテストの欠点
- 開発チームから隔絶している。
- 開発担当者の品質に対する責任感が薄れる。
- 独立したテストチームは、ボトルネックと見られたり、リリース遅延のために非難されたりする。
●テスト仕様の支援ツール
- テスト設計ツール
- テストデータ準備ツール
●テスト実行と結果記録支援ツール
●性能・モニタリング支援ツール
- 動的解析ツール
- 性能テスト/ロードテスト/ストレステストツール
- モニタリングツール
●運用テストの目的
→信頼性や可用性などのシステム特性をチェックすること。
●テスト技法の違い
- 静的技法：故障より欠陥（故障の原因）を効率よく検出できる。
- 動的技法：欠陥より故障を効率よく検出できる。
●機能要件と非機能要件の違い
- 機能要件：要件定義の中で実装する機能に関する要件のこと
- 非機能要件：実装する機能以外の要件のこと
→属性として、信頼性、効率性、使用性、保守性、移植性などが関係する。
●ブラックボックス技法とホワイトボックス技法の違い
ブラックボックス技法
テストするコンポーネントやシステム内部構造についての情報を使用しない。
仕様ベースのテスト技法の特徴
- 対象となる問題、ソフトウェアコンポーネントを定義する場合、形式的、非形式的にかかわらず、モデルを使用する。
- モデルから、体系的にテストケースを導き出す。
- 同値分割法
- 境界値分析
- デシジョンテーブルテスト
- 状態遷移テスト
- ユースケーステスト
ホワイトボックス技法
コンポーネントやシステムの内部構造に基づく。
構造ベースのテスト技法の特徴
- ソフトウェアの構成に関する情報（コードや詳細化された設計情報）を基にテストケースを導き出す。
- テストケースを基に、ソフトウェアの構造に関するカバレッジを計測し、カバレッジを上げるためのテストケースを導き出せる。
●イテレーティブインクリメンタル開発モデル
システムの要件、設計、構築、テストを何回かの短い開発サイクルで繰り返してソフトウェアを作成するモデル。
具体例としては下記
- プロトタイピング
- RAD
- RUP
- アジャイル開発モデル
イテレーション（反復）によって開発されたシステムは、それぞれのイテレーション匂いつ複数のテストレベルでテストされる。
開発ずみのソフトウェアを追加する場合も、システムの一部を構成するのでテストが必要である。
開発を繰り返すたびに回帰テストの重要性は増していく。
検証や妥当性確認は、各繰り返しにおいて、実施できる。
●プロジェクトリスク
組織問題の要素
- スタッフのスキル、およびトレーニング不足、人員不足
- 人事の問題
- テスト担当者のニーズやテスト結果がうまく伝わらない
- テストやレビューで見つかった事項がチームでうまくフォローアップできていない。（例えば、開発やテストの実施方式が改善されていない）
- テストから期待できるものを正しく評価しようとしない。
技術的な問題
- 要件を正しく定義できない。
- 制約があるために、要件を拡張できない。
- テスト環境が予定通りに用意できない。
- データ変換の遅れ、移行計画の遅れ、データ変換/移行ツールの開発・テストの遅れ
- 設計、コード、構成データ、テストデータ、テストの低い品質
供給者側の問題
- サードパーティ製品の故障
- 契約上の問題
●プロダクトリスク
ソフトウェアやシステムで失敗する可能性のある領域（次に起きる事象が意にそぐわなかったり、危険を引き起こしたりする可能性）のこと。
- 故障の起きやすいソフトウェアの出荷
- ソフトウェアやハードウェアが個人や会社に対し損害を与える可能性
- 貧弱なソフトウェア特性（機能性、セキュリティ、信頼性、使用性、性能など）
- 貧弱なデータの完全性と品質（データ移行問題、データ変換問題、データ伝送問題、データ表人への違反）
- 指定の機能が動作しないソフトウェア
●テストリーダーとテスト担当者の実施作業の違い
テストリーダー（テストマネージャー、テストコーディネーターとも言う）
- テスト戦略とテスト計画をプロジェクト管理者やその他の関係者と調整する。
- プロジェクトのテスト戦略や組織のテストポリシーを策定したりレビューしたりする。
- テストの観点から、プロジェクトの他の活動（例えば、統合計画など）に貢献する。
- プロジェクトの背景を考慮し、テストの目的とリスクを理解してテストを計画する。
- テスト結果やテストの進捗に基づいて計画を修正し、問題を補正するために必要なあらゆる対策を取る。
- 構築するテスト環境を決定する。
- テスト期間中に収集した情報をベースにテストレポートを書く。
テスト担当者
- テスト計画に対してレビューによって貢献する。
- 試験性の観点で、要件仕様、モデルを分析し、レビューし、評価する。
- テスト仕様を作成する。
- テスト環境をセットアップする。
- テストデータを作成したり、入手したりする。
- 全てのテストレベルのテストを実装し、テストを実行して記録を取り、テスト結果を評価し、期待した結果との差異を文書化する。
- 必要に応じて、テストコントロールツールやマネジメントツール、モニタ用ツールを使う。
- テストを自動化する。
- 必要ならば、コンポーネントやシステムの性能を計測する。
- 他の人が実施したテストをレビューする。
●テストの終了基準
●レビューの種類
非公式レビュー
- 決まったプロセスはない。
- 主な目的は、金や時間をかけずにある程度の効果を出すことである。
ウォークスルー
- 作成者が進行を主導する。
- 主な目的は、ソフトウェアの内容を学習、理解し、欠陥を見つけることである。
テクニカルレビュー
- 同僚や技術のエキスパートが参加し、そのプロセスはあらかじめ定義し、ドキュメント化してある。
- 経験を積んだモデレータ（作成者ではなく）が進行を主導するのが理想である。
- 指摘一覧、ソフトウェア成果物が要求事項を満たしているかどうかの判定、そして適宜、指摘事項に関連する推奨事項を含むレビューレポートを準備する。
- 主な目的は、ディスカッションすること、判断を下すこと、他の方法を評価すること、欠陥を見つけること、技術的な問題を解決すること、仕様や計画、企画、標準に準拠していることをチェックすることである。
インスペクション
- 経験を積んだモデレーター（作成者ではなく）が進行を主導する。
- 同僚によるチェックが一般的である。
- 各人の役割が決まっている。
- メトリクスの収集が含まれる。
- 規則やチェックリストを使い、形式に基づいたプロセスで進める。
- ソフトウェア成果物の受け入れに対する開始、終了基準を決める。
- インスペクションのレポートや指摘一覧を書く。
- 形式の決まったフォローアッププロセスがある。
→プロセス改善が含まれる場合がある。
- 主な目的は欠陥の検出である。
●機能テスト、非機能テストの違い
機能テスト：システムが「何をするのか」のテスト
- 全てのテストレベルで実施する必要がある。
- ソフトウェアやシステムの機能からテスト条件とテストケースを抽出する際に仕様ベースの技法が使える。
- ソフトウェアの外部動作を検証する。
非機能テスト：システムが「どのように動作するのか」のテスト
- 全てのテストレベルで実施できる。
- 性能テスト、ロードテスト、ストレステスト、使用性テスト、相互運用性テスト、保守性テスト、信頼性テスト、運用テストなどがある
●テスト戦略、テストアプローチ
分析的アプローチ：例えば、緊急度が最も高い分野を重点的にテストするリスクベースのテストなど。
モデルベースアプローチ：故障率（信頼度成長モデル）や、使用法（運用プロファイル）に関する統計的情報を使う確率テストなど。
方法論的アプローチ：フォールトをベースにしたもの（例えば、エラー推測、フォールト攻撃）チェックリストをベースにしたもの。品質特性をベースにしたものなど。
プロセス準拠アプローチや、標準準拠アプローチ：例えば色々なアジャイル方法論や、業界固有の標準など。
動的で経験則に基づいたアプローチ：事前に計画するのでなく、発生した事項に対応する方法や、テスト実行と評価を同時に実行する探索的テストなど。
コンサルテーションテストベースのアプローチ：テストチーム外のビジネスドメインのエキスパート、又は技術的エキスパートの助言や指導を受けた部分から優先的にテストカバレッジを上げていく。
回帰的アプローチ：既存のテストを再利用したり、回帰テストを高度に自動化したり、標準のテストスイートを使うなど。
