まーた間が空いてしまいましたが、後編では、当日の関連ツイート(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図は、またどこかで・・・。