Dream's Square

お返事ありがとうございます。:)＞ものものさん

この疑問はさわらさんに向かってではなく、自分に対して向けたものでした。
@ITの記事でRexに聞いたように、最近リスクベースドテストとは何かというのを自問自答していたために、このように書いてしまいました。
不愉快な思いをさせてしまったとしたら、大変申し訳なく思います。お許し下さい。

なるほど、ものものさんの自問だったのですね。
私が勘違いしていました。ご心配をおかけしてすみませんでした。

不愉快とのことですが、全くそんなことはないです。寧ろ貴重なご意見をいただけて嬉しかったです。:)

私もリスクに関しては同じような悩みを持っています。＞品質リスクをきちんと理解してない
折角なので少し考えてみました。精神論っぽいかもしれませんが。
品質という単語が曖昧なように、リスクという単語もまた曖昧です。

ですから、品質を確保するためにリスクを評価するべきだと言われても、曖昧な物を証明するために曖昧な物を指標とする？？？、という考えに至ってしまってどうもすっきりとしません。

考えすぎなのかもしれませんけれど、曖昧な要素を消していくことがソフトウェア開発において求められている昨今、そういった前提に置いては逆行するようにも思えます。
そこらへんのリスク自体の位置づけなり意味持たせはある程度しっかりと考察をすべきなのだろうなと思っていますが、堂々巡りになって未だ解らしきものを見つけることが出来ないでいます。

ただし、Rexのいわんとするところの有効性は十分に理解も出来るので、やはりまずはチャレンジするしかないのでしょうね。

ここで大事なのは、リスクは誰にとってのリスクであるのかという視点です。
Rexの書籍の記述が今ひとつすっきりとしないのは、開発チーム(テストチーム)が認識している(しやすい)リスクに偏っているきらいがあるからだと思っています(まだしっかりと読んでいないので違うかもしれないけれど)。

一口にリスクと言っても、発注元、受注元、受注元の開発チーム、ユーザと様々で、さらに細分化していくことも出来ます。
当然立場の違いにより、同じシステム(オブジェクト)に対しても、コンセプトや職責の違いにより重要視するリスクの種別は異なってきます。

だから、開発チームがリスクだと思って力を入れたところが、実はユーザにとってはたいしたリスクでなかったということがあり得るわけで、そういう状態になってしまうとリスクベースドテストの有効性は果たして…？となってしまうわけですよね。

私も、正直考えあぐねているところがあって、日々の悩みとなっています。(TT)

論文書きのご迷惑になってしまったことをお詫びいたします。

いえいえ、迷惑なんてとんでもない。
煮詰まっていたところですし、気分転換によい頭の体操でした。

どうぞ、今後ともお気軽にご意見下さいませ。
こういったディスカッションは常時受け付け中です。ちゃんとお答え出来るかどうかは謎なのですが。（弱）