テスト観点まとめ

Yasuharu NISHI @YasuharuNishi

この辺までの内容を一度テスト観点ツリーにまとめた方がいいのかな？ ＞ @kyon_mm

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

はい。いまはTogetterにまとめるくらいしかできていません。。。 RT: この辺までの内容を一度テスト観点ツリーにまとめた方がいいのかな？ ＞ @kyon_mm (via @YasuharuNishi)

鈴木三紀夫 @mkoszk

ストーリー ＞ シナリオ、ストーリー ＝ シナリオ、ストーリー ＜ シナリオ それぞれの人がいますね。以前、青山先生に確認したときは、ストーリー ≒ シナリオ でした。ストーリーは形式を持たず、シナリオは形式を持ちます。

鈴木三紀夫 @mkoszk

シナリオを例にします。シナリオと要求の関係は、シナリオから要求を導出する場合もあれば、シナリオの一部に要求がある場合もあり、文脈を知らないとシナリオと要求について語ることができません。

鈴木三紀夫 @mkoszk

シナリオの一部に要求がある場合の例を挙げます。シナリオとしてユースケース記述を取り上げます。ユースケース記述の書き方は様々ですが、「アクターは・・・する」「システムは・・・する」という書き方が一般的でしょう。この「システムは・・・する」は機能要求です。

鈴木三紀夫 @mkoszk

シナリオの構成要素の一部が要求（この場合は機能要求）になっています。

鈴木三紀夫 @mkoszk

@ikedon0505 僕は、非形式、形式の区別は同じですが、ストーリー　＞　シナリオのイメージを持っていました。

鈴木三紀夫 @mkoszk

シナリオを（システム）ユースケース記述としたとき、シナリオと要求の関係は１対１～多になります。

鈴木三紀夫 @mkoszk

要求にビジネス要求、システム要求、ソフトウェア要求といったスコープがあるように、シナリオにもスコープがあります。業務を中心としたものや、システムを中心としたものです。

鈴木三紀夫 @mkoszk

しかし、業務シナリオの中にビジネス要求、システム要求、ソフトウェア要求が入ることがあり、シナリオ一般でシナリオのスコープと要求のスコープの関係を語るのは難しいと感じています。

鈴木三紀夫 @mkoszk

. @kyon_mm さんのツイートに触発されて書き始めましたが、kyon_mm さんのコメントに対する批判やクレームではありません。誤解なきように。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@mkoszk 僕が誤解しているのかもしれませんが、自分と結構近いイメージでした。

鈴木三紀夫 @mkoszk

@kyon_mm うん、たぶん同じなんだろうなあと思っていました。僕のツイートは、より厳密にしたものですから。