最新のテスト戦略の定義について調べた
テスト戦略について、2021年に発行された国際標準であるISO/IEC/IEEE 29119-2:2021とISO/IEC/IEEE 29119-3:2021をベースに書いていきます。
今日の学びのアウトプットです。
ここに書く内容は、あくまで上記の国際標準（29119-2と3）を私が解釈して書くので、正しく知りたい場合は標準を直接読んでもらうことをお勧めします。
テスト戦略の定義
特定のプロジェクト、テストレベル、またはテストタイプのテストアプローチを説明するテスト計画の一部。
注記 1: テスト戦略は通常、実装されるテストレベルとテストタイプ、使用される再テストとリグレッションテスト、使用されるテスト設計技法と対応するテスト完了基準、テストデータ、テスト環境およびテストツール要件、そしてテスト成果物に対する期待を一部または全部説明する。
過去のISTQBのFL(2018年度版まで)では、プロダクトまたは組織のレベルでの、テストプロセスに関する汎用的な考え方を提供するのがテスト戦略と呼んでいました。「テスト戦略はテストプロセスを汎用的に説明したものであり、テストアプローチは特定のプロジェクトまたはリリース用にテスト戦略をテーラリングしたもの」って書いてあったが、FLの2024年度版ではこういう記述がバッサリなくっています。多分2021年に国際標準にてこの定義が変わったので、合わせるって意味でも変えたんではないかと思われます。(確認したわけではなくあくまで想像です)
プロセスとしていつテスト戦略が作られるか？
ISO/IEC/IEEE 29119-2:2021はプロセスの標準なので、内容をサマると、テスト計画を作るときの流れの中の、「コンテキストを理解（つまり、状況把握）」して、「リスクの識別と分析」をして「リスクへの対処方法」を特定した後にテスト戦略を作ります。
テスト戦略を作った後、人のアサインとスケジューリング、テスト計画書として文書化して、計画の内容を関係者と合意していきます。
テスト計画書の中の技術的な部分の根幹になるのがテスト戦略なんだなっていう感想です。（要は今までの言い方だと、テストアプローチのことなので、「まぁ、そうなるよな」って思います）
テスト戦略を作る時の流れ
a) テスト戦略の設計
b) 活動の識別
c) モニタリングとコントロールをするメトリクスの識別
d) テストデータ要件の識別
e) テスト環境およびテストツール要件の識別
f) テスト成果物の識別
g) リソースの初期見積もりの作成
h) テスト戦略を文書化
i) テスト戦略の承認
テスト戦略の設計ってところでは、プロダクトリスク、テスト対象の要件など（テストベースから）、組織やプロジェクトでの決め事や守らなきゃいけないこと、プロダクトとして守らなきゃいけないこと（自動車業界なら自動車業界の決まりがあるとか）を考慮してテスト戦略作りましょう、ってことが書いてあります。
けど、具体的に設計するってどんなことするんだろうってことで、こんどはISO/IEC/IEEE 29119-3:2021というテストのドキュメント標準を見てみます。ここにはテスト計画書にはどんなことを書くか？って記載があります。さらに、サンプルも載っててイメージしやすいです。
テスト戦略はテスト計画書の一つの章として記載例がのってます。
アジャイル開発でのテスト戦略の記載例
アジャイル開発でテスト戦略の記載例がISO/IEC/IEEE 29119-3:2021のアネックスに載ってるので、そのうちの代表的なのを引用します。全部載せてませんし、私の解釈で意訳してるのでちゃんと読みたい人は標準を見てください。
また、アジャイル開発だけでなくトラディショナルなテストプランではどうかくかって例も標準には載っています。
テスト戦略:
・リリースおよびイテレーションプランニングで、ベロシティに基づいてテストと開発の労力を見積もり、イテレーションの終わりまでに完了できないユーザーストーリーや解決できない蓄積された技術的負債をバックログに戻す。
・コーディング開始前にストーリーに基づき、TDDで自動ユニット＆インテグレーションテストを作成する。新しいコードをシステムテストでテストし、外部システムとのシステム統合テストを行い、最後にユーザー受け入れテストを行ってストーリーを完了とする。
・顧客にユーザー受け入れテストに関与してもらう。可能な限り多くのテストを自動化する。
・前のイテレーション以降に変更された機能と、リリース前の全システムに対して、自動テストスイートを通じてリグレッションテストを実施する。
・受け入れ基準に最も適したテスト設計技法を使用し、高リスクストーリーは低リスクストーリーよりも徹底的にテストを行う。
・ストーリーがDoneになるときには、重篤度1または2の欠陥が未解決であってはならない。未修正の欠陥はすべて新しいユーザーストーリーに入れて、今後のイテレーションのためにバックログに置く。
・日々のスタンドアップミーティングでテストの進捗を報告する。計画通りにテストが進まない環境問題があればそれも報告する。
・すべてのテストはテスト管理ツールに、すべての自動テストスクリプトはコードリポジトリに保存し、再テストおよびリグレッションテストで再利用する。
・テストの開始、完了基準はDone定義に組み込む。
テスト戦略って言うと仰々しいけど、ようはテストを計画する時にどんな感じでテストするかちゃんと考えて書きましょうってことですね。あと、テストデータの要件や、テスト環境についてこの例では載ってませんが、トラディショナルなほうには記載がされています。また標準では、OTP（Organizational Test Practices）って呼んでいるものを作りましょう！って書いてあるのですが、組織でテストをするときにはどんなことをすればよいか標準的なやり方や具体的な例を挙げておくようにしておいて、それに従えば良いってすることで計画にいちいち書かなくて大丈夫ってことが記されています。たしかにそうだよね。バク管理の仕方とか、テスト環境の準備とか、いつもやってて決まってるなら、その通りやれば良いので毎回書く必要ないってことだと思います。
いいなと思ったら応援しよう！
