-
- いいね！0
しんすく(け) さん。
@snsk
@kyon_mm @oota_ken とすると、テスト戦略を建てるためのpatternとして、リスク駆動や特性駆動があるかなー、というのもスッキリする。特に日本はリスク駆動(問題おきますよ！)のほうが相性いいように思える。
2013-09-18 10:44:33
しんすく(け) さん。
@snsk
@kyon_mm @oota_ken でもねー、脳内お花畑としてはー、問題起こさないために作ってんじゃないんだよねー、的なソウルもありー。なので個人的には、かつチームを鼓舞するためには特性駆動のほうが好き。
2013-09-18 10:45:46
Kenichiro Ota
@oota_ken
@snsk @kyon_mm 特性はそこから導き出される潜在リスクが分かっている人には有効かなー。その因果関係が分からないお客様とかはリスクから行った方がいいかな
2013-09-18 10:47:00
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@snsk @oota_ken 多くのテストでは「これができるとうれしいよね」と「それができないとかこまるなぁ」を表現する必要があるので、目的機能とかリスクベースは話しやすいわけですが、それはテストの問題領域であって解決領域ではないしんですよね。(続く)
2013-09-18 10:57:02
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@snsk @oota_ken 僕が欲しいのはテストの解決領域の設計実装パターンなんですよ。その上ではテスト観点はドメインとか実装方法とか跨ぐことができすぎるというか、感覚の都合になっていて、テストアーキテクチャ図の記号くらいにしか思えないのが非常にこう残念。
2013-09-18 10:59:24
しんすく(け) さん。
@snsk
@kyon_mm @oota_ken テスト自体が「解決領域」の中の話かと思ってましたが、その活動自体をモデル化したときの「問題領域」という理解前提で。テスト観点？は問題領域と解決領域の間を繋ぐものかなーと思ってました。ドメインをまたぐことができる、のは例えばどんな感じでしょ？
2013-09-18 11:10:43
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@snsk @oota_ken あ、ドメインっていっているのは問題領域/解決領域です。どちらでも使えそうな感じですが、解決領域の言葉として扱うには不十分な定義、パターンですが、問題領域を十分に扱える定義でもなく、むしろテスト観点って言葉必要だったのかよくわからない的な。
2013-09-18 11:29:35
しんすく(け) さん。
@snsk
@kyon_mm @oota_ken なるほど。僕はテスト観点？っていくつかの部品が組み合わさったアーキテクチャ的なイメージで、"テストの"問題領域のモデリングには充分な気がしてるのです。これF2Fで絵を書きながら話したいですね。
2013-09-18 11:32:03
しんすく(け) さん。
@snsk
@kyon_mm @oota_ken たぶん、その方法論を確立して広めようという人には取り敢えずの足場として必要、いまいま現場で考えたい人には混乱するだけ、じゃないかなーと思います。
2013-09-18 11:38:54
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
昼間にテスト観点ないわーってtweetしましたが、僕のテスト設計コンテストの成果物は基本的にこのスタイルなんで。[休眠＊´×｀＊エンジニア]
2013-09-18 18:38:24
Yasuharu NISHI
@YasuharuNishi
もう少し具体的に教えてくれると嬉しいな。例えば、こういうのをモデリングしようと思ったら困っちゃった、とか。 RT @kyon_mm: 曖昧な定義でむしろ使いにくい。オブジェクトが何かわからない時代と同じ雰囲気を感じる。
2013-09-20 10:44:12
Yasuharu NISHI
@YasuharuNishi
ふむふむ。 RT @kyon_mm: テスト観点は…設計スタイルの一種なのか、テストのためのメモ書きをまとめたものなのか
2013-09-20 10:44:40
Yasuharu NISHI
@YasuharuNishi
kwsk RT @mkoszk: 「テスト観点が分からない」の種類が違うと思う。 RT …キュミタソも同じように思っているみたいだから。
2013-09-20 10:45:23
Yasuharu NISHI
@YasuharuNishi
質問１「テスト観点って何だか分からない」 回答：テストケースをテスト条件、テスト対象、期待結果などに分解して下さい。それらを抽象化したものがテスト観点です。具体的な値は含みません。
2013-09-20 10:48:07
Yasuharu NISHI
@YasuharuNishi
例えば三角形の種類を判定するプログラムのテストにおいて、(3,3,3)はテスト観点ではありません。具体的な値だからです。(3,3,3)を抽象化すると例えば「正三角形」になりますね。この「正三角形」はテスト観点です。それをさらに抽象化した「三角形の種類」もテスト観点です。
2013-09-20 10:49:07
Yasuharu NISHI
@YasuharuNishi
テスト観点って何だかよく分からないという方は、とりあえず「テストケースを分解して抽象化したもの」と考えて下さい。まずはそこから始めましょう。
2013-09-20 10:49:55
Yasuharu NISHI
@YasuharuNishi
一方、そのことは重々分かってるんだけどよく分からん、という、どちらかというとソフトウェアエンジニアリングを修めた（？）方からの疑問もあります。きょんくんさんとか太田さんなんかはこのタイプだと思います。
2013-09-20 10:50:49
鈴木三紀夫
@mkoszk
@YasuharuNishi ２つある。 一つは、従来の仕様網羅＋テスト技法適用型とは、まったく異なる考え方を必要とされているので、それに対する困惑。 もう一つは、「テスト観点」という言葉を戦略的に曖昧にしているために、厳密な設計への障壁になっているが故の困惑。
2013-09-20 10:53:05
Kenichiro Ota
@oota_ken
@YasuharuNishi オブジェクト指向分析では正三角形がクラスだとしたら三角形の種類の定義はそのクラスのパワータイプです。抽象化という言葉で同じテスト観点としてまとめてしまっているのがわかりにくさを産んでいると思います
2013-09-20 10:53:44
Yasuharu NISHI
@YasuharuNishi
なぜなら、テスト要求分析（やテストアーキテクチャ設計）におけるテスト観点について議論しているからだと思います。クラスを構造体のようなものだと考えるレベルの人と、OOAで考えるレベルの人の、クラスに対する理解度の差だと私は認識しています。違うかもしれませんが。
2013-09-20 10:54:17
Yasuharu NISHI
@YasuharuNishi
TRA（テスト要求分析）でテスト観点をモデリングしようとすると、そもそもその時点でテストケースは考えてないわけですから、「抽象的なテスト条件など」という捉え方はできないわけです。思考がバックトラックになってしまいます。
2013-09-20 10:56:03
Yasuharu NISHI
@YasuharuNishi
するとTRAにおけるテスト観点は何ですか、という問いになるわけですが、そうすると「テストにおける関心事で、将来ブレークダウンするとテストケースになるやつです」みたいな言い方になってしまいます。でもこれでは全然分からないので、具体的な例示で曖昧な定義をカバーしようとしています。
2013-09-20 10:58:08
Yasuharu NISHI
@YasuharuNishi
例えば、負荷、構成、性能などはテスト観点であり、納期、エンジニアスキル、単価などはテスト観点ではありません。でもそうすると「テストタイプとどう違うの？」という問いが出てきます。
2013-09-20 10:59:33