テストタイプってなんなの？
はじめに
本記事は以下の記事からインスパイアされています。
テストレベルに「機能テスト」が入ると困る理由〜ごまずん編〜
という記事を書こうと思ったのですが、「テストレベル」「テストタイプ」で語るべきところがあると思って、記事を分割しています。
こちらに記載する記事は「オレオレ定義」であり、「正しい定義」を知りたい場合は各規約を参照してください。
それでもnoteで書く意味は、読者の方がこの記事を読むことによって「テストタイプ」に対する理解や思考が深まることを期待するからです。
この記事を元に自分はどうだろうと考えたり、議論していただければ嬉しいです。
テストタイプの意味
テストタイプの定義を見てみる
「テストタイプ」という用語はISTQBで定義されています。
テストタイプ（test type）
コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたもの。
References After TMap
「テストの目的」を識別するために使うものみたいですね。
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.
これは明確に品質特性に紐づいているみたいです。
JSTQB FL V4.0の記述も見てみます。
テストタイプは、特定の品質特性に関連するテスト活動のグループであり、それらのテスト活動のほとんどは、すべてのテストレベルで実行することができる。
というわけで、
「テストの活動をまとめたもの」
「品質特性に関連がありそう」
「テストの目的を表す」
定義の揺れがありますがこういうことが要素としてありそうですね。
テストタイプの例
テストタイプは「品質特性に紐づいたテスト」とするのがよくある気がします。
以下のような形ですね。
機能テスト
非機能テスト
使用性テスト
性能テスト
信頼性テスト
ここから特にオレオレ定義なので不愉快な人は見ないでください
演繹的テストタイプと帰納的テストタイプ
演繹的テストタイプと帰納的テストタイプというのを命名してみました。
トップダウンとボトムアップと言ったりもします。
演繹的テストタイプとは、あるテストタイプモデル(これも命名しました)からブレイクダウンして実施のテストタイプを選ぶものです。
品質特性からブレイクダウンしたり、組織の標準テストタイプからブレイクダウンしたりですね。そういう使われ方をよく見ます。
帰納的テストタイプとは、テスト開発の中で識別したテストの目的やテスト条件やテストケースといった具体的な内容から集約して「テストタイプ」を識別するやり方です。テストタイプがあることの嬉しさは後で記述するのですが、帰納的テストタイプはテストタイプの定義がより柔軟です。
その分より深く考えて定義する必要がありそうですね。
テストタイプは実装するのか、識別するのか
演繹的テストタイプの場合、ブレイクダウンして「実装」することになると思っています。
帰納的テストタイプの場合、集約して「識別」することになると思っています。
どちらにせよ言ってることは同じかもしれないですが、考える頭や思考プロセスは結構違うのではないかと思います。
様々なテストタイプパターン
本項目ではテストタイプを識別するというスタンスを取ります。
テストタイプの整理方法について、一度テストタイプパターンと命名してみます。
ここで感情的になった人は回れ右してください。
品質特性
そのテストが品質特性が関連する品質特性を表している場合です。
あるいはそのテストを全て完了することによって満たす品質特性を表している場合もありそうですね。
テストマネージャーがテスト関係者以外のステークホルダーに対して様々なテストをやっていると合意をとったり、品質特性レベルで抜け漏れがないか確かめるのに使えそうです。
最も代表的なパターンだと思います。
要件定義の性質
これは私の好きなやり方です。
機能テストは「機能要件に対応するテスト」、非機能テストは「非機能要件に対応するテスト」です。
なので、要件定義がされていないとテストできません。
逆に言えば、テストを定義した時点で要件定義にフィードバックすることができます。
シーケンシャルな開発の場合には、性能要件などは実際にソフトウェア動かしてみないと決められないという場合もありますが、その場合でも「決められない」「計測する」ということを決めたりします。
要件定義とのトレーサビリティも取れるので、開発のドキュメンテーションを重視する開発には向いているかもしれません。
一方で、テストをドキュメントとする文化では少し思いテストタイプパターンですね。
テストのやり方
このパターンは私はよく見ます。
「ユーザビリティテストを行う」「性能テストツールで性能テストを行う」「セキュリティテストは専門家が行う」などの手段で識別している場合です。
テストベンダーなんかもこういう考えでテストパターンを識別している場合がありますね。
タスクや見積もり、あるいは必要なリソースや専門性をすぐさま識別できる利点があります。
テスト観点のまとまり
テスト観点と呼ばれる謎の食べ物をまとめるという考え方です。
これはよりテストの成果物をまとめあげて、それに意味を与えるような手法を取ります。
主にこれらは「テストの目的」と呼ばれたりします。
私がテスト設計する場合は、この手法をよく使いますが、テストマネージャーとして嬉しいかどうかは正直よくわかりません。
そのテストタイプが網羅できているかやどれくらいのリソースを拠出したらいいかは、結局のところわからない場合が多いからです。
テストのタイミング
これはさすがにテストフェーズ、またはテストランの種類だろって言われそうですが、テストのタイミングとかもありそうです。
２サイクル目のテストとか、リグレッションテストもここに入るでしょうか？
一部テストレベルと被りそうですが、テストレベルの識別方法と別の整理をしていれば、テストレベルとは違うと言えそうです。
テストタイプを識別する嬉しさ
実はわかっていません。想像で以下を考えてみます。
標準的なテストのやり方が識別できる
どんな専門性が必要か知ることができる
工数の見積もりができる
テスト条件見るの辛い人へ寄り添うことができる
おわりに
すみません。テストタイプのことはよくわからないので、また思いついたら加筆するかもです。
一旦これでお納めください。
次回は本当に語りたい「テストレベルに機能テストが入ると困る理由」について考察したいです。
この記事が気に入ったらサポートをしてみませんか？