-
- いいね！0
鈴木三紀夫
@mkoszk
JaSST 東京のチュートリアルの資料を考えているのだけど、シナリオテストの解説は本当に難しい。たぶん、テストを専門にやっている人には、初めて聞く用語だらけになってしまうだろうし、いつも使っている頭の使い方とだいぶ違うだろうし。かと言って開発を主にやっている人にも馴染みが無い言葉
2012-01-10 15:18:03
鈴木三紀夫
@mkoszk
前職でシナリオテストの研修を企画していたんだけど、企画レベルで落とされまくって、一度も開催できなかったんだ。その理由は幾つかある。一つが受講者の設定が曖昧というもの。
2012-01-10 15:20:39
鈴木三紀夫
@mkoszk
前職では、シナリオテストのテスト設計を誰が実施するのか、という役割が標準化されていなかったのも原因なんだけど、企画を聞いた人たちの感想はこんな感じ。１．シナリオテストのテストケースを書く人が理解できそうもない。２．要件定義をやっている人でも、ここまで知っている人はいない。（続く）
2012-01-10 15:23:04
鈴木三紀夫
@mkoszk
（続き）３．誰でも出来るようになっていない。４．金融や産業のどの事業部でも使えるようになっていない。 ・・・ など、まぁ、肯定的な意見というのが一つも無かったんだな。
2012-01-10 15:25:51
鈴木三紀夫
@mkoszk
前職では、要件定義が出来る人というのは、ものすごく少ない。誤解があるか。保守案件の小さい規模の要件定義はできるけれども、シナリオテストが必要になるような中・大規模が出来る人が少ない。その少ない人がシナリオテストのテスト設計をするかというと、ほとんどしない。
2012-01-10 15:27:12
鈴木三紀夫
@mkoszk
だから誰でもできるようになっていないと、難しいんだな。あっ、シナリオテストのやり方を誰でもできるようにするのは比較的簡単なんだ。要件定義書が完璧ならばという前提をつけるならば。でも現実は出来る人が少ない訳だから、シナリオテストで使える要件定義書じゃないという前提で考えることになる
2012-01-10 15:29:40
鈴木三紀夫
@mkoszk
JaSST 東京のチュートリアルということは、業種業態が異なる人たちが集まるわけで、その人たちに満足してもらうようにするためには、今まで以上に工夫しないと、アンケートが酷い状況になりそうな気がするんだな。どこまで話をすべきか悩ましいんだな。
2012-01-10 15:32:59
鈴木三紀夫
@mkoszk
川口市のの業務要件定義 事業税[PDF] bit.ly/wdPj8W 、固定資産税[PDF] bit.ly/yw3LZf 、 法人住民税[PDF] bit.ly/A8oSMy 軽自動車税[PDF] http://t.co/81hjugAk
2012-01-10 15:38:39
鈴木三紀夫
@mkoszk
シナリオテストをGoogle先生に聞いてみると、おどろくほど情報が無い。外部セミナーも一部のクローズセミナーは別にして、オープンセミナーはほとんど無い。ISTQBのシラバスをみても、ユースケーステストはあってもシナリオテストは無い。
2012-01-10 17:39:08
鈴木三紀夫
@mkoszk
だからと言って、「シナリオテストなんていうのは無い」とは言えない。シナリオテストという名称を使っていないにしても、類似のテストは行っている組織はある。
2012-01-10 17:40:35
しんすく(け) さん。
@snsk
@mkoszk う。そういえばどう違うのか言えないです^^;シナリオの一種にユースケースがある？が真の場合ユースケース以外のシナリオとは？？です。
2012-01-10 17:40:38
鈴木三紀夫
@mkoszk
では、なぜ情報が少ないかというと、シナリオテストはドメイン知識と密接で、テストだけ切り出して考えている人が少ない。そもそもシナリオテストに従事した経験のある人が少ない。シナリオテストを実施する人はユーザ企業の人が大半で、外にでて発表することが少ない。などでしょう。
2012-01-10 17:43:29
鈴木三紀夫
@mkoszk
今度のチュートリアルでは、このような状況でシナリオテストを説明することになるわけです。だから背景、前提説明だけで、持ち時間が無くなってしまう危険性があるのです。(^^;) チュートリアルでは、テスト設計まで解説をするので、時間配分が大切なんです。
2012-01-10 17:46:00
鈴木三紀夫
@mkoszk
@snsk 業務とシステム軸とユースケースとそれ以外のマトリクスを考えてみてください。シラバスにあるユースケーステストは、システム×ユースケースにあたります。シナリオテストというのとそのほかの３つの枠も対象になります。
2012-01-10 17:48:43
鈴木三紀夫
@mkoszk
@snsk ユースケーステストは更に２つに分かれます。ユースケース記述をフローチャートのようにグラフにして、制御フローパステストのように、パスをシナリオとみなしてテスト設計する方法と、シナリオ構成要素を抽出し、この組合せでシナリオを作る設計方法があります。
2012-01-10 17:51:16
鈴木三紀夫
@mkoszk
ちなみに Googleで検索すると上位にくる「はじめてのシナリオテスト」[PDF] http://t.co/wWm9PQWz は、ＬＴの資料なので、読むときは気をつけてね。
2012-01-10 17:55:25
しんすく(け) さん。
@snsk
@mkoszk ありがとうございます。確認ですが、1.業務 2.システム軸 3.ユースケース 4.それ以外 の4^2 16マスのマトリクスになる、で前提合っていますか？？
2012-01-10 17:57:06
鈴木三紀夫
@mkoszk
@snsk 業務×ユースケース（ビジネスユースケースのテスト）、システム×ユースケース（ISTQBのユースケーステスト）、業務×それ以外（業務シナリオテスト、サイクルテストなど）、システム×それ以外（運用シナリオテストなど） の４つの箱ね。
2012-01-10 17:59:52
しんすく(け) さん。
@snsk
@mkoszk なるほど！4つのハコ理解です。で、JSTQB的なユースケースの実装方法として先ほど挙げて頂いた2種類があるわけですね。アウトライン理解できました。ありがとうございます。咀嚼にはあと少し掛かりそうです^^;
2012-01-10 18:13:01
鈴木三紀夫
@mkoszk
@snsk 一般的に言われているユースケーステストは、ユースケース記述をフローチャートにします。（グラフ化） 制御フローパステストのようにカバレッジを設定して、パスをシナリオと見なしてテスト設計します。
2012-01-10 18:25:14