この記事はソフトウェアテスト Advent Calendar 2017 – Qiitaの3日目です。
一つ前の記事は@yoshikiitoさんの テスト自動化における集中と拡大でした。
今年から生まれて始めてアドベントカレンダーに参加させていただきます。
freddiefujiwaraです よろしくお願いします。
#1.全数テストは不可能
早速ですが、みさなん "全数テストは不可能"という原則は聞いたことがあるけど
どのくらい膨大になるのかイマイチピントこないという事はありませんか？
有名な下記の問題があります。
"N×Nで区分された碁盤目状の道を、左上から右下まで遠回りを許しつつ同じ場所を通らない道順の数"
例えば
##2x2であれば
= 12通り
5x5であれば。。。
=126,281通り 
##では16x16 はどうでしょう
= 6.8*10^62通り 
こちらのYouTubeを見るともっと実感がわきます。フカシキの数え方
同じようにアプリケーションの中でも、
各モジュールやクラスのユニットテストのステートメントカバレッジは100%は目指せても
その後の結合テストやシステムテストすべてのケースを網羅することは
テストケースを一つ一つ書き出すことはもちろん、実行となったら膨大な時間がかかることが予想されます。
#2.欠陥は偏在する
つくづく"バグ"という言葉はいい表現だなと改めて思うのですが。
ソフトウェア開発において、欠陥はまんべんなく存在しているのではなく
こんな感じで
 |
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
実際は偏在して存在していることが多いです
こんな感じでスイートスポットが存在します。
|||||
|:--|---|---|---|--:|
|||||
|||||
|||||
|||||
理由としては欠陥は人間のミスによって引き起こされ
複雑な箇所、変更を加えた箇所、新しい技術を適応した箇所や多くの人が関与している場所
欠陥が発生した箇所（なぜなら欠陥の修正は先述の変更にあたるからです)等
ミスを起こしやすいところというのは全体ではなく絞られてきます。
#3.リスクベーステスト
以上
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年半やってみてです。お楽しみに