Jasst'18 kansai テスコンからの納得できるテスト設計への挑戦

Jasst'18 kansai テスコンからの納得できるテスト設計への挑戦

Transcript

1. テスコンからの 納得できるテスト設計への挑戦 2018年6月15日 大段智広 （おおだん ともひろ） てすにゃん 1 /67 JaSST’18 Kansai
2. 公開用 自己紹介 2 /67 名前： 大段 智広 （おおだん ともひろ） お仕事： 開発技術導入支援（CI、静的解析 等） テスト関連の研修講師 社外活動： ソフトウェアテスト系のコミュニティ＆イベント に出没中 ✓JaSST Kansai 実行委員 ✓テスト設計コンテスト`15～18（てすにゃん） ✓関西ソフトウェアテスト勉強会(WARAI) ✓バグ票ワーストプラクティス検討プロジェクト
3. 3 /67 本日お伝えしたいこと
4. 4 /67 自分のテスト設計が いまいち（と言われる）
5. 5 /67 自分もテスト設計に いまいち納得できない
6. 6 /67 そのためには…
7. 7 /67 本当に解決したい “テストの意図や目的” を理解し、押さえる！
8. 8 /67 テスコンの活動を通じて これから２つのことを お話しします ※テスコン：ASTER テスト設計コンテスト
9. 9 /67 １つめは、 「”テストの目的や意図” を理解し、押さえる方法」
10. 10 /67 ２つめは、 「実践した 自分たちのテスト設計」
11. 公開用 1. テスコン（テスト設計コンテスト）とは 2. なぜテスコン？ 3. 納得できないテスト設計 4. “テスト設計”とは 5. “納得”とは 6. “納得できるテスト設計にするために” 7. 自分たちのテスト設計 8. まとめ 11 /67 アジェンダ
12. 公開用 指定のテストベースに対するテスト設計を行い、優劣を競う。 コンテストは各地域予選を行い、優秀と認められたチームが 決勝戦で争う。 テスコン（テスト設計コンテスト）とは 12 /67 http://aster.or.jp/business/contest.html#system
13. 公開用 参加当時のテストの悩み ✓会社のテストプロセスに沿ったテストしかしていない ✓現状でもテスト設計を行えるがより改善できるのでは？と感じている ✓開発が楽になる方法やQAの人ともっと連携できる方法があるはず… なぜテスコン？ 13 /67 納得できないテスト設計をしている (より良いテスト設計をしたい)
14. 公開用 テスト設計の悩み具体例 ⚫テストの項目自体がなんか足りない ⚫あるけどロジカルじゃない ⚫あるテストとあるテストのやり方に整合性や統一性がない ⚫網羅度が十分じゃない ⚫テスト項目、テストケース導出の根拠が不十分 ⚫項目の洗い出しやテストの実施が俗人的 ⚫そもそも開発製品が何やりたいかさっぱりわからん etc,.., 14 /67 納得できないテスト設計 ”テスト設計”と“納得”を改めて考える
15. 公開用 15 /67 “テスト設計”ってなんだ
16. 公開用 ソフトウェア開発プロセスと対応したテスト開発プロセスを 推奨している。 テスト開発プロセス 16 /67 テスト 要求分析 テスト アーキテク チャ設計 テスト 詳細設計 テスト 実装 テスト 実施 テスト目的(要求) の抽出と整理 テスト目的(要求) のテスト構造化 テスト条件・ テストケース作成 テストデータ/手順 作成や優先度づけ
17. 公開用 テスト設計（test design）】(JSTQB 引用) (1) test design specification を参照のこと。 テストアイテムのテスト条件（カバレッジアイテム）、詳細なテストアプロー チ、及び、関連する高位レベルテストケースを記述したドキュメント。 (2) 概略的なテスト目的を具体的なテスト条件とテストケースに変換 するプロセス。 17 /67 “テスト設計”とは テスト 要求分析 テスト アーキテク チャ設計 テスト 詳細設計 テスト 実装 テスト 実施 テスト設計 Input Output
18. 公開用 18 /67 “納得”ってなんだ
19. 公開用 『他人の考え・行為を理解し、もっともだと認めること』 19 /67 “納得”とは なるほど… そういうこと 考え 行為 理解 ＆ 認める 他人 自分 (デジタル大辞泉引用)
20. 公開用 20 /67 “納得”とは 考え 行為 他人 自分 例えば…他人の考え・行為が見えなかったり… 観る 見えない…
21. 公開用 21 /67 “納得”とは 考え 行為 他人 自分 見えたとしても、理解のための意図や目的は理解できないと… 観る わからん…
22. 公開用 22 /67 “納得”とは 他人 自分 認められず、無意識に拒否したり、理解できず混乱する。 混乱 考え 行為 拒否
23. 公開用 23 /67 “納得”とは 他人 自分 自分自身の拒否がその相手（他人）に伝わると… 混乱 考え 行為 不満 拒否
24. 公開用 24 /67 “納得”とは 行為 他人 自分 混乱 拒否 行く先は『争い』…。
25. 公開用 下記の取り組みが必要になる。 ① 他人（自分含む）を決める ② 他人の行為・考えに触れる ③ 理解するための方法を持つ ④ 他人と考えを認め合う術を持つ “納得”するためには… 25 /67 『他人の考え・行為を理解し、もっともだと認める』 ① ② ③ ④
26. 公開用 『テストに対する他人の考え・行為の目的や意図を理解し、 もっともだと認める』 26 /67 “納得できるテスト設計”にするために ① 他人（自分含む）を決める ⇒ ①文脈、場面状況を決める ② 他人の行為・考えに触れる ⇒ ②他人の行為・考えを話し合う ③ 理解するための方法を持つ ⇒ ③可視化・整理する ④ 他人と考えを認め合う術を持つ ⇒ ④文脈、場面状況を確認する そのためには
27. 公開用 27 /67 テスト設計した結果
28. 公開用 自分たちのテスト設計 28 /67 ① 文脈、場面状況を決める No. 内容 1 OSSプロジェクトへのアジャイルＱＡが分かる 2 エンドユーザのニーズに合わせた市場リリースができる 3 アジャイルのテストプロセスが知りたい 4 テストタイプ教えて 5 自動テストってどこをどんだけやればいいの？ 6 テストケースの作り方が分かる 7 テストケースがメンテしやすい 8 アジャイルテスト参考文献を探すときに便利 9 これやってみよう、うまく行きそうと思える 10 だれでもアジャイルテストがわかる 11 抽象的にも具体的にもテストの内容を説明できる 12 アジャイルプロジェクトでのテストについてこれ見てと言える 上 か ら 実 践
29. 公開用 自分たちのテスト設計 29 /67 ① 文脈、場面状況を決める ⚫開発製品 :オープンソースソフトウェアの通信カラオケシステム ⚫立場 :コミュニティメンバ QA担当 ⚫リソース :2人 ⚫リリース周期 :2週間(最新版)、6か月(安定板) 製品のフィーチャーはコミュニティ開発者の意思で、適宜実装される。
30. 公開用 自分たちのテスト設計 30 /67 ① 文脈、場面状況を決める
31. 公開用 自分たちのテスト設計 31 /67 ② 他人の行為・考えを話し合う 「製品のリリースを止めるバグ を許容範囲まで減らしたい！」 なんで？
32. 公開用 自分たちのテスト設計 32 /67 ③ 可視化・整理する 理由を理解できる要素まで分解する。 フィードバックが多い (バグ票が大量に出る) バグがなかなか治らない 提起課題の全体像 が分からない ソフトウェア構造の全体像を簡 単に把握できる手段がない ソフトウェア構造が 分からない 課題の全体を整理 する人がいない 修正箇所の影響範囲が 分からない テストする人員が少ない テストが十分にでき ていない コードをいじる と不具合が出る バグが見過ごされる テストのモチベー ションが低い
33. 公開用 自分たちのテスト設計 33 /67 ③ 可視化・整理する 問題の因果関係を整理する。
34. 公開用 自分たちのテスト設計 34 /67 ③ 可視化・整理する 解決すべき箇所を特定する。
35. 公開用 自分たちのテスト設計 35 /67 ④ 文脈、場面状況を確認する 確認しながら開発しているテスト設計を行う。
36. 公開用 ① 製品のリリースを止める事象およびバグをどう特定するか？ ② テストで対処する/しない事象はどのように決めるか？ ③ 対処するためにどんなテストをどれくらい行うか？ リリースについての課題 36 /67
37. 公開用 テストの全体像 37 /67 ① ② ③
38. 公開用 テストの全体像 38 /67 1 2 議論/合意ポイント
39. 公開用 事象の影響度(被害金額)と発生確率(リスク値)から 対処すべき事象(フォールト)を特定し、対応者について合意 する。 テストアーキテクチャ(フォールト) 39 /67 1 フォールトの やばさ 被害金額 コード変更リスク
40. 公開用 テストアーキテクチャ(フォールト) 40 /67 1 身体的 リスク 不快な音波 大音量 気分が悪くなる映像が流れる チカチカ(光の点滅) 金銭的 リスク 課金ができない 課金の計算が正しくない 課金データが改ざんされる 社会的 要請 クラッキングされる 踏み台にされる 操作データが外部にもれる 楽曲データがとられる 物理的破壊 リスク ハードウェアが壊れる バックアップデータが壊れる サーバーのデータを破壊する 大量にデータをDL 被害額一覧 フォールトリスト フォールトツリー図 リスク値一覧 身体的リスク 1000万円 金銭的リスク 500万 社会的要請 5億円 物理的破壊 リスク 10万円 フォールトツリーフレーム 被害額 × リスク値の総和 =やばさ：一位 合意ポイント
41. 公開用 フォールトツリー作成方法 41 /67 ユーザ事象 (トップ階層) システム事象 (ミドル階層) 原因事象 (ボトム階層) Top事象 サブ事象 サブ事象 原因事象 原因事象 まず、三層に分けてフォルトツリーを考える。
42. 公開用 フォールトツリー作成方法 42 /67 ユーザ事象 (トップ階層) システム事象 (ミドル階層) 原因事象 (ボトム階層) Top事象 サブ事象 サブ事象 原因事象 原因事象 ステークホルダーの要求からTop事象を出す。 より導出するため、要求に対して ガイドワードを適用し、Top事象を洗い出す。
43. 公開用 43 /67 要求からのTop事象(フォールト)だし 要求 ガイドワード ユーザ フォールト 起きてほしくない事象 要求＋HAZOPガイドワードにより、Top事象を効率よく導出する。 オーナ お客さんが利用 してくれ、儲かる （課金ができる） 種類：違う 課金額を誤る
44. 公開用 フォールトツリー作成方法 44 /67 ユーザ事象 (トップ階層) システム事象 (ミドル階層) 原因事象 (ボトム階層) Top事象 サブ事象 サブ事象 原因事象 原因事象 また他にハードとソフトの分析を行ってから作成する。 より導出するため、下記の分析を行っておく 1．システムのハード構成:機器の種類、機器の構成 2．システムのソフト構成:処理の種類、処理実装のファイル構成 ※想定でもよいので出す
45. 公開用 ハードの分析:機器の構成 45 /67 ソフト処理 ハード機器 グループ ユーザー グループ 例 処理の流れ ハードウェア機器の構成を考える。
46. 公開用 ソフトの分析：処理実装のファイル構成 46 /67 ソフト処理 課金制御ファイル ファイル 処理 関連 ※可能であれば、処理の流れも書く。 例 ソフトウェア処理実装のファイル構成を考える。
47. 公開用 リスク値の算出と割り当て 47 /67 原因事象 (ボトム階層) 原因 原因 課金制御ファイル 設定ファイル ソフト処理 ソフト処理 Bugspots（Google のバグ予測アルゴリズム） リスク値一覧 処理実装ファイル 原因に処理実装ファイルを紐づけ、リスク値を算出・割り当てる。
48. 公開用 原因事象 (ボトム階層) システム事象 (ミドル階層) ユーザ事象 (トップ階層) フォールトツリーフレームサンプル 48 /67 連曲モードで、単曲モー ド課金されてしまう 課金形態設定で単曲モー ドが設定されない 15-1 課金の計算が正しく ない or 単曲モードで、連曲モー ド課金されてしまう 課金形態設定で連曲モー ドが設定されない 15-2 キャンセルしても課金さ れてしまう（返金されな い） キャンセル信号が送信さ れない 15-3 設定した割引率が適用さ れない 課金リストの参照条件が ずれている 15-4 設定ファイル ソフト処理 機器通信ファイル ソフト処理 処理実装 ファイル
49. 公開用 原因事象 (ボトム階層) システム事象 (ミドル階層) ユーザ事象 (トップ階層) フォールトツリーフレームサンプル 49 /67 連曲モードで、単曲モー ド課金されてしまう 課金形態設定で単曲モー ドが設定されない 15-1 課金の計算が正しく ない or 単曲モードで、連曲モー ド課金されてしまう 課金形態設定で連曲モー ドが設定されない 15-2 キャンセルしても課金さ れてしまう（返金されな い） キャンセル信号が送信さ れない 15-3 設定した割引率が適用さ れない 課金リストの参照条件が ずれている 15-4 設定ファイル ソフト処理 機器通信ファイル ソフト処理 処理実装 ファイル 被害額：５００(万) リスク値：３．６ やばさ １８００ リスク値： ０．９ リスク値： ０．９ リスク値： ０．９ リスク値： ０．９ リスク値： ０．９ リスク値： ０．９ リスク値： ０．９ リスク値： ０．９ リスク値： ０．９ リスク値： ０．９
50. 公開用 テストで対処する起こってほしくない事象のために、テスト設 計方針を合意する。 テストアーキテクチャ(テスト設計方針) 50 /67 2 データ 条件 シナリオ イベント /タイミング 構成 軽 最低限のテスト 有効/無効 重複結果なし C0 0-switch 1-wise 中 ＋同値クラス 無効なし C1 セル網羅 2-wise 重 ＋境界値 完全 C2 1-switch 3-wise テストの重みづけ テストタイプ※1 データ 条件 シナリオ イベント /タイミング 構成 軽 最低限のテスト 31.00% 25.00% 56.76% 61.67% 23.57% 中 71.00% 45.00% 77.35% 83.89% 80.71% 重 95.00% 95.00% 95.00% 95.00% 95.00% リスク値低減度 テストタイプ ※テスト実施誤り率:5%と想定した。 フォールトテストの重み表
51. 公開用 システム事象 (ミドル階層) サブ事象 サブ事象 対処する事象(フォールト)の選定と対処方法割り当て 51 /67 QAが対処すべきかを合意する。 原因事象 (ボトム階層) 対応者 ユーザー ハード ベンダー 開発者 ＱＡ担当 テストする事象 原因 原因
52. 公開用 事象ごとのテスト担当決めフロー 52 /67 リスクが 顕在化しやす いか ソフト要因 のリスクか しにくい ユーザー テスト フォールト テスト(ハード) しやすい ユーザー ハード ベンダー ハード要因だけ ソフト要因がある No フォールト テスト(ソフト) ＱＡ担当 ユニット テスト 開発者 Yes 外部(コミュニティ外): ※コントロールできない範囲(ex.テストの方法、リソース) テストの種類 テスト実施者 ソフトカラオケ ハードカラオケ コード処理 が要因 ユニット テスト ＱＡ担当 開発者が ミスしやす いと思って いる Yes No ソフトカラオケ ソフトカラオケ テストの対象 コミュニティ: ソフトカラオケ
53. 公開用 対処する事象(フォールト)の選定と対処方法割り当て 53 /67 QAが対処すべき事象に対処方法（テストタイプ）を割り当てる。 システム事象 (ミドル階層) サブ事象 サブ事象 原因事象 (ボトム階層) 原因 原因 テストタイプ (テスト技法) 原因からどのようにテストケース を作成するか事前に決めておく。 同値分割/境界値分析 状態遷移図 ・・・
54. 公開用 テストタイプ⇔テスト技法対応表 54 /67 原因からどのようにテストケースを作成するか決めておく。
55. 公開用 対処する事象(フォールト)の選定と対処方法割り当て 55 /67 テストタイプの重みを割り当て、事象全体の「やばさ」を下げる。 原因事象 (ボトム階層) 原因 原因 0.9 リスク値 テストタイプ（データ） 重み 軽 ： 30％ 中 ： 70％ 重 ： 95% リスク低減度 0.64 0.27 0.045 -0.26の低減
56. 公開用 56 /67 フォールトツリー図サンプル ID 実装ファイル リスク値 対象カテゴリ 対処者 対処方法 重み リスク低減率対処後のリスク値 or before 1.8000 after 0.43416 リスク低減数 1.3658 データ 重 95.00% 0.0450 軽 56.76% 0.3892 設定しても演奏料金額が特定の料金 に反映されてしまう 14-2 設定ファイル 0.9000 ソフト QA 設定した演奏料金額が反映されない 14-1 設定ファイル 0.9000 ソフト QA 流れ 実装ファイル リスク値 対象カテゴリ 対処者 対処方法 重み リスク低減率対処後のリスク値 データ 重 95.00% 0.0450 軽 56.76% 0.3892 設定ファイル 0.9000 ソフト QA 設定ファイル 0.9000 ソフト QA 流れ リスク 特定 リスク分析 リスク評価
57. 公開用 テストケース導出モデルからテストケースを作成する。 テストケースサンプル 57 /67 テストケース導出モデル テストタイプ テスト技法 データ 同値分割/境界値分析 ※割引率の適用はなしとする テストケース 重み カバレッジ 実施テストケース数 テストケースNo. 課金形態 演奏料金 額 課金対象 予約登録数 1 連曲モード -10円 コンテンツ 1曲 設定できない 営業状態 になる 14-1 2 単曲モード -10円 コンテンツ 1曲 設定できない 同上 16-1 3 連曲モード -10円 コンテンツ 10000曲 設定できない 同上 4 なし 10000円 楽曲 9999曲 設定できない 同上 5 連曲モード 10000円 コンテンツ 10000曲 設定できない 同上 6 なし 0円 コンテンツ 6曲 課金されない 同上 7 単曲モード 10000円 楽曲 9曲 設定できない 同上 8 単曲モード 0円 コンテンツ 7曲 指定金額で課金 される 同上 9 単曲モード 0円 楽曲 6曲 指定金額で課金 される 同上 10 連曲モード 0円 コンテンツ 7曲 指定金額で課金 される 同上 11 単曲モード 9990円 楽曲 0曲 指定金額で課金 される 同上 12 連曲モード 9990円 コンテンツ 10000曲 指定金額で課金 される 同上 13 なし 9990円 楽曲 6曲 課金されない 同上 14 単曲モード 0円 コンテンツ 9999曲 指定金額で課金 される 同上 15 なし -10円 コンテンツ 6曲 設定できない 同上 16 単曲モード 10000円 楽曲 0曲 設定できない 同上 17 単曲モード 10000円 コンテンツ 9999曲 設定できない 同上 18 単曲モード -10円 コンテンツ 0曲 設定できない 同上 19 単曲モード 9990円 コンテンツ 10000曲 指定金額で課金 される 同上 20 なし 0円 コンテンツ 7曲 課金されない 同上 21 単曲モード -10円 楽曲 9999曲 設定できない 同上 22 なし -10円 コンテンツ 10000曲 設定できない 同上 23 連曲モード 0円 楽曲 6曲 指定金額で課金 される 同上 24 連曲モード -10円 コンテンツ 9曲 設定できない 同上 25 単曲モード 0円 楽曲 1曲 指定金額で課金 される 同上 26 なし 9990円 コンテンツ 1曲 課金されない 同上 27 単曲モード 9990円 コンテンツ 6曲 指定金額で課金 される 同上 28 なし 0円 楽曲 10000曲 課金されない 同上 29 なし 9990円 楽曲 7曲 課金されない 同上 168 事後条件 事象ＩＤ 入力条件（事前状態） 期待結果 有効/無効＋同値クラス＋境界値 重 … テストケース導出モデル テストケース
58. 公開用 リスク・テスト全体を俯瞰 58 /67 「やばさ」に対して、許容範囲になっているか、何をテストす るかを俯瞰する。 テスト俯瞰表
59. 公開用 リスク・テスト全体を俯瞰 59 /67 現在 対処後 基準値:1000 「やばさ」がどうなるかをそのリリース毎に確認していく。 対応必須なもの
60. 公開用 テスト開発コンセプト 「製品のリリースを止めるバグを許容範囲まで減らす！」 課題 1. 製品のリリースを止める事象およびバグをどう特定する か？ ⇒フォールトツリー図を用いた事象の分解 2. テストで対処する/しない事象はどのように決めるか？ ⇒被害金額とコード変更履歴からのリスク値による優先順位 3. 対処するためにどんなテストをどれくらい行うか？ ⇒テストタイプのリスク低減表による事象の許容範囲への調節 実現できそうか？ 60 /67
61. 公開用 テスト開発コンセプト 「製品のリリースを止めるバグを許容範囲まで減らす！」 課題 1. 製品のリリースを止める事象およびバグをどう特定する か？ ⇒フォールトツリー図を用いた事象の分解 2. テストで対処する/しない事象はどのように決めるか？ ⇒被害金額とコード変更履歴からのリスク値による優先順位 3. 対処するためにどんなテストをどれくらい行うか？ ⇒テストタイプのリスク低減表による事象の許容範囲への調節 実現できそうか？ 61 /67 テストする人員が少なくても、 修正箇所から影響範囲を見極め てテストを十分できる
62. 公開用 納得できている/できていないところが今後の課題。 開発したテスト設計 62 /67 ◆納得できていること ◦ 文脈や場面状況にあったテスト設計になった ◦ 実践できるテスト技術を習得・開発して適用できた ◆納得できていない（未消化な）こと ◦ テスト設計コンテスト審査員からのフィードバック ◦ 数値化したやばさ、被害金額の妥当性 ◦ テストケースを十分性 ◦ 文脈や場面状況が同じ、実テーマへの実践とフィードバック ◦ やりきれない場面が出てくるはず…その際の課題と解決方法の検討
63. 公開用 ◆納得するために ◦ 関連する他人の考えや行為を観察範囲を増やし、整理する ◦ 整理したものを通して、関連する他者と議論する ◦ 納得できている/できていないものを明確にして取り組む まとめ 63 /67 文脈、場面 状況 を決める 行為・考え を話し合う 可視化・ 整理する 文脈、場面 状況を確認 する やる やる やる やる やる しない やる テスト要求(目的)モデル やる
64. 公開用 ◆納得するために ◦ 関連する他者の考えや行為を観察範囲を増やし、整理する ◦ 整理したものを通して、関連する他者と議論する ◦ 納得できている/できていないものを明確にして取り組む まとめ 64 /67 文脈、場面 状況 を決める 行為・考え を話し合う 可視化・ 整理する 文脈、場面 状況を確認 する やる やる やる やる やる しない やる テスト要求(目的)モデル やる 自分がやり易いやり方でやってみる
65. 公開用 ◆ワンステップするために ◦ 関係する自分以外の押さえるべき考えや行為をないがしろにしない ◦ 考えや行為の観察範囲を整理して成長、洗練させていく ◦ 合わせてテスト技術を取り込んでいく（無暗に使わない） まとめ 65 /67 テスト要求 （目的、意図） テスト要求(目的)モデル テスト設計モデル テスト技術 テスト技術 テスト技術
66. 公開用 まとめ 66 /67 テスト要求 （目的、意図） テスト要求(目的)モデル テスト設計モデル テスト技術 テスト技術 テスト技術 一つずつ試していく ◆ワンステップするために ◦ 関係する自分以外の押さえるべき考えや行為をないがしろにしない ◦ 考えや行為の観察範囲を整理して成長、洗練させていく ◦ 合わせてテスト技術を取り込んでいく（無暗に使わない）
67. 公開用 ◆納得するために ◦ 関連する他者の考えや行為を観察範囲を増やし、整理する ◦ 整理したものを通して、関連する他者と議論する ◦ 納得できている/できていないものを明確にして取り組む まとめ 67 /67 ◆ワンステップするために ◦ 関係する自分以外の押さえるべき考えや行為をないがしろにしない ◦ 考えや行為の観察範囲を整理して成長、洗練させていく ◦ 合わせてテスト技術を取り込んでいく（無暗に使わない） ”テストの目的や意図”を理解し、押さえる方法確立して 自分なりのテストを開発して、育てていきましょう！
68. ご清聴 ありがとうございました 68
69. 公開用 参考資料 69 1. ASTER(2017)『テスト設計コンテスト’18 チュートリアル資料 Open版』ASTER. 2. International Software Testing Qualifications Board 用語集作業班(2014)『ソフトウェアテ スト標準用語集（日本語版）Version 2.3.J01』 Japan Software Testing Qualifications Board 技術委員会. 3. JaSST Kansai実行委員会(2016)『「ソフトウェアテストの価値って？」 ～ てすにゃんくえすと ～』http://jasst.jp/symposium/jasst16kansai/pdf/S4-1.pdf (2018/06/11 アクセス) 4. Igrigorik (2011)『Bugspots - Bug Prediction Heuristic』 https://github.com/igrigorik/bugspots (2018/06/11 アクセス)