テスト設計コンテスト負け犬の会 #tdcmakeinu
-
- いいね！0
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
Yki DaRMAチームの発表。「スープカレー法」になるのかなぁ。 #tdcmakeinu [うさみみ＊´×｀＊エンジニア]
2012-03-24 13:06:32
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
テスト設計コンテストの発表内容見ていると @mzp がたまにいってる「コード(プロダクトとして動くもの)以外のもの書きたくない」っておもうね。バランス難しいな。テスト設計することが目的になっていないかって大切よね。 #tdcmakeinu [うさみみ＊´×｀＊エンジニア]
2012-03-24 13:12:03
みずのり：jack of all trades/freelance
@NoriyukiMizuno
成果物を順に紹介します。テスト対象分析、製品を理解する。テスト観点で要求仕様書をレビューします。作成者に報告できないので、テストで確認する方針にしました。ユーザ議題、用途分析、ユーザの想定を考えて、議題と解決手段を考える。 #tdcmakeinu
2012-03-24 13:13:17
みずのり：jack of all trades/freelance
@NoriyukiMizuno
スープカレー表のユーザーゴールを導き出すために考えました。スープカレー表の元となる内容です。 #tdcmakeinu
2012-03-24 13:14:37
みずのり：jack of all trades/freelance
@NoriyukiMizuno
ユーザーゴール達成指標と機能要求、非機能要求を考えました。要求仕様構成を再構成して並び替えし、見直したものを行見出しへ。非機能要求を列見出しに割り当ててスープカレー表に繋げます。 #tdcmakeinu
2012-03-24 13:16:41
みずのり：jack of all trades/freelance
@NoriyukiMizuno
仕様書のレビュー結果から仕様書のリスクに落とし込むという検討を行いました。 （ひどい使われているケースも含めて）事故が発生したシナリオをあわせて考えて、異常シナリオを考えました。 #tdcmakeinu
2012-03-24 13:35:40
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
表現手段と実現手段を取り違え過ぎなんじゃないかな。->表はアーキテクチャじゃない #tdcmakeinu [うさみみ＊´×｀＊エンジニア]
2012-03-24 13:41:46
みずのり：jack of all trades/freelance
@NoriyukiMizuno
状態遷移図の通過パスを考えて、毎回通るパスの優先度を調整する。また、通過していないパスを見つけて考えることが出来ました。 #tdcmakeinu
2012-03-24 13:42:35
みずのり：jack of all trades/freelance
@NoriyukiMizuno
うさみみの ほんきが みられるぞ！ RT @kyon_mm 表現手段と実現手段を取り違え過ぎなんじゃないかな。->表はアーキテクチャじゃない #tdcmakeinu [うさみみ＊´×｀＊エンジニア]
2012-03-24 13:43:40
KEN-san
@krsna_sub
操作は組み合わせができるよね。ある操作中に他の機能を操作するなど。人の操作としては２機能が限度だろうということで２機能までの組み合わせとした。 #tdcmakeinu
2012-03-24 13:44:59
KEN-san
@krsna_sub
東京からの質問：システムレベルの設計をしてその後、統合テストの設計をしているように見えるが？ 実際はシステムと統合を並行して作業した。要求は同じなのでどっちが先かは意識していない。 #tdcmakeinu
2012-03-24 13:49:25
KEN-san
@krsna_sub
全チームに言えることなんだけど、発表者の内容がソフトウェア開発を意識していないように見える。例えばバグが出た後、修正が入るがその時にテスト成果物の影響を意識しているのだろうか？ #tdcmakeinu
2012-03-24 13:50:29
KEN-san
@krsna_sub
きょん質問：再テストになった時は、テストケースはどう修正されるのか？ 回答：んーそこはあんまり考えてないです。 #tdcmakeinu
2012-03-24 13:53:02