13
2015年10月3日 盛岡ソフトウェアテスト勉強会 バグ票ワーストプラクティス検討プロジェクト すずき しょうご 「BUG ADVOCACY」読んでみた

「Bug advocacy」読んでみた 公開版

  • Upload
    -

  • View
    288

  • Download
    0

Embed Size (px)

Citation preview

Page 1: 「Bug advocacy」読んでみた 公開版

2015年10月3日 盛岡ソフトウェアテスト勉強会

バグ票ワーストプラクティス検討プロジェクト

すずき しょうご

「BUG ADVOCACY」読んでみた

Page 2: 「Bug advocacy」読んでみた 公開版

自己紹介

• すずき しょうご

• 某メーカ系関連企業の企業向けソフトウェアの品質保証部門

• 設計レビュー / プロセス改善 / ソフトウェアテスト

• JCSQE初級、JSTQB FL / AL(Test Manager)

• バグ票ワーストプラクティス検討プロジェクト SQuBOK読破会 / 探索的テスト研究会 SQiP関連のイベント等 / JaSST関連のイベント等

• 「バグレポートの改善に向けた問題事例の調査とアンチパターン化」 ソフトウェア品質シンポジウム2013(Best Paper Future Award受賞) JaSST’14 Tokyo 経験発表

• 「バグレポートの改善に向けた問題事例の調査とアンチパターンの作成」 ソフトウェア品質シンポジウム2014招待講演

Twitter : @rin2_

Page 3: 「Bug advocacy」読んでみた 公開版

バグレポートで困った経験はありませんか?

3 2015/9/16 6:30現在の検索結果 https://twitter.com/search?q=%E3%83%90%E3%82%B0%E7%A5%A8&src=typd

Page 4: 「Bug advocacy」読んでみた 公開版

コミュニティ活動の背景

テスター プログラマ

設計者 QA

サポート 経営者

マネージャ ユーザ

バグ

レポート

開発現場では、バグレポートは有効に利用されていないのでは? (※バグレポート=ISTQB用語集のインシデントレポート)

バグレポートは、今日ソフトウェア開発の多くの組織で 使われている。

Page 5: 「Bug advocacy」読んでみた 公開版

はじめに • 以前の発表資料に「悪いバグレポートがどのようなものか議論がな

い」と書きました。

• しかし、2015/7/27 に上記のことに少し触れる書籍が出ました。

• 少しだけ、というかかなりかみ砕いて、紹介したいと思います。

http://www.amazon.com/gp/product/098981193X

Cem Kaner and Rebecca L Fiedler

BUG ADVOCACY

BUG

ADVOCACY

Page 6: 「Bug advocacy」読んでみた 公開版

バグ票ワーストプラクティス検討プロジェクト

すずき しょうご

2分で分かる「BUG ADVOCACY」

4分

Page 7: 「Bug advocacy」読んでみた 公開版

流し読み後の雑感

• バグレポートの書き方に関することを1冊にまとめた あまり他に例のない本

• バグレポートの書き方、扱い方(つまりは、コミュニケーション)に関して多くの示唆が得られる本

• 開発側とテスト側(担当者、マネジャ)についてのコミュニケーションについては書かれているが、開発プロセスのプロセス改善についての記載はあまりみられない?

• 見落としの恐れもあるため再度見直す

Page 8: 「Bug advocacy」読んでみた 公開版

本の構成

1.基本概念

2.バグを直したい人を作る

3.クリアなバグレポートを書くこと

4.再現できないバグ

5.非現実的、不合理として却下されるバグ

6.信用と影響

Page 9: 「Bug advocacy」読んでみた 公開版

概要

1. 基本概念

1.品質の定義(SQuBOKの内容とおおよそ同じ)

2.バグレポートのワークフロー

2. バグを直したい人を作る

1.バグの報告だけではない →直させるような記載でなければならない

2.「もっともよいテスターは、バグを見つけるひとではなく、 バグを直させる人である。」

3.直させるようなモチベーションをあたえる

Page 10: 「Bug advocacy」読んでみた 公開版

3. クリアなバグレポートを書くこと

1. BTSのお話し(目的とか)

2. 好まれない項目(修正時間、根本原因とか)

3. 問題が起こりやすい項目 (サマリ、レポートタイプ、再現性、深刻度、優先度とか)

4. 再現できないバグ

1. 事例

5. 非現実的または不合理として却下されうるバグ

1. バグレポートはいろいろな要因で却下されることがある

2. 反対意見に打ち勝つ→どんなときに抵抗されるのか? (再現できない、レポートが理解できない、多くの作業を強いられる とか)

Page 11: 「Bug advocacy」読んでみた 公開版

6. 信用と影響

1. なんでもかんでも報告としてあげればいいものではない。 しかし、深刻なものだけ報告すればいいというものでもない。

2. バグレポートの質の改善 (時間を与える、良いバグレポートを見せる、フィードバックを得るとか)

3. バグレポートは報告者によりバイアスがかかる →適切なバグレポートを書くようにする必要がある (明確に、重要なものを、誇張せずに などなど)

4. 開発者、その他ステークフォルダを礼儀と敬意をもって接する

Page 12: 「Bug advocacy」読んでみた 公開版

さらに詳しく知りたい方へ

• 一部動画で公開されているようです。( http://bbst.info/?page_id=23 )

Page 13: 「Bug advocacy」読んでみた 公開版

参考資料 • 本書の中で特に紹介されていた書籍

• Safeware: System Safety and Computers ( Nancy G. Leveson )

• How to Break Software ( James A. Whittaker )

• Measuring and Managing Performance in organizations (Robert D. Austin )

• Judgment Under Uncertainty: Heuristics and Biases

(Daniel Kahneman, Paul Slovic, Amos Tversky)

• Heuristics and Biases: The Psychology of Intuitive Judgment

(Thomas Gilovich and Dale Griffin)