2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

システム開発プロジェクトの社内テストが実施され、たくさんのバグ報告や改善要望を頂いた。

その報告を受けて対応を行う時にスムーズに対応を行えるものと、何度か報告者とラリーをしないといけないものなど、報告内容によって対応スピードが大きく変わることに気付いた。

そこで今回の対応を通じて感じたこんなバグ報告の仕方をしてくれたら対応捗る!という報告の仕方について纏めてみた。

先に結論・・・こんな内容で報告してほしい!

効果的なバグ報告は、開発プロセスをスムーズに進めるための重要な要素です。
良いバグ報告を行うためには、以下の点を心がけてください。

スクリーンショット 2024-03-30 13.53.03.png

詳細かつ具体的に問題を記述する:
発生手順、環境情報、エラーメッセージやログの詳細を提供し、エンジニアが問題を迅速に理解し対処できるようにします。

感情的にならず、客観的に報告する:
バグの存在を非難するのではなく、問題の解決を目指す姿勢で報告を行いましょう。

問題ごとに報告を分ける:
一つひとつの問題に焦点を当てて報告することで、対応の精度を高めます。

積極的なコミュニケーションを心がける:
報告後も情報を更新し、開発チームとの継続的なやり取りを行いましょう。

これらのポイントに注意してバグを報告することで、開発チームは迅速かつ効果的に問題に対処できるようになります。
結果的に、プロジェクトはスムーズに進行し、より良い製品が完成します。

プロジェクトチームの一員として、質の高いバグ報告はプロジェクト成功のために不可欠な貢献となります。

そもそもバグ報告を受けてエンジニアは何をしているか

バグの報告を受けるとエンジニアはまず事象が再現するかどうかを確認する。
事象が再現しないのであれば、再現するために見落としている条件が無いか、環境依存していないかといったことを調査する。

事象が再現したら、なぜそれが起きているかの仮説を立て、その仮説があっているかを確認するためにコードリーディングをしてみたり、ログやデータベースなど出力内容の確認を行う。

仮説が合っていることが確認できたら、修正を行う。
修正は実際にその動きをさせている部分のコードだけでなく、単体テストのコードも見直して必要に応じて修正を行う。

修正ができたら、事象が発生しなくなっているか、デグレが起きていないか、コードの可読性や汎用性に問題がないかといったことを確認し、プルリクエストを出す。

そのプルリクエストを他のエンジニアにレビューしてもらい、問題がないようあれば環境に反映させて、報告者に修正完了報告を出して対応が完了する。

スクリーンショット 2024-03-30 13.19.01.png

再現や仮説を行う時にどんな情報が必要か

対応の中でも再現や原因特定に時間がかかってしまうと、対応に時間がかかってしまう事が多い。
再現や原因特定のスピードをアップするためには下記のような情報があると良い。

発生手順

単にこんなことが起きたよ、というだけだと再現確認に時間がかかってしまうので、可能な限り詳細な発生手順を報告してもらえると素早い対応をすることができる

環境情報

特定の環境でのみ起こるバグもあるので、OSやブラウザの情報、デバイスの種類といった環境情報を貰えると特定条件下での事象再現に役立つ

メッセージやログ

エラーメッセージやログが出力されていた場合には、その内容についても報告をしてもらえると調査がしやすくなる

× → ログインボタンをクリックしたところ、エラーメッセージが表示されてログインができませんでした
○ → ログインボタンをクリックしたところ、「500 Internal Server Error」というエラーメッセージが表示されてログインができませんでした

スクショや動画

スクショや画面を収録した動画があると齟齬なく事象を確認できるため、調査の助けになる

その他気をつけてほしいこと

その他、直接多対応スピードを上げる、といったものではないものの気をつけてほしいことをまとめてみた。

感情的にならない

バグがあるとイライラしたり、フラストレーションが溜まることは理解できますが、それを報告内容に盛り込まれると受け取った側はほんとにツラいです。

テスターは客観的にならず、自分もこのシステム開発メンバーの一員なんだという主観的な気持ちでテストに取り組み、システムをよりよいものにするためにテストを実施し、バグ報告をしているんだという気持ちになれば自然と感情的な言葉を使わなくなるんじゃ無いかと思います。

報告の分割

複数の問題が発見された場合でも、それぞれを個別の報告として分けてほしいです。
一つの報告に複数の問題をまとめてしまうと、それぞれの対応が複雑になり、解決までの時間が長引いてしまいます。

コミュニケーションを心がける

報告して終わり、ではなく続報があれば積極的に情報を提供したり、対応のレスが無いようであれば状況確認をするといったことを心がけることで誤解や行き違いなどをなくすことができます。

また、対応者からも報告者と積極的にコミュニケーションを取るようにして、報告を上げてくれたことへの感謝を忘れないようにするとチームの雰囲気も良くなると思います。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?