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

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

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

 この記事は、ソフトウェアテストの小ネタ 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:前倒しの場合、遅延率はマイナスになります。

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

 『テスト管理を語る夕べ』というイベントで、お話をさせていただきました。
 主催のみっきーさん、インフラ整えてくださってしんすくさんとなそさん、twitter実況してくれた書記のぱいんさんとブロッコリーさん、←どんなメンツなんだ?
 そしてこんなマニアック目なテーマの勉強会に金曜夜を使ってくれた奇特な参加者のみなさんに感謝します。

kataruyube.connpass.com togetter.com

 「テスト管理」というと対象範囲が広く、たとえば「テストの進捗に遅延が発生した際に、どのように解決していくのか!」といった、かっこいい感じの「テスト管理」もあるのですが、今回の発表は地味な「テストケースの持つべき情報・構造」に関するものです。

 Excelによる2次元表でのテストケース&テスト実行管理というのがもっとも「わかりやすい」ものですが、その扱いづらさ、限界、破綻を感じるは少なくないでしょう。
 たとえば2回同じテストを行い、その結果がExcelの1行に「pass/fail」と記載されているのを見たことがありませんか。こんな些細なことでも以下のような問題があります。

  • 1つの行に複数の結果が書かれており、集計が困難になる。
  • 2回のテストが、どのプロダクトバージョンで行われたか追跡できない。
  • 同じプロダクトバージョンで2回目で合格したとしたら、テストケースの方を修正した可能性があるが、それも追跡できない。

 場合によってはそこから、いわゆる「テスト管理ツール」の検討に進む組織もあるでしょう。しかしそれもうまくいくとは限りません。
 テスト管理ツールが提案するテスト管理・表現方法と、自組織の考え方が合わない。手動テストと自動テストをうまくシームレスに扱えない。導入のためのイニシャルコスト(検討、ツール比較、パイロット導入、ルール作成、トレーニング、・・・)が払えないなど。
 幸いわたしは、仕事の一部にテスト管理ツールを導入できていますが、それもどうも、ニーズを完全に満たすものではない。

 そんな中で、そもそもテストケースというものはどのような「カタチ」をしているべきなのだろう。また他の成果物とどのような関係を持つべきなのだろう。ということをあらためて考え始めました。ざくっとまとめてTwitterに投げたのが、以下です。

 これに対し有益なコメントをたくさんいただけたので、一人で盛り上がって2次検討した結果が、以下の表とER図です。ER図は記法がいい加減なので「エセ」ですが。

er contents

 今回はこの2つを中心に、

  • テストケースのバージョンとは
  • テストケースのパラメタライズとは
  • キーワード駆動テストとは

などについて自分の考えを説明しました。

 後半はパトスがほとばしり過ぎて謎の早口おじさんになっていた気がしますが、少なくとも一部の方には興味を持っていただけたようで、ほっとしました。

 さて、以下に資料を公開していますが、当日多くのツッコミを受けたことからもわかるとおり、ドラフトに過ぎない資料です。
 今回いただいたご質問・ご指摘を踏まえてもう少しブラッシュアップしようと思っています。また、これもう少し進めたいねというご意見があれば、第2回目もやりたいなー(わたしはあまりしゃべらない立場で)とも思います。

www.slideshare.net

 この記事は「前編」です。「後編」では、いただいたコメントに対し、現時点での回答を試みます。