#■はじめに
下記の内容については、
参考記事（プログラミングとテストの要点）を主に参考に基本的な内容を私個人の独断と偏見でまとめてみた内容となっています。
賛否両論、過不足のある内容とは思いますが、１つの意見（見解）として参考にして頂ければと思います。
※上記の参考記事は、簡潔に要点をおさえた内容と感じましたので、参考記事としてお勧めいたします。

#■不具合の原因/要因について（個人見解）
　開発者は担当する機能が正しく動作するように完璧に仕上げることは念頭に開発を行っていると思いますが、それでも「想定できなかった部分」や「想定しきれない部分」など、いわゆる想定外による不具合（バグ）を完全になくすことはできないと思います（※開発規模が極めて小さければ可能な場合もある）
　不具合（想定外）の原因は、設計や定義などの考慮不足や漏れ、仕様確認や仕様変更などの情報共有が遅延した場合、又は、開発者のケアレスミス、仕様や設計の誤認、修正（作業）による影響範囲の誤認、外部要因など様々な要因があると思います。
　テスト実施者は、テスト項目と各項目の期待する結果も含めて客観的な視点で「腑におちない点」がないかも併せて確認できることが望ましいと考えます。
「腑におちない点」とは単純に「ん？」って感じる違和感です。「あれ？これ何かおかしくない」とか「これ大丈夫？」って感じる点です。
「腑におちない点」があるということは、お客様（運用者）から見ても腑におちない点である可能性が高く、それに対して設計者又は開発者が十分な説明ができないのであれば、要件の誤認、設計不備や考慮漏れなどの問題が潜在している可能性が高いと思うからです。

#■テストの考え方
　「テスト対象機能が予め定められている要件や仕様／設計通りに正しく動作することを確認することが大前提」となります。
設計者や開発者が当初「想定できなかった部分」が開発／テスト工程を進めていく過程で、顕在化することもあると思いますので、設計書に記載がない仕様だからといってそれがイコールで不要／問題ないと決めつけるようなことは避けてほしいと思います。
※「テスト仕様書を作成する際に抑えるべきポイント」を記載しておりますが、正直、難しいですね。。。経験上で不具合が発生しやすいと思わる点をあげさせて頂きます。
　原則としては案件の開発ルールやテスト観点／方針を必ず確認し、それらに準ずるかたちで作成するようにしてください。

#■単体テスト（プログラムテスト）
　単体テストとは、プログラムが設計書通り要求される機能を満たし正しく動作するかどうかをチェックすることです。
基本的にテストケースはプログラム構造設計書に記述されている、全処理パターンが対象となります。
すなわち、記述されたプログラムの全ルートをテストすることがテストの目的となります。

＜テスト仕様書を作成する際に抑えるべきポイント（例）＞
　・境界値の判定（以下、未満、以上、超過、イコール）
　・関数パラメータの組み合わせ（全処理パターン、共通系除く機能固有の実装関数）
　・入力値などの各種バリデーション、又は、入力値とDB登録値の差異
　　⇒ 型、定義値、必須性、文字数、大文字／小文字、全角／半角、空白（NULL）
　・空値（未入力=''）、空白（半角／全角）、空白含む文字列値の判定や加工（trimなど）
　・エラーハンドリング（Exception）
　　⇒ エラー発生の検知可否、エラー原因の通知、エラーの判定ログ出力、ロールバック処理など
　　※設定や定義されていない値などがバグなどによって渡された場合、それに対するチェックおよび適切にエラー処理されることなど。

#■結合テスト
　結合テストは、プログラムテストの後に行われるテストで、いくつかのプログラムを組み合わせて、1つの機能として正しく動いているかを確認します。
例えば、プログラム間のデータの受け渡しや、画面遷移が正しく行われているかなどを確認します。

＜テスト仕様書を作成する際に抑えるべきポイント（例）＞
（※Webアプリの場合）
　・異なる複数ブラウザにて並行操作した場合の動作
　・複数タブにて並行操作した場合の動作
　・ブラウザバック（前画面へ）、ダブルクリックした場合の動作
　・GET／POSTパラメータを不正値に変更した場合の動作（hidden含む）
　　⇒ 不正値（定義値外）への考慮、セキリティテスト的な観点
　　　（ブラウザの開発ツールなどで編集可能な範囲）
　・入力値とDB登録値の差異（空白とNULLの差異、余白の有無、文字化け、桁落ち）
　・セッション制御がある場合、有効期限切れ時の動作
　・システム間連携時の通信障害時などの動作（レスポンスなし、タイムアウト時の考慮）

#■システムテスト（総合テスト）
　システムテストは、結合テストの後に行われるテストで、全ての機能を組み合わせて、1つのシステムとして、正しく動いているかを確認します。
ユーザの要件どおりに動いているか、機能間の連携はとれているか、性能（処理の速さなど）は問題ないかなどを確認します。

＜テスト仕様書を作成する際に抑えるべきポイント（例）＞
　・機能要件を満たしているか
　・性能要件を満たしているか
　・セキリティ要件を満たしているか（個人情報の扱いなども含む）
　・障害対策（メンテナンスモード、冗長化構成の切替可否(Web障害、DB障害)、バックアップからのシステム復元）

#■運用テスト（シナリオテスト／受入れテスト）
　運用テストは、開発が完了（システムテストが終了）したシステムに対し、実際のシステム利用者がテストを行い、業務運用上の支障がないかを確認するテスト。
基本的なテストの観点は、前述した通り、**「実際の業務に沿ってシステム動作を確認する」**ことだ。
通常業務シナリオに沿ったテストはもちろん、レアケース業務だったり、異常対応業務だったりと、様々なシナリオを業務視点で作成する。

＜テスト仕様書を作成する際に抑えるべきポイント（例）＞
　・運用者の誤操作によるデータ削除してしまった場合（復元可否、操作対象者の特定、など）
　・何らかの定義値（種別、区分など）を変更（追加、削除(無効化)、変更）した場合（機能要件に含む）

#■参考記事