テスト観点、テストカテゴリ、テストアーキテクチャなど

Yoshiki Ito/伊藤由貴 @yoshikiito

ゆもつよメソッドを使ってテストケースから意図をリバースする　#wacate

リナ？ @____rina____

ただの仕様書目次のコピペにならないように　#wacate

やの　よしを @YoshiwoYano

個人的には、ソフト構造を意識しない機能整理はデンジャラスと思ふ。#wacate

K_Suzuki @keigo1450

デジカメを例にテスト対象分析 #wacate

Masaki Kase @softest

ゆもつよメソッド小演習。入出力＋設定が主枝になる班、CRUDが主枝になる班、遷移に注目する班があった #wacate

zunko motoyama @motozun

先生、機能分解奥深いです。。。#wacate

やの　よしを @YoshiwoYano

機能分割、、、奥深いというよりも、ここでミスると後で死ぬ。 #wacate

リナ？ @____rina____

Q.「～画面」単位に考えてしまうので、 「～機能」「～遷移」を基準にというのがピンとこない。 #wacate

やの　よしを @YoshiwoYano

難しい質問。。マインドマップを、MECE的に機能を分解していくために使うのか、トップビュー（？）を設けて機能の抽出に使うのかの違いかな？ #wacate

Masao @MasaoApril

抽象と具象の軸なのかな？ #wacate

やの　よしを @YoshiwoYano

「品質モデルからその製品にあったものを選択する」、シレッと凄く重要なことを言いました。 #wacate

山本くにお＠元村上 @gen519

@____rina____ 開発・デザイナーの方は、「画面」単位で、仕様・テストを考え。。。企画・要求開発の方は、遷移・フローで考え。。。　バックエンド（サーバ）の方は、機能がで考える場合が、多いかも？　#wacate

Masaki Kase @softest

機能モデル：入力、出力、貯蔵、変換、サポート、そして管理 #wacate

山本くにお＠元村上 @gen519

@YoshiwoYano 品質モデルは、ドメイン毎に、重みづけがかなり異なると思っているので・・・本当に、すごいことをシレッと言いましたね！　w でも、品質モデルとマッピングするのは、超重要ですよね！！ がんばれ、WACATE達よ！！　#wacate

やの　よしを @YoshiwoYano

機能モデルも品質モデルと同様、その製品のコンテキストに合わせて、考慮の有無や優先順を決めるべきかと思いました。#wacate

Yoshiki Ito/伊藤由貴 @yoshikiito

自分がテストする対象に応じた機能モデルを作ってみる　#wacate

zunko motoyama @motozun

今、機能モデルに似た感じの絵をもとに要件定義してる気がするのでなんとなく納得。。#wacate

山本くにお＠元村上 @gen519

@____rina____ 「一は全、全は一」、すべては、システムとして繋がっています。ｗ 画面仕様書の導線もフローの導線も、事象としては「等価」です、根源を理解・分解・再構築すると、良い仕様書になるかもしれませんね。ｗ #wacate

Masao @MasaoApril

機能モデルと品質モデルを繋げる要素って、目的なのかな？(間違っているかもしれないけど) #wacate

飛鳥🌗外資系占い師 @askamijo

結構な情報量なので、ぜひぜひslideahareも後でご覧くださいませ。 #wacate

時雨 @siguremon

4.2.4のこの図はもやもやするなぁ… #wacate

飛鳥🌗外資系占い師 @askamijo

こちらがゆもつよメソッド関連唯一のslideshareです。　slideshare.net/kjstylepp/ss-3…　#wacate

Masao @MasaoApril

ドメイン知識も必要な気がした... #wacate

時雨 @siguremon

テスト分析マトリクスを先にイメージしないとテストカテゴリは出せないような…？ #wacate

時雨 @siguremon

違うか。機能一覧と機能モデルをぶつけたマトリクスを作って、当てはまるテストカテゴリを見つければいいのかな #wacate