テスト戦略を立てたい

0. あけましておめでとうございます！

新年あけましておめでとうございます。
この歳になって私気づきました、新年の抱負ってやることを増やす方向でしか考えられていないのでは無いでしょうか。
もうやりたいことだらけの日々で優先順位付けをするだけではルーチンに隙間がありませんし、それどころか自身の健康維持のための隙間も欲しいです。

"趣味をプロジェクト化して、隙間を増やす"が今年の抱負です。
抱負とは何か、言葉にならないイメージが胸に去来する。
日々のルーチンが飽和してきたので整理したいと思います。

1. はじめに

これはテスト戦略についての理解がふわっとしていた頃の「なんとなくわからない」を残すことで、何が理解できていないのかを明らかにする試みとなります。
箇条書きでまとめた要素についてコメントする形で自ら振り返ります。

腹落ちの過程を残すことで誰かのアイデア発想につながれば何よりです。

• 対象読者

  • QAの方
  • QAに興味がある方

• 背景:

  • テスト戦略を元に活動の振り返りをしたい
    • 人数が増えてきた時にメンバーの活動量だけでない指針が欲しい
    • 開発・QAでの共通言語を形成したい

  かっこよく書いたことを開くと「ふわっと理解していること発表することで意見を募り、具体的にモデリングしたい！」という気持ちで社内勉強会で発表しました。

• ゴール:

  • テスト戦略の基本的な概念を理解
  • テスト戦略策定の流れやアプローチ手法、リスク分析の活用イメージを掴む
    • 私たちでどうするかの想像につなげたい

2. テスト戦略とは何か

• 定義:
  • プロダクト全体の品質保証活動を方向付ける包括的な計画・ガイドライン
• 要素:
  • テストの目的・品質目標
  • テスト範囲・スコープ
  • テスト手法・ツール選定
  • リスク分析とプライオリティ設定
  • 品質メトリクス、継続的改善の仕組み
• メリット:
  • 最も効果的な領域を見つけ、リソースを配分する
  • チーム内で統一的な品質ビジョンを共有
  • 継続的改善を容易にし、品質向上の基盤を作る

特に”継続的改善の仕組み”を進められる指標が必要そう。
テスト戦略のドキュメントを作りました！ではなく、運用として周期的に振り返り、必要に応じて改訂する仕組みまで考える。

「なぜテスト戦略が必要なのか」を振り返ると、戦略を共有することで共通言語やビジョンを共有することが挙げられると気づきます。例えば、仕様の勘違いを減らしたい・会議を減らしたいが要求が伝わらない。

チーム規模が大きくなることでコミュニケーションの再定義がどうしても発生してきます。しかし時間は有限なので、コミュニケーションの基底はこういうところですよ、と示していくことがこれからもドライブしていくために必要です。

3. テスト戦略を作るための道筋

テスト戦略を棚に眠らせることなく、運用に乗せるまでにはどういう懸念がありそうでしょうか。

• ステップ例:
  1. 現状把握と目標設定:
     • 現在の品質課題を洗い出し、品質目標（例：主要機能での重大バグ0）を定義
  2. 品質基準・テスト範囲定義:
     • どの機能、どの品質特性（性能・セキュリティなど）を重視するか明確化
  3. テストレベル・種類の選定:
     • 単体、統合、システム、受入、パフォーマンス、セキュリティなど
  4. リスク分析とプライオリティ付け:
     • 高リスク領域に重点的なテスト投下
  5. テストアプローチ策定:
     • リスクベースド、要求ベースド、シナリオベースド、カバレッジベースドなどから選択
  6. メトリクス設定と継続的改善計画:
     • テストカバレッジ、バグ発生率など指標化し、スプリント毎に改善
• 結果物:
  • テスト戦略ドキュメント

自身のチームにフィットするように、「品質課題の洗い出し」「分析のための指標」が大事そう。
ここで「なんのためのテスト戦略か」という問いがしっかり現れたと思います。

4. アプローチ手法の例

• リスクベースド:
  • リスクが高い領域に重点。ビジネスクリティカルな機能や過去不具合多発部分にリソース集中
• 要求ベースド:
  • 要求仕様書を参照して全要求項目をカバー
• シナリオベースド(ユーザージャーニー):
  • ユーザー目線で実シナリオを辿る
• カバレッジベースド:
  • コードや機能の網羅率を指標にテスト構築
• モデルベースド:
  • 状態遷移やビジネスフローモデルから自動的にテスト生成

テストピラミッドやテスティングトロフィーなんかも参照。

アプローチは目的とリソースの兼ね合いで決定されるのが多そう。
アプローチ例に対して向き/不向きを考え、自身のチーム状況と照らし合わせてみようと思います。

5. アプローチ手法を決めるためのリスク分析

• リスク分析の視点:
  • ビジネスインパクト（売上への直結度合い）
  • 技術的複雑性（外部連携、複雑ロジック）
  • 過去の不具合履歴（どこでバグ多発？）
  • 非機能要件の重要度（性能、セキュリティ）
• リスク分析の結果活用:
  • 高リスク領域でシステム・受入テスト比重UP
  • 低リスク領域は単体テスト中心でコスト削減
  • 適宜、要求ベース、モデルベースなど他の手法と組み合わせ

現状のメディカルフォースを例にとるとどういったアプローチが良いか。

6. まとめ

• テスト戦略は品質改善の羅針盤
• リスク分析を基盤に最適なアプローチを選択
• スプリント毎の見直し・改善で戦略を成熟

7. 次にどうするか

ここまでの振り返りで「なぜ必要か」「なにが必要か」の指針を明確にする必要があると気づけたのが収穫でした。

• テスト戦略策定のために何が足りないか
  • 現状の開発チームにテスト戦略がなぜ必要か
  • 現状の開発チームのテスト戦略になにが必要か
    • 課題化して書き出し、進捗管理してプロジェクト化する

具体的な作業が明確になりました！
あくまで試行錯誤を言語化した記事となりますが以上です！