前提
自分が仕事で携わっているのはWebアプリなので主に以下を利用しています。
・ブラウザ: Chrome
・監視ツール: DataDog
・エディタ: VSCode
不具合報告
起票内容
以下の記事を指針として起票する。
完璧に理解できないバグ票について
開発現場に根強く残る8個のバグレポートアンチパターン
間接原因の把握
事象だけ書いてdevに伝えると彼らも再現&ログ確認の時間を割かなければならないのでできるだけQAで間接原因、直接原因の特定を行う。何らかの操作ができないバグでコンソールにエラーが出ているとすれば、APIエラーの具体的な内容の把握に努める。
DevToolsのNetworkタブでAPIの一覧とHTTPステータスコードを眺めながら、エラーが出ているAPIを把握。API名から「おそらくこんな処理をするAPIなのかな...?」と推測する。
networkタブでのAPIエラーチェック方法
HTTPステータスコード一覧
APIを把握できたら監視ツールを使ってコンテキストを把握する。コンテキストとは、その名の通り処理が行われた文脈のこと。処理の前後で何があったのか把握し、ユーザーがどんな流れでどんな操作をした時にエラーが発生したのかを特定する。サービスを指定してAPI名と発生時間を指定するもよし。自分の手元で発生したならAPI名と自分のIPアドレスから検索をすると早い。
DataDogからのログ検索
直接原因の把握
API名が特定できたら、ソースコードから該当するAPIを検索してみる。
「Go to definition」でAPIの定義にたどり着く。ここで直接原因の把握を試みる。
VSコードチートシート
不具合報告のマインド
-
プロジェクトで提供したい本質的な価値についてバランスよく考える。
- インパクトや優先度の低いバグに固執してリリースを遅らせない。
- 早くリリースすることのビジネスインパクトやプロダクトを通して提供したい本質的な価値についてバランスよく考える
-
ステークホルダーへのリスペクトを欠かせない
- 実装バグであれ、仕様バグであれ、誰もバグを生みたい人はいない。
- 誰かを責めることは避けて労ったり、感謝を伝える。
- 建設的な改善への議論を進める。
-
要求を不具合を切り分ける
- 思い通りにならないからバグではない。
- UXを考えるのも大事だが、不具合とリクエストは明確に分けること。
-
ネクストアクションを考える
- 「これは仕様ですか？」と確認だけで止まって後は放置はNG
- 「この挙動が気になりました。優先度は○○です。次のアクションとしてxxはどうでしょう？」までいきたい。
-
期待値とのギャップを正確に捉える
- 期待結果ができるだけ正確な把握に努める。
- ギャップが正確でなければそれを埋める方向性がぶれやすい。
言語技術を磨く
蛇足だが、言語技術によってバグ報告の質が変わる
言語技術を磨き直してみるのもおすすめ。
大学生・社会人のための言語技術トレーニング