バグの定義って曖昧じゃない？

Transcript

1. "バグ"の定義って曖昧じゃない？
2. 自己紹介 • エンジニア ◦ web・インフラ（約7年）、QA（約1年） ◦ 上流工程と品質報告に首を突っ込んでいるうちにQAに • 趣味 ◦ 音楽、ドライブ、街作りゲーム、釣り ◦ 入った店がアプリ出してたら絶対入れて会員登録する
3. これから話すこと • かけだしQA向け ◦ 自動化の話はないヨ • かけだしの自分に聴かせたい内容 • 成長の足がかりになるかも？ ◦ なったらいいな
4. 「バグって何？」
5. 「バグって何？」 • ボタンが押せない、表示金額が間違っている。 • 条件式が間違っている、StringじゃなくIntegerを返している。 • そもそも仕様が間違っている。 ← これもバグ、、？
6. 「バグって何？」 • ボタンが押せない、表示金額が間違っている。 • 条件式が間違っている、StringじゃなくIntegerを返している。 • そもそも仕様が間違っている。 ← これもバグ、、？ • 「"プログラムが間違っていること、期待しない挙動のこと"」とか、、？ • 色々な意味で使われていそう
7. 「バグって何？」 • 本を読んでみた！ • "色々な意味"を区別して良い感じに表現してくれる言葉が用意されていた！ • これを紹介します。
8. 読んでみた
9. 現象と原因の違いに注目してみる 例：ある銀行のアプリ • ユーザーの口座残高が100円以上のとき、送金ボタンが出現する仕様 • 実際には、100円のとき送金ボタンが出現するはずが、出現しない挙動になっていた • 原因は、プログラム上の条件分岐が間違っていた。 → これはバグであるか？ バグだとしたらどこがバグか？
10. 現象と原因の違いに着目する • 「条件分岐が間違っていたこと」と、「送金ボタンが出現しない」は異なる概念 • 前者は"原因"で、後者は原因により発生した"現象"である。
11. みなさんはどれを”バグ”としましたか？
12. 何に注目するべきなのか • どちらも”バグ”と呼ぶことはできそう。 • 一旦定義から離れて、この区別について考えてみる。 • "原因"に注目した方がいい場合と、"現象"に注目した方がいい場合の両方がある。 • 不具合の管理や分析においては、"原因"に注目すると嬉しいことが多い。 （状況によるが、品質管理をする上では一般的にはおそらく。）
13. > 「検出バグ数（現象）、（原因）の各定義はどうなっているか？参考数値として使う場合に、どちらを使えば良いか？」 「現象数」は運用時やテスト実施時において想定と異なる形で発現した事象（不具合現象）の件数をいい、「原因数」は不具合現象 を引き起こしたソフトウェアの誤り（不具合原因）箇所の件数です。通常、試験工程において不具合が検出された場合、まず、不具 合の現象毎に記録し、その後不良の原因を分析して必要な対策をとるという流れになると考えます。 この場合、一つの原因から様々な現象が発生する場合や、逆に様々な原因が重なって、ある現象が発生する場合があります。そこで 不具合を管理する場合は、「現象別」での管理（カウント）と「原因別」での管理（カウント）の2種類が考えられます。そのため、 「検出バグ数」として、それらを区別して管理（カウント）しています。どちらの値を参考値とするかは、御社での不具合のカウン ト方法（現象別、原因別）に依存します。因みに、不具合は、本来は「原因別」で管理されるべきであると考えます。よって、デー タ白書では、「原因数」がある場合は、「原因数」を優先して使用しています。 https://www.ipa.go.jp/archive/publish/wp-sd/qa.html より IPAのデータ白書のQ&A
14. 理由書いてないやん
15. 私の理解 例：100画面で1種のAPIを呼ぶシステムAと、1画面で5種のAPIを呼ぶシステムB • どちらも全てのAPIに不具合があったとき。 • 現象で捉えた場合、システムAの方が不具合が多い • 原因で捉えた場合、システムBの方が不具合が多い → 不具合の修正工数や、リリースに関するリスクが大きいのはシステムBになる。 システムの不具合を取り除き、良い品質で計画通りリリースするという視点では、 現象よりも原因で考えた方が都合が良い。（だからIPAはそう言っている、と理解。）
16. 原因からさらに深掘ってみる
17. JSTQBでは以下の用語が定義されている • 故障（failure）.. コンポーネントやシステムが定義された範囲内で要求する機能を実 行しないこと。 • 欠陥（defect）.. 作業成果物に存在する、要件または仕様を満たさない不備または欠 点。 • エラー（error）.. 間違った結果を生み出す人間の行為。
18. 欠陥をよく理解する • "欠陥"は、これまでの話の"原因"に近いが、設計書の間違いも"欠陥"である。 • 例： ◦ 設計書には「xxには税込金額を表示」と記載されていた ◦ 実装もその通り税込金額を出すようになっていた ◦ 要件として正しいのは税抜金額を表示することだった • →この場合、設計書と実装のどちらにも欠陥があったことになる。 • 注：どちらも欠陥であることと、設計書の欠陥と実装の欠陥の因果関係（=設計の欠陥 により実装の欠陥が生まれたこと）を認めることは、両立する。
19. 故障、欠陥、エラー。 • "エラー"は、プログラム上のExceptionと言葉が似ていてややこしい。 ◦ 個人的には、野球におけるエラーと似たものと解釈すると分かりやすかった。 • "エラー"によって"欠陥"が生まれ、その"欠陥"により"故障"が生まれる、という因果関 係を、この用語たちで説明することができる。 • 「設計書の作成者が要件定義書をよく読まずに設計をしたため、記載を誤ったという "エラー"によって、「xxには税込金額を表示」という設計書の"欠陥"を生んだ。」 というように、先の例を表現することができる。
20. 注：エラーのその先 • エラーにも原因はある。 • 先の例で、誤った記載をしてしまった原因を考える ◦ 要件定義書をよく読まなかった ◦ そもそも読みづらかった ◦ プロジェクトに入ったばかりだった ◦ 睡眠不足で注意散漫だった... • エラーの原因はいくらでも深掘っていくことができる。 • 「なぜなぜ分析」をしていくことが、根本原因を取り除くことに繋がる。 • JSTQBの定義上は、欠陥の直接原因となった行為が"エラー"と呼ばれている。
21. より明確な言葉を使えば 物事をより深く理解できるかも
22. 言語的相対論
23. > 言語相対性仮説はサピア＝ウォーフの仮説とも言われ、言語学者のサピア,E.とウォーフ,B.L.が発 展させた考えです。これは、人の思考様式はその人が使う母語により決定される、または影響を受 けるという仮説です。 > もう１つは弱い仮説で、こちらは言語相対論と言われるものです。 これは外界をどう捉え分類していくかは、言語や文化の影響を受けて異なってくるというややマイ ルドな考え方です。例えば親族関係を表す際、日本語ではきょうだいを兄・姉・弟・妹と区別する 単語がありますが、英語では単体で兄を表す言葉はなく、言語的な特徴が異なります。言語相対論 ではこうした母語の特性の違いが、その言語を使用する人の思考様式にも影響を及ぼすと考えま す。 https://psychoterm.jp/basic/cognition/linguistic-relativity-hypothesis より 言語的相対論
24. 言語的相対論 • この仮説については現在も様々な議論があるらしい。 （この畑の人間ではなく詳しくはないです、すみません。） • この学説を肯定的に捉えてみると、、 • 今まで"バグ"とただ表現してきたものを、より明確に"故障", "欠陥", "エラー"という言 葉を使い分けて表現すれば、不具合についてより深い理解ができるかもしれない。
25. 正しい理解をすると良い結果になるはず • 自分の頭の中で、なんとなく使っている用語について理解を確かめてみる。 • 社内の方言もあるかも。 • プロの方々が定義した良いモデルにあやかる。 • “良いモデリング”ができることは、色々な場面で役に立つはず。
26. ありがとうございました