テストレベルってなんなの？
はじめに
本記事は以下の記事からインスパイアされています。
テストレベルに「機能テスト」が入ると困る理由〜ごまずん編〜
という記事を書こうと思ったのですが、「テストレベル」「テストタイプ」で語るべきところがあると思って、記事を分割しています。
こちらに記載する記事は「オレオレ定義」であり、「正しい定義」を知りたい場合は各規約を参照してください。
それでもnoteで書く意味は、読者の方がこの記事を読むことによって「テストレベル」に対する理解や思考が深まることを期待するからです。
この記事を元に自分はどうだろうと考えたり、議論していただければ嬉しいです。
テストレベルの意味
テストレベルの定義
「テストレベル」の定義はISTQBでは以下となっています。
テストレベル（test level）
具体的にインスタンス化したテストプロセス。
同義語
テストステージ（test stage）
上記の意味は一目でわからんかったです。私の知っている定義ではありません。
https://t.co/hLOjrpqjW1
— やまずん (@55_ymzn) May 19, 2024
JSTQBのテストレベルの定義が「具体的にインスタンス化したテストプロセス。」ってなってるけど、これ大丈夫なのか？？
私の知らないところで何か起こってる？？？
私の知っているテストレベルの定義は以下です。
「テスト対象を何らかの関心ごとでまとめて管理・実行されるテスト活動の集まり」
"それぞれのテストレベルで固有のテストプロセスがある"ので、最新JSTQBと対応しているはしているのですが、「テスト対象がなにか」というところに重点を置きたいので、上記の定義で考えています。
「具体的にインスタンス化する」というのはすごく29119みを感じました。
テストレベルの識別
それはおいといて、私がテストプロセスを聞き取りする時は以下の図を用います。
テストレベルの名前は典型的には「単体テスト」とか「システムテスト」とかに分かれますが、名前は会社によっていろいろなので、敢えて書かないようにしています。
以下では、テストレベルを識別する観点をいくつか紹介します。
テスト対象の結合度
開発環境の種類(代表性って言ったりする)
テストベースの詳細度
品質ゲート
提供側と受け入れ側
これらは「こう分けるといいよ」ではなく、私の経験則から「こんなのを元に識別してる現場があるよ〜」くらいに思ってもらうのがいいかもしれません。
テストレベルを識別する観点
テスト対象の結合度
一番多いのはこのパターンな気がしています。
これはウォーターフォールでもアジャイルでも成り立つテストレベルだと思っています。
「テスト対象の結合度」と言っていますが、正式な名前を私はよくわかっていません。
システムは複数のモジュールやサービスで成り立つという世界観で、それぞれのモジュールやサービスを実際に使うかどうかで識別しています。
例えば以下の感じです。
開発者の手元で実施されるテスト
チーム内でモジュールを結合した場合のテスト
チーム間で結合した場合のテスト
外部サービスまで結合した場合のテスト
それぞれの結合度で実施することで、例えば以下の効果を期待します。
特定のテストレベルのテストのスコープを狭める(集中する)
テスト実行のスピードを調整する(テストピラミッド的な考え)
デバッグをしやすくする
それぞれの結合度での信頼の積み上げ
他チームに渡すために自信をつける
もっとあるかもしれません。
また、それぞれの効果は相関関係があると思います。
テスト環境の種類、代表性
意外と語られていないですが、「テスト環境の種類」という観点でも識別できます。
「テスト環境の代表性」って言ったりもすると思っていますが、この表現に問題があれば、この記事を修正します。
「テスト環境がどれだけ本番環境に近いか」ということを表しています。
開発者が実施するローカル環境が一番本番環境から遠く、最後のフェーズになるほど本番環境で動作する環境に近いという意味です。
以下の効果を期待します。
テスト環境を用意する費用を抑えてバグを検出する
テスト環境を用意するタイミングより早くソフトウェアのテストを行う
特定のテスト環境依存のバグを検出する
もっと他にあるかもしれません。
私がここでテスト環境の種類を識別するのは、主にハードが関わる組み込み系を想定していました。
組み込みだとハードの用意に時間もコストもかかるので、「ハードが必要なテストはハードのある環境で集中してやる」みたいな考えが一定あるのかなと思います。
他にもWEB系だと本番環境の設定周りのテストとかもあるかもですね。
テストベースの詳細度
主にシーケンシャルな開発を想定しています。
それぞれのテストベースに記載された内容がそれぞれのテストレベルのテストで対応しているかどうかを確認します。
シーケンシャルな開発では、それぞれの成果物が段階的詳細化されると考えています。
「要件定義ベースのテストは要件定義ベースのテストで見たらいいし、単体テストは単体テストの設計書に書いてある内容をテストすればいいよね」という世界観です。
私が観測している範囲では、それぞれのテストベースが1対1で対応することはほとんどありません。
「一つのテストレベルでテスト条件は要件定義書から拾って期待結果は基本設計書から拾います」という現場はざらにあります。
そのため私の図では様々なテストベースが様々なテストレベルに飛ぶカオスな図になっています。
主に以下の効果があると思っています。
テストベースに対するテストを行うことによる検証の繰り返しを実現する
「何がテストベースか」というスコープを狭める（集中）
ベンダー委託の場合、設計書に対する検証を実施する
他にも(略)
品質ゲート
これもシーケンシャルな開発を想定しています。
「下位のテストレベルが完了して品質への信頼性が高まってから次のテストレベルに移行する」ですね。
「品質保証部」とかのIV&V的な観点がある場合も私はここに入れています。
効果は以下です。
IV&Vができる(具体的な効果はググってください)
下位のテストが完了することで、そのテストレベルのスコープに集中することができる
「システムテストレベルで単体テストレベルのバグが出てるよ！」というコミュニケーションができる（存在意義は不明）
他(略)
提供側と受け入れ側
「受け入れテスト」の存在意義を識別するために記載しました。
受発注関係のある現場を想定しています。
効果については省略します。
テストレベルを識別する嬉しさ
上記のことを考えようと思いましたが、「テストレベル」という考えが自分にとって自然すぎて、「テストレベル」自体の必要性を言語化することが難しいと思いました。
個別の嬉しさは個別の識別観点で見れます。
以下な気がしました。
「テストスコープと実行スピードを調整することでデバッグのしやすさの確保」
「品質に関する確信の積み上げ」
ただ一つ言えそうなことは、それぞれのテストレベルの嬉しさを言語化していない全体テスト計画はBad テスト計画ということではないかと思います。
おわりに
あんまり参考になる記事ではなかったかもしれません。
もっと勉強したい人は多分他の人の記事を見た方がいいと思います。
次は「テストタイプってなんなの？」について記事を書きたいです。
この記事が気に入ったらサポートをしてみませんか？