これはソフトウェアテストの小ネタ Advent Calendar 2022の20日目の記事です。
はじめに
皆さんの開発現場では、不具合の流出を防ぐために日々あらゆるテスト活動が行われているかと思います。開発チームによる単体/結合テスト、QAチームによるシステムテスト、SREチームによる負荷テスト等、その種類は様々です。
工程別・目的別にテストを使い分ける事によって意図通りの不具合を検出することが可能になりますが、実はこれらのテスト、テスト技術者資格のJSTQBシラバスやテスト関連の書籍の間でも定義に差分があったりと、何か統一された一つの定義が国内にある訳では無いのです。
例えば「結合テスト」と言っても、API単位でのテストを指すのか、DBとの結合を指すのかなど、現場内での共通の定義が固まっていない場合、人によって広く解釈が可能になってしまいます。
「テストレベル-テストタイプ」はソフトウェア開発の現場ごとに定義され、開発チーム全体に周知されている必要があります。
テストレベル-テストタイプを定義することのメリット
テストレベル-テストタイプを定義することには、下記のようなメリットがあります。
１．開発現場での共通の定義が出来ることで、テスト改善の議論がスムーズになる
「〇〇テストを充実させよう」というような議論の際、「どのチームが主体になるのか？」「本来どの粒度で実施されるべきものなのか？」「どんな不具合を発見する目的で実施されるテストなのか？」が事前に整理されているため、各チーム間でのコミュニケーションが容易になります。
２．テストアーキテクチャの設計が可能になる
テストプロセスの中で実施するべきテスト・観点を細分化し、適切な箇所に割り振ることで品質保証の整合性を取っていく、テストアーキテクチャ、テストコンテナという考え方があります。
テストレベル-テストタイプを事前に定義することで、このテストアーキテクチャ内に何を割り振っていけば良いのかの整理が可能になります。テストアーキテクチャについては 西康晴 QAアーキテクチャの設計による説明責任の高いテスト・品質保証 2016 電気通信大学をご参照ください。
テストレベルの定義
上記メリットを享受するため、まずは テストレベルの定義 から開始しましょう。テストレベルとは、開発モデルの段階ごとに該当するテストのことを言います。
テストレベルを定義した例が下記となります。各テストレベルごとに実施主体、役割を明記しています。
決定のためには開発全体での議論を行う必要がありますが、たたき台作成の際には、文末に記載の参考資料P25〜27「テストの概要」が大変参考になります。
この定義はスクラム開発、ウォーターフォールのどちらにも適用できるものになります。例示されている定義の内容はウォーターフォール(W字モデル)の定義に近いものとなっていますが、両者スピードや規模感の違いはあれど、プロセスの中で実施が必要なテストの種類には違いは生じないため、同様の考え方を用いることができます。
それに伴い「レビュー」も開発工程(要件定義、設計、実装)で行われる静的テストとしてテストレベルに含めることも可能です。
また、通常は運用テスト・受け入れテストは顧客が実施主体となりますが、自社開発の現場では、開発チーム外のビジネス側のチーム、PO/PdMを顧客と見立てて定義を行うことも可能です。
テストタイプの定義
続いて、 テストタイプの定義 です。
テストタイプとは文字通りテストの種類のことで、特定のテスト目的にそれぞれフォーカスを当てています。「機能テスト」がよくテストレベルと混同されやすいですが、テストタイプに含めるようにしています。
こちらも開発チームやSREチームへのヒアリングと議論を行い、現場に最適な定義を行う必要があります。
テストレベル同様、議論のたたき台作成の際には、文末に記載の参考資料P25〜27「テストの概要」が大変参考になります。
テストタイプの例が下記です。
テストレベル-テストタイプ対応表
それぞれの定義が完了し、最終的に下記のような テストレベル-テストタイプ対応表 にまとめることができます。
開発初期の要件定義から、最後の受け入れテストまで、工程ごとにどの様なタイプのテストが実施可能か、実施するべきかという所を整理しています。
さらに、ソフトウェアの内部構造に着目するかしないかの観点を「ブラックボックステスト」「ホワイトボックステスト」に分けて縦軸に、ソフトウェアを動作させるかさせないかの観点を「静的テスト」「動的テスト」に分けて横軸に置き、各テストがどの様な位置づけであるかを明示出来るようになります。
この対応表のたたき台作成の際には、文末に記載の参考資料P23「さまざまなテストと分類」図2-6 代表的なテストの分類 が参考になります。
おわりに
テストレベル-テストタイプが定義されたことで、開発・QAでテストに関する改善を進めるためのコミュニケーションの土台、目線合わせを行う準備ができました。
品質作り込みのための実装前の静的テストや、エンジニアが実施主体となるホワイトボックステストも合わせ、開発プロセス全体で必要なテストの最適化をチーム全体で行っていきましょう。
参考資料
テストレベル-テストタイプの定義の際、下記の書籍に記載されている各テストタイプおよび対応表をたたき台作成の参考にしました。
※今回は手元にある初版を参考にしていますが、現在第2版が出ていますので新しく購入される際は新版の購入をお薦めします。
【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践
書籍情報：
石原一宏 (著), 田中英和 (著), 田中真史 (監修)
『【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践』(SBクリエイティブ、2012)
参照元：
P23「さまざまなテストと分類」図2-6 代表的なテストの分類
P25〜27「テストの概要」