リスクベーステストに関して

Last updated at 2017-12-03Posted at 2017-12-02

今年から生まれて始めてアドベントカレンダーに参加させていただきます。
freddiefujiwaraです　よろしくお願いします。

1.全数テストは不可能

早速ですが、みさなん　"全数テストは不可能"という原則は聞いたことがあるけど
どのくらい膨大になるのかイマイチピントこないという事はありませんか？

有名な下記の問題があります。
"N×Nで区分された碁盤目状の道を、左上から右下まで遠回りを許しつつ同じ場所を通らない道順の数"
例えば

= 12通り

5x5であれば。。。

=126,281通り

= 6.8*10^62通り　

こちらのYouTubeを見るともっと実感がわきます。フカシキの数え方

同じようにアプリケーションの中でも、
各モジュールやクラスのユニットテストのステートメントカバレッジは100%は目指せても
その後の結合テストやシステムテストすべてのケースを網羅することは
テストケースを一つ一つ書き出すことはもちろん、実行となったら膨大な時間がかかることが予想されます。

つくづく"バグ"という言葉はいい表現だなと改めて思うのですが。
ソフトウェア開発において、欠陥はまんべんなく存在しているのではなく
こんな感じで

実際は偏在して存在していることが多いです
こんな感じでスイートスポットが存在します。

理由としては欠陥は人間のミスによって引き起こされ
複雑な箇所、変更を加えた箇所、新しい技術を適応した箇所や多くの人が関与している場所
欠陥が発生した箇所（なぜなら欠陥の修正は先述の変更にあたるからです)等
ミスを起こしやすいところというのは全体ではなく絞られてきます。

以上
1.全数テストは不可能
2.欠陥は偏在する
という２つの理由から

欠陥の発生によって起こりうる問題の大きさ x 欠陥の発生確率

この２つを駆使して、スイートスポットを見つけ
リスクの高いところからテストを行うというのが今日紹介する方法です

PRISMAメソッドというのをネット上で見つけ　著者に英語から日本語への翻訳の許可をとりました
https://twitter.com/ErikvVeenendaal/status/922712650211053569

先日ようやく翻訳作業が終わりましたのでここで紹介させていただきます。
http://www.erikvanveenendaal.nl/site/wp-content/uploads/Practical-Risk-Based-Testing.pdf

翻訳の内容をgithubにあげており、もし間違いや不適切な箇所がありましたら
こちらからpull requestいただけると幸いです。
https://github.com/freddiefujiwara/prisma

それでは皆様、寒くなってきたので風邪を引かぬようお気をつけください
つぎは @taikoheiさんのTPI NEXT®を社内で1年半やってみてです。お楽しみに