stivan622

ソフトウェアテスト教科書 JSTQB Foundation 第4版シラバス2018対応

第1章　テストの基礎
　1.1　テストとは何か？
　1.2　テストの必要性
　1.3　テストの7原則
　1.4　基本的なテストプロセス
　1.5　テストの心理学

第2章　ソフトウェア開発ライフサイクル全体を通してのテスト
　2.1　ソフトウェア開発ライフサイクルモデル
　2.2　テストレベル
　2.3　テストタイプ
　2.4　メンテナンス（保守）テスト

第3章　静的テスト
　3.1　静的テストの基本
　3.2　レビュープロセス

第4章　テスト技法
　4.1　テスト技法のカテゴリ
　4.2　ブラックボックステスト技法
　4.3　ホワイトボックステスト技法
　4.4　経験ベースのテスト技法

第5章　テストマネジメント
　5.1　テスト組織
　5.2　テストの計画と見積り
　5.3　テストのモニタリングとコントロール
　5.4　構成管理
　5.5　リスクとテスト
　5.6　欠陥マネジメント

第6章　テスト支援ツール
　6.1　テストツールの考慮事項
　6.2　ツールの効果的な使い方

第7章　模擬試験
　7.1　問題
　7.2　解答・解説

stivan622

テストとは？

テストとは、ソフトウェアがちゃんと動くかを見ることです。
これは、ソフトウェアの本番稼働時で問題が起きないようにするための活動です。

テストをしっかりやらないと、お金の損失や時間の無駄、信用を失うこと、怪我や命の危険などのリスクがあります。これらのリスクは、ソフトウェアを使う人（一般の人や会社）と、ソフトウェアを作る人（開発者や会社）の両方に影響します。

テストでは、ソフトウェアをリリースする前に、ちゃんと動くかを見ます。もし問題があったら、それを直して、リリース後に問題が起きないようにします。

テストの活動は、大まかには以下のようなものがあります：

テスト実行前作業：テスト計画の作成、テストケースの設計など
テスト実行中作業：テストケースの実行、テスト結果の記録など
テスト実行後作業：テスト結果の分析、報告など
テスト全体にかかわる作業：テストプロセスの改善など

これらの活動を通じて、ソフトウェアがちゃんと動くことを確認し、問題があったらそれを直すことで、ソフトウェアを本番稼働時に問題が起きないようにします。

Regenerate response

stivan622

テストの目的

欠陥を摘出する。

開発でのテスト(単体テスト、統合テスト、システムテストなど)では、なるべく多くの故障を見つけて、それを治すことが目的

対象ソフトウェアの品質レベルが十分であることを確認する。

開発したものがステークホルダーの期待する動作になっているかを確認することが目的
主に受け入れテストで行う

ステークホルダーの期待する動作になっているか確認
リリース時に、ソフトウェアの品質を確認し、どんなリスクを含んでいるのかをステークホルダーに情報提供する

意志決定のための情報を示す。

ソフトウェアの品質を見て、ソフトウェアをリリースするときに何か問題が起きるかどうかを、関係者に伝える

欠陥の作りこみを防ぐ。

保守テストでは、ソフトウェアの変更時に、新たに欠陥が混入していないかチェックするテストも実施する

stivan622

参考記事

stivan622

テストの7原則

原則1. テストは欠陥があることは示せるが、欠陥がないことは示せない

テストを実施してバグが発生した部分には確かにバグがあったということは示せる。
しかし、いくらテストをしてもバグがない事は証明できない

ただし、範囲を限定すればそれに対抗することができる

つまり、テストを行うときには、「どういう目的で、どの範囲について、どんな網羅基準でテストしたのか」の情報が大切

原則2. 全数テストは不可能

膨大なテストパターンを有限な時間で行うことは難しい

ソフトウェアの性質・目的・使われ方から、重点的にテストする機能を絞る
優先順位を決めてテストする

原則3.早期テストで時間とコストを節約

バグを検知するタイミングが、ソフトウェア開発工程の前工程であればあるほどテストにかかる時間を低減できる

開発者の頭がコーディング内容に対してホットなうちに欠陥を見つけないと、デバッグに時間がかかる

欠陥が複数作り込まれてしまい、欠陥の関連個所が多くなると、間違った直し方をしてしまう可能性も高まる

原則4. 欠陥の偏在

ソフトウェアの品質は均一ではない、欠陥がみつかる場所は、ある部分に集中する

効果的にテストを行うために欠陥偏在を過去の不具合分析や直近のテスト結果によって予測し、テスト箇所を絞り込むとよい

原則5. 殺虫剤のパラドックス

同じテストを何度も繰り返すと、新しい欠陥を見つけられなくなる
ソフトウェアは、テストセットに対する耐性を作っていく

対策：
新しい内容のテストを常に作っていく必要あり
入力パターンを変える
視点を変えたテストを作る

ただし、リグレッションテストは、デグレードの確認が目的のため、繰り返しの実行で問題ない

原則6.テストは状況次第

状況が異なればテストの方法も変わります。
安全性が重要な医療系のソフトウェアとECサイトではテストの方法が異なります。
アジャイルプロジェクトとシーケンシャルライフサイクルプロジェクトでは、テストの実行方法が異なる

下記を考慮して戦略的にテストをやりましょう

どんなシステムなのか
どんな機能があるのか
どんな機能は優先的にやるのか
どんな開発方法なのか
プロジェクトの状況はどうか
誰が使うシステムなのか

システムの目的にマッチしたテストケースを開発する必要がある

過負荷、多重入力、割り込みのテストをしたほうがいいか？を考える
正確性、セキュリティのテストをしたほうがいいか？を考える
使用性（簡単に使えるとか）のテストをしたほうがいいか？を考える

システムの開発方法や状況にあわせてテストを実施する必要がある

ウォーターフォール：テストは一気にまとめて実施すべきか？を考える
アジャイル：リグレッションを毎日回す必要があるか？を考える

原則7. 「バグゼロ」の落とし穴

発者は、仕様に対して欠陥のデバッグと修正を行い、バグゼロを目指す。
欠陥を修正し、バグがゼロになっても、システム全体の機能や性能がユーザにとって使い勝手の良いものでなければ意味がない
機能としては、「～できない」故障は解決できてもソフトウェアとして使い物にならない（処理重いとか）になったら意味がない

stivan622

JSTQBのテスト戦略（アプローチ）は、リスクベースドテスト

stivan622

「テスト技法」
　・入力の値：　同値分割法、境界値分析
　・ループ：　0回、1回、2回、MAX回
　・状態遷移：　状態遷移図・表、N-スイッチテスト
　・タイミング：　並行処理テスト
　・ロングラン：　統計技法、シナリオテスト技法
　・組合せ：　直交表やペアワイズなどの組合せテスト技法

stivan622

各開発者が作るモジュールの開発がすべて終わったら、それら多数のモジュールを一斉に結合しテストするため「ビッグバンテスト」と呼ばれました。

さて、「ビッグバンテスト」では、モジュールを単独でテストするための「ドライバー」や「スタブ」の開発が要らず、すべてのモジュールを好きにテストできるというメリットがある一方で、モジュール間インタフェースエラーの発見が難しく、デバッグが面倒というデメリットがありました。
したがって「ビッグバンテスト」は、小規模開発以外ではデメリットが大きいやり方でした。

stivan622

基本的なテストプロセス

テスト計画：テストの目的をはっきりさせます。テストのリリース時期やテストレベルなどを考えます。

テストのモニタリングとコントロール：テストの進行状況を見て、計画通りに進んでいるかを確認します。問題があったら、テスト計画を見直します。

テスト分析：テストする内容を決めます。テストベース（テスト対象の要件や設計情報など）をもとに、テストすべきフィーチャー（機能や属性）を識別します。

テスト設計：テスト条件（何をテストするか）を満たすためのテストケース（それをどうテストするか）を決めます。

テスト実装：テストケースをもとに、実際にテストを行うための準備をします。

テスト実行：テストを実行します。問題があったら、それを修正します。

テスト完了：テストが終わったら、結果をまとめます。

テストプロセスが必要な理由は、テストが行き当たりばったりにならないようにするためです。テストが行き当たりばったりになると、テストケースが漏れたり、テストの時間が足りなくなったり、故障を見つけられなくなったりする可能性があります。そのため、テスト計画を立てて、正しいテストプロセスを実行することが大切です。

stivan622

テストの心理学

開発者とテスト担当者の視点の違い：開発者は自分の作ったソフトウェアに対してプライドを持っているため、テストで欠陥が見つかると自分への非難と感じることがあります。一方、テスト担当者は欠陥を見つけることが品質向上につながる重要な活動だと考えています。

協調姿勢：開発者とテスト担当者は、ゴールが高品質のシステム開発であることを理解し、協力して作業を進める必要があります。

テスト担当者の中立性：テスト担当者は、欠陥を客観的に報告し、開発者を非難しないようにすることが大切です。

コミュニケーション：開発者とテスト担当者は、互いの説明が正しく理解されていることを確認するために、コミュニケーションを大切にする必要があります。

マインドセット：開発者とテスト担当者は、それぞれの役割に対するマインドセットを持ち、互いの能力を最大限に発揮して補完しあうことが求められます。

stivan622

テストとデバック

テストとデバッグの違いを理解することは非常に重要です。それぞれの目的と役割を理解することで、ソフトウェア開発プロセス全体が効率的になり、品質が向上します。以下に、それぞれの役割とその重要性について説明します。

テスト：テストの主な目的は、ソフトウェアの機能や性能を確認し、欠陥やバグを見つけることです。テストは、ソフトウェアが要件を満たしているか、期待通りに動作するかを確認します。テストは、ソフトウェアの品質を保証し、ユーザーが信頼できる製品を提供するために不可欠です。

デバッグ：デバッグは、テストで見つけた欠陥やバグの原因を特定し、それを修正するプロセスです。デバッグは、ソフトウェアの問題を解決し、その品質を改善するために必要です。

テストとデバッグの違いを理解することで、開発チームは以下のような利点を得ることができます：

効率的な問題解決：テストとデバッグの役割を理解していると、問題を効率的に特定し、解決することができます。テストで問題を見つけ、デバッグでそれを修正するという明確な役割分担があるため、開発プロセス全体がスムーズに進みます。

stivan622

ソフトウェア開発ライフサイクルモデル

ソフトウェア開発ライフサイクルモデルとは、ソフトウェアが完成するまでに行う活動（要求分析・要件定義、設計、コーディング、テスト）とテストの対応関係や時系列的関係を表したもの。

アジャイル開発の場合

開発システムをフィーチャー単位で分割し、ソフトウェアのフィーチャー（機能）単位で開発(要求分析・要件定義、設計、コーディング、テスト)を行う。

stivan622

テストレベル

テストを系統によって分別したもの。
ここでいう系統は、それぞれのテストレベルによって異なる。テスト目的、テストベース、テスト対象、テストタイプ、検出できる欠陥・故障、実行者、アプローチのこと。

テストレベル	目的	テスト対象	検出できる欠陥と故障	特別なポイント
コンポーネントテスト（ユニットテスト、モジュールテスト）	- 内在する欠陥を検出 - 機能的・非機能的振る舞いの検証 - 品質の確認	- コンポーネント(ユニット、モジュール) - コード・データ構造	- 正しくない機能 - データフローの問題 - 不適切なコードとロジック	-
統合テスト (コンポーネント統合テスト/システム統合テスト)	- インターフェースの欠陥を検出 - 機能的・非機能的振る舞いの検証 - インターフェースの品質確認	- インターフェース - API - サブシステム - データベース - インフラストラクチャー	- 不適切なデータ、データ不足 - 呼び出し順序の欠陥 - インターフェースの不整合 - コミュニケーション故障 - セキュリティ規制への非準拠	- 個々の機能テストを避ける - ビッグバン統合を避ける - 段階的統合を採用 - テスト実行者には内部構造理解と統合の影響理解が必要
システムテスト	- 法的/規制的要件または標準を満たすことの確認 - データ品質の検証	- アプリケーション - ハードウェア/ソフトウェアシステム - オペレーティングシステム - テスト対象システム - システム構成及び構成データ	- 期待通りでないシステムの機能的・非機能的振る舞い - 正しくない制御フロー・データフロー - 本番環境でシステムが適切に動作しない - システムマニュアル・ユーザーマニュアル通りにシステムが動作しない	-
受け入れテスト	- テスト対象の機能的・非機能的振る舞いの検証 - システムが完成し、期待通りに動作することの妥当性確認 ※欠陥の検出は目的に含まれない	- テスト対象システム - システム構成及び構成データ	- システムのワークフローがビジネス要件・ユーザー要件を満たさない - ビジネスルールが正しく実装されていない - システムが契約要件・規制要件を満たさない - セキュリティの脆弱性 - 高負荷時の不適切な性能効率 - 非機能特性の故障	受け入れテストの種類： - ユーザー受け入れテスト - 運用受け入れテスト - 契約による受け入れテスト - 規制による受け入れテスト - アルファテスト・ベータテスト

stivan622

テストタイプ

テストタイプは、テスト目的に焦点を当て区別したテストの種類。テストの実現手段の種類。
各テストタイプで、テストベース、適応するテストレベル、適応するテスト技法、カバレッジの集計方法、必要知識が異なる