はじめに
◆この記事は何？
テスト戦略のサンプルドキュメントです。
◆対象は？
テスト戦略の立案に関わる方
◆ねらい
様々なプロジェクトで活用できるテスト戦略のテンプレートを提供するのがねらいです。
何を書くべきかわからない方に向けて、テンプレートだけでなくサンプルを記載します。
サンプルの根拠を示すために参考文献も記載します。
◆前提
- アジャイル開発でのwebアプリケーション開発を前提に、テスト戦略のサンプルを作成します
- 皆さんのプロジェクトの状況に応じて、編集してください
- テスト戦略そのものに関係のない補足コメントは「info」で追記します
テスト戦略についてご意見があればコメントをお願いします。
サンプルドキュメント（テンプレート）として改善していくつもりです。
Qiitaの「Markdownで本文を見る」機能を使用することで、Markdown形式でコピーできます。
テスト戦略のサンプルドキュメントはここからです。
はじめに
テスト戦略の目的
- テストの進め方について、チームで合意するため
- 個人の経験だけに基づかずチームの経験に基づいて、プロダクトの品質向上に生かすため
「テスト戦略」と「テスト計画」の違い
テスト戦略に基づいて、テスト計画を作成する。
テスト計画では具体的なテストの日程を明確にする。
対象
本ドキュメントの対象者は以下とする。
- XXプロジェクトメンバー
- 特にスクラムチームメンバー
用語
テストについてチームメンバーで認識を合わせるために用語を定義する。
◆テストレベルについて
- E2Eテスト（業務フローテスト）
- 外部ストレージや連携するサブシステムを含むテスト
- 例：ユーザー登録からログイン、商品購入、決済までの一連の流れをテスト
- 結合テスト
- 複数モジュールが連動する機能に着目したテスト
- 例：検索機能とデータベースクエリの連携テスト
- 単体テスト
- テスト対象モジュールが定められた入力値から期待する出力値が得られるかをテストする
- 例：数値計算関数（例：割引計算）の入出力テスト
テストレベルについて、それぞれ例を書くことを推奨します。
人やプロジェクトによって、それぞれのテストレベルが何を指しているかが変わります。
例を書くことで、テストレベルの認識を合わせやすくなります。
◆テストタイプ
- 機能テスト
- ソフトウェアが提供すべき機能の有無や機能の適切性をテストする
- 非機能テスト
- 性能テスト
- ソフトウェアの性能（主に処理時間）を評価する
- セキュリティテスト
- 脆弱性がないことを確認する
- ユーザービリティテスト
- ソフトウェアの使い勝手を評価する
- 性能テスト
プロジェクト概要
プロジェクトの目的
プロジェクトの目的を記載
プロジェクトの背景
プロジェクトの背景を記載
プロジェクトのタイムライン
プロジェクトのタイムラインを記載
特にテストに関わる締め切りを明確にする
プロジェクトの前提
- 開発プロセス
- アジャイル開発を採用
- スクラムを採用
- 開発言語
- フロントエンド
- React(JavaScript)
- バックエンド
- Python
- フロントエンド
リスク分析
プロジェクト固有のリスクについて
プロジェクト固有のリスクを記載する
難易度が高い、複雑性が高いモジュールに注目する。
テスト目標と品質基準
テスト目標
- 単体テスト
- C1分岐網羅率80%以上
- 全てのpublicメソッドについてテストコードを作成
- 結合テスト
- データベース操作を含むすべてのトランザクションフローのテストを実施
- E2Eテスト
- ハッピーパス100%
- 性能テスト
- ピーク時の想定ユーザー数の1.5倍の負荷で応答時間3秒以内
- セキュリティテスト
- 脆弱性診断ツールでCriticalな脆弱性0件
- ユーザービリティテスト
- System Usability Scale (SUS) スコアで75点以上
品質メトリクス
- WMC(クラス当たりの平均メソッド数)
- 20以下
- 循環的複雑度
- 20以下
受け入れ基準
ユーザーストーリーひとつに対して、受け入れ基準をひとつ作成する。
テスト環境
- 単体テスト
- 開発者のローカルマシンで実行する
- 結合テスト/E2Eテスト
- 開発環境にデプロイされたWebアプリで実行する（打鍵）
- CICD
- GitLab CI/CD
テストプロセス
リソースの配分
「テスティングトロフィー型」を採用する。
結合テストを重視する。
テストアクティビティ
- 継続的テストモデルを採用する
- ユーザーストーリー作成時に、受け入れ基準を作成する
- スプリント開始前に、「完成の定義」を作成する
- テストファーストを採用する
- コーディングを実施する前に、少なくとも一つ以上のテストケースを設計する
バグ管理プロセス
プロジェクトでのバグ管理プロセスを記述する。
報告方法、追跡方法など
静的解析
- Linterを使用する
- Formatterを使用する
レビュー
ウォークスルー形式を基本とする。
重視するレビュー観点は以下の順。
- 変更容易性
- テスト容易性
- モジュール性
- 信頼性
- 再利用性
- 効率性
テストアプローチ
自動化の範囲
単体テスト、結合テストは自動化する。
E2Eテストは手動で実施する。
使用ツール
プロジェクトで使用するツールを記載する（Jest, Pytestなど）
役割
- 誰がテストを設計するか？
- 開発者
- 誰がドキュメントをレビューするか？
- リーダー
- 誰がドキュメントを承認するか？
- リーダー
- 誰がテストを実行するか？
- 開発者
テスト戦略のサンプルドキュメントはここまでです。
おわりに
この記事では、テスト戦略のテンプレート及びサンプルドキュメントを提供しました。
テスト戦略立案時に参考になれば幸いです。