テストタイプってなんなの？
はじめに
本記事は以下の記事からインスパイアされています。
これらについて考えるにあたり、「テストレベル」「テストタイプ」それぞれについて語るべきところがあると思いました。
こちらに記載する記事は「オレオレ定義」であり、「正しい定義」を知りたい場合は規格等を参照してください。
一方で、私はそれでもzennで書く意味はあると考えています。
読者の方がこの記事を読むことによって「テストタイプ」に対する理解や思考が深まることを期待するからです。
この記事を元に自分はどうだろうと考えたり、議論していただければ嬉しいです。
テストタイプの意味
テストタイプの定義を見てみる
「テストタイプ」という用語はISTQBで定義されています。
テストタイプ（test type）
コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたもの。
References After TMap
https://glossary.istqb.org/ja_JP/term/test-type-2
「テストの目的を基に」とあるので、「テストの目的を対応する特性を表したもの」とも言えるかもしれません。
After TMapとあるので、TMap Nextの定義も見てみます。
A group of test activities with the intention of checking the information system in respect of a number of correlated (part aspects of) quality characteristics.
TMap Next: For Result-driven Testing
TMapの方は、明確に品質特性に紐づいています。
また、JSTQB FL V4.0の記述も見てみます。
テストタイプは、特定の品質特性に関連するテスト活動のグループであり、それらのテスト活動のほとんどは、すべてのテストレベルで実行することができる。
JSTQB FLV4.0
これらの定義には若干の揺れがあるように見えます。
一方で同じような性質も見て取れます。
- テストの活動をまとめたもの
- 品質特性に関連がありそう
- テストの目的を表す
定義の揺れがありますがこういうことが要素としてありそうですね。
テストタイプの例
テストタイプについて、もっとも多いのは「品質特性に紐づいたテスト」だと考えています。
以下のような形ですね。
- 機能テスト
- 非機能テスト
- 使用性テスト
- 性能テスト
- 信頼性テスト
「こういった例がある」ということを認識合わせした上で次に進みます。
テストタイプの選ばれ方
「テストタイプがどのように選ばれるのか？」を考えるにあたって、
演繹的なテストタイプと帰納的なテストタイプというものを考えます。
これは公式の用語ではなく、私が作った造語です。
トップダウンとボトムアップという場合もあります。
演繹的なテストタイプ
演繹的なテストタイプとは、あるテストタイプパターンからブレイクダウンして実施のテストタイプを選ぶものです。
たとえば品質特性のセットからブレイクダウンしたり、組織の標準テストタイプからブレイクダウンしたりする場合です。
こういったテストタイプの選ばれ方は比較的大きな組織や、品質水準が設定されている組織で存在します。
帰納的なテストタイプ
帰納的なテストタイプとは、「テストの目的」や「テスト条件」や「テストケース」といった具体的な内容から集約して「テストタイプ」を識別するやり方です。
帰納的なテストタイプはテストタイプの定義がより柔軟です。
しかしながら、帰納的なテストタイプはテストタイプでのテストの十分性の説明が難しく、またテストタイプレベルでのテストの抜けが発生する場合があります。
テストタイプのセットはテストアーキテクチャの一側面である
「テストタイプのセット」「テストタイプパターン」と書きましたが、これは私の造語です。
「テストタイプのセット」とは、テストタイプを列挙する形で表す全体像です。
「テストタイプパターン」とは、テストタイプのセットにおける一定のパターンです。
これらはテストアーキテクチャの一側面を表します。
「これらのテストタイプで我々はリリースできるよね」というものを端的に表したものが、テストアーキテクチャ一側面であるという考え方です。
これらは、今後「どのようにテストアーキテクチャ設計をするか」と考えてから、どのようにしてテストタイプを導出するか考えるのもいいかもしれません。
テストタイプは実装するのか、識別するのか
演繹的なテストタイプの場合、ブレイクダウンして「実装」することになります。
帰納的なテストタイプの場合、集約して「識別」することになります。
これらは結果として必要なテストの全体像を導くことになりますが、考える頭や思考プロセスには違いがあります。
さまざまなテストタイプのセット
私が見たことがあるテストタイプのセット、およびテストタイプパターンについて言及します。
品質特性
これは私が知っている唯一のテストタイプパターンです。
そして、帰納的なテストタイプです。
テストタイプと品質特性が対応している場合は品質特性パターンが該当します。
品質特性はISOなどで定義されているある程度一般的な品質モデルであり、元々のISTQBなどのテストタイプの定義と同じであると言えます。
なので、結構使う人は多いです。
テストマネージャーがテスト関係者以外のステークホルダーに対して、さまざまなテストをやっていると表明できます。
また、品質特性レベルで抜け漏れがないか確かめるのに使えます。
もっとも代表的なパターンです。
要件定義に合わせる
「要件定義に合わせる」は私の好きなやり方です。
そして、帰納的なテストタイプです。
ここでの機能テストは「機能要件に対応するテスト」、非機能テストは「非機能要件に対応するテスト」です。
ですので、要件定義がないテストはテストがされません。
これは「要件定義がないからテストしません」ではないです。
むしろ、テストを定義した時点で要件定義にフィードバックすることを表しています。
シーケンシャルな開発の場合には、性能要件などは実際にソフトウェア動かしてみないと決められないという場合もあります。
その場合でも「決められない」「計測する」ということを決めたりします。
要件定義とのトレーサビリティも取れるので、開発のドキュメンテーションを重視する開発には向いていると考えています。
一方で、テストをドキュメントとする文化では成り立たないテストタイプパターンでもあります。
テストのやり方
このパターンは私はよく見ます。
これは演繹的なテストタイプです。
「ユーザビリティテストを行う」「性能テストツールで性能テストを行う」「セキュリティテストは専門家が行う」などのテスト実行の手段で識別している場合が度々見られます。
テストベンダーやマルチベンダー体制などの大規模のテスト組織では、このようなパターンを見ることがあります。
このパターンには、タスクや見積もり、あるいは必要なリソースや専門性をすぐさま識別できるという利点があります。
テスト観点のまとまり
テスト観点のまとまりで識別している場合もあります。
これは演繹的なテストタイプです。
これはテストで確認したいことをまとめて、それに端的な意味を表した言葉をつけます。
これらは「テストの目的」と呼ばれたりします。
「テスト観点のまとまり」については、VSTePという手法の中で”テストコンテナ”という概念で使われています。
私がテスト設計する場合は、この手法をよく使います。
一方で、テストマネージャーとしては、チーム外のステークホルダーへの説明に困るパターンでもあります。
また、「テストタイプが網羅できているか」「テスト実行計画時にどれくらいのリソースを拠出したらいいか」は、
これらから導出できないことが多いと思っています。
テストのタイミング
さすがにテストフェーズ、またはテストランの種類じゃないかと思いますが、テストのタイミングで識別する場合もあります。
2サイクル目のテストとか、リグレッションテストなどです。
テストレベルと被るような概念ですが、テストレベルの識別方法と別の整理をしている場合に保管する形でテストのタイミングが使用される場合を観測しています。
テストタイプを識別する嬉しさ
テストタイプを識別する嬉しさについて、はっきりしたものは私はわかっていません。
ただ、以下のような嬉しさがあるのではないかと考えています。
- 標準的なテストのやり方を参考にできる
- 一見、網羅しているように見える
- 外部のステークホルダーに対してもっとも粒度の粗い単位でのテストを示せる
- テスト実行のためにどのような専門性が必要かを知ることができる
- テストの工数の見積もりができる
おわりに
テストタイプについてはまだ理解が浅いと実感しています。
ですので、今後も理解を深めて本記事は加筆修正していきたいと考えています。
Discussion