-
- いいね！0
イベント実況用アカウント
@rin2_live
個人任せにしないでチームで行っている立場：問題が発生したときに、必ず付随する問題があるので、それをチームで分析する #jasst11tokyo #jasst
2011-01-26 16:43:36
イベント実況用アカウント
@rin2_live
過去の不具合を分析してテストをやっている事例：Prgでできていたりできていなかったり。できているところは地祇のフェーズでのテストに組み込んでいる。分類の軸は2つ。機能や設計の種類とどんな種類(データ、タイミング)の不具合か、というもの #jasst11tokyo #jasst
2011-01-26 16:45:50
イベント実況用アカウント
@rin2_live
開発状況が得られない状況でどのようにバグの分析を行うか？→仕様書ベースで類似の機能をみていく #jasst11tokyo #jasst
2011-01-26 16:49:38
イベント実況用アカウント
@rin2_live
BTSの書かれた内容をみて、何をミスしたのかという原因などを見る。テストたーの人と毎朝共有する。次はどのようにすればバグがでるかを担当者と打ち合わせる #jasst11tokyo #jasst
2011-01-26 16:54:04
イベント実況用アカウント
@rin2_live
探索型テストは動きが怪しいところの原因を考えるが、考えるきっかけやポイントがあるのか？＞コーポランド #jasst11tokyo #jasst
2011-01-26 16:55:36
YOSHIDA Takehiko
@chihayafuru
上司はテストをやめろといった。やめるべき？？？ => テストを続ける倫理的、道徳的、法律的理由はあるか？ by コープランド #jasst
2011-01-26 16:57:24
イベント実況用アカウント
@rin2_live
上司がテストをいいといったらやめるべきか？→テストを続ける理由があるか？を自問する。あるならやるべき。ないなら上司に従うべき #jasst11tokyo #jasst
2011-01-26 16:57:56
YOSHIDA Takehiko
@chihayafuru
でもそのような理由がないのであれば上司は上司であり、彼／彼女に従うべきである。そのために彼／彼女は高給をもらっているのだから。 #jasst
2011-01-26 16:59:02
イベント実況用アカウント
@rin2_live
不具合ｈあ収束しても品質は必ずしもいいとは限らない。テストの数は増えてバグが減っても、品質が伴っているかは別の確認が必要 #jasst11tokyo #jasst
2011-01-26 17:00:35
YOSHIDA Takehiko
@chihayafuru
システムの最も重要なところ、リスクがあるところを潰しておく。潰してある。リスクベーステストの考え方。必ずしもテスト数や収束率だけがテスト終了の判断材料ではない。 #jasst
2011-01-26 17:02:18
イベント実況用アカウント
@rin2_live
1つは、ツーリングをする。機能のマップをつくる。何らかの順番で試していく。リスクに応じて実施すんべき #jasst11tokyo #jasst
2011-01-26 17:03:32
イベント実況用アカウント
@rin2_live
他の方法もある。機能からのアプローチではなく、アウトプットからのアプローチも考えられる。 #jasst11tokyo #jasst
2011-01-26 17:04:23
イベント実況用アカウント
@rin2_live
じぶんの直感に頼るところが大きい。感覚に依存。以前あったところにはまた不具合があると考える #jasst11tokyo #jasst
2011-01-26 17:05:35
イベント実況用アカウント
@rin2_live
リスクベースドテストを考えるのは難しい。リスクのつけ方はあたるんですか？ #jasst11tokyo #jasst
2011-01-26 17:06:31