ISO/IEC/IEEE 29119-2～4の改訂で新しくでてきたテストモデルについて少し調べてみた

3 Lines Summary

• 2021年10月に、ISO/IEC/IEEE 29119 Part 2～4の改訂版がリリースされました
• その中で、テストモデルという新しい概念が示されたようです
• テストモデルってなんだろうかを調べてみたのでそれを整理してみました

注意事項

• 私は中の人ではないので、どうしてこのように変更されたかの内情などは分かりません
• この規格群の一利用者として、読んでみた上での理解や疑問などを記述したものです
• つまり、この情報の正確性などには怪しいという前提で読んでくださいね（フィードバックや議論は大歓迎です）

背景

ISO/IEC/IEEE 29119のPart 1からPart 3は2021年10月にIS(International Standard: 国際標準)としてリリースされました。その後、Part 4が2015年にリリースされています¹。今回、改訂版がリリースされ、それを購入したので、ざっと目を通してみました。

規格番号	種類	タイトル	初版	改訂
ISO/IEC/IEEE 29119-1	IS	コンセプトと定義	2013	リリース準備中2
ISO/IEC/IEEE 29119-2	IS	テストプロセス	2013	2021
ISO/IEC/IEEE 29119-3	IS	テスト文書化	2013	2021
ISO/IEC/IEEE 29119-4	IS	テスト技法	2015	2021

「テスト設計と実装プロセス」が変わった

全体的にさまざまな変更が入っているようで、いわゆるレッドライン版のような差分を示せるような量の変更ではないです。とはいえ、ドラスティックに骨格レベルで変更が入ったかといえばそうではなく、全体的にブラッシュアップしたといったようなイメージです。その中でも、割と大きめの変更で特に目を引いたのが、「テスト設計と実装プロセス」の変更です。

文書内で示している「テスト設計と実装プロセス」の図を見ると分かりやすいでしょう。まず、2013年の初版のテスト設計と実装プロセスのイメージ図を引用します。

次に、2021年の改訂版のテスト設計と実装プロセスのイメージ図を引用します。

つまり、テスト開発プロセスとしての段階的詳細化に変更が入ったようです。この変更において、「テストモデル」という新しい概念が示されています。

テストモデルとは？

なにはともあれ、用語定義でテストモデルがどう説明されているかを見てみましょう。ISO/IEC/IEEE 29119-2:2021から引用します。

test model

representation of the test item (3.42), which allows the testing to be focused on particular characteristics or qualities

ざっくりと意訳すると、テストモデルはテストアイテムを表現したもので、テストモデルによって特定の特性や品質に焦点をあてたテストを行えるといった感じでしょうか。ん～、よくわかりませんね。用語定義には例も示されているので、これも読んでみましょう。

EXAMPLE Requirements statements, equivalence partitions, state transition diagram, use case description, decision table, input syntax description, source code, control flow graph, parameters and values, classification tree, natural language.

テストモデルの例として次のものがあげられていますね。

• 要求の文章
• 同値パーティション
• 状態遷移図
• ユースケース記述
• デシジョンテーブル
• 入力構文の記述
• ソースコード
• 制御フロー図
• パラメータと値
• クラシフィケーションツリー
• 自然言語

モデルという言葉から連想するのとは異なり、非常に多岐にわたるものをテストモデルとして取り扱っているようです。状態遷移図がテストモデルというのは、モデルベースドテストの文脈から容易に連想できます。ただ、要求の文章や自然言語が例と示されているように、テストモデルとして扱うものは何でもよさそうです。同値パーティション、ユースケース記述、デシジョンテーブルなどブラックボックステスト技法でとして扱うものや、ブラックボックステスト技法の中でもパラメータと値やクラシフィケーションツリーなど組み合わせテストで扱うもの、ソースコードや制御フロー図などホワイトボックステスト技法で扱うものが示されています。どうも、逆説的ではありますが、テスト設計技法で適用してテストカバレッジアイテムを獲得する対象をおしなべててテストモデルといっているようにも見えます。

これまで、テスト条件とはなんであるか？というのは、なかなか難しい問題でした。テスト条件は抽象度の高いものもあればより具体的なものもあり、それこそテスト条件とテストカバレッジアイテムの実態が同じものであるといったこともありました。個人的に、この幅があることで、自分の担うテストに対しての説明責任を果たすときに、良い塩梅にテスト条件（その前段階のテストアイテムやフィーチャーセットを含め）を調整していたので、少数派かもしれませんが初版の段階的詳細化は好きでした。ただ、分かりやすさと便利さのトレードオフではないですが、「結局、テスト条件とはなんであるか？」という疑問を持つ人が多いのも、経験的にそうだろうと思います。実際に、そういう話をよく聞きます。

それを考えると、まだテストモデルは腹落ちしていませんが、テスト技法を用いてテストを開発する文脈においては、分かりやすいものではあるようです。

また、例に続いて、4つの注釈が示されていますので、こちらも見ていきましょう。

Note 1 to entry: The test model and the required test coverage (3.28) are used to identify test coverage items (3.29).
Note 2 to entry: A separate test model can be required for each different type of required test coverage included in the test completion criteria (3.2).
Note 3 to entry: A test model can include one or more test conditions (3.27).
Note 4 to entry: Test models are commonly used to support test design (e.g. they are used to support test design in ISO/IEC/IEEE 29119-4, and they are used in model-based testing). Other types of models exist to support other aspects of testing, such as test environment (3.34) models, test maturity models and test architecture models.

ざっくり翻訳すると、こんな感じでしょうか。

• 注釈1: テストモデルと要求されるテストカバレッジを用いて、テストカバレッジアイテムの識別する
• 注釈2: テスト完了基準に含まれる要求されるテストカバレッジの種類が異なるごとに、別のテストモデルを要求できる
• 注釈3: テストモデルは、1つ以上のテスト条件を含むことができる
• 注釈4: テストモデルは、一般的にテスト設計を支援するために使われる（例えば、ISO/IEC/IEEE 29119-4でテスト設計を支援するために使用され、モデルベースドテストで使用される）。テスト環境モデル、テスト成熟度モデル、テストアーキテクチャモデルなど、テストの他の側面を支援するためのモデルも存在する。

注釈を読む限り、割と前述のテストモデルに対する所感は、そこまで外れたものではないようです。

テストモデルに対しての補足（ISO/IEC/IEEE 29119-2:2021の付属書Eより）

今回、新しいテストモデルという概念を導入するにあたって、付属書（Annex E）にテストモデルに対する補足が示されています。ただし、informativeな参考情報で規格の適合性に対して制約を課すものではありません。

1ページ丸々テストモデルについて述べているので、流石に引用の範囲を超えるので示しませんが（是非、規格を買って読んでくださいね）、雑に要約すると次のようなことが書いてありました。

• 初版のテスト設計と実装プロセスにはテスト条件が含まれていたけど、テスト条件がなんなのかよくわからないという多くの声があったよ
• なので、テストモデルをベースとした代替アプローチを示したんだよ
• テストモデルは、Part 4のテスト技法で、各技法を定義するために使うよ。初版のテスト条件で示した例と比べると、シンプルで分かりやすくなったでしょ？
• テストモデルを使うことで、テストカバレッジアイテムとの関係性が整理され、テスト設計と実装プロセスが簡単になったよ
• 前は、テスト条件の獲得（TD2）とテストカバレッジアイテムの獲得（TD3）が同じアウトプットになって、「どういうこと？」ってなってたので
• テストモデルとテスト条件の違いを把握するのは難しいかも。テスト条件はもっと抽象的な概念だし。さまざまなレベルで使われる幅の広いものなので、それこそ顧客と合意形成するレベルから、開発者がテストするコードそのものとか
• ただ、テストモデルはテストカバレッジアイテムと密接につながっている。テスト条件がテストモデルと同等の場合もあるが、そうでない場合も多いのが、テストモデルは明確
• また、テストモデルを識別して、そから多くのテストを作ることで、細かなまとまりのない多くのテスト条件を満たすこともできるし

テストモデルに対しての補足（ISO/IEC/IEEE 29119-4:2021の付属書より）

定義や解説だけだと空中戦になるので、具体的なものを見てみましょう。例えば、状態遷移テストにおける例はこんな感じです。

• テストモデル: 状態遷移図
• 要求されるテストカバレッジ: 0スイッチカバレッジ100％
• テストカバレッジアイテム: 状態遷移モデルにおける0スイッチの各パス
• テストケース: 各パスに対して、事前条件、事後条件、入力、期待結果を定義したもの
• テスト手順: 上記のテストケースを実行可能な状態に実装したもの(手順化やスクリプト化）

確かに、テスト技法を使う限りにおいて、テストモデルは明確なので、分かりやすいですね。でも、テストモデルよりも抽象度の高いところがすっぽりとなくなった印象です。テストの全体像を構造化して合意形成することが個人的には多いので、なくなってしまったテストアイテム→フィーチャーセット→テスト条件といった段階的詳細化の部分が欲しくなってしまいます。

なお、実際のテスト設計と実装プロセスでの情報インスタンスの例は、ISO/IEC/IEEE 29119-2:2021の付属書Aにも示されています。また、各テスト技法における具体例は、改訂版のPart 4の付属書で詳しく示しているので、より具体的なイメージをつかみたい方は参照してみてください。

まとめ

以上、ISO/IEC/IEEE 29119における新しい概念、テストモデルについて具体的に見てきました。

テスト技法でテストカバレッジアイテムを示す対象としてテストモデルが分かりやすい一方、これまで抽象度の高いレベルでテストの説明性のために使っていた部分がなくなってしまったようにも見えます。そのため、今回のテストモデルは、賛否が分かれるかもしれません。

ただ、初版だろうが改訂版だろうが、ステークホルダとテストについて合意形成するには、ISO/IEC/IEEE 29119のテスト設計と実装プロセス通りだからといって着地するわけではないのは、ある意味これまで通りとも言えます。

ステークホルダ間でテストにおける納得感を持つには、やはりテスト設計コンテスト³の文脈のような、テスト要求分析やテストアーキテクチャ設計といった部分が重要であると改めて感じました。また、そこがテストの難しいところであると同時に、テストの創造性の高い面白い箇所でもあると思います。

今回は、時間もなく、ざっと見ていった程度ですが、また機会があれば改訂版の変更点などについて深掘りしていければと思います。

ではでは。

1. Part 5以降もリリースされていたり、開発されていたりしますが、今回はスコープではないので割愛しています。気になる方は、ISOのWebサイトで29119をキーワードに検索してみてください。リリース後5年程度を目処に改訂が必要かどうか検討されるそうで、今回の改訂が行われたようです。 ↩

2. Part 1は、本記事執筆時点ではまだリリースされていませんが、ステータスがUnder publicationとなっており、もうすぐでそうな感じです。 ↩

3. NPO法人ASTERが主催している、テスト設計のコンテスト。チュートリアル資料が公開されているので、詳細はそちらをご参照ください。 ↩