Articles on 株式会社エフカフェ - Qiita
Articles on 株式会社エフカフェ.
https://qiita.com/organizations/fcafe/items?page=4
Photo by Glenn Carstens-Peters on Unsplash
システム開発プロジェクトの社内テストが実施され、たくさんのバグ報告や
改善要望を頂いた。
その報告を受けて対応を行う時にスムーズに対応を行えるものと、何度か報告者とラリーをしないといけないものなど、報告内容によって対応スピードが大きく変わることに気付いた。
そこで今回の対応を通じて感じたこんなバグ報告の仕方をしてくれたら対応捗る!
という報告の仕方について纏めてみた。
詳細かつ具体的に問題を記述する
発生手順、環境情報、エラーメッセージやログの詳細を提供し、エンジニアが問題を迅速に理解し対処できるようにします。
感情的にならず、客観的に報告する
バグの存在を非難するのではなく、問題の解決を目指す姿勢で報告を行いましょう。
問題ごとに報告を分ける
一つひとつの問題に焦点を当てて報告することで、対応の精度を高めます。
積極的なコミュニケーションを心がける
報告後も情報を更新し、開発チームとの継続的なやり取りを行いましょう。
これらのポイントに注意してバグを報告することで、開発チームは迅速かつ効果的に問題に対処できるようになります。
結果的に、プロジェクトはスムーズに進行し、より良い製品が完成します。
プロジェクトチームの一員として、質の高いバグ報告はプロジェクト成功のために不可欠な貢献となります。
バグの報告を受けるとエンジニアはまず事象が再現するかどうかを確認する。
事象が再現しないのであれば、再現するために見落としている条件が無いか、環境依存していないかといったことを調査する。
事象が再現したら、なぜそれが起きているかの仮説を立て、その仮説があっているかを確認するためにコードリーディングをしてみたり、ログやデータベースなど出力内容の確認を行う。
仮説が合っていることが確認できたら、修正を行う。
修正は実際にその動きをさせている部分のコードだけでなく、単体テストのコードも見直して必要に応じて修正を行う。
修正ができたら、事象が発生しなくなっているか、デグレが起きていないか、コードの可読性や汎用性に問題がないかといったことを確認し、プルリクエストを出す。
そのプルリクエストを他のエンジニアにレビューしてもらい、問題がないようあれば環境に反映させて、報告者に修正完了報告を出して対応が完了する。
対応の中でも再現や原因特定に時間がかかってしまうと、対応に時間がかかってしまう事が多い。
再現や原因特定のスピードをアップするためには下記のような情報があると良い。
❌ ログインボタンをクリックしたところ、エラーメッセージが表示されてログインができませんでした
⭕️ ログインボタンをクリックしたところ、「500 Internal Server Error」というエラーメッセージが表示されてログインができませんでした
直接多対応スピードを上げる、といったものではないものの気をつけてほしいことを
まとめてみた。
バグがあるとイライラしたり、フラストレーションが溜まることは理解できますが、それを報告内容に盛り込まれると受け取った側はほんとにツラいです。
テスターは客観的にならず、自分もこのシステム開発メンバーの一員なんだという主観的な気持ちでテストに取り組み、システムをよりよいものにするためにテストを実施し、バグ報告をしているんだという気持ちになれば自然と感情的な言葉を使わなくなるんじゃ無いかと思います。
複数の問題が発見された場合でも、それぞれを個別の報告として分けてほしいです。
一つの報告に複数の問題をまとめてしまうと、それぞれの対応が複雑になり、解決までの時間が長引いてしまいます。
報告して終わり、ではなく続報があれば積極的に情報を提供したり、対応のレスが無いようであれば状況確認をするといったことを心がけることで誤解や行き違いなどをなくすことができます。
また、対応者からも報告者と積極的にコミュニケーションを取るようにして、報告を上げてくれたことへの感謝を忘れないようにするとチームの雰囲気も良くなると思います。
* 本記事はQiitaでもご確認いただけます