テストの価値とか目的とか期待とかについての雑記

　前回書いた記事について、まったく想定外の角度からのツッコミを受けました。

「はじめてのテスト」 って、なし→失敗じゃないの？

— あきやま🌱 (@akiyama924) 2020年3月14日

　「期待」という言葉が未定義だったことに加えて、「テストの目的とは何か」という基本的な点で、人によって考え方が大きく異なることをあらためて認識しました。

テストの目的について

　JSTQBのFoundation Sylabussの「1.1.1 テストに共通する目的」には、以下のように書かれています。番号はこちらで振っています。

1. 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
2. 明確にしたすべての要件を満たしていることを検証する。
3. テスト対象が完成し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
4. テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
5. 欠陥の作りこみを防ぐ。
6. 故障や欠陥を発見する。
7. ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
8. （以前に検出されなかった故障が運用環境で発生するなどの）不適切なソフトウェア品質のリスクレベルを低減する。
9. 契約上、法律上、または規制上の要件や標準を遵守する、そして／またはテスト対象がそのような要件や標準に準拠していることを検証する。

　思ったよりたくさんありました*1・・・。
　何らかの軸で、もう少しきれいに整理できそうな気もしますね。

　さて、あくまで個人的な意見なのですが、テストケースを作るときには2つの気持ちがあります。

1. いやここは仕様ややこしすぎるし絶対何かやらかす場所だよ、バグ見つけるぜ～
2. まあここはね・・・ 何も起きないだろうけど、網羅性という意味では通さないとね・・・。

　前者は、上述のJSTQBリストの6個目。後者は3個目です。
　テスト実行していて楽しいのはもちろん前者です。後者のテストは、「対象のソフトウェアを学ぶ」という目的以外にはあまり魅力がない・・・。

　いただいたご指摘は、「テストは fail した時に価値がある」という立場からのご指摘であり、上述リストの#6に重きをおいた価値観だと思います。
　一方わたしは、「ソフトウェアの誤った部分に対し fail する」（真陽性）テストと、「ソフトウェアの正しい部分に対し pass する」（真陰性）テスト、どちらにも価値があると考えています。上述リストの#7の、「情報を提供する」という役割を果たすためです。

インフルエンザの検査を考えてみます。検査は偽陽性が出てもいいから陽性（患者がインフルエンザであることを）を見逃さないことが期待されます。
テストも同様です。
テスト対象のソフトウェアにバグが残っている前提に立つと、それを見逃さないで少ないテストが良いテストです。

— あきやま🌱 (@akiyama924) 2020年3月14日

　「インフルエンザの検査」のアナロジーもとてもわかりやすいのですが、インフルエンザの検査が果たすべき役割についての考え方も、秋山さんとわたしで異なっていました。
　秋山さんは陽性の人を漏れなく見つけることに重きをおき、わたしは陰性であるとわかることにも価値を感じるという立場で、テストについての考え方とまったく同じようにズレていたので、合意には至れませんでした(笑)。

テストの「期待」結果について

　「目的」とか「価値」みたいな根本でズレているので、何を「期待」するかについて一致しないのはある意味当然ですね。
　わたしとしては、「テスト屋はコケさすつもりでテストするけれど、実装側はしっかり動くつもりでテストに出してきている」みたいなイメージで、「テストが成功することを"期待"する」と表現していました。とはいえ、「たぶんいろいろボロが出るので、早めに叩いてもらえますか」みたいなケースもあるし、いろいろですね。

　「期待」じゃなくて、以下の方が書かれているように「終了基準」とか、「この結果であれば次にいける」みたいな表現がよかったのかもしれませんね。

横からすみませんが、もしはじめてのテストが「なし→失敗」になるならばリグレも「成功→失敗」になる（といいますか今回成功を期待するテストは存在しない）と思います。
そもそも該当のマトリクスは「期待」ではなく「終了基準」であって、それであればマトリクスは正しいように見受けられます。

— ama／あまやん (@MZRSEN) 2020年3月15日

　辰巳さんからは以下のようなご指摘をいただいています。

書かれている「成功/失敗」が、テストケースのpass/failと(Myersの)テストのsuccsess/unsuccessの2つの意味が混ざっているように感じました。pass/failは客観的事実で、succsess/unsuccessは主観的なもの。後者は誰の主観かという議論もあるかな。

— Keizo Tatsumi (@KeizoTatsumi) 2020年3月14日

　記事で述べている pass / fail はあくまでも、「テストケースの成功/失敗」のことです。「テスターというロールにおける成功/失敗」ではありません。
　後者だとすると、結局また「テスターとしての成功とは何か」という話になりますね・・・。

　ともあれ、この手の議論は楽しく、また学ぶことも多いので、大好物です。コメントくださったみなさん、ありがとうございました。

*1:2018年のシラバス改訂で増えたとの情報を @nowsprinting さんからいただき調べたところ、Ver2011では以下の4つになっていました。

テストには以下のような目的がある。
* 欠陥を摘出する。
* 対象ソフトウェアの品質レベルが十分であることを確認する。
* 意志決定のための情報を示す。
* 欠陥の作りこみを防ぐ。

テストの成功と失敗どちらを期待するのかマトリクスを描いてみる

　2月に「リグレッションテストと他のテストを分けるものは何？」という、哲学的な問いが現れていたので、その疑問には全然答えない記事を書いてみます。

リグレッションテストとその他のテストを分けるのってつまるところ実行回数なのかな？2回目以降のテストはリグレッションテスト？

— tsuemura (@tsueeemura) 2020年2月6日

　I/JSTQBによると、リグレッションテストの定義は以下の通りです。

リグレッションテスト（regression testing）
ソフトウェアの変更されていない領域で欠陥が混入している、もしくは露呈していることを検出するための、変更関連のテストの一種。

　目的は「欠陥の検出」なのですが、期待している結果は「成功」だと考えてよいですよね。
　言い換えると、リグレッションテストでは、「前回成功したテストが、今回も成功する」ことを期待しているわけです。*1

テストに対する期待結果のマトリクス

　ここで、「前回」「今回」をパラメタ、「成功」「失敗」をその値と考えると、リグレッションテストを次のようなマトリクス上に位置付けることができます*2。

リグレッションテスト

　このマトリクスは、「前回のテストに結果に対し、今回はどういう結果を期待しているか」を表しています。よって、リグレッションテストは 成功→成功 のセルに入っています。

成功を期待するテストには何があるか

　グラフを見たら、網羅せよ（Boris Beizer）。もちろん表も、網羅せよ。これぞテスターの心意気。 　さあ、どこから埋めましょうか。

　わかりやすいのは、失敗→成功。これは、不良を修正した後のテストです。
　I/JSTQBではこのテストを、「再テスト」「確認テスト」というかなり一般的な（テクニカルタームとは思えないような）名称で呼んでいます。定義は以下の通りです。

再テスト（re-testing）
変更関連テストの一種。欠陥を修正した後に実行し、それらの欠陥により引き起こされていた故障が発生しなくなっていることを確認する。

　この「変更関連のテスト」というのは、リグレッションテストの定義でも出てきましたね。
　再テストとリグレッションテストの二つが、変更関連のテストに属します。

再テスト

　「成功」列を埋めてしまいましょう。
　前回は「なし」で、今回「成功」を期待するのは、「はじめてのテスト」 ですね。特に名前はありません。

はじめてのテスト

　ちなみに、「テスト実行」に関する秋山さんの記事で、Myersの言葉が引用されていました。

58号：テスト実行｜Kouichi Akiyama｜notenote.com

「テストとは、エラーを見つけるつもりでプログラムを実行する過程である。」 （1979年）　　by G.J. Myers

　テストの目的（の一つ）は「バグを見つけること」なのですが、そうはいってもテスト対象は「正しく動く」前提でテストに流れてくるので、ここでは「成功を期待する」としてマッピングしています。

失敗を期待するテストには何があるか

　 さあ問題は、「失敗を期待するテスト」の方です。失敗することを期待して行うテストなんてあるでしょうか。

　その一つは、実は再テストとペアになるものです。

　再テストにおいては、「修正前のバージョンで、バグに起因する現象が再現すること」をまず確認したうえで、バージョン以外の条件を維持したまま、「修正後のバージョンでは、バグに起因する現象が発生しないこと」を確認するのが基本です。

　すでにわかっている現象をなぜ、あらためて再現させるのでしょうか。

　バグの内容によっては、現象を発生させる条件が難しかったり、複雑だったりします。「修正後」の確認だけだと、「バグは正しく直っていないのに、発生条件が整っていないせいで、現象が出ない」ことがありえます。これをもって、「バグは直った」と誤解するリスクがあるのです。
　ですから、必ず再現させたうえで、修正後のバージョンでもう一度同じテストを行うことが大切です。

再テスト前の再現テスト

　次に左上のセル、なし→失敗 です。
　最初から失敗を期待する、そんな奇特なことを目的としてテストなんてある・・・？

　・・・あるぞ・・・これは・・・TDDの説明でよく見るやつ・・・。

www.atmarkit.co.jp

最初に、失敗するテストコードを記述します。また、テストを実行可能にするために、テスト対象コードはテストを失敗させるように仮実装します。

　この、「TDDで一番初めに書くテスト」、これは「最初から失敗を期待する」テストだ！

　同じように、成功→失敗 も、TDDにおける「RED」のためのテストコードですね！
　なお「GREEN」は、失敗→成功 のところに入るでしょう。

TDDのテスト

マトリクスを網羅した！

　色でグルーピングしてみました。

完成版

　いやあ、表を埋めると仕事した気分になりますね！
　他にもこのセルに入るテストはあるでしょうか？

*1:ここでいう「成功」とは、「影響を受けていない」「劣化していない」という意味も含みます。

*2:「前回」のテストがない場合もあるので、縦軸には「なし」を追加しています。

『ソフトウェアテスト技法 練習帳』を解きながら、自分の考え方も整理していく。

　『ソフトウェアテスト技法 練習帳』を、じわじわ解いています。

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~

JaSST'19 Tohokuにて好評を博した練習帳をベースに、問題を増やし内容にさらに磨きをかけて刊行します。

ということで、そもそも参加者特典のレベルを超えた「冊子」が、書籍となったのが本書です。
　同値分割、境界値分析、デシジョンテーブル、状態遷移テスト、組み合わせテストという代表的なテスト技法に、「総合問題」が付くという構成です。

　わたしの進捗は悪く、未だに「同値分割法と境界値分析」を終えられていませんが、ごくシンプルな問題からじわじわと複雑さを上げて体を慣らしていくスタイルは、独学にも、勉強会にも向く作りだと思います。テスト技法によるテストケースの絞り込みは必ずしも唯一の正解が存在するわけではありませんが、本書では「解答例」として、なぜそのテストケースが選定されたかを丁寧に説明してくれるのも、お気に入りの点です。

同値分割・境界値分析の問題を解いてみて

　というところで、「1.12 配達便の料金体系」を解いていて疑問に思った点について、著者のネモさんと秋山さんに補足していただきましたので、整理しておきたいと思います。

問題の内容

　問題1.12の正確な内容は同書をあたっていただきたいと思いますが、ざっくり以下の通りです。

• 荷物の「三辺の合計」（以下「大きさ」）と「重量」（以下「重さ」）から、以下のように「荷物サイズ」が決まる。

荷物サイズ	大きさ	重さ
60サイズ	60cm以下	2㎏以下
80サイズ	80cm以下	5㎏以下
100サイズ	100cm以下	10㎏以下

• 大きさが100cmを超える または 重さ10kgを超える 場合はエラー。
• 荷物サイズは、大きさ または 重さ の対応する荷物サイズの大きい方に決まる。
  • たとえば大きさ50cm、重さ4kg だと、80サイズとなる。
• 大きさも重さも、0の入力を許容する。
• 大きさは4桁以上の整数、重さは3桁以上の整数の入力を許容しない。

選択するべき値

　ここで、2つのパラメタ「大きさ」「重さ」それぞれの数直線を描くのが定石かもしれませんが、軽く一時間は溶けてしまいそうので描かず・・・。
　それぞれのパラメタで選ぶべき値を列挙してみます。わたしは、境界値のみを選んでいます。

• 大きさ　0, 60, 61, 80, 81, 100, 101, 999
• 重さ　0, 2, 3, 5, 6, 10, 11, 99

　「解答例」では、以下の値が選ばれています。

• 大きさ　0, 30, 60, 61, 70, 80, 81, 90, 100, 101, 110, N/A
• 重さ　0, 1, 2, 3, 4, 5, 6, 8, 10, 11, 15, N/A

　主な違いは、以下です。

1. 「解答例」では、2つのパラメタについて、境界値だけでなく代表値も選んでいる。たとえば60サイズの大きさとして、「30cm」など。*1
2. 「解答例」では、無効クラスの値として、「101」「110」「N/A」を選んでいる。

　2つ目については理由を以下のように述べています。

「3辺合計」の無効同値は最大の入力値が999になりますが、今回は有効同値に近い101と代表値である110をテストデータとして扱います。

　この点は理由が述べられておれず、天下りな印象を受けます。
　また「N/A」については「上限の境界値はなし」としており、ちょっと矛盾を感じる点です。

導出されるテストケース

　さて「解答例」では、大きさ・重さの値の各11個をフルで組み合わせた121パターンをテストケースとして挙げています。
　パラメタは2つ、出力のパターンも4つ（60、80、100、エラー）しかないのに、121パターンというのは多すぎるように感じるのではないでしょうか。

　先ほどのパラメタの組み合わせを、マトリクスで表現してみましょう。セルに埋まっているのは、「荷物サイズ」です。4つのエリアに色分けできることがわかりますね。
　色を少し濃くしているのが、2次元「面」になった各エリアの境界です。

「大きさ」「重さ」と、「荷物サイズ」の関係

　たとえば緑色のエリア（荷物サイズ=80）の境界で、「特に重要なセル」はどこでしょう。
　まず目につくのは、大きさ80、重さ5のセル (80, 5) でしょう。大きさや重さがこれよりプラスになると、隣のエリア（荷物サイズ=100）に入ってしまう、まさに境界ギリギリです。
　このセルより上のセル5つは、大きさがプラスになると隣のエリアに入りますが、重さがプラスになっても同じエリア内に留まります。(80, 5) のセルに比べて優先度は低いでしょう。

　この(80, 50)のエリアから境界をまたいだ (81, 5) と (80, 6) の2つのセルも大事です。この3つでワンセットですね。(81, 6) も何となく特別感がありますが、「境界値のさらに隣」というところです。

　他のエリアも同じように考えると、

• 青の上限ギリ (60, 2) とその隣接セル (61, 2) (60, 3)
• 緑の上限ギリ (80, 5) とその隣接セル (81, 5) (80, 6)
• 黄の上限ギリ (100, 10) とその隣接セル (101, 10) (100, 11)
• 赤の上限ギリ (999, 99)

　この9パターンに加えて、

• 青の下限ギリ （0, 0)

　自分なら、この合計11パターンをまず高優先度にするかなと思います。*2

と書いてきたものの、

　著者の方の意図は以下の通り。

全組み合わせは「力技だけど誰にでも分かる解答例」として用意しました。
ただパターンの掛け算になるので、120サイズが増えただけでも増えまくります。。。

— ネモトノリユキ＠ソフトウェアテスト技法練習帳 発売中！！ (@nemorine) 2020年3月7日

ええとですね。これは、第1章なので「勇者」（読者〕は「ひのきのぼう」（同値分割法と、境界値分析の知識）しか持っていないのです。
ですから、各テストアイテム（長さ合計と、重さ）の境界値分析をして総組み合わせをしたのが解答例ですね。
（続）

— あきやま☀️ (@akiyama924) 2020年3月7日

　これだとかなり多いことはもちろんご承知のうえで、「今手持ちの技法で何ができるか」ということなのですね。
　この後の章でデシジョンテーブルが出てきますので、「互いに関係する複数のパラメタの扱い」について知ることができるはずです。楽しみですね！
　わたしも今年度の間には行けるかな～。

補足 (2019/3/28)

　わたしのふんわりとした値選択とは異なる、ドメイン分析の正統なロジックに基づいたテストケース導出について、秋山さんがツイートされていましたので、補記しておきます。

（続）
まずは、こちらの表をご覧ください。
こちらは今回のテストをドメイン分析で設計するときのカバレッジアイテムです。
4つのドメイン（昨日は3つと書きましたが「エラー」も取り敢えずドメインとしました）で、何を網羅するのかの表です。
（続） pic.twitter.com/n1YeBG2jJ5

— あきやま☀️ (@akiyama924) 2020年3月25日

　わたしは以下の部分は「有効同値クラス」と考えたこともあり、差分があるようです。

「3辺合計」が100cmを超える、または「重量」が10㎏を超える場合は「荷物サイズ」にエラーと表示し、

*1:『練習帳』のこの章ではすべて、境界値に加えて代表値をテストケース候補に入れています。わたしは全部はやらないかな・・・。

*2:入力できないこと、の確認はここでは省略

パスワード要件で原因結果グラフを描いてみたけれど苦しい。

　完全にローカルメモ。

　dマガジンというサービスのパスワード要件に一瞬迷ったのですが、秋山さんから「原因結果グラフを描くのだ！」とのご神託を受けたので、トライしてみました。

原因結果グラフを描くのだ！
ちょっと難しいけど。

— あきやま🌸 (@akiyama924) 2020年2月17日

　わたしは原因結果グラフ（CEG: Cause Effect Graph）が苦手です。「グラフが完成した」というゴールがわからず、いつも「どこか間違っているのではないか」という気分にさせられるからです。
　今回、秋山さんに模範解答をいただきましたが、自分では一発でそこまでたどり着けませんでした。なのでせめて、「どのようなロジックでそこにたどり着けるか」の理屈付けを考えてみました。

お題はコレ

　文字数、必須/任意、文字種 の3つの情報があるのですが、今回は文字種だけに注目します。単純そうですが、これだけでもけっこうやりがいあります。
　「英字のみ、数字のみ、記号のみ不可」というのは日本語がわかりづらいけれど、「英字のみの文字列は不可」「数字のみの文字列は不可」「記号のみの文字列は不可」のAND条件と見なします。また文字種は、英字・数字・記号の3つしかないということにします。

1. まずはそのままグラフを書く

　日本語をそのままノードにしてみます。3つの命題をAND条件で接続します。

2. ノードをシンプルにする。

　1.のデシジョンテーブルを見ると、原因ノードが「英字のみでない」と限定＋否定形になっており、T/Fがややこしくなります。ノードの各命題を「裏」にして、「文字種に問題あり」という中間ノードをかませましょう。
　また、原因ノードになる3つは、1つ以下しかTになりえないので、EXCL制約をかけます。*1

3. 「確認したいこと」に近づける

　さて、2.でも間違ってはいないと思いますが、1点気になります。今回確認したいのは、「特定の文字種を含まない場合の挙動」なのですが、原因ノードがそうなっていません。
　そこで、3つの「含まない」を原因ノードにしてみます*2。

　「英字のみである」は、そのまま読めば「数字を含まない」∧「記号を含まない」なのですが、暗黙の前提として「英字は含む」も意味しているので、「英字を含まない」からNOTの線を引きます。

4. 制約を付ける

　3.のデシジョンテーブルを見ると、#4は成立しないことがわかります。2つまではTになってもいいけれど、全部がTになるのはダメ。しかしこれを表現できる制約はありません。
　よって、また原因ノードを「裏」にしてから制約をかけることにします。

　これで一応完成（＝秋山さんの解）です。
　ただやっぱり、自力で2.から3.に進める気がしない。秋山さんの解答案に近づけるための無理やり感がある。。

8,1,
文字種に問題あり
英字のみである
数字のみである
記号のみである
文字種に問題あり
英字を含む
数字を含む
記号を含む
362,630,126,20,obs,OR,0,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
293,423,113,20,obs,AND,0,0,0,0,0,1,1,1,0,0,0,0,0,0,1,1,,-1,
361,420,113,20,obs,AND,0,0,0,0,0,1,1,1,0,0,0,0,0,1,0,1,,-1,
433,415,113,20,obs,AND,0,0,0,0,0,1,1,1,0,0,0,0,0,1,1,0,,-1,
363,819,126,20,obs,AND,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,,-1,
292,258,77,20,obs,,,-1,
365,257,77,20,obs,,,-1,
435,256,77,20,obs,,,-1,
INCL,371,142,31,20,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,0,0,0,0,0,0,0,0,,-1,
--
[Cause Node]
英字を含む=
数字を含む=
記号を含む=

[Middle Node]
文字種に問題あり=(英字のみである OR 数字のみである OR 記号のみである),
英字のみである=(英字を含む AND NOT 数字を含む AND NOT 記号を含む),
数字のみである=(NOT 英字を含む AND 数字を含む AND NOT 記号を含む),
記号のみである=(NOT 英字を含む AND NOT 数字を含む AND 記号を含む),

[Result Node]
文字種に問題あり=(NOT 文字種に問題あり),

[Constraint]
INCL(英字を含む 数字を含む 記号を含む),

まとめ

　ノードの導出から変形、制約の付け方についてもう少しロジカルな進め方があるはずなのですが、まだかなり曖昧です。他の問題も通じて、もう少し道筋をはっきりさせたいと思います。

おまけ

　以下のCEGは、「英字のみでない」を、「英字を含む」かつ「数字か記号を含む」のように表現したケースです
　デシジョンテーブルの#2と#5を見ると、原因ノードは同じTF組み合わせなのに、中間ノード「数字のみでない」のT/Fが違っていて気持ち悪い・・・。対称性もないし、不気味な結果となりました。
　おそらくCEGTestではなく、グラフ自体に矛盾が含まれているのだと思います・・・。

10,1,
文字種問題なし
英字のみでない
数字のみでない
記号のみでない
英字を含む
数字を含む
記号を含む
数字か記号を含む
記号か英字を含む
英字か数字を含む
344,648,113,20,obs,OR,0,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
236,443,113,20,obs,AND,0,0,0,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
353,441,113,20,obs,AND,0,0,0,0,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,,-1,
475,452,113,20,obs,AND,0,0,0,0,0,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,,-1,
265,112,77,20,obs,,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
355,111,77,20,obs,,,-1,
447,113,77,20,obs,,,-1,
191,276,126,20,obs,OR,0,0,0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
308,275,126,20,obs,OR,0,0,0,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
420,278,126,20,obs,OR,0,0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
INCL,355,15,31,20,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
--
[Cause Node]
英字を含む=
数字を含む=
記号を含む=

[Middle Node]
英字のみでない=(英字を含む AND 数字か記号を含む),
数字のみでない=(数字を含む AND 記号か英字を含む),
記号のみでない=(記号を含む AND 英字か数字を含む),
数字か記号を含む=(数字を含む OR 記号を含む),
記号か英字を含む=(英字を含む OR 記号を含む),
英字か数字を含む=(英字を含む OR 数字を含む),

[Result Node]
文字種問題なし=(英字のみでない OR 数字のみでない OR 記号のみでない),

[Constraint]
INCL(英字を含む 数字を含む 記号を含む),

*1:中間ノードがOR条件なので、制約をかけてもかけなくても出てくるデシジョンテーブルは同じになった。

*2:ここに大きな論理の飛躍があると思う。適切な原因ノードの選び方のロジックを詰め切れていない。

ソフトウェアの品質特性についての参考資料

　前回の記事で、「テストのアトミック性」というコンセプトについて書きました。

www.kzsuzuki.com

　ISO/IEC25010ではソフトウェアの品質特性、つまりソフトウェアの価値や良し悪しを測るための軸を提示してくれていますが、「ソフトウェアのテスト」の良し悪しはどのように考えればいいのでしょう。
　プロダクトと違ってテストはユーザが（少なくとも直接には）使うものではないから、良し悪しの軸などいらないでしょうか？ いやいや、開発においてベロシティやコードカバレッジを計測することで改善や維持を図れるように、テストの良さを測ることで、それをさらに良くしていくモチベーションにすることはできそうです。

テストの品質特性

　テストの品質特性の提案例として秋山浩一さんから、JaSST'09 Tokyoでの加文字諭さんのライトニングトークスの資料を紹介していただきました。テスト（スイート）の品質特性として、12個の主特性と81個の副特性が提案されています。
　それぞれの特性についての説明までは書かれていないので推測になってしまいますが、ソフトウェアの品質特性とはかなり違います。一つの傾向として、テストの各プロセスをスムーズに行えるかというところに焦点が当たっているように見えます。

　たとえば主特性「テスト実施性」に対し、以下の9つの副特性が定義されています*1。

• 手順可読性
• 手順実施容易性
• 対象結果確認容易性
• 期待結果可読性
• 結果比較容易性
• 不具合検討容易性
• 環境復元容易性
• 復元確認容易性
• テスト実施内容記入判断容易性

　「〇〇容易性」が多いことから、「テストを実施するにあたり、実施者がどれだけスムーズにテストを行えるか」ということを重視していると読み取れます。
　もちろんそれだけということではなく、たとえば「網羅性」という主特性の下には

• 網羅信頼性
• 網羅妥当性
• 実施可能性
• 必要テスト実施誤差性

という副特性がぶら下がっています*2。これはいわゆる「テスト分析」プロセスでのアウトプットに対応する特性といえそうです。「網羅」を定量的に証明することは困難なので、「信頼性」という、「ステークホルダーが納得・合意してできるものか」という尺度を入れているのが面白いですね。

　主特性「ピンポイント性」の副特性である「対象関連明確容易性」は、先の記事に書いた、テストケースとテスト条件のトレーサビリティが取れていることに相当しそうです。
　一方見たところ、個々のテストケースが抱えるテスト条件の数、目的のシンプルさといったものに該当するものはなさそうです。もちろん「再利用独立性」など、間接的に関係しそうなものは見当たるのですが。ただ、主特性の名前が「ピンポイント性」なので、意図しているところは「アトミック性」に近いのかな、と感じます。

アトミック性とやらに触れている文献

　辰巳敬三さんにリサーチいただいたところ、いくつかの文献がありました。
　多くは「ほかのテストケースを前提とせず、独立して実行できる」という意味で使っています。こちらの書籍

Continuous Practices: A Strategic Approach to Accelerating the Software Production System (English Edition)

では、以下のように言及しています。

The second prerequisite is atomicity. By atomicity we mean the property of test cases behaving as independent entities, which can be executed in isolation without assumptions as to any particular state resulting from the execution other set of test.

　なお別の箇所では、atomicity 以外の特性にも言及しているようなので、この箇所は面白そうです。

we argue that these prerequisites are test case homogeneity, test case atomicity and tractability

自動テストの品質特性

　自動テストの文脈における品質モデルについては、テスト自動化研究会の井芹洋輝さんの発表資料がわかりやすいです。

テスト自動化の品質モデルの扱い from H Iseri

www.slideshare.net

　まず、テスト自動化に関わる品質モデルを、3つに分けています。
　そのうち1つは、実はテスト自体ではなく、テスト対象のプロダクトのテスタビリティに対するモデルです。Pressmanによる例を提示しています。

　テスト自体のモデルは2つ。
　1つは「テスト環境の品質モデル」とあります。この「環境」という言葉がちょっとわかりづらいのですが、これは「テスト実行環境」という意味ではなく、自動テスト自体の品質の考え方といってよさそうです。
　テストコード自体の不良やプロダクト側の変更に合わせて、テストコードを容易に修正できるか（保守性）。そもそもバグが少なく、正しくテストを行うことができるか（機能性）。といったものが特性になります。

　もう1つが「テスト設計の品質モデル」で、これはテスト自体の品質と言える内容もあります。

十分性　網羅すべき実行領域に対してテストが十分かどうかの程度

　加文字さんの分類でいう「網羅性」ですよね。

　この資料で紹介される例が少ないこともあり、やはり「アトミック性」に近いものは見当たりません。
　引用元をあたってみるか・・・とよく見てみたら、自分が翻訳に関わった本からの引用じゃないか・・・。こんな話が書かれていたなんて記憶のかなたなので、あらためて読み直してみようと思います。

システムテスト自動化 標準ガイド CodeZine BOOKS

@yattom さんからは、TDD FIRST principle をご紹介いただきました。

自動テストやTDDでF.I.R.S.T.という指標(というか心がけ？)がありますが、すみません違う話な気が。。。 https://t.co/wkpRaSzrX2

— YASUI Tsutomu (@yattom) 2020年2月14日

stackoverflow.com

　以下は勝手訳です。

• Fast: テストを迅速に実行できること
• Independent: テスト同士が依存しておらず、どんな順番でも実行できること
• Repeatable: 何度実行しても同じ結果となること
• Self-checking: 成功したかどうかが自動的にわかること
• Timely: テスト対象のコードと同時に、そのテスト自体が書かれていること

　多くは自動テストで重要なものですが、手動テストにおいても通ずるものもあります。

　わたしとしては、テストの品質特性を一から網羅的に議論したいわけではないですが、ちょっと調べただけでもいろんな観点での価値・軸があり、面白いですね。

*1:これを転記していると、「いや自分ならこれとこれは一緒にするし、これは違う主特性にぶら下げるかな・・・」とムズムズしてきたので、品質特性の検討は沼という予感がしました。

*2:実施可能性は「テスト実施性」に入れたくなる・・・