“Issueの書き方と伝え方”勉強会 ツイートまとめ

ふじふじ @fuji_fuji_test

066: 障害管理システムをテスト実施者の評価に使うな #issue

ふじふじ @fuji_fuji_test

067: バグの報告は新鮮さが大切 #issue

ふじふじ @fuji_fuji_test

◎073: 優先度と重要度を区別せよ 重要度が低くても優先度の高い欠陥もある #issue

broccoli @nihonbuson

ほー。 この話がなかったら、「緊急度＝優先度」として使ってしまうかも…。 #issue

奇声を発する何か。 @sby_unk

#issue 緊急度・影響度・重要度から、優先度を導く。 緊急度(リスク、何が起こるか)＞影響度(客観的にお客様や他の機能に影響するか)＞重要度（主観でどう思うか）

yuki shiromoto @yuki_shiro_823

『優先度と重要度を区別せよ』 #issue

ふじふじ @fuji_fuji_test

緊急度、影響度、重要度を５段階で書く 緊急度：リスクが見えているかどうか 影響度：お客さんへの影響、他の機能への影響 重要度：主観的に決める #issue

broccoli @nihonbuson

再現しないバグは10%ぐらいしか直らない（秋山さん曰く） #issue

ふじふじ @fuji_fuji_test

076: 再現しないエラーも全て報告せよ。時限爆弾になる恐れがある 再現しないインシデントも登録しておくこと。 #issue

奇声を発する何か。 @sby_unk

#issue 「再現しないインシデントも報告せよ」基準を決めて報告する。「再現できなかった」とかも書く。

broccoli @nihonbuson

再現しない場合は「再現しない」と明記しよう 開発者は必ず発生すると勘違いしてしまう #issue

broccoli @nihonbuson

再現しなくても、それらが何個か起票されることで、起票された発生条件の共通部分から再現条件が分かるかもしれない #issue

ふじふじ @fuji_fuji_test

082: 障害レポートは１件１葉 #issue

奇声を発する何か。 @sby_unk

#issue 感想：同時に修正できそうなインシデントを一つにしちゃうと、同じ原因だとしても直し方で変わるから本当に一つにしちゃだめだと思う。どうせ後で責められるのは起票しなかったテストの人なのだ。

ふじふじ @fuji_fuji_test

083: 障害レポートはタイトルで決まる マネージャや経営者が最終的に未修正で良いと【タイトルから判断】することがある #issue

ふじふじ @fuji_fuji_test

重要なのは第1に「タイトル」 その次が「再現手順」 #issue

奇声を発する何か。 @sby_unk

#issue 秋山さんの起票時に大事だと思うとこ １：タイトル ２：再現手順 他も大事だけど、まずはここを！！ 偉い人はタイトルしか読まない 解決策を書く必要はない。それは開発側の役割。

ふじふじ @fuji_fuji_test

085: 問題点をはっきり報告し、解決策は書かない 障害レポートとは、テストで見つかったインシデントを報告することであって、その原因を究明したり具体的な解決策を指示することではない。 #issue

奇声を発する何か。 @sby_unk

#issue 感想：信頼大事！マジ大事！

ふじふじ @fuji_fuji_test

097: 全てのバグ修正を矯正するな。戦いの場は選ぶべきだ 小さな欠陥の修正によって新たに深刻な欠陥を生み出してしまうこともよくある #issue

奇声を発する何か。 @sby_unk

#issue 感想：「感嘆に修正できるからしました」って直されるのが、テストするとなると大変な工数がかかる物もあるので、安易に修正されるのは本当にうれしくないです。

broccoli @nihonbuson

競合製品を知るって大切 #issue

奇声を発する何か。 @sby_unk

#issue どうしても直してもらえない時、きちんと準備して伝えると直してもらえる 「競合他社はこうですよ」って言って、直してもらえたことがある

broccoli @nihonbuson

質問タイムという名の討論会 #issue

broccoli @nihonbuson

重要度の判断 納得するかどうか 権限を移譲したいかどうか あとは、テストオペレーターに対しての教育をしてから取り組んだり #issue