テストについて

概要

プロジェクトではいろいろなテストを行うが、テストの種類や目的を理解しておくと良い感じがしたので、調べてみた。

結論

略称がいっぱいあって分かりづらいがある程度整理出来たと思う。
エンジニアからするとテストをしっかりして問題を抽出してくれることは非常に助かるものなので、
ちゃんと管理していきたい。（感想みたいになってしまった。）

テストの種別

大雑把にリスト化して出してもらいました。

テスト種別	略称	目的	実施タイミング	主なテスト内容
静的テスト	SAST	ソースコードや設計書の構文・セキュリティ欠陥を検出	実装前～単体テスト前	コードレビュー、Lint／静的解析ツール（SonarQube 等）
単体テスト	UT	モジュール／関数単位での動作検証	実装完了直後	正常系・異常系、境界値、例外パスの確認（JUnit／Jest／pytest 等）
結合テスト	IT	複数モジュール間のインターフェース整合性を確認	単体テスト完了後	API呼び出し／戻り値、例外時挙動、トランザクション整合性
システムテスト	ST	システム全体を稼働環境に近い形で検証	結合テスト完了後	E2Eテスト、基本的なセキュリティチェック、機能フロー検証
性能テスト	PT	応答時間やスループットなど性能要件を満たすか確認	システムテストと並行もしくは直後	レスポンスタイム測定、スループット・リソース使用率の検証
負荷テスト	LT	実運用想定の同時アクセス数やトラフィックに耐えられるか確認	性能テスト後	同時ユーザシナリオ、ピーク負荷、スケールアウト挙動
レグレッションテスト	RT	既存機能改修後に不具合が再発していないか確認	単体～システムテスト後のリリース前	過去テストケースの自動再実行による防止（CI/CD パイプライン連携）
運用テスト	OT	日常運用・監視／バックアップ手順が正しく動作するか確認	リリース前～リリース後初期	障害発生／リカバリシナリオ、バックアップ・リストア、ログローテーション
受け入れテスト	UAT	要件どおりに動作するかをエンドユーザー視点で最終確認	ステージング環境／リリース直前	ユーザーワークフロー検証、顧客承認テスト
フィールドテスト	FT	実運用環境下で限られたユーザーに展開して問題を検証	リリース直後のパイロット運用期	実業務での安定性、ユーザー操作性、環境依存不具合の抽出
セキュリティテスト	SecT	脆弱性スキャンや侵入テストでセキュリティリスクを検出	システムテスト以降	SAST／DAST／ペネトレーションテスト、CVE 脆弱性スキャン
インストールテスト	InstT	インストーラーの動作やアップグレード手順の正当性を確認	ビルド完了後	新規インストール、アンインストール、バージョンアップ、依存関係検証
ユーザビリティテスト	UST	実際のユーザー操作における使いやすさやアクセシビリティを検証	システムテスト以降	タスク完了時間計測、ナビゲーション評価、支援機能の有用性

基本の流れ

基本的なテストの流れとしては下記のようなイメージで実施します。

1. 要件定義
2. 設計
3. 実装（コーディング）
4. 単体テスト
5. 結合テスト
6. システムテスト
7. 受け入れテスト

ドキュメント

テストでは複数のドキュメントを作成するが、プロジェクト規模に応じて統合されて一つになっていたりする事がある…

テスト計画書

テストの要件定義書みたいなもの。
プロジェクトによって異なるが、テスト期間を設けてテストを実施する。
このときに基本的にテスト計画書を作成し、テストの目的や範囲、実施方法、スケジュール、制限事項（出来ないこと）を明確にしておく。
特に出来ないことを明確にして、その問題をどのタイミングで解決するかを明確にしておくことが重要である。

テスト設計書

テストの設計書みたいなもの。
テスト計画書を元に、テスト設計書を作成する。
テスト設計書では、テストの観点（機能/非機能）などを整理してテストケースを作れる準備を行うものである。

テストケース

テストの詳細設計書みたいなもの。
実際にテスターが実施できるレベルで細かく手順を明確にしたもの。
具体的な手順と期待値を記載しておき、テスト実施後に実施結果が記載できるようになっている。

不具合

テストでは不具合が見つかった場合の管理が重要である。

不具合報告

不具合が見つかった場合は、報告を行うのだが報告する項目をプロジェクトで明確にしておくと良い。
プロジェクトの状態や規模によって、報告する粒度が異なるため参考程度にしてください。

1. 問題が見つかったテストケース
2. 問題を発生させる手順
3. 問題の内容
4. 問題の影響度（他のテストが止まる要因になっているか？）
5. 再現頻度（例えば10回やって10回発生するか？）
6. エビデンス（スクリーンショット、動画やログなど）
7. 環境情報（OSやブラウザのバージョン、アカウント情報など）
8. 期待していた結果（期待値）

テスト管理

テストの管理を行うために、いくつかのグラフを使って進捗を管理することができる。

テスト実行進捗グラフ

実際にテストがどれくらい完了したかを管理するグラフ。
予定されている期間の中で、件数がしっかり減っているかを確認することができる。

欠陥（バグ）トレンド／累積残件数グラフ

不具合の状態を管理するグラフ。

• 新規報告件数
• 修正完了件数
• 累積残件数

これらの数値を確認して、不具合が減っているかを確認することができる。