はじめに
この記事は株式会社ビットキー Advent Calendar 2023の24日目の記事です。
QAテストの管理方法として、機能ファーストと観点ファーストの2種類があるよ、という記事です。
なお、この記事で使っている「テスト観点」という言葉ですが、ここでは製品の評価指標という意味で使っています。例えば、
- 性能
- セキュリティ
- 負荷/連続
- 複合機能
- etc...
といったものです。それぞれの末尾にテストをつけて、「テスト種別」と呼ぶ方が世の中的には一般的かもしれません。
機能ファーストと観点ファースト
ソフトウェアエンジニアであれば単体テストを作成したり整理したりする際、
- 機能を大まかに分類する
- 分類されたそれぞれの機能についてのテストを列挙する
という業務を経験された方は多いと思います。これによって設計されるテスト項目群の構造を超簡易的に表すと下記のようになります。
- 機能Aのテスト項目群
- タイミング観点のテスト
- 性能観点のテスト
- セキュリティ観点のテスト
- 機能Bのテスト項目群
- タイミング観点
- 性能観点
- セキュリティ観点
最上位に機能があって、それぞれに各観点のテストがぶら下がっている格好です。こういった整理で管理されるプロジェクトでは、テストスケジュールやアサイン、テストシートは、機能ごとに管理されることが多くなるでしょう。この管理方法を機能ファーストと呼ぶことにします。
一方で、単体テストのような開発者テストではなく、テスター/テストチームによるテスト（いわゆるQAテスト）では、機能ではなく観点を先行させたテスト設計をすることがあります。
- その製品におけるテスト観点（テスト指標）を列挙する
- それぞれのテスト観点について、機能を列挙していく
このアプローチで設計されるテスト項目群の構造を、超簡易的に表すと下記のようになります。
- タイミング観点のテスト項目群
- 機能Aのテスト
- 機能Bのテスト
- 性能観点のテスト項目群
- 機能Aのテスト
- 機能Bのテスト
- セキュリティ観点のテスト項目群
- 機能Aのテスト
- 機能Bのテスト
こちらは、最上位に観点の一覧があって、そのそれぞれに機能ごとのテストがぶら下がっている格好です。こういった整理/アプローチで進めるプロジェクトでは、テストスケジュールやアサイン、テストシートは、観点ごとに管理されることが多くなるでしょう。この管理方法を観点ファーストと呼ぶことにします。
機能ファーストと観点ファースト、どちらかが絶対的に正しいということはないと考えています。ただ、どちらを選択したかによって、シチュエーションごとのプロジェクト管理の難易度に違いが出てきます。この違いは、テスト対象が大規模になるにつれて（管理するべきテストケースが多くなるにつれて）大きくなっていきます。理想は両者を上手く使い分けることでしょう。
テストの抜け漏れ
市場での不具合報告を減らすためには、なるべく不具合が起きやすい部分にテストの抜け漏れがないようにしなければなりません。前述の２つの管理方法のうち、よりテストの抜け漏れを防ぎやすいのはどちらでしょうか。
仮にテスト項目/内容を機械的に自動列挙していけるのであれば、両者に違いはありません。上記2つの例をよく見ると分かりますが、列挙されるテストの数は同じですし、機能と観点の組み合わせも同じです。当たり前ですね。
しかし、上記の例はとても単純にしているので機械的にできそうですが、実際は人間が抜け漏れがないかをチェックしたり取捨選択したりする必要があります。もちろんソースコード、仕様書、回路図、品質指標などを入力として、現実的な工数に収まる最適なテスト群を自動出力してくれるAIが登場すれば話は別ですが、2023年12月現在においては、テスト設計（の最上位から少なくともある程度下位レイヤーまで）をするのは人間です。テスト設計を人間がする前提だと機能ファーストと観点ファーストとでは抜け漏れやすさに差が出ます。
どちらの管理方法にするかを決める材料の1つは、「組織や責任者の意志として、抜け漏れさせたくないのが機能なのか観点なのか」、だと考えています。ただしこれは下記仮説が正しいことを前提としています。
- 管理における上位レイヤーの要素ほど多くの人の目に付くことになり、抜け漏れを検知しやすい
- 逆に下位レイヤーの要素ほど属人的になりやすく、抜け漏れを検知しにくい
つまり機能の抜け漏れを防ぎたいなら機能ファーストを、観点の抜け漏れを防ぎたいなら観点ファーストを選択するのが良いということです。ただこれは私の経験則に過ぎませんが、ことQAテストにおいて機能の抜け漏れというのはあまり見たことがありません。そもそも機能というものはテスト管理において上位にあろうがなかろうが多くの人の目につくからではないか、と考えています。そういうわけで、QAテストの管理では観点を上位に置いて複数人が常にチェックできる状態にするほうが、抜け漏れなくできる可能性が高くなるのでは、と考えています。
変更への追従
アジャイル開発では機能が後から追加されることを前提としています。このときテスト管理が機能ファーストであれば、管理としては単純な追加作業なので、追加工数、追加コストを比較的簡単に見積もることができます。一方テストプロジェクト管理が観点ファーストの場合、機能追加による影響が各管理対象に散らばっていく格好になります。つまり、観点ごとに管理されたものを一段深掘りしてテスト対象機能を追加し、それをまた上位に上げて集計する作業が発生します。この作業は、大規模なプロジェクトになればなるほど重くなります。以上のことから、テスト対象とするソフトウェア変更への追従は、機能ファーストの管理方法が有利だと考えています。
この点に関しては、QAテストだけでなく、開発者テストでも同じです。実際、単体テストなどの開発者テストは、機能単位（≒ソースコード単位）で管理されていることがほとんどです。その理由は、ソフトウェアは機能単位で開発されるものであって、直接そこに追従させるべきテストもその単位で管理するのが効率的だからです。逆に、単体テストが観点ファーストで管理されていたとするとどうでしょうか。開発者は機能を追加するたびに、観点ごとにまとめられたテストファイルを複数ピックアップして、それぞれにテストを追加することになります。何となく非効率的な感じがしますよね。
テスト実施効率
テストによっては、特殊な検査治具、特殊な環境を必要とする場合があります。例えば、電流測定機、静電気印加冶具、電波暗室などです。テストプロジェクトにおいて、これらの検査治具、特殊な環境を必要とするテスト群がひとかたまりになっていた方が管理しやすくなることは想像に難くないでしょう。これらはテスト実施直前に治具のセットアップ作業が必要になりますし、場合によってはテスター自身が遠く離れた場所に赴く必要があったりもします。テストをリリースまでに終わらせるためにはこうした時間はなるべく抑えて、効率よく実施したいところです。
ではプロジェクトを管理する上で、特殊な検査治具、特殊な環境を必要とするテストをまとめるには、観点ファーストと機能ファーストのどちらが向いているでしょうか。これはケースバイケースです。
例えば、「ソフトウェアが持つ機能Aをトリガーするには外気温を60度にしなければならない」という制約があったとします。この場合は機能Aに関するテストを一括りで管理して、スケジュールやアサインを決めたくなりますよね。よって機能ファーストが望ましいでしょう。
逆に観点ファーストが望ましいのは、例えばテスト対象の製品に「全ての機能をxxmA未満のピーク電流で実現する」といった仕様がある場合です。この場合、電流測定機が必要になるテスト群を性能観点でのテストとして全機能一括りに管理することができます。
まとめ
機能ファーストと観点ファースト、それぞれの管理手法についていくつかの論点で比較しました。先に書いた通り、これらのアプローチのどちらかが絶対的に正しいということはなく、両者のメリット/デメリットを理解して使い分けることが重要だと思います。
25日目の 株式会社ビットキー Advent Calendar 2023 は @pauli-agile が担当します！