Upgrade to Pro — share decks privately, control downloads, hide ads and more …

defect_report

k.i.
March 27, 2022

 defect_report

欠陥レポートについて持っている知識のまとめ

k.i.

March 27, 2022
Tweet

More Decks by k.i.

Other Decks in Technology

Transcript

  1. 欠陥レポートとは • 欠陥レポートに書かれる内容の例 ◦ 報告者 ◦ 事象 ▪ 画面キャプチャやスタックトレースなどが添付されることもある ◦

    再現手順 ◦ 再現環境 ▪ モバイルアプリの場合は、アプリのバージョンも ◦ もともと期待していた結果 ◦ 再現率 ◦ 関連するテストケースの情報 ◦ 欠陥レポートのステータス ◦ 調査結果 ◦ 対応内容 5
  2. 欠陥レポートは作成後いつ使われるか? • 欠陥の修正中 ◦ 欠陥の再現手順や条件を確認するため • 欠陥を修正後 ◦ 再度、テストができるようになったことを知らせるため ◦

    修正後のテストが終わり、欠陥が解消されたことを知らせるため • プロセスの完了判断 ◦ 欠陥の出方を分析するため。増減、多く出ている欠陥の傾向など ◦ 残存している欠陥を確認し、プロセスの終了や次のプロセスの開始ができるか確認するため • ふりかえり ◦ 欠陥の予防や早期検出ができないか検討するため 6
  3. • 複雑な仕様や事象が関係していることがある ◦ テストを行うときには必要なデータや条件が、すべて欠陥に関与しているとは限らない • 欠陥の話は、プロジェクトのスケジュールを遅らせたり、ステークホルダー の立場を危うくさせるものとしてネガティブに捉えられることがある ◦ 『バグの報告が、設計者や実装者に対する⾮難と捉えられる』 ◦

    『プロジェクトの進⾏の邪魔と捉えられる』 ◦ 『バグレポートが争いの場になったり、役に⽴たないと⾔われ続けると、他に誰も気づいて いない⼩さな違和感や、重⼤だが確証が得られない問題をフィードバックしにくくなる』 『』内の引用元:WACATE2020冬 良いテストは良いフィードバック 75ページ 難しさ 9
  4. ではどうするか? 次のページから、以下について詳細を述べる • 事実を伝える ◦ 欠陥についての事実に焦点をあてる ◦ ⽬的を⾒失わない ◦ 問題点は明確に、でも丁寧に伝える

    • 必要な情報を分かりやすく伝える ◦ 簡潔で認識齟齬が起こりにくい文章にする ◦ 一件一葉 ◦ 過不足なく書く • 役割が異なる複数の人が欠陥レポートに関与することを意識する 10
  5. 事実を伝える • 欠陥についての事実に焦点をあてる ◦ できるだけ推測は書かない、書く場合は事実と分ける ▪ ただし、事象再現の確認をするときは事実に基づいた仮定を使うと効果的なことがある • ⽬的を⾒失わない ◦

    ステークホルダーに対して思うところを書くドキュメントではない ▪ 欠陥レポートが不要な対立やモチベーション低下を招いては、元も子もない ▪ ステークホルダーに価値を届けるために、早く適切に欠陥に対応してもらうことが大事 ◦ 『「バグ対我々」という構図をイメージする』 ▪ 『』内の引⽤元:プログラマとテストエンジニアにバトル勃発!正しいバグ票の書き方とは?  • 問題点は明確に、でも丁寧に伝える ◦ 読むのも人間 ◦ 『はっきりと問題を指摘しながらも、相手への配慮を込めた丁寧な表現を用いる。』 ▪ 『』内の引⽤元:JaSSTʻ20 Kyushu サーバントリーダーシップを⾝に付けましょう︕ 34ページ 11
  6. • 簡潔で認識齟齬が起こりにくい文章にする ◦ 人によって捉え方が違う言葉に注意 ▪ 例 “やばい” • 『危険や不都合な状況が予測されるさま。あぶない。』 • 『[補説]若者の間では、「最高である」「すごくいい」の意にも使われ

    る。』 ◦ 上記2つの『』内の引用元:コトバンク デジタル大辞泉「やばい」の解説 ▪ 例 “やばい”の認識齟齬 • 『アイコンがほんの少しズレている(仕様通りでない)』 • 『担当した機能が仕様書通りに動作していない?』 • 『リリースを再検討するレベルの重大バグ?』 ◦ 上記3つの『』内の引用元:ソフトウェアテストシンポジウム(JaSST) 2017 東海 バグ票カウン セリング ~ バグ票の悩み、話してみよう!解決しよう! ~ 51ページ 必要な情報を分かりやすく伝える 13
  7. 必要な情報を分かりやすく伝える • 一件一葉 ◦ 1件の欠陥レポートには、1つの欠陥についてのみ書く ◦ 1つの欠陥レポートに複数件の欠陥A、B、Cが書かれていると… ▪ どこからどこまでが修正範囲や修正後の確認テスト範囲なのか、分かりにくい ▪

    A、Bが完了しても、Cは将来対応とになると、レポートのステータスで表現できない • レポートをクローズできない ▪ 欠陥の数や重要度・優先度をリリース判断等に用いる際、 正確な件数が把握しにくく、集計が不正確になる恐れがある ◦ 但し、欠陥の原因が特定されるまでは、どこまで1件とするか難しい場合がある ▪ 周囲に相談する ▪ 後から複数件に分けたり1件に統合したりすることもある 14
  8. 必要な情報を分かりやすく伝える • 過不足なく書く ◦ 特に再現手順 ▪ 例 新規登録画面を開き、氏名欄を入力する。氏名欄の下にある電話番号欄を未入力に して保存ボタンを押しても、必須入力のエラーメッセージが出ない • 電話番号欄が氏名欄の下にある記述は要らないのでは?

    ▪ 例 ポップアップ右上の×ボタンを押す • Escキーでは? ポップアップの外をクリックした場合は? • 調査に時間がかかる場合は、先に欠陥レポートを起票した方がよいこともある ◦ 手順以外の条件や特徴も忘れずに。 ▪ モバイルアプリでは特定のOSバージョンのみ起こる問題もある ▪ 再現性はあるか? ◦ フォーマットに従うことである程度は過不足なく書けることもある 15
  9. 必要な情報を分かりやすく伝える 影響の度合いや範囲、優先度が不明確 • [データ全削除] ボタンをクリックするとデータが全削除される データ不整合の恐れあり、急いで対応 • [データ全削除] ボタンをクリックしても、データ削除は起こらない ◦

    「権限がありません」とメッセージが表⽰される ◦ ボタンに⾒えるが、クリックしても何も起こらない 紛らわしいが、他に緊急性の高い問題があるならば優先度は下がる 箇条書き部分の引用元:WACATE2020冬 良いテストは良いフィードバック 68ページ 19
  10. 役割が異なる複数の人が欠陥レポートに関与することを意識する • 人により目的が異なる ◦ テスト担当者 …欠陥を修正してもらいたい ◦ プロダクトオーナーやマネージャ(判断する人) …欠陥の検出傾向や重要度・優先度を知 りたい ◦ 修正担当者 …欠陥を修正したい

    ◦ 再テスト担当者 …欠陥修正後の確認テストを行いたい ◦ など • 人により前提知識が異なる ◦ テスト担当者が実施中のテスト内容の詳細を知らないかもしれない 自分と異なる目的や前提知識を持つ人が欠陥レポートを読む可能性を意識する 必要な情報を届けるためにはどこまで書けばよいか、検討する 欠陥レポートに自分が使わない項目があっても、他の人が使うことがあるので注意 21
  11. • 起票前に、再現する条件や環境をできる限り特定する ◦ どのような条件や環境ならば再現するか、しないか、仮説を立てる ▪ 例 アカウントの種類に関係しているのではないか? ▪ 例 ブラウザの種類に関係しているのではないか? ◦ 仮説に沿って、様々な条件や環境で再現手順を実行してみる

    ▪ 例 異なるデータでも再現するか? • 別の入力値でも再現するか? • 別のデータ状態の場合に再現するか? • 別のアカウントでも再現するか? ▪ 例 OSやブラウザを変えても再現するか? ▪ 例 キャッシュを消しても再現するか? ▪ 例 PCアプリやモバイルアプリなら別のバージョンでも再現するか? 欠陥レポートを書くときに注意したいこと 24
  12. 欠陥レポートをうまくつくるための工夫 • チーム内でレビューをする • 声に出して読んでみる • 自分が読む立場だったらどう思うか考える • 他の人のレポートで分かりやすいと思った書き方は真似をする ◦

    文章の書き方 ◦ どのような情報を書いているか、書く順序はどうか • 欠陥レポートのフォーマットを工夫する ◦ チームの合意を得てから 26
  13. 引用文献、参考文献(1/2) いずれも、最終閲覧は本書執筆時点である • ISTQB Glossary 欠陥レポート ◦ https://glossary.istqb.org/jp/search/%E6%AC%A0%E9%99%A5%E3%83%AC%E3%83% 9D%E3%83%BC%E3%83%88 • 連載

    : 究極のバグレポート ◦ プログラマとテストエンジニアにバトル勃発!正しいバグ票の書き方とは? ▪ https://thinkit.co.jp/story/2012/07/11/3614 ▪ https://thinkit.co.jp/story/2012/07/11/3614?page=0%2C2 ◦ 「困った」バグレポートの数々から得た「正しい」レポートのための教訓とは ▪ https://thinkit.co.jp/story/2012/07/18/3619?page=0%2C1 • オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 > バグピンポン ◦ https://blogs.itmedia.co.jp/morisaki/2010/08/post-2cf3.html • WACATE2020冬 良いテストは良いフィードバック ◦ https://speakerdeck.com/omn/wacate2020w 28
  14. 引用文献、参考文献(2/2) いずれも、最終閲覧は本書執筆時点である • Making Software ―エビデンスが変えるソフトウェア開発、Andy Oram (編集), Greg Wilson

    (編 集), 久野 禎子 (翻訳), 久野 靖 (翻訳)、オライリージャパン、2011年 • JaSSTʻ20 Kyushu サーバントリーダーシップを⾝に付けましょう︕ ◦ http://www.jasst.jp/symposium/jasst20kyushu/pdf/S3.pdf • コトバンク デジタル大辞泉「やばい」の解説 ◦ https://kotobank.jp/word/%E3%82%84%E3%81%B0%E3%81%84-400880 • ソフトウェアテストシンポジウム(JaSST) 2017 東海 バグ票カウンセリング ~ バグ票の悩み、 話してみよう!解決しよう! ~ ◦ http://www.jasst.jp/symposium/jasst17tokai/pdf/S5-3.pdf • WACATE 2014冬 バグ票をもっとうまく使うために ◦ https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxzd3dvc nN0cHJhY3RpY2VzaXRlfGd4OjE5N2MwZmI2MDU5YTUwODY 29