柏/ネタ帳/HighPriorityDefect の履歴(No.9)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 柏/ネタ帳/HighPriorityDefect へ行く。
  • 1 (2018-02-27 (火) 00:59:53)
  • 2 (2018-02-27 (火) 01:06:55)
  • 3 (2018-02-27 (火) 07:40:00)
  • 4 (2018-02-28 (水) 02:04:50)
  • 5 (2018-03-05 (月) 01:56:57)
  • 6 (2018-03-05 (月) 07:05:31)
  • 7 (2018-03-09 (金) 02:30:31)
  • 8 (2018-03-22 (木) 13:26:00)
  • 9 (2018-03-23 (金) 03:35:08)
  • 10 (2018-03-29 (木) 08:57:22)
  • 11 (2018-03-30 (金) 06:12:29)
  • 12 (2018-04-02 (月) 05:12:24)
  • 13 (2018-04-02 (月) 18:54:13)
  • 14 (2018-04-04 (水) 02:23:06)
  • 15 (2018-04-04 (水) 05:25:09)
  • 16 (2018-04-05 (木) 06:57:01)
  • 17 (2018-04-06 (金) 07:46:24)
  • 18 (2018-04-07 (土) 07:25:36)
  • 19 (2018-04-08 (日) 03:09:34)
  • 20 (2018-04-10 (火) 02:14:30)
  • 21 (2018-04-16 (月) 08:28:14)
  • 22 (2018-04-16 (月) 13:36:57)
  • 23 (2018-04-17 (火) 06:31:14)
  • 24 (2018-04-17 (火) 11:35:15)
  • 25 (2018-04-18 (水) 01:08:44)
  • 26 (2018-04-18 (水) 13:31:25)
  • 27 (2018-04-22 (日) 08:01:42)
  • 28 (2018-04-24 (火) 04:43:50)
  • 29 (2018-04-27 (金) 03:58:49)

---

柏

ゴール†

• 優先度の自動設定ができるようにする
  • 優先度が意味があるものと証明すること
  • なぜ優先されるのかを明らかにする

背景†

• 不具合の優先度づけは大変
  • テストフェーズには大量の不具合が報告される
  • 報告される不具合はプロジェクトのコア開発者が不具合の内容を精査し，修正するかや優先度を決める
  • この精査は多くの時間を要する
  • リリースまでにプロジェクトの品質を上げるために，直すべき不具合を適切に把握・優先度は適切に設定し，リソースを上手く最大限活用して，優先すべき不具合を修正するべき
• 優先度の予測研究が行われている
  • 精度は40%程度と低い
  • 特にP1は低く，ソフトウェアは１件の不具合でもシステムが停止することがあるため，P1値はより，正確に見積もる必要がある

関連研究†

柏/ネタ帳/HighPriorityDefect/関連研究

研究設問†

RQ1 ：開発者はいつ優先度をつけるか†

• 各月の優先度変更数を比較

RQ2：優先度は守られているか（意味があるか）†

• 不具合の修正日数やリリースまでの修正完了率を比較

RQ3：優先度は誰が付けているか（コアな開発者か）†

• 優先度を付ける開発者に偏りがあるか

RQ4：なぜ優先されるのか（優先度をつける基準は何か）†

• 優先度ごとに以下を比較
  • リリースまでの時間を比較
  • 修正したソースコードがコア部分
  • 深刻度
  • セキュリティに関するワードが含まれるか

RQ5：(RQ4)で違いがでた値は予測に使えるか†

結果†

Eclipse†

RQ1 ：開発者はいつ優先度をつけるか†

• リリース前の3ヶ月間では変更回数が増える

RQ2：優先度は誰が付けているか（コアな開発者か）†

• 8割の優先度の変更は半分以下の開発者で行われている
• コアの定義が未定のため保留

RQ3：優先度は守られているか（意味があるか）†

• 修正日数は優先度が高いほど短い
• 修正完了率は優先度が高いほど高い

RQ4：優先度をつける基準は何か†

Discussion†

優先度が予測できるようになると，次のリリースまでにこのプロジェクトが直してくれるかがわかる†

全部の不具合が優先度を変更されていないのはめんどくさいから？†

• さっと直せるものは良いとして，リリース直前のものは，ちゃんとつけるべき
  • でも，それが面倒くさいから，優先度をちゃんとつけてないのでは？
  • 結局，リリースまでの時間を鑑みて，相対的に付けなければならないから，人間には容易ではない

メモ†

• 優先度は深刻度を見てつける(by David Lo)
• そもそも優先度と深刻度の違いは？
  • http://istqbexamcertification.com/what-is-the-difference-between-severity-and-priority/
  • 優先度
    • 相対的?
    • 影響範囲の広さ
  • 重要度は絶対的?
    • バグをひいたときの影響の強さ

• 修正時間は無視した方が良い←吉行の研究で結果が出なかったことを考慮
  • ただし，優先度が設定され直してから修正されるまでの時間であれば変わる可能性がある

疑問†

時期†

• 年度ごとにバラツキはあるか？
• 月によって違いはあるか
  • 3.4.5.6月でたくさんプライオリティが変更されているが，
    • それぞれの月で違いがあるか
    • また，その他の月と違いはあるか

内容†

• 優先度の指標は人によって違うのか
• 特徴量や単語を抽出できるか？
  • プロダクトやコンポーネントによって重要視されているものが違うのか？
• 正常系処理に関する欠陥がおおいのか？

その他†

• 研究者は優先度は当てにならないと言っているが，開発者もそう思っているのか
  • これ一章にもってきたら面白いのでは？

• 高い優先度の欠陥はすべて直されてリリースされてる？
  • リリースバージョンに注意
• 直す直さないの境目はどこ？
  • リリースまでに直せる・直せないがあることに注意
• 高い優先度はセキュリティが多いのか？
• 経験のない人が付ける優先度は無視されてるのではないか？
  • 不具合報告時も含める

• 優先度や重要度が高い不具合は経験がある開発者が担当するのか

• High/Low-Priority/Severityで分類すると修正時間に特徴はあるか
• https://www.testingexcellence.com/severity-and-priority-difference/

るか

情報†

• 優先度は，まず，テスターによってセットされ，最終的にはプロダクト・プロジェクトマネージャーが変更し直す．
  • http://softwaretestingfundamentals.com/defect-priority/
  • http://www.softwaretestinghelp.com/how-to-set-defect-priority-and-severity-with-defect-triage-process/

結果†

• 80%の不具合は，最初に付けた優先度から変更されずに修正されている
  • 残り２０％は誰が，どのタイミングで，なぜ，変更しているのか
  • リリース付近もよく見たほうが良い