ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

有則のテストは「組み合わせテスト」の技法に含まれるのか?

 Twitterで、「組み合わせテストに分類されるテスト技法はどれか」という話が流れていました。
 デシジョンテーブル、原因結果グラフ、原因流れ図といった、いわゆる「有則」のテスト技法でも命題の真偽の組み合わせを考えますが、これは組み合わせテストに含まれるかそうでないのか、というものです。

 わたし自身以前、(無則の)組み合わせテストを人に説明するときに少しモヤモヤしたので、自分の意見を整理しておきます。

TL;DR *1

  • 自分の中で整合性が取れていて、かつ世の中の一般的な理解から大きくハズレていなければいい*2

  • 用語が有名なのに指す範囲が人しだいというのは議論の妨げになるので、立場を明確にしておくのがベター。
  • combinatorial testing はテクニカルタームとして、無則の組み合わせテストを指すとすると都合がいい。
  • 有則のテストの中にも「組み合わせのテスト」はある、と補足しておくといい。

combinatorial とは

 とりあえずJSTQBの用語集で「組み合わせテスト」を検索すると、以下の結果が出ます*3

組み合わせテスト(combinatorial testing)
ブラックボックステスト設計技法の一つ。複数のパラメータの値を特定の組み合わせで実行するためのテストケースを設計する。

 そもそも、combinatorial というのがふだん見慣れない単語ではないでしょうか。combinational とどう違うのか

 こんなときにに役に立つのが「vs検索」ですね。
 たとえば、ともに「継続」のニュアンスがある continuous と continual の違いが知りたければ、「continuous vs continual」で検索して、信頼できそうなサイトを読んでみることでそれなりに理解できることが多い。下のサイトを見ると、continuousは「頻度は高いが断続的である」ようなニュアンスがあることがわかります。 en.oxforddictionaries.com

 という成功体験を胸に、調べてみましょう。

wikidiff.com

As adjectives the difference between combinatorial and combinational is that
combinatorial is of, pertaining to, or involving combinations
while
combinational is of or pertaining to (a) combination.

 明確な違いが、「combinations」なのか、「a combination」なのか、だけ・・・? なんかもっとこう・・・。

 以下は数学の文脈になってしまいますが、また名詞と形容詞の比較なので少し奇妙ですが、

wikidiff.com

In context|mathematics|lang=en terms the difference between combination and combinatorial is that combination is (mathematics) one or more elements selected from a set without regard to the order of selection while combinatorial is (mathematics) of or pertaining to the combination and arrangement of elements in sets.

 これもなかなか難しい。
 ただここで「数学」というキーワードから、「順列」「組み合わせ」と関係あるのでは?と思っていろいろググって見ると、「組み合わせ数学」(combinatorics)という分野があるのですね。組み合わせ最適化(combinatorial optimization)もこの分野に含まれていることがわかります。

ja.wikipedia.org

 組合せ数学(くみあわせすうがく、combinatorics)や組合せ論(くみあわせろん)とは、特定の条件を満たす(普通は有限の)対象からなる集まりを研究する数学の分野。特に問題とされることとして、集合に入っている対象を数えたり(数え上げ的組合せ論)、いつ条件が満たされるのかを判定し、その条件を満たしている対象を構成したり解析したり(組合せデザインやマトロイド理論)、「最大」「最小」「最適」な対象をみつけたり(極値組合せ論や組合せ最適化)、それらの対象が持ちうる代数的構造をみつけたり(代数的組合せ論)することが挙げられる。

 これで、最初の「combinations」「a combination」の意味が何となくみえてきます(個人の感想です)。
 a combination は、「組み合わせの行為・結果」です。たとえばA~Eまでのチームがあったとして、最初の試合が「チームA vs チームC」であれば、「AとC」というのは a combination。日本語の「組み合わせ」にほぼ合致しそうです。combinational はそれを形容詞にしたもの。
 combinatorial は、結果自体ではなく、a combination に至るまでの組み合わせの「基準」や「方法」を含意しているように感じます。たとえば先の5チームでリーグ戦を行うとき、「総当たり」などの組み合わせ導出のアルゴリズムを考えることが combinatorial な議論であり、その結果導出される複数の組み合わせ10試合が combinations になるわけです。

組み合わせテストに含まれる技法は?

 やっと話が戻ってきます。
 Twitterの議論のポイントは、「組み合わせテストは、無則の組み合わせのみを指すのか、有則の組み合わせも指すのか」というものでした。

ISTQBでの扱い

 用語集では以下のように定義されています。

 ブラックボックステスト設計技法の一つ。複数のパラメータの値を特定の組み合わせで実行するためのテストケースを設計する。

 これを読むと、無則に限るものではないと読めますね。
 またTechnical Analystシラバスでは以下のように記載されています。

Combinatorial testing is used when testing software with several parameters, each one with several values, which gives rise to more combinations than are feasible to test in the time allowed. The parameters must be independent and compatible in the sense that any option for any factor can be combined with any option for any other factor. Classification trees allow for some combinations to be excluded, if certain options are incompatible. This does not assume that the combined factors won’t affect each other; they very well might, but should affect each other in acceptable ways.

 組み合わせテストは、複数の値を持つ複数のパラメータを含むソフトウェアをテストする場合で、組み合わせ数が、許容される時間内にテスト可能な数よりも多く存在するときに使用する。どのようなパラメータのどのようなオプションでも、他のどのようなパラメータのどのようなオプションと組み合わせられるという意味で、パラメータ間に依存関係はなく、両立させるべきである。

 「パラメタは独立しており、各値が自由に組み合わせられる」という記述は、無則のテストを想起させますね。用語集より一歩踏み込んでいます。
 またそもそもTAのシラバスは、章構成としても、「3.2.3 デシジョンテーブル」「3.2.4 原因結果グラフ法」とは別に「3.2.6 組み合わせテスト技法」となっており、有則のテストを組み合わせテストの外に位置づけているようにも読めます。

 ところが。

 この辰巳さんのご指摘*4の箇所を引用すると、以下です。

Combinatorial test techniques are useful for testing the implementation of system requirements that specify how different combinations of conditions result in different outcomes. One approach to such testing is decision table testing.

 確かに combinatorial test techniques という言葉が出てきます。このシラバス内で、combinatorial という単語が出てくるのはこの箇所だけのようです。
 ISTQBの既存のシラバス・用語集での立ち位置を考えると、デシジョンテーブルを combinatorial testing の一つとして扱うのは確かに奇妙、と思います。

『ソフトウェアテスト技法ドリル』での扱い

 わたしのバイブルでもある『ソフトウェアテスト技法ドリル』を確認してみましょう。

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

 「本書の読み方」の表1によると、以下のように分類されています。

論理組合せテスト
ドメイン分析テスト
デシジョンテーブル
原因結果グラフ
CFD法

無則組合せテスト
HAYST法
スライド法
ペアワイズ

 前者はいわゆる「有則」に相当しますので、有則・無則の双方に、「組み合わせテスト」という言葉を当てたうえで、「論理の」「無則の」という言葉で区別しています。 

まとめ

 有則の組み合わせにせよ無則の組み合わせにせよ、「組み合わせの方法を与える」という意味では、combinatorial とはいえそうです。
 一方、コードカバレッジ基準、たとえばMC/DC(改良条件判定カバレッジ)だって真偽値の「組み合わせ方」ではあり、それらを全部 combinatorial testing と呼んでしまうと、名前をつける意味すらなくなってしまいます。

 ということで再掲ですが、以下のように考えます。

  • 自分の中で整合性が取れていて、かつ世の中の一般的な理解から大きくハズレていなければいい。
  • 用語が有名なのに指す範囲が人しだいというのは議論の妨げになるので、立場を明確にしておくのがベター。
  • combinatorial testing はテクニカルタームとして、無則の組み合わせテストを指すとすると都合がいい。
  • 有則のテストの中にも「組み合わせのテスト」はある、と補足しておくといい。

 次回は、「組み合わせ」と「組合せ」の違いについて検討していきたいと思います。より深刻だよ。

*1:1回書いてみたかっただけ。「too long; didn't read」の略なんですね。en.wikipedia.org

*2:居駒さんからのご指摘を踏まえて、4/6に書き直しました。

元の文章は以下です。

有則のテストも「組み合わせのテスト」ではあると補足しておくといい

*3:2019年4月3日時点。

*4:なお一連の辰巳さんのツイートは、一通り読んでおくべきですね・・・、。

ソフトウェアテスト技法の使い間違いって何? 彼氏はいるの? 性格が悪いって本当? 調べてみました!#テストアドカレ

 この記事は、ソフトウェアテストの小ネタ Advent Calendar 2018、17日目の記事です(先走り)。

qiita.com

 16日は、mktkさんの以下の記事でした。

panmania.hatenadiary.com

15216848023_d54c7e6344_o無意味な風景画像

0. テスト技法の「使い間違い」

 テスト技法にはそれぞれ使い所があり、また使う上での注意点があります。使い方を間違えると、良いテストを作るはずが、逆の効果をもたらしかねません。
 この記事では、テスト技法の使い間違いによってテストケースが漏れてしまう様子を、『ソフトウェアテスト技法ドリル』の例題を使って眺めてみましょう。

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

1. デシジョンテーブル: 実装を無視して圧縮する!

1-1. 圧縮とは?

 『ドリル』の第3章では、デシジョンテーブル(決定表)を扱っています。
 この章の例題の仕様は、ざっくり以下の通りです。

「商品カテゴリーが書籍である」 かつ 「価格が1,500円以上である」 かつ 「配送先が離島でない」 場合に「送料が無料」となる。

 3つの条件がそれぞれ「真」「偽」の2つの値を取るので、完全なデシジョンテーブルの列数は23=8になります。

テストケース12345678
条件書籍であるTTTTFFFF
1,500円以上であるTTFFTTFF
離島でないTFTFTFTF
動作送料無料TFFFFFFF

 ですが、場合によってはこれを「圧縮」することができます。『ドリル』から引用します(太字筆者、以下同様)。

圧縮とは、列をまとめて総規則数を減らすことです。その方法は同じ動作(結果)をもつテストケースのなかで、結果に影響を及ぼす行が1行しかなかった場合、その列をまとめて結果に影響を及ぼす行のセルを「Y」でも「N」でもどちらでもよいという意味で「ー」に変更するという方法です。

 圧縮したデシジョンテーブルは以下のように8列が4列になっており、半分のテストケースが削減できることになります。

テストケース1234
条件書籍であるTTTF
1,500円以上であるTTF
離島でないTF
動作送料無料TFFF

1-2. 圧縮の注意点と具体例

 デシジョンテーブルの圧縮には、重要な注意点があります。

このときに重要となるのは、条件が処理される順番です。どの規則も、品物、合計金額、配送先の順で処理されるから...圧縮できるのです。

 つまり、プログラムの実装を無視して圧縮すると、本来必要なテストケースが漏れることがあるということです。
 直感的には理解できるのですが、いざ「じゃあどんな場合?」と考えたときに、例がパッと出てこなかったため、考えてみました。
 以下のような仕様としましょう。

  • 仕様1: 書籍 かつ 1,500円以上 かつ 離島以外 なら、配送料無料
  • 仕様2: 書籍 かつ 1,500円以上 かつ 離島 なら、配送料300円
  • 仕様3: 書籍 かつ 1,500円以上でない なら、配送料400円
  • 仕様4: 書籍でない かつ 離島以外 なら、配送料500円
  • 仕様5: 書籍でない かつ 離島 なら、配送料1,000円

 この順番のまま素直にデシジョンテーブルを作ると、以下のようになります。

テストケース12345
条件書籍であるTTTFF
1,500円以上であるTTF
離島でないTFTF
動作送料無料無料300円400円500円1,000円

 ドリル本の圧縮テーブルとの違いは、#4と#5です。ドリル本では、書籍がF判定だった時点で結果は1つだったのですが、こちらはもう一度判定が必要になります。
 ハイフンは「TとF、どちらでもよい」ので、たとえばここではともに「T」を指定することにしましょう。

テストケース12345
条件書籍であるTTTFF
1,500円以上であるTTFTT
離島でないTFTTF
動作送料無料無料300円400円500円1,000円

 このまま実装すると、こんな感じでしょうか。

 一方「離島でないか否か」の方から判定を始めると、以下のようになるでしょうか。

 どちらにせよ、上のデシジョンテーブルに基づくテストケースはすべてパスします。

 しかし・・・
 ここで2つ目のプログラムの12行目を誤って「4,000」としてしまったとします。この場合、上の5つのテストケースでは検出が漏れます。テストケースT-F-Fのケースが、圧縮によって省略されたためです。
 配送料を代入する式が6つあるのにテストケースは5つしかないので、漏れるケースがあるのはある意味当たり前ですね。

2. オールペア法: 有則の組み合わせに用いる!

 無則の組み合わせテスト技法である「直交表」や「オールペア法」を学ぶと、「パラメタが多い場合の組み合わせは、組み合わせテスト技法で大幅削減できるんだ!」というところだけを記憶してしまうリスクがあります。

 上のデシジョンテーブルの例では、3つの条件に対し組み合わせが8つもあるし、圧縮するには実装を意識しないといけないから大変だなあ・・・そうだ! オールペア法を使おう!と突き進んでしまうと失敗します。
 ためしに、3つの「条件」をパラメタと考えて、PictMasterで組み合わせてみましょう。

pictmaster

 PICTMasterに入力して・・・ポン!

品物は書籍合計は1,500円以上配送先は離島以外
TFT
TTF
FFF
FTT

 よーし、組み合わせ数が半分に減ったぞ・・・って、えーーー!
 一番肝心な、「送料無料」になるケースが出てこない・・・。

 無則の組み合わせテスト技法は、組み合わせるパラメタ同士が影響しない(ことになっている)場合に利用するものであり、強度2では、3パラメタ間の特定の組み合わせの出現を保証しません。影響し合うパラメタの組み合わせに用いてはいけないことが確認できましたね。

3. 状態遷移テスト: 2スイッチカバレッジ100%で1スイッチカバレッジも網羅!

 最後に、状態遷移テストのスイッチカバレッジにおける使い間違いを見てみましょう。「nスイッチカバレッジ」というのは、状態遷移をn回行う遷移パターンの網羅率のことです。

 たとえば以下のような状態遷移図を考えてみましょう。

stateMachine

 これを状態遷移表で表現すると、以下のようになります。

SABE
Sa
Abc
Bd
E

 この各セルの状態遷移をすべて実行すれば、1スイッチカバレッジが100%ということになります。
 2スイッチカバレッジであれば、状態S→状態A→状態B のような、2回の状態遷移パターンの網羅率を指すということです。

 さて、ここで気になるのは、nスイッチカバレッジが100%の場合、n-1以下のスイッチカバレッジは自動的に100%になるのか、という点です。
 無則の組み合わせテストでは、強度nのカバレッジが100%なら、強度n-1以下のカバレッジも100%になります。コードカバレッジでも、判定網羅が100%なら命令網羅も100%になります。

 『ドリル』では以下のように説明されています。

ここで、注意しなければならないのは、2スイッチカバレッジを行うだけでは、状態遷移表や1スイッチカバレッジのテストをしたことにはならない場合があるという点です。状態遷移がループしていない場合に、1スイッチはできても2スイッチできないケースがあるからです。

 試しに、2スイッチカバレッジのパターンを見てみましょう*1
 まず、関係行列は以下の通り。

 この行列を掛け算すると・・・。このような行列になります。 

 たとえば右上に「ac」が出ていますね。これは、状態Sから始まって、遷移aによって状態Aへ。さらに遷移cによって状態Eへ。という2スイッチのパターンとなります。この中には、1スイッチの遷移a~dも含まれており、2スイッチカバレッジ100%は、1スイッチカバレッジ100%も満たしているようです。

 さらに掛け算して、3スイッチカバレッジを見てみましょう*2

 3スイッチの遷移パターンは、たった34つになってしまいました。2スイッチであったパターン5個のうち、状態Sから始まる「ac」と、状態Bから始まる「5cdc」が消えてしまっています
 行列計算上、acも5cdcも掛け算対象が0になっているため、消えてしまうのです。状態遷移図で見ると自明で、Eから遷移する先はないので、S→A→E、B→A→Eで止まってしまうのですね*3

 このように、nスイッチカバレッジを100%にしたからといって、n-1以下のスイッチカバレッジが100%になるとは限らないということがわかりました。

まとめ

 いかがでしたか?
 テスト技法の使い方を間違うと、重大なテストケース漏れが起こることを実感いただけたでしょうか。
 みなさんもぜひ、テスト技法の誤った使い方について調べてみてくださいね!

*1:2スイッチカバレッジのパターンの導出方法は『ドリル』で詳しく説明されています。ざっくり言うと、状態遷移表を行列(これを「関係行列」といいます)とみなして、行列を掛け算することで求められます。

*2:A→B→A→Aのパターンが抜けていたので訂正。秋山さん、ありがとうございました!

*3:SとEが同一の状態であるとすれば、EからさらにAに入っていくことが可能です

「ソフトウェアプロジェクトでのめんどくさい人の扱い方」 、品質保証(QA)の場合

 こちらのツイート*1を見て、さっそく見に行ってきました。
 美しい色使いで構成されたこのサイト、そこにあるスタイリッシュな動物アイコン群はそれぞれ、「めんどくさい人」の象徴でもあります。

 「めんどくさい人」はまず以下のロールに分けられています。

  • プロダクトマネジャー
  • デザイナー
  • プロジェクトマネジャー
  • 開発マネジャー
  • 開発者
  • 品質保証(部門)

 アイコンをクリックすると、「めんどくさい人」が以下の構成で説明されています。

  • 定義と特徴
  • 修正の見込み
  • プロジェクトへの弊害
  • 問題点
  • 対処法

 アンチパターン集と、ソフトウェアバグのアナロジーを混ぜたような感じですね。
 それぞれのロールにカテゴリーがあります。仕事柄、「品質保証」を読まざるを得ません。

 以下では、品質保証における「めんどくさい人」の定義を紹介します。
 カテゴリーごとに感想を書こうと思いましたが、概ねオリジナルページに包含されているので、この美しいサイトを読んでみてください。気が重くなりますよ。

The Firehose(消火ホース)

neilonsoftware.com 「大量のバグレポートを開発者を投げつけるQA。あまりに速すぎるので開発チームがバグのバックログに圧倒され、対応しきれなくなる」

The Blamer(非難屋)

neilonsoftware.com 「バグを見つけるたびに、『なぜちゃんとテストしていないんだ!?』と開発者を追求するQA」

The Alarmist(警告屋)

neilonsoftware.com 「第一印象だけに基づいて、プロダクト全体の品質が受け入れられるレベルじゃないと宣言してしまうQA」

The Scientist(科学者)

neilonsoftware.com 「バグを見つけることよりも、バグを文書化することに大半の時間を使ってしまうQA」

The Misleader(惑わせ屋)

neilonsoftware.com 「バグを不正確に報告し、事象の再現やバグを改修するための方向性を、開発者に見誤らせてしまうQA」

The Downtrodden(いじめられっ子)

neilonsoftware.com 「開発者に虐げられ、いじめられることを恐れてバグを報告できなくなっているQA」

The Random Clicker(ランダムクリッカー)

neilonsoftware.com 「バグを見つけるために、思うがままにただクリックしまくるQA」

The Flippant(不真面目)

neilonsoftware.com 「開発者が失礼だと感じるような、受動攻撃的な *2バグレポートを書くQA」

所感

 みなさんの職場では、心当たりがまったくないものばかりですよね!
 他にも、プロセスを守ることがすべてに優先する「プロセス屋」とか、テスト・品質の技法を振り回して権威を築こうとする「技法屋」がいると思いました。
 自分たちのチームがこのようなアンチパターンパーソンになっていないか、定期的に振り返りたいものです。

*1:タイトル訳もそのままお借りしました

*2:受動的攻撃行動(Passive-aggressive behavior)とは、Wikipediaで以下のように説明されています。初めて聞きました。

怒りを直接的には表現せず、緘黙や義務のサボタージュ、あるいは抑うつを呈して相手を困らせるなど、意識的無意識的にかかわらず後ろに引くことで他者に反抗する(攻撃する)行動である。

『テスト管理を語る夕べ』での発表内容についての補足(とか言い訳) ー 後編

 まーた間が空いてしまいましたが、後編では、当日の関連ツイート(togetter)に対し回答・補足していきたいと思います。

www.kzsuzuki.com togetter.com

 資料はコチラです。

www.slideshare.net

そもそもの目的について

 「目的」は、確かに根本的なことなのですが、「あまり考えていない」というのが本音です。「ぼくがかんがえた、さいきょうのちょうじん」みたいなもので、高邁な目的などなく、「こんなの考えたけどうどう!?」くらいの意味しかないです。それでも、何かのネタになるならいいかなーくらいです。

 まああとは、

 これですね。

テストプロセス・用語について

 発表資料P.10~22あたりです。

 「テスト観点」という用語は、JSTQBの用語集に載らないほど深遠なものなので、あえて立ち入りませんでした。。

 にしさんからのご質問と、それに対する回答だったかと思いますが、ちゃんと回答できていませんね。
 わたしとしては、フローグラフや状態遷移図に、カバレッジ基準やフィルタ基準を追加したものが、テスト設計仕様だと考えています。
 たとえば状態遷移図を書いて、「2スイッチカバレッジ=100%を満たすためのテストケースのうち、優先度・高の状態を経由するもののみ」みたいな基準を与えるということです。

 これについても当日、やまさきさんのご指摘を理解できなかったので、後日確認した結果が以下です。

 わたしとしてはできるだけI/JSTQB用語に準拠したいと思っていて、あえて独自路線を走るつもりはなかったのですが、不勉強と誤認のため「ズレ」が出ていたようです。
 そうか、テストケースってテスト設計のアウトプットなのか・・・。この辺は勉強しなおしです。。。

テストケース周りのER図について

 発表資料P.24あたりです。

 これは鈴木三紀夫さんによる、「テストケース周りをモデリングする際の2つのアプローチ」についての説明です。
 1つ目は、現在すでにある帳票(たとえばExcelベースの書式)からのモデリング。たとえばExcelシートに「機能ID」「機能名」を書く欄があって、その下にテストケースを書く行がずらーっと並んでいるとしたら、これは「機能IDに対してテストケースは0個以上存在する」ということを意味していることになり、ER図でいうと1:nの関係になります。
 もう1つのアプローチは、すでに実装されているテスト管理ツールの外部仕様から、「おそらくこうであろう」という内部モデルを推定するモデリング。

 今回のわたしのモデリングは、基本はまず後者。バージョン管理、プラットフォーム管理という部分はTestLinkから、データ駆動テストの部分はSquash TMから。またキーワード駆動テストの部分は、使用している自動テストフレームワークから学んだことをベースにしています。

 現場のExcelテスト仕様書も、テスト管理ツールも、As-Isであることには変わらないと思っていて、両方をごっちゃにした印象になりましたね。

 おそらく、ER図を見てのご指摘かと思います。「テスト設計仕様」を導出するものとして「テスト開発の上流成果物」をおいているのですが、テストベースもこの位置にあるべきですね。「テスト設計仕様」より上流の工程はある意味ブラックボックスで語っちゃっています。

 初めはテストケースと「観点」をn:1で関連付けていたのですが、にしさんに「1つのテストケースに複数の観点が入ることはないのか」と問われ、n:mにしました。その後もう一度考え直し、「観点とテストケースの間に、テスト設計仕様があるのでは」と考えて、今の形になっています。この辺は、全然煮詰まっていないですね。

テストケースが持つべき情報について

 発表資料P.27あたりです。

 あまり厳密にルール化しない方がいいかなと思います。発表資料P.27にあるように、機能・品質特性・テスト設計仕様名*1からある程度類推できるので、さらに補足があれば補う、程度で。

 これはどんな議論だったか忘れてしまった。
 たしか、「テスト手順」に入る前の、「事前条件」を整えること自体の pass / fail を確認したいという話だったかと思います。
 リプライにぶら下がっているように、それを確認したいなら「事前条件」を「手順」に移すのが自然じゃないかなと思います。

テストケースのバージョン管理について

 発表資料P.31~32あたりです。

 当日の議論は、「共通部」には変更が発生せず、「個別部」はバージョン管理を行う、という前提でお話ししていました。
 言われて気づきましたが、確かにバージョンに依存しない「共通部」も変化はしますよね・・・。ってことはバージョン管理が必要なのか・・・。
 現時点では、「誤字レベルはバージョン管理しない。それより重い変更は、テストケース自体が別物と考える」かなあ。

 確かにそのとおりで、インシデント管理システム側にプロダクトバージョンを記録することはあると思います。
 ですが、その場合、「インシデントを検出したテスト実行」にしか記録されない可能性があるので、「テスト実行」自体に、対象プロダクトバージョンと対象テストケースバージョンを記録しておくべきかなと思います。

 これは資料P.32の表現が悪かったです。
 ある1つのプロダクトに対しバージョンがあり、それに対応してテストもバージョンが上がっていきます。
 一方そのプロダクトに兄弟製品(たとえば機能制限版)があると、その別プロダクトに対してもテストが定義され、別プロダクトのバージョンが上がると、それに対応してテストもバージョンが上がっていきます。
 議論の中で、この2つのプロダクトのことまで「プロダクトバージョン」と呼んでいたため、おかしくなっていました。

 この辺は議事録なのか個人ツイートなのか思い出せないのですが、今回の議論の中で特に生煮えな部分だと思います。
 データ駆動化されたテストケースにおいて、「バージョン個別部」のテストパラメタまで変わる場合、パラメタライズされた手順に影響があるのは必至です。となると、「バージョン個別部」に対応して「テスト手順」も変わっていくので、バージョン管理が必要ですね。ただ、「バージョン個別部」と「テスト手順」は1:1対応でいい(ような気がしている)ので、いっしょくたに管理することになるのかもしれません。

データ駆動・キーワード駆動について

 疑問の内容がうまく理解できていないのですが、「パラメタと値をどういうテーブル構造で管理するのか」ということでしょうか。
 SquashTMというテスト管理ツールは、データ駆動用のパラメタをテスト手順と個別に保持することができ、そのパラメタ数は可変です。
 おそらく、パラメタ1・値1、パラメタ2・値2、・・・というカラムを持つテーブル構造なのではと思います。

 このネタ1本でけっこうもちそうなテーマですね。実行時まで抽象的テストケースのままということはありうると思います。

その他

 だいぶ、事前に参照しておくべきことを怠っていました。勉強します。

 次回の議論があれば、絶対そうした方がいいですね・・・。

 バージョンの話と、データ駆動・キーワード駆動の話はかなり色合いの違う話で、また上述のように、エンティティの関係性はかなり生煮えでしたね。
 一人で考えていると、なんとなくきれいに整理できた気になるのですが、実際に運用回そうとするといきなり行き詰まりそうだとよくわかったので、あらためて整理していきたいと思います。

 E-R図をしっかり見直してからこの「後編」を書こうと思っていたのですが、いつまで経っても完成しないので先に投稿します。
 修正版E-R図は、またどこかで・・・。

*1:P.27にはテスト設計仕様IDしか書かれていないけれど、テストケースのビューとしては設計仕様まで表示するとベター

進捗管理のメトリクスに関するメモ

 作業の進捗における、計画値と実績値の乖離の表現について、考えたことの整理&実験です。
 ここでは例として、テストケースの件数ベースの進捗管理を考えます。

遅延率と「相対的進捗率」

 「どれだけ遅延しているか」を表現する場合によく使われるのは、「遅延率」です。
 たとえば、ある時点で50件が消化済みである予定だったが、実際には45件しか消化できていない。この場合、分母が50、分子が5(=50-45)なので、遅延率は10%ということになります*1。直感的でわかりやすいですね。

 一方、Squash TMというテスト管理ツールでは、「Real vs. prev. progress」というメトリクスが使われています。

sites.google.com

 計算式が不明なのでいろいろ試してみると、以下のようなものだと判明しました。名前がないので、ここでは仮に「相対的進捗率」と呼ぶことにします。

相対的進捗率 = 進捗率 / 期間経過率

 自然言語でいうと、「経過した時間に相当するだけの進捗が出ているか」ということです。
 たとえば、全10日のテスト期間に対し3日間がすでに終わったとして、全100のテストケースのうち20件が消化済みだとしましょう。進捗率 = 20%、期間経過率 = 30%なので、相対的進捗率は66.7%ということになります。

 遅延率を使う場合、「妥当な消化計画があること」という暗黙の前提がありますが、相対的進捗率の計算には「消化計画」は出てこないので、計画を立てない場合でも利用できます。逆に言うと、たとえば「最初の立ち上がりは遅いが、途中からテストケース消化のスピードが上がり・・・」といったニュアンスは加味してくれません。

 ちなみにSquash TMでは、テストケースごとの消化計画という概念がありません。理由はわかりませんが、短期間のイテレーションごとにテストを行うという文脈でのツールなので、わざわざ綿密な消化計画は立てず、期間で簡易に進捗状況を把握しようということなのかもしれません。

遅延率と相対的進捗率の比較

 ざくっと整理すると、以下の表のようになります。

遅延率 相対的進捗率
意味 計画した消化済み件数に対する、計画と実績の差分 すでに経過した期間の割合に対する、すでに消化した件数の割合
計算式 (消化済み件数(計画)-消化済み件数(実績)) / 消化済み件数(計画) 進捗率 / 期間経過率
値域 -∞~0~100% 0%~∞
0%の意味 計画に対して遅延がない状態 進捗がない状態
100%の意味 進捗がない状態 経過した時間に対して遅延がない状態
-100%の意味 計画に対して実際の進捗が倍の状態
長所 計画が適切であれば、遅延の程度がわかりやすい。 計画がなくても、日数の経過だけで算出できる。
短所 計画が不適切だと、重大な遅延を見逃すことがある。 件数の重みがある場合などが考慮できない。

2つのメトリクスの挙動

 まずは一番単純なケースとして、「毎日同じ件数だけ消化していく」計画を考えてみましょう。マーカーがある方が第1軸、ない方が第2軸です。

01

 最初は計画を上回る進捗速度でしたが、次第に鈍化していき、7日目には計画を下回っています(赤の実線)。
 遅延率(青の実線)は0%が基準、相対的進捗率(緑の実線)は100%が基準であり、正負は逆転しているものの、本質的に同じ動きをしています。

 次に、「始めはなだらかに、中間は急に、終盤はまたなだらかに」という計画を考えてみます。テストの場合、最初の立ち上がりに時間がかかったりするケースはよくありますね。
 この計画に対し、1日目だけ1件遅延するケースはどうなるか。

02a

 遅延率はいきなり100%と最悪値ですが、それ以降は計画どおりなので急速に0に戻っていきます。一方相対的進捗率は、計画とは無関係に、「経過した時間の分だけ進捗しているか」なので、進捗スピードの速くなる中盤になるまでは正常値に戻りません。

 こうして比べてみると、妥当性のある計画がある場合には遅延率で、そうでない場合は相対的進捗率で様子を見るとよさそうですね。

遅延率と相対的進捗率の問題点

 さて、2つのメトリクスの今ひとつの欠点について。

 たとえば毎日、計画の8割ずつしか進められなかったとしましょう。遅延率は、ずっと20%です。それ自体は正しいのですが、期間の序盤の遅延20%と、終盤のそれとでは、「ヤバさ」が異なるはずです。が、それを読み取ることは難しい。

03a

  そして奇妙なことに、相対的進捗率の方も、なだらかながら「改善」しています。進捗スピードこそ計画の半分ながら、中盤の急な計画に対する半分なので、期間比率からみると改善しているように見えてしまうのです。
 となると、この2つを合わせて見ても、「遅延は一定だが、全体的には回復傾向にある」とミスリードされかねません。

遅延率に残期間を織り込んでみる

 ということで、遅延率の考え方と、相対的進捗率の2つの要素を合わせて、次のような式を作ってみましょう。仮に名前を「進捗リスク」と置きます。

進捗リスク = 遅延率 / 期間残余率

 期間残余率 = 1- 期間経過率 で、要は10日の期間のうち8日経過したのであれば、残余率は20%です。
 これを先ほどのグラフに追加すると、こう。

03b

 「リスク」(赤い実践)があからさまに増大していることがわかります。8日では分母が0.2、9日目では0.1になるので、全体として倍になるためです。

 「1件だけ遅れ続けている」ケースにおいても、

02b

 序盤では「あー、遅れてると言っても1件だけね、特に問題ないかな」って感じで0に近づいてきますが、中盤から「は? いつまで遅延残してるの?」って雰囲気を出し始めて、終盤で「おーい! 早く回復しろよ!」と訴え始めるふるまいになっています。なんかかわいいですね。

 いや、進捗管理の定石メトリクスってこれだろ普通!っていうのがあれば教えてください。特に何も調べず、Excelとにらめっこしながら考えただけなので・・・。

*1:前倒しの場合、遅延率はマイナスになります。