Successfully reported this slideshow.

インシデントレポートReboot 公開用

1

Share

1 of 39
1 of 39

インシデントレポートReboot 公開用

1

Share

Download to read offline

Description

WACATE2017 冬 - インシデントレポートセッション の資料です

Transcript

  1. 1. インシデントレポート :Reboot WACATE2017 冬 2017/12/17 WACATE 実行委員 藤原 洋平
  2. 2. 自己紹介 ふじわら ようへい 4代目 WACATE 実行委員長 2010年:新卒で開発系会社に入社 品質保証としてインシデントレポートを書く毎日 2016年:第三者検証会社へ転職 以来、テストとは無縁の生活を送る毎日 WACATE2017 冬
  3. 3. インシデントレポートとは WACATE2017 冬
  4. 4. インシデントレポートとは 発生したあらゆるインシデントを報告する ドキュメント 引用:JSTQB WACATE2017 冬
  5. 5. インシデントとは WACATE2017 冬
  6. 6. インシデントとは 発生した事象の中で、調査が必要なもの 引用:ISTQB WACATE2017 冬
  7. 7. つまり? WACATE2017 冬
  8. 8. 発生した事象の中で、調査が必要なもの  → 期待していた結果と違う 調査が必要と思われるものは、 すべてインシデントとして扱われる 従ってインシデントはコードの欠陥に限らず、 ドキュメントなどにも発生する 「バグ」 ≠ インシデント WACATE2017 冬
  9. 9. インシデントレポートとは 調査が必要となる事象が発生したときに、 それを報告するためのドキュメント 誰に? 開発担当者 テストリーダー プロジェクトリーダー WACATE2017 冬
  10. 10. ちなみに インシデントレポート バグレポート/バグ票/バグチケット 不具合報告書 問題点処理票 障害管理 などなど… WACATE2017 冬
  11. 11. 体験してみよう WACATE2017 冬
  12. 12. 体験してみよう ユーザビリティテストセッションで扱った BlackWACATEに不具合(インシデント)が 発生しました! インシデントレポートを作成して 開発担当者に現象を伝えて下さい WACATE2017 冬
  13. 13. 個人ワーク:10分 以下のテストケースを実施してください 手順: 1. <URL> にアクセス 2. 「参加申込」から、確認画面まで申請を進める  期待結果:  確認画面のメールアドレス欄に、入力した メールアドレスが表示されていること WACATE2017 冬
  14. 14. 個人ワーク:10分 システムを実際に確認しながらインシデント レポートを作成してください 全く書いたことがない方: 「開発者に、起こった事象を文章で伝えてください」 書き慣れている方: あなたの考える最強のレポートを作成してください 注意:バグ出しが目的ではありません! WACATE2017 冬
  15. 15. グループワーク:8分 班で共有してみてください 全く同一のレポートはありますか? 違いがある場合は違いに注目してみてください どんな観点で書かれたものなのか 誰のレポートが、分かりやすいと思いましたか? その理由はなぜですか? WACATE2017 冬
  16. 16. インシデントレポート :Reboot WACATE2017 冬
  17. 17. このセッションのゴール ほとんどレポートを書いたことがない人  インシデントレポートとは何なのかを知り 明日から報告ができるように 普段それなりに報告している人  目的を再認識し、レポートを改善するきっかけ を見つけてください インシデントレポート職人の皆様  最高のレポートを提供するための見直しとして WACATE2017 冬
  18. 18. Re:インシデントレポートとは 調査が必要となる事象が発生したときに、 それを報告するためのドキュメント → 開発担当者 → テストリーダー → プロジェクトリーダー WACATE2017 冬
  19. 19. Re:インシデントレポートとは テストを実施する テストケースの環境、手順に沿った操作 → 思い通りに動かない = 期待と違う 期待結果と操作の結果を比較 ⇒ インシデント WACATE2017 冬
  20. 20. Re:インシデントレポートとは 期待と違う動作を修正してもらうために 開発担当者へ依頼をする そのための手段のひとつとして、 インシデントレポートがある WACATE2017 冬
  21. 21. 分かりやすいレポートとは 開発者目線になって… 現象の把握がしやすいこと 何を実施しようとして発見したのか 期待動作が記載されている 再現できること 環境や手順が明確であること etc… WACATE2017 冬
  22. 22. どんな項目があると良いか 考えることも非常に重要ですが、 先人の知恵(「規格」)を拝借 ISO/IEC/IEEE 29119-3 ご参考:「60分でわかった気になるISO29119」 https://www.slideshare.net/kjstylepp/60iso29119-wacate WACATE2017 冬
  23. 23. ISO29119-3 Scope References Glossary Incident details Timing information Originator Context Description of the incident Originator’s assessment of severity Originator’s assessment of priority Risk Status of the incident WACATE2017 冬
  24. 24. IEEE829(ご参考) 識別ID 概要 詳細 入力 期待結果 実際の結果 障害内容 日付 実行手順 環境 再現手順 テスト担当者 オブザーバ 影響範囲 WACATE2017 冬
  25. 25. 個人&グループワーク どんな項目があり、何が書かれていると より良いレポートになるでしょうか それぞれの立場に立って、考えてみて下さい 開発担当者 テストリーダー プロジェクトリーダー WACATE2017 冬
  26. 26. 個人&グループワーク 付箋1枚に1項目書き出す なぜその項目が必要なのか その項目があると誰が嬉しいのか WACATE2017 冬
  27. 27. 全体共有 各班で 1〜2つ、 どんな項目があがったか なぜその項目が必要なのか その項目があると誰がうれしいのか を発表してください WACATE2017 冬
  28. 28. 情報源としてのレポート インシデントレポートは情報の宝の山 適切な項目を書いてもらうことで あらゆるものが可視化される テストの進捗状況/品質状況 → 今後の予測 モジュール毎の不具合の偏り → テスト濃淡 根本原因/抽象化された事象 → テストの入力 etc,etc… WACATE2017 冬
  29. 29. やりすぎには注意 項目が多ければ多いほど、入力に工数が かかる その項目は本当に必要なのか? 誰のために 何のために ”面倒臭い” と思われたら負け WACATE2017 冬
  30. 30. まとめ(まだワークあるよ) WACATE2017 冬
  31. 31. 私が考えるインシデントレポート インシデントレポートは様々なひととの コミュニケーション手段のひとつ 開発者、テストリーダー、プロジェクトリーダー インシデントを正しく、分かりやすく 「伝える」ことが重要 WACATE2017 冬
  32. 32. 私の好きな名言 WACATE2011 夏 より WACATE2017 冬 インシデントレポートは書くこと自体が目的ではない。 読む人に何か訴えたい、 伝えたいことがあるから書くもので、さらに、 読んだ人を動かす、何かアクションを起こしてもらう ために書くものなんだ http://jibun.atmarkit.co.jp/lcom01/special/wacate2011/02.html
  33. 33. 私の考える「良い」レポート 読む人にとって、必要な情報が書かれている 分かりやすく書かれている ⇒ インシデントレポート単体で見たときには もちろん必要なこと WACATE2017 冬
  34. 34. 私の考える「良い」レポート 「そもそも何でインシデントレポートが 必要なんだっけ」 テスト活動の一環 品質を確保するため プロセス改善をするための情報提供として 他人に影響を与えられるレポート WACATE2017 冬
  35. 35. 最後のワーク WACATE2017 冬
  36. 36. またしても……! ユーザビリティテストセッションで扱った BlackWACATEに不具合(インシデント)が 発生しました! インシデントレポートを作成して 開発担当者に現象を伝えて下さい WACATE2017 冬
  37. 37. 個人ワーク: 以下のテストケースを実施してください 手順: 1. <URL> にアクセス 2. 「会社:」に「わかてB」と入力し検索  期待結果:  検索結果が何も表示されないこと (わかてB という会社は存在していない) WACATE2017 冬
  38. 38. 今度は、こんなことを意識して見てください 誰のためにレポートを書いているのか 何のためにレポートを書いているのか そのレポートはどんな価値を持つのか 最初のワーク結果と変わった所はありますか? WACATE2017 冬
  39. 39. WACATE2017 冬

Description

WACATE2017 冬 - インシデントレポートセッション の資料です

Transcript

  1. 1. インシデントレポート :Reboot WACATE2017 冬 2017/12/17 WACATE 実行委員 藤原 洋平
  2. 2. 自己紹介 ふじわら ようへい 4代目 WACATE 実行委員長 2010年:新卒で開発系会社に入社 品質保証としてインシデントレポートを書く毎日 2016年:第三者検証会社へ転職 以来、テストとは無縁の生活を送る毎日 WACATE2017 冬
  3. 3. インシデントレポートとは WACATE2017 冬
  4. 4. インシデントレポートとは 発生したあらゆるインシデントを報告する ドキュメント 引用:JSTQB WACATE2017 冬
  5. 5. インシデントとは WACATE2017 冬
  6. 6. インシデントとは 発生した事象の中で、調査が必要なもの 引用:ISTQB WACATE2017 冬
  7. 7. つまり? WACATE2017 冬
  8. 8. 発生した事象の中で、調査が必要なもの  → 期待していた結果と違う 調査が必要と思われるものは、 すべてインシデントとして扱われる 従ってインシデントはコードの欠陥に限らず、 ドキュメントなどにも発生する 「バグ」 ≠ インシデント WACATE2017 冬
  9. 9. インシデントレポートとは 調査が必要となる事象が発生したときに、 それを報告するためのドキュメント 誰に? 開発担当者 テストリーダー プロジェクトリーダー WACATE2017 冬
  10. 10. ちなみに インシデントレポート バグレポート/バグ票/バグチケット 不具合報告書 問題点処理票 障害管理 などなど… WACATE2017 冬
  11. 11. 体験してみよう WACATE2017 冬
  12. 12. 体験してみよう ユーザビリティテストセッションで扱った BlackWACATEに不具合(インシデント)が 発生しました! インシデントレポートを作成して 開発担当者に現象を伝えて下さい WACATE2017 冬
  13. 13. 個人ワーク:10分 以下のテストケースを実施してください 手順: 1. <URL> にアクセス 2. 「参加申込」から、確認画面まで申請を進める  期待結果:  確認画面のメールアドレス欄に、入力した メールアドレスが表示されていること WACATE2017 冬
  14. 14. 個人ワーク:10分 システムを実際に確認しながらインシデント レポートを作成してください 全く書いたことがない方: 「開発者に、起こった事象を文章で伝えてください」 書き慣れている方: あなたの考える最強のレポートを作成してください 注意:バグ出しが目的ではありません! WACATE2017 冬
  15. 15. グループワーク:8分 班で共有してみてください 全く同一のレポートはありますか? 違いがある場合は違いに注目してみてください どんな観点で書かれたものなのか 誰のレポートが、分かりやすいと思いましたか? その理由はなぜですか? WACATE2017 冬
  16. 16. インシデントレポート :Reboot WACATE2017 冬
  17. 17. このセッションのゴール ほとんどレポートを書いたことがない人  インシデントレポートとは何なのかを知り 明日から報告ができるように 普段それなりに報告している人  目的を再認識し、レポートを改善するきっかけ を見つけてください インシデントレポート職人の皆様  最高のレポートを提供するための見直しとして WACATE2017 冬
  18. 18. Re:インシデントレポートとは 調査が必要となる事象が発生したときに、 それを報告するためのドキュメント → 開発担当者 → テストリーダー → プロジェクトリーダー WACATE2017 冬
  19. 19. Re:インシデントレポートとは テストを実施する テストケースの環境、手順に沿った操作 → 思い通りに動かない = 期待と違う 期待結果と操作の結果を比較 ⇒ インシデント WACATE2017 冬
  20. 20. Re:インシデントレポートとは 期待と違う動作を修正してもらうために 開発担当者へ依頼をする そのための手段のひとつとして、 インシデントレポートがある WACATE2017 冬
  21. 21. 分かりやすいレポートとは 開発者目線になって… 現象の把握がしやすいこと 何を実施しようとして発見したのか 期待動作が記載されている 再現できること 環境や手順が明確であること etc… WACATE2017 冬
  22. 22. どんな項目があると良いか 考えることも非常に重要ですが、 先人の知恵(「規格」)を拝借 ISO/IEC/IEEE 29119-3 ご参考:「60分でわかった気になるISO29119」 https://www.slideshare.net/kjstylepp/60iso29119-wacate WACATE2017 冬
  23. 23. ISO29119-3 Scope References Glossary Incident details Timing information Originator Context Description of the incident Originator’s assessment of severity Originator’s assessment of priority Risk Status of the incident WACATE2017 冬
  24. 24. IEEE829(ご参考) 識別ID 概要 詳細 入力 期待結果 実際の結果 障害内容 日付 実行手順 環境 再現手順 テスト担当者 オブザーバ 影響範囲 WACATE2017 冬
  25. 25. 個人&グループワーク どんな項目があり、何が書かれていると より良いレポートになるでしょうか それぞれの立場に立って、考えてみて下さい 開発担当者 テストリーダー プロジェクトリーダー WACATE2017 冬
  26. 26. 個人&グループワーク 付箋1枚に1項目書き出す なぜその項目が必要なのか その項目があると誰が嬉しいのか WACATE2017 冬
  27. 27. 全体共有 各班で 1〜2つ、 どんな項目があがったか なぜその項目が必要なのか その項目があると誰がうれしいのか を発表してください WACATE2017 冬
  28. 28. 情報源としてのレポート インシデントレポートは情報の宝の山 適切な項目を書いてもらうことで あらゆるものが可視化される テストの進捗状況/品質状況 → 今後の予測 モジュール毎の不具合の偏り → テスト濃淡 根本原因/抽象化された事象 → テストの入力 etc,etc… WACATE2017 冬
  29. 29. やりすぎには注意 項目が多ければ多いほど、入力に工数が かかる その項目は本当に必要なのか? 誰のために 何のために ”面倒臭い” と思われたら負け WACATE2017 冬
  30. 30. まとめ(まだワークあるよ) WACATE2017 冬
  31. 31. 私が考えるインシデントレポート インシデントレポートは様々なひととの コミュニケーション手段のひとつ 開発者、テストリーダー、プロジェクトリーダー インシデントを正しく、分かりやすく 「伝える」ことが重要 WACATE2017 冬
  32. 32. 私の好きな名言 WACATE2011 夏 より WACATE2017 冬 インシデントレポートは書くこと自体が目的ではない。 読む人に何か訴えたい、 伝えたいことがあるから書くもので、さらに、 読んだ人を動かす、何かアクションを起こしてもらう ために書くものなんだ http://jibun.atmarkit.co.jp/lcom01/special/wacate2011/02.html
  33. 33. 私の考える「良い」レポート 読む人にとって、必要な情報が書かれている 分かりやすく書かれている ⇒ インシデントレポート単体で見たときには もちろん必要なこと WACATE2017 冬
  34. 34. 私の考える「良い」レポート 「そもそも何でインシデントレポートが 必要なんだっけ」 テスト活動の一環 品質を確保するため プロセス改善をするための情報提供として 他人に影響を与えられるレポート WACATE2017 冬
  35. 35. 最後のワーク WACATE2017 冬
  36. 36. またしても……! ユーザビリティテストセッションで扱った BlackWACATEに不具合(インシデント)が 発生しました! インシデントレポートを作成して 開発担当者に現象を伝えて下さい WACATE2017 冬
  37. 37. 個人ワーク: 以下のテストケースを実施してください 手順: 1. <URL> にアクセス 2. 「会社:」に「わかてB」と入力し検索  期待結果:  検索結果が何も表示されないこと (わかてB という会社は存在していない) WACATE2017 冬
  38. 38. 今度は、こんなことを意識して見てください 誰のためにレポートを書いているのか 何のためにレポートを書いているのか そのレポートはどんな価値を持つのか 最初のワーク結果と変わった所はありますか? WACATE2017 冬
  39. 39. WACATE2017 冬

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

×