ssmjp-20211125-nlog2n2

バグ報告書フォーマットLT @nlog2n2 Sekiguchi Toshihiro

コメント稼ぎ（Twitterで猫可愛いって言ってね！） • 質問・コメントがあればTwitterへお願いします！

ssmjp は運用とセキュリティの勉強会

ssmjp は運用とセキュリティの勉強会

質問です

バグトラッキングシステムは、 何を使っていますか？ 9685 1298 https://www.menti.com/en7b4o2sos

• https://www.menti.com/en7b4o2sos

アンケート結果

• 一太郎で不具合報告は衝撃的

バグ報告書

バグ報告書とは • テストもしくは本番環境でのソフトウェアの不具合を知らせる報告書のこと。 主に以下のような内容が記載される。 • どのような不具合か分かるタイトル • 不具合の内容 • 期待される挙動と実際に起きた挙動 • テストケース • 再現手順 • 不具合発生時の事象 • ログ • スタックトレース • スクリーンショット • 不具合が発生した環境情報

バグ報告書とは • テストもしくは本番環境でのソフトウェアの不具合を知らせる報告書のこと。 主に以下のような内容が記載される。 • どのような不具合か分かるタイトル • 不具合の内容 • 期待される挙動と実際に起きた挙動 • テストケース • 再現手順 • 不具合発生時の事象 • ログ • スタックトレース • スクリーンショット • 不具合が発生した環境情報 テスト技術に書かれた書籍は多いが、 バグ報告書の書き方に言及した資料は少ない。

本題に入る前に

バグトラッキングシステム比較表 項目 プロジェクト 作成者/報告者 トラッカー 題名/件名/要約 コンポーネント 説明/詳細 ステータス 優先度 マイルストーン カテゴリ/課題タイプ 担当者 （対象|発生|修正）バージョン ラベル 親チケット 開始日 期限日 予定時間 残余見積 実績時間 環境情報 スプリント 添付ファイル ストーリーポイント リンクされた課題 課題 Redmine ○ ○ ○ ○ Backlog ○ ○ JIRA ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○

バグフォーマットの前に 開発者が報告して欲しいことを知ろう

何の報告が役に立つか（開発者、報告者） • オライリーから出版されているMaking Softwareでは、Apache,Eclipse,Mozilla の 開発者、報告者の両者にバグレポートに対するアンケートをとっていました。 雑観は以下の通りです。 • 開発者の必要としているものと報告者の報告しているものにずれがある • 開発者と報告者でバグの修正に必要な情報については共通の認識がある • 報告者の文章能力、報告者の実績などがバグの修正時間に影響している

何の報告が役に立つか（開発者、報告者） • オライリーから出版されているMaking Softwareでは、Apache,Eclipse,Mozilla の 開発者、報告者の両者にバグレポートに対するアンケートをとっていました。 雑観は以下の通りです。 • 開発者の必要としているものと報告者の報告しているものにずれがある • 開発者と報告者でバグの修正に必要な情報については共通の認識がある 報告すべき内容はわかっているが、報告することに難易度が高いものが存在する。 • 報告者の文章能力、報告者の実績などがバグの修正時間に影響している 開発者と報告者ではソフトウェアの見えている側面が違う。

何の報告が役に立つか（開発者、報告者） • オライリーから出版されているMaking Softwareでは、Apache,Eclipse,Mozilla の 開発者、報告者の両者にバグレポートに対するアンケートをとっていました。 雑観は以下の通りです。 • 開発者の必要としているものと報告者の報告しているものにずれがある わかりやすい文章、もしくは信用度の高い報告者のバグ報告は修正が早い • 開発者と報告者でバグの修正に必要な情報については共通の認識がある • 報告者の文章能力、報告者の実績などがバグの修正時間に影響している

何の報告が役に立つか（開発者、報告者） • 開発者がバグの修正に役に立ったとしている項目は、再現手順、スタックトレース、テストケースが上位３位 でした。その中で、スタックトレースとテストケースはバグ報告に半分程度しか報告されずに重要視されてい ませんでした。 • 開発者からするとスクリーンショットも有用な情報と捉えていますが、報告者が6割程度の報告がなく低い項 目となっていました。 • 報告では再現環境に関する項目を重要視していましたが、開発者からするとあまり役に立っていないという 認識でした。 • 期待される挙動と実際に起きた挙動については、開発者がバグの修正利用度合いも高く、報告としてもほぼ 100%でした。 • 開発者から「不完全な情報の提供」について問題視する意見が多かったようです。 加えて報告者の言語能力が高い報告（読み手が理解しやすい文書）だとバグ修正が早くなるという傾向もあ るようです。

何の報告が役に立つか（開発者、報告者） • 開発者がバグの修正に役に立ったとしている項目は、再現手順、スタックトレース、テストケースが上位３位 でした。その中で、スタックトレースとテストケースはバグ報告に半分程度しか報告されずに重要視されてい ませんでした。 • 開発者からするとスクリーンショットも有用な情報と捉えていますが、報告者が6割程度の報告がなく低い項 目となっていました。 • 報告では再現環境に関する項目を重要視していましたが、開発者からするとあまり役に立っていないという 認識でした。 • 期待される挙動と実際に起きた挙動については、開発者がバグの修正利用度合いも高く、報告としてもほぼ 100%でした。 • 開発者から「不完全な情報の提供」について問題視する意見が多かったようです。 加えて報告者の言語能力が高い報告（読み手が理解しやすい文書）だとバグ修正が早くなるという傾向もあ るようです。

何の報告が役に立つか（開発者、報告者） 項目 プロジェクト 作成者/報告者 トラッカー 題名/件名/要約 コンポーネント 説明/詳細 ステータス 優先度 マイルストーン カテゴリ/課題タイプ 担当者 （対象|発生|修正）バージョン ラベル 親チケット 開始日 期限日 予定時間 残余見積 実績時間 環境情報 スプリント 添付ファイル ストーリーポイント リンクされた課題 課題 Redmine ○ ○ ○ ○ Backlog ○ ○ JIRA ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 要はここをきちっと書くことで、 不具合修正の時間が短くなる。 他の項目は修正時間に大きく影響しない。 他の項目については参考程度になる恐れがある。

バグ報告で読み手が理解しやすい文書とは？ • 個人の感想になりますが以下の通りです。 • １文は30文字程度に抑える。 • 全体の文書が冗長にならないように記載する。 • 文章には推測は入れない。 • 期待される挙動と実際の挙動は対になるように記載する。 • 再現手順・テストケースは事実のみを書く。 • 再現環境情報を間違えない。 • 重複した不具合の報告は避ける（副次的効果があるため例外あり）

バグ報告フォーマット # 概要 ## 不具合の概要 （不具合概要を 200 文字〜300文字程度で書く） ## 期待する挙動と実際に起きた挙動 （各挙動を60文字程度で書く） # 環境情報 ## 発生バージョン ## クライアントアプリケーション情報 ### OS ### Webブラウザ情報 ## テストケース ## 再現手順 ## 再現回数（○回/XX回） # その他 ## 参考情報（RFC・仕様書等へのリンク） ## 備考 # 不具合発生時のログ等の情報 ## ログ ## スクリーンショット ## スタックトレース ## 添付ファイル #プロジェクトに必要な情報 ## 優先度 ## ステータス ## 担当者 ## 報告者 ## 期限日

バグ報告フォーマット # 概要 ## 不具合の概要 （不具合概要を 200 文字〜300文字程度で書く） ## 期待する挙動と実際に起きた挙動 （各挙動を60文字程度で書く） # 環境情報 ## 発生バージョン ## クライアントアプリケーション情報 ### OS ### Webブラウザ情報 具体例を書こうとしたけど どれも守秘義務に抵触する恐れあり (́；ω；｀) ## テストケース ## 再現手順 ## 再現回数（○回/XX回） # その他 ## 参考情報（RFC・仕様書等へのリンク） ## 備考 # 不具合発生時のログ等の情報 ## ログ ## スクリーンショット ## スタックトレース ## 添付ファイル #プロジェクトに必要な情報 ## 優先度 ## ステータス ## 担当者 ## 報告者 ## 期限日

オチなし 🍊🍊🍊🍊🍊

TIPS：バグ報告のあれこれ • 使わない方がいい文字列 「特定の条件で」「ダメ」などの言葉は、バグ報告書内ではトートロジーになってしまう項目のため利用しない。 頭にそれらの言葉がよぎった時は、どう言い換えるかを考えて報告をする。 • 諦めた方がいい不具合修正 明らかに不具合だったとしても、ビジネス的に旨味がなければ修正しなくてもよい。テストケースとして利用頻度 が少ないもしくは０に近いものを不具合修正してもビジネス的には赤字なので修正しない方がメリット大きい。 • 単体テストに便利な文字列はいっぱい持っておくといい 氏名を入力する項目があった場合、「森鷗外」のような特殊な文字列を使う人物はメモしてテストセットとしてい くつも持っておくと、テストを依頼された時にさらっと入れて、モンキーテストができる。 • モンキーテストを依頼された時の初動 ユニットテストの前にモンキーテストを依頼された場合、システムテストで複雑そうなものを 2,3 パターンを実施 すると開発者の不具合の癖が見える。あとは仕様の数倍の入力をいれたりすると、大体のシステムは固まるので、 初動でパフォーマンステストを仕掛けることもある。

ネタ切れ nlog2n2 先生の次回作をご期待ください🍊

コメント稼ぎ（Twitterで猫可愛いって言ってね！）