Slide 1

Slide 1 text

バグから学び、次につなげよう WACATE 2023 冬

Slide 2

Slide 2 text

自己紹介 ● CazunariMuraho(caz) ● @cazu_PR ● WACATE の参加歴 ○ WACATE 2022 冬 オンライン初参加 ○ WACATE 2023 夏 オフライン参加 Most Accelerating Paper賞 ○ WACATE 2023 冬 から WACATE 実行委員 ● その他、社外活動 ○ mablers_JP サポートメンバー ● 猫も犬もどっちもかわいい🐶🐱

Slide 3

Slide 3 text

このセッションの目的 ● テストに慣れてきたベテランではないQA担当者に、バグとの 新しい向き合い方を知ってもらう ● バグを分析するための体系的な手法をおおまかに知ってもら う ⏩

Slide 4

Slide 4 text

話の流れ 1. バグってなに? 2. バグから「そのバグがある」以上の情報を得る方法 3. 「バグ分析」が指すもの 4. バグから学びを得ようとした先にあるもの ⏩

Slide 5

Slide 5 text

話の流れ 1. バグってなに? 2. バグから「そのバグがある」以上の情報を得る方法 3. 「バグ分析」が指すもの 4. バグから学びを得ようとした先にあるもの ⏩

Slide 6

Slide 6 text

皆さんにとってバグとはどんなものですか?

Slide 7

Slide 7 text

皆さんにとってバグとはどんなものですか? ● プロダクトの伸びしろ(素敵やん) ● この世から無くなってほしいもの(過激) ● 気持ちがネガティブになるもの(わかる) etc…

Slide 8

Slide 8 text

皆さんにとってバグとはどんなものですか? ● プロダクトの伸びしろ(素敵やん) ● この世から無くなってほしいもの(過激) ● 気持ちがネガティブになるもの(わかる) etc… 程度の差はあれど、たいていの人がネガティブな気持ちになるので は?

Slide 9

Slide 9 text

バグに対してネガティブな印象を持ってしまう理由 ● プロダクトが正しく動作しないとユーザが困るから ● 実装にミスがあったことを示唆するから ● テストの不備を示唆するから

Slide 10

Slide 10 text

バグに対してネガティブな印象を持ってしまう理由 ● プロダクトが正しく動作しないとユーザが困るから ● 実装にミスがあったことを示唆するから ● テストの不備を示唆するから そもそも... 「人間は完璧ではない(ミスをする)」 「単純なシステムを除き全数テストは不可能」 なので”そういうことはある”という前提を持つ必要がありそう。

Slide 11

Slide 11 text

● プロダクトが正しく動作しないとユーザが困るから ● 実装にミスがあったことを示唆するから ● テストの不備を示唆するから バグに対してネガティブな印象を持ってしまう理由 これは... そう。

Slide 12

Slide 12 text

バグが良くない理由 →ユーザが困るから

Slide 13

Slide 13 text

ユーザじゃなかったら?

Slide 14

Slide 14 text

そもそもバグって... ● プロダクトや開発プロセスの状態を把握できる”情報” ● プロダクトや開発プロセスの明確な課題(解決すると良くなるも の) ⏩

Slide 15

Slide 15 text

そもそもバグって... ● プロダクトや開発プロセスの状態を把握できる”情報” ● プロダクトや開発プロセスの明確な課題(解決すると良くなるも の) ↓ であるならばバグとは、プロダクトや開発プロセスに関与できる者 の立場で捉えてみると... ⏩

Slide 16

Slide 16 text

プロダクトや開発プロセスを より良くするための示唆であり伸びしろ というポジティブな捉え方もできる ⏩

Slide 17

Slide 17 text

バグって何? →プロダクトや開発プロセスを より良くするための示唆であり伸びしろ

Slide 18

Slide 18 text

話の流れ 1. バグってなに? 2. バグから「そのバグがある」以上の情報を得る方法 3. 「バグ分析」が指すもの 4. バグから学びを得ようとした先にあるもの ⏩

Slide 19

Slide 19 text

バグから「そのバグがある」以上の情報を得るに はどうすればいい? ⏩

Slide 20

Slide 20 text

分析・観察すること ⏩

Slide 21

Slide 21 text

バグの分析・観察に使える 体系的な手法がある ⏩

Slide 22

Slide 22 text

今回は4つの手法をご紹介します ● なぜなぜ分析 ● ODC ● 欠陥モデリング ● 信頼度成長曲線 ※今回は概要だけの説明となります

Slide 23

Slide 23 text

なぜなぜ分析

Slide 24

Slide 24 text

なぜなぜ分析の概要 目的 やり方 結果 注意点 根本原因の追求 「なぜ」という問いか けを繰り返す 問題の真の原因を 究明できる(はず) 根本原因を特定するの が重要。「なぜ」の回数 自体は重要ではない 「なぜ」の深堀を他人が 行うと原因追及ではなく 反省行為になる場合が ある 根本原因を個人に帰結 させるとチームや仕組 みで解決できなくなる

Slide 25

Slide 25 text

なぜなぜ分析のイメージ 事象 事象発生の 原因 事象発生の 原因の原因 なぜ? なぜ? 事象発生の 原因の原因 の原因 なぜ? 対策

Slide 26

Slide 26 text

ODC

Slide 27

Slide 27 text

ODC(Orthogonal Defect Classification) の概要 目的 やり方 結果 注意点 ソフトウェア開発(プ ロセス)の見える化 プロセスの論理的 不具合分布と、実際 の不具合分布を比 較することで「何か がおかしい」ことを 気づかせる 個々の不具合に対 してではなく、それ を生み出したプロセ スの「やり方の質」 を改善するための 情報を得られる テスト担当者と開発 担当者が一緒に取 り組む必要がある が、学習コストが高 い 開発プロセスが定 義されている必要 がある

Slide 28

Slide 28 text

ODC のイメージ 1/3 バグ 各バグに属性情報を 付与する タイプ属性 ○○ トリガー属性 △△ ソース属性 □□ インパクト属性 ×× ※単純化して 図式してます バグ タイプ属性 ○○ トリガー属性 △△ ソース属性 □□ インパクト属性 ×× ・・・

Slide 29

Slide 29 text

ODC のイメージ 2/3 属性情報を元に開発プロセス内の 不具合分布が分かるグラフを作り、論理的な分布と実際 の比較する ※単純化して 図式してます 論理的 な分布 設計 レ ビュ ー 単体テス ト 機能テス ト システムテス ト 個別のモジュールやモジュールの組 み合わせに起因するバグ 実際 設計 レ ビュ ー 単体テス ト 機能テス ト システムテス ト 改善の示唆 を得る

Slide 30

Slide 30 text

ODC のイメージ 3/3 ※単純化して 図式してます 論理的 な分布 設計 レ ビュ ー 単体テス ト 機能テス ト システムテス ト ○○ 設計 レ ビュ ー 単体テス ト 機能テス ト システムテス ト ×× △△ ※実際は以下のような「積上げグラフ」や棒グラフを1プロセス内に複数 横に並べる形で表現する

Slide 31

Slide 31 text

欠陥モデリング

Slide 32

Slide 32 text

欠陥モデリングの概要 目的 やり方 結果 注意点 バグを資産化する バグの情報から一 般化できる内容を 取り出し、永続的・ 長期的な情報整理 を行う バグから得られた 知見を横展開しや すくなる 抽象化のスキルが 身に付くまで取り組 みに時間がかかる

Slide 33

Slide 33 text

欠陥モデリングのイメージ バグをモデル化 (バグの構造や仕 組みを単純化する) 対策 バグ バグ 誘発因子 ○○ 過失因子 △△ 増幅因子 □□ 欠陥 ×× 表出現象 II 誘発因子 ○○ 過失因子 △△ 増幅因子 □□ 欠陥 ×× 表出現象 II 参照 蓄積(資産化) ・・・

Slide 34

Slide 34 text

信頼度成長曲線

Slide 35

Slide 35 text

信頼度成長曲線の概要 目的 やり方 結果 注意点 残存バグ数推測 バグの「累積数」と 「経過時間(もしくは 消化テストケース 数)」の関係をグラフ 化する 残存バグ数を推測 できる(精度につい ては...) 実際にバグが見つ かり切っているの か、単にテストが上 手くいってないのか 見極めることが難し い

Slide 36

Slide 36 text

信頼度成長曲線のイメージ 意思決定の参 考にする 類似プロジェク トとの相対評価 累積 バグ数 経過時間(もしくは消化テストケース数)

Slide 37

Slide 37 text

以上が、バグの分析・観察に使える 体系的な手法の一部でした ⏩

Slide 38

Slide 38 text

※かなり詳細を省いてい説明している手法もあるため、 取り組む前にご自身でもお調べください (スライドの最後に私が参照した資料をご紹介しています)

Slide 39

Slide 39 text

話の流れ 1. バグってなに? 2. バグから「そのバグがある」以上の情報を得る方法 3. 「バグ分析」が指すもの 4. バグから学びを得ようとした先にあるもの

Slide 40

Slide 40 text

「バグ分析」という言葉が指すものって どんなもの?

Slide 41

Slide 41 text

SQuBOK では「バグ分析」を以下のように説明をしている ● バグの根本原因や発生傾向を把握し、同一原因のバグの発 見を図るとともに、類似バグの混入を防止してプロダクトの品 質を向上する ⏩

Slide 42

Slide 42 text

バグ分析には2種類のやり方がある 1. 個々のバグに対して混入した根本原因を調べる 2. プロセスや組織の弱点をバグの統計情報を使って調べる 1 は根元を特定するイメージ 2 は環境を把握するイメージ この葉がバグだとすると 共通:バグの情報を使う 相違点:得られる情報の種 類 ⏩

Slide 43

Slide 43 text

先ほど紹介した4つの手法は「バグ分析」に該当 する(バグ分析と呼べる)取り組みのように思え る

Slide 44

Slide 44 text

信頼や品質の向上という文脈で登場する分析手法は様々 ● なぜなぜ分析 ● ODC ● 欠陥モデリング ● 成長度信頼度曲線 ● 故障モード影響解析(FMEA) ● FTA ● STAMP ● HAZOP など

Slide 45

Slide 45 text

信頼や品質の向上という文脈で登場する分析手法は様々 ● なぜなぜ分析 ● ODC ● 欠陥モデリング ● 成長度信頼度曲線 ● 故障モード影響解析(FMEA) ● FTA ● STAMP ● HAZOP など 「バグ分析」って どれが該当するの?

Slide 46

Slide 46 text

信頼や品質の向上という文脈で登場する分析手法は様々 ● なぜなぜ分析 ● ODC ● 欠陥モデリング ● 成長度信頼度曲線 ● 故障モード影響解析(FMEA) ● FTA ● STAMP ● HAZOP など リスク評価手法と呼ばれるもの リスクを評価し、マネジメントするための手法 ISO.IEC 31010:2019 – リスク管理 – リスク評価技術」で紹介されてるも の ※STAMP は上記での紹介はないがリスク評価手法の仲間 「バグ分析」といえそう なもの

Slide 47

Slide 47 text

「バグ分析」と言われたら... 「バグの根本原因や発生傾向を把握し、同一原因のバグの発見を図るととも に、類似バグの混入を防止してプロダクトの品質を向上する活動。具体的には 「なぜなぜ分析」「ODC」「欠陥モデリング」「信頼度成長曲線」などの手法が該 当する」 と思えば良さそう ※具体的な例は人によって認識に差が出る内容なので注意

Slide 48

Slide 48 text

話の流れ 1. バグってなに? 2. バグからそのバグ以上の情報を得る方法 3. 「バグ分析」が指すもの 4. バグから学びを得ようとした先にあるもの

Slide 49

Slide 49 text

バグ分析などを駆使して情報を集めだした結果 ● 色々な情報は集まったものの、何をしていいかわからない ● 何をしていいかわかったものの、するリソースがない(優先度 が上がらない)

Slide 50

Slide 50 text

バグ分析などを駆使して情報を集めだした結果 ● 色々な情報は集まったものの、何をしていいかわからない ● 何をしていいかわかったものの、するリソースがない(優先度 が上がらない) プロジェクトの制約や目的によっては仕方ない場合がある

Slide 51

Slide 51 text

バグ分析などを駆使して情報を集めだした結果 ● 色々な情報は集まったものの、何をしていいかわからない ● 何をしていいかわかったものの、するリソースがない(優先度 が上がらない) どんな現場であっても避けたい。

Slide 52

Slide 52 text

情報が集まったのに何をしていいかわからなくなる原因 ● 情報を集める目的(達成したいこと)が定まってない ● 何をすべきか判断できるだけの情報がまだ集まっていない

Slide 53

Slide 53 text

情報が集まったのに何をしていいかわからなくなる原因 これを判断するためにも「目的」が必要 ● 情報を集める目的(達成したいこと)が定まってない ● 何をすべきか判断できるだけの情報がまだ集まっていない

Slide 54

Slide 54 text

目的(達成したいこと)がはっきりしてないと活動 を進めたり修正することができない

Slide 55

Slide 55 text

目的(達成したいこと)大事 ※登壇者自身に向けても言っています

Slide 56

Slide 56 text

情報を集めだした結果ぶつかる課題を乗り越えるために ● 色々な情報は集まったものの、何をしていいかわからない →目的(達成したいこと)に立ち返る ● 何をしていいかわかったものの、するリソースがない(優先度が上 がらない) →最小リソースで効果の出そうな施策を提案する(課題を小さくする) or 分析活動を続けて学びを増やしつつ改善のアクションチャンスが来 るのを待つ

Slide 57

Slide 57 text

本セッションのまとめ ● バグは、ユーザの視点に立つと悪だが、開発の視点に立つと改善のため の有益な情報となる ● バグ分析などの手法を使うと、バグから「そのバグがある」以上の情報を知 ることができる ● 今日紹介したような手法はバグ分析に該当すると思われる ● バグ分析などを通じて情報を得る時は、目的(達成したいこと)を意識する のが重要 ● 分析結果を元にした改善活動に取り組むリソースがない場合、最小リソー スで効果の出そうな施策を提案するか、分析活動を続けて学びを増やしつ つ改善のアクションチャンスが来るのを待つなどできると建設的

Slide 58

Slide 58 text

END

Slide 59

Slide 59 text

参考資料 書籍 - ソフトウェア品質知識体系ガイド-SQuBOK Guide V3 第3版- - ソフトウェア不具合改善手法ODC分析 工程の「質」を可視化する web - 情報処理システム高信頼化教訓集 ITサービス編 2020年3月16日 (https://www.ipa.go.jp/publish/qv6pgp0000000wo6-att/000071988.pdf) - 根本原因とは何か?ソフトウェア開発などのエラー解消に役立つ「なぜなぜ分析」についても解説( https://q-media.jp/about/) - 過失に着目した欠陥のモデリング バグ分析はなぜうまくいかないのか?(https://www.jasst.jp/symposium/jasst13tokyo/pdf/C4.pdf) - 欠陥モデリングの記法で日常トラブルを表現してみた(https://mejiro8.hatenablog.com/entry/2022/12/28/224035) - 評価者によるODCを使用した不具合分析の現場展開~属人化を排除していく試み~ (https://jasst.jp/symposium/jasst15tokyo/pdf/A5-2.pdf) - 設計プロセスの課題をODC分析で改善してみた(https://www.jaspic.org/event/2015/SPIJapan/session1C/1C-2_ID004.pdf) - 信頼度成長曲線を使って品質管理をする!(https://itmanabi.com/reliability-growth-curve/) - 不具合分析(テスト漏れ・欠陥流出原因の分析)のやり方、私の場合 (https://kawabeaver.hatenablog.com/entry/2021/08/10/233000)