テスト技法ってなんなの？〜テスト技法とその先〜
はじめに
この記事では「テスト技法」について解説します。
テスト技法について、本質的なところが語られずに、「なんとなく使っている」という状態が良く見れます。
この記事ではテスト技法の存在意義について語ろうと思います。
と、思っていたら、株式会社ベリサーブの長谷川さんが私が言いたいことを端的に表した記事を記載されていました。
先に、テスト技法が何のためにあるのかについて説明します。ずばり、それはカバレッジのためです。
2024.03.13
記事：長谷川聡
ぶっちゃけ私が一番主張したいことは上のことそのままです。
ですので本記事ではもう少し私の色を出した思想強めの主張を記載します。
テスト技法とは
テスト技法とはズバリ、カバレッジのためです。
そしてもう一つ付け加えるならば、カバレッジは「テストケース」によって為されます。
もう少し私の言葉で補足すると、テスト技法とは「カバレッジを満たすテストケースを生成する技術」です。
超重要な「カバレッジ」という概念
テスト設計の本質は私は「カバレッジ」だと考えています。
なんらかのテストモデルに対してなんらかのカバレッジ基準を元にカバレッジできるテストケースを導入することがテスト設計だと思っています。
カバレッジができていればテストケースは一つでもカバレッジを満たしていると思っています。
また、あるカバレッジ基準を満たすテストケースはそれぞれ重要度は同じであると考えています。
テストケースの重要度は「テスト条件」単位で設定され、それをカバレッジする限り、複数のテストケースは全て同様の重要度を持つと思っています。
テストケースによって個別の重要度が識別される場合は、個別のテスト条件が識別できると考えています。
ちなみにJSTQB ALTAのシラバスでもテスト技法の欄には必ず「カバレッジ」の章があります。
追記
上記の文章は有識者のあきやまさんからコメントがありました。
また、指摘された箇所について考えた結果、残すことは私の意図とも違うため、コメントしたいただいた時点から以下の記載を変えています。
「ピンポイント的」という言葉=>別で既に使われている言葉だったので、当該の文書を削除して別で補足します。
「カバレッジアイテム」=>元々モデルの話をしておらず、カバレッジアイテムという言葉も現規約に沿ってなかったので削除して補足します。
“ピンポイント的であれ”、、、はて？
— あきやま🎣 (@akiyama924) May 18, 2024
ピンポイントとカバレッジは補完し合うものでしょう？？
あと、カバレッジの前に「モデル」の話が必要だと思いました。【モデルを網羅する】のですから。
テスト技法ってなんなの？〜テスト技法とその先〜｜ごまずん #note https://t.co/fc4guooNl5
テストモデル
「カバレッジすることが大切」と述べました。
「何をカバレッジするんだ」というのも大事です。
それは「モデル」a.k.a.テストモデルです。以後は「テストモデル」とします。
「テストモデル」はISTQBやISO/IEC/29119で用いられている概念です。(テスト技法の本で触れられているのを私は見たことがありません)
厳密な定義は上記で確認してください。
私の言葉で説明する「テストモデル」とは、テストの対象をテスト可能な側面に抽象化したものです。
単に「モデル」とも言うのは、テスト用のモデルと設計にも使えるモデルの２つを想定しているのかなと思っています。
私にとっての「テスト技法」とは後者のモデルをテストケースに落とすことを指しています。
一方、後でも触れますが、「テストモデル」を作ること自体は重要な技術だと考えています。
また、「ホワイトボックステスト」における「モデル」の考え方ですが、これは私の理解ですが、「コード」を「行」として認識するか「分岐」として認識するかなど、それぞれ固有のモデル化がされていると私はみなしています。
プログラミング言語で表されている時点でモデルと言えるかもしれません。
なので、私にとって「ホワイトボックステスト」は「モデルをカバレッジしている」という定義に矛盾はありません。
また、モデルについては必ず図に表現されるものではなく、自然言語で表現されたものも「モデル」と考えています。
「自然言語で表現された要求」などもテストカバレッジの対象に入ると考えるからです。
これは誰かが同じようなこと言ってましたが誰だったか忘れました。
どんなテストモデルが適切かはテスト対象とテスト条件によって識別されると考えていますが、これは別の記事で記載するか、別の文献をあたってください。
smalltalk「悲しきかなカバレッジアイテム」
当初の記事では「テストモデル」の代わりに「カバレッジアイテム」という言葉を使っていましたが、これの定義は今と昔では変わってしまっているようです。
例えばJSTQBの場合
カバレッジアイテム（coverage item）version2
テスト技法を使用して、一つ以上のテスト条件から導出される属性または属性の組み合わせ。テスト実行の完全性を測定するために使用する。
カバレッジアイテム（coverage item）version1
テストカバレッジの基礎となる実体や属性。たとえば、同値分割やステートメント。
version1では「同値分割」や「ステートメント」といったテストモデルとなっていますが、version2では「属性または属性の組み合わせ」となっています。
ISO/IEC/IEEE29119でも扱いが変わっています。
2013では以下のような記述でした。
test coverage item
attribute or combination of attributes that is derived from one or more test conditions by using a test design technique that enables the measurement of the thoroughness of the test execution
一方、2023の最新規格では「テストモデル」に対してテスト技法を適用するようになっているらしいです。
ピンポイントと網羅
テスト条件を識別するにあたり、「テスト観点」という言葉を使う人々がいます。
VSTePを使う人々などですね。
そうでない人も普通に使っています。
https://www.jaspic.org/event/2006/SpiJapan/proceedings/4c1.pdf
あるいはテスト設計コンテストの文脈では「ピンポイント型のテスト観点」「網羅型のテスト観点」という言葉があります。
https://www.aster.or.jp/business/contest/doc/2021_chibicon_V1.0.0.pdf
あきやまさんのおっしゃる通り、ピンポイントと網羅はそれぞれ補完関係にあります。
この記事では上記の定義や使われ方を尊重した上で、「テスト技法のキモはカバレッジによる網羅である」というスタンスを取りたいです。
ピンポイント型のテスト観点であろうと、網羅型のテスト観点であろうと、それらはテストケースによって「網羅されている」と定義付けします。
ブラックボックステスト技法
ブラックボックステスト技法には色々あります。
私はオレオレ定義でいくつかブラックボックステスト技法の種類を識別しています。
これは教科書的にコンセンサスを得られているものではなく、ごまずんの認識です。
カバレッジするだけのテスト技法
以下のテスト技法が該当すると考えています。
デシジョンテーブルテスト
状態遷移テスト
ユースケーステスト
これらの特徴は「ソフトウェア設計で導出した設計書をテストケースでカバレッジするだけ」という性質を持っていることです。
テスト技法としては「デシジョンテーブル作成」「状態遷移表や図の作成」はスコープに含まれていないと思っています。
元々ソフトウェア設計技法として「デシジョンテーブル」「状態遷移」というものがあり、これらをカバレッジするテストケースを生成するのがテスト技法であるという認識です。
ただこれは「デシジョンテーブル作成」「状態遷移表や図の作成」が不要と言っているわけではありません。
ソフトウェア開発において、デシジョンテーブルや状態遷移図が必ずしも作成されるとは限らないため、それらを作成することはエンジニアとして重要なスキルだと思っています。
ただ、それはソフトウェアや仕様の性質がその設計技法に適している場合に有効であるということを忘れてはいないと思います。
テストするからといってなんでもデシジョンテーブルにしちゃうのはBadなテスターだと思っています。
また、テスト技法として「デシジョンテーブル作成」「状態遷移図の作成」は含まれていないという立場ですが、エンジニアとして持っていて悪いことはないスキルだと思っています。
なので、「デシジョンテーブル作成」ができるテスターは胸を張って「私はエンジニアです」と名乗っていいんじゃないかと思っています。
テストをする/しないの理由付けのための技法
同値分割法
境界値分析
ペアワイズとか直交表とかその辺
これらはソフトウェア設計で使う技法では多分ありません。多分。有識者の人知ってたら教えてください。
上記は「テストをする/しないの理由付け」のためにある技法だと思いました。
「同値パーティションに含まれる場合はテストしない」「ペアワイズは網羅する」などですね。
これらは上記の理由づけによってなされるテストケースを導出することが目的のテスト技法です。
よくわからんテスト技法
クラシフィケーションツリー
クラシフィケーションツリーはどこからやってきて、どこに行くのか私はよくわかっていません。
入力値とかの整理に使うけど、特にカバレッジとか導出しないような気がするなあとか思っています。
有識者がいらっしゃったら教えてください。
と思ったら、あきやま先生がnoteで記載されていました。
ちなみに、このテスト技法自体は仕様の整理などによく使います。
ホワイトボックステスト技法
ホワイトボックステスト技法は色々ありますが、「特定のコードカバレッジを満たす」ということを表現しているとふわっと理解しています。
テストベースがコードになるので、「コードをこんだけカバレッジしました」以上の意味は持たないと考えています。
一方で「制御フローテスト」「データフローテスト」などはコードカバレッジではないかも？と思ったりします。
その点はブロッコリーさんから指摘をいただいたりしています。
せ、制御フローテスト…
— broccoli (@nihonbuson) April 21, 2024
ホワイトボックステストの定義については「動いているソフトウェアのコードやデータからカバレッジするものを決める」でいかがかと思いましたが、これで正しいかどうかは有識者の意見を聞きたいと思っています。
また、ホワイトボックステスト技法は単体テストの文脈で語られます。
単体テストにおいて、ホワイトボックステストで不十分であることは「Effective Software Testing」という本が詳しいです。
私はこの本でメイクセンスしました。
経験ベースのテスト技法
経験ベースのテスト技法も存在します。
「チェックリストベースドテスト」「エラー推測」などですね。
これらもテストベースとして「何らかの経験」が存在して、それをカバレッジするテストケースを生成するという理解を私はしています。
「探索的テスト」だけは扱いに困ります。
探索的テストは本来的にテスト対象から学び、テストケースの作成と評価を同時に行うからです。
この場合のテストモデルは「テスターが認知したソフトウェアのふるまい」になるのでしょうか。
謎。
何にせよ「テストケースを導出することができる」という点で、「探索的テスト」を使うのならばテスト技法の仲間に入れてあげてもいいです。
「テストチャーターを網羅してテスト設計しています」なら探索的にやらなくてもいいかなと思います。(最初からテスト設計してください)
そうでなければ探索的テストは下記のテストエンジニアリングかな〜と思ったりします。
オレオレ定義:テストエンジニアリング
テストケースを導かない様々なテストの技術はテスト技法、Test Techniqueではなくて、なんと呼べばいいのでしょうか？
そこで私は「テストエンジニアリング」という言葉を提案したいと思います。
テスト技法だけでなく、様々な技術を用いてテストを効果的に、効率化して、納得感を高めたり、説明力を高めたり、いろんな有益なフィードバックする
これらは全部「テストエンジニア」による「テストエンジニアリング」と呼称するのはいかがでしょうか。
おわりに
テストエンジニアリングのくだりは共感してもらえたら嬉しいですが、業界に混乱を招きたくないので、別に積極的に使って欲しいとは思っていません。
なんとなく言ってみたかっただけです。
この記事が気に入ったらサポートをしてみませんか？