〇〇くん！ここのバグ修正しといて！と言われた時にやること
初めに
普段自分の業務で、何かのバグ修正のタスクがアサインされた時に、どんなことをやっているのかを整理しておきたいと思ったので、こちらに記載します。また、記事を読んでくれた方のタスクの進め方などの参考になればと思います。
前提
- WEBアプリのアジャイル開発
- ある日上司から口頭で、雑にバグの修正依頼をされたという想定。
バグが修正されるまでのフロー
- バグ修正の依頼がくる
- バグの再現
- 原因調査
- 修正案出し
- 影響調査
- テストケースの作成
- ドキュメントの作成
- 実装
- 結合テスト
- マージ
バグ修正の依頼がくる
依頼を受けた時に確認,考慮すること
「じゃあ、ここの修正よろしく！」と突然言われた時、まずは何をするべきでしょうか？
自分がこの想定でタスクを引き受ける場合、まずは以下のことを行います。
- いつ、どんな条件で、どのような手順で起きたのかを確認
- スケジュールの確認
- あるべき姿の確認
- チケットの作成
まずはバグが発生した条件を細かく聞きます。いつ、どのような条件で、どの環境で、・・・など。
それからスケジュールの確認を行います。何日の何時までに完了すればいいのか、指定がなければ事前に聞いておきます。
また、修正後どうなっていれば良いのか、タスクが完了したことの定義、あるべき姿をPMなどと話しあって決定します。
次に、バグの内容、期日、あるべき姿を記載したチケットを作成します。チケット管理はGitHubを使用しています。このあたりはチームで使用しているもので統一されてあればなんでも良いと思います。
バグを再現させる
チケットを切ったら、実際に自分の手元で再現させてみます。本番環境では起こるけど、ローカルでは発生しないというようなことがよくあったりするので、必ず自分の手で再現させて確認します。再現が難しければ発見者に再度詳しく聞いてみたり、実際の画面で見せてもらうこともあります。
またバグによっては、似たような別の箇所で同じバグが起きていた、ということも稀によくあるので、その辺りもついでに確認しておきます。
原因の調査
再現ができたら原因を探します。起きてるバグについて、思い当たる節のある部分のコード読み書きしたり、デバッグなどを行って見つけます。もし何時間もかかってわからなければ、上司の人や機能について詳しい人に相談をさせてもらったりします。
Gitを使用しているのであればコミット履歴から実装者に聞いてみるのも良いと思います。（実装者が自分だった場合は・・・）
修正案を出す
原因の箇所を見つけることができたら、次はどのように修正をするのか考えます。ここについて考えるべきことはたくさんあると思いますが、大まかに以下のようなことでしょうか。
- 修正を行うことによって起きる影響
- 修正によってUIの変更が必要になるか
- 修正案が複数ある場合
- どの案がベターなのかは期日や影響範囲によって変わってくる
- 一時的な対応を行うのか？
- 根本的な部分を直すのか
修正案が複数でてきて、絞ることが難しそうであったり、少しでも迷ったりしたら、上司や別のエンジニアに雑談でもしがてら相談しにいったりします。
影響調査
修正案を出すことができたら、思わぬ箇所で修正による影響で、新たなバグが生み出されることがないように影響調査を行います。例えばUIの修正であれば、修正するコンポーネントが別のページなどで使用されていないか、使用されている場合は現状の修正案で問題がないか、など。
テストケースの作成
影響範囲が絞れて問題なさそうであれば、テストケースを作成します。テストケースはのちに、自身で結合テストを行うにあたって使用するためのものになります。どのように書いていくのか、正直この辺り自分自身知見があまりないのですが、私のチームではスプレッドシートで管理をしています。
この工程はQAチームなどがあれば、必要ない場合もあるかと思いますが、基本的には修正した箇所は自分で確認をするかと思うので、箇条書きにでもパターンを出しておくと良いかと思います。
ドキュメントの作成
ここまで考慮したことに加えて、コードレベルで設計を行い、それらをドキュメントに落とし込みます。
ドキュメント化するメリットとしては、いつでも引き継ぎが可能ということと、ここまでの設計をレビューなどをしてもら際に、スムーズに行うことができるということが挙げられます。
レビューなどを挟まず、そのまま実装に入る場合は必要がないかもしれません。ドキュメントのフォーマットなどは事前に決めておくとレビュワーが助かるかもしれないです。
実装
レビューが終わったら実装に入ります。設計通りに書いていくのみ。
PRを作成して、レビューと修正を繰り返し行います。
結合テスト
最後に事前に作成したテストケースを用いて、結合テストを行います。こちらはローカルではなく、develop環境に修正ブランチをデプロイして確認を行います。NGのケースがある場合は
マージ
結合テストを全てクリアしたら、メインのブランチにマージします。
まとめ
かなりざっくりしたものなので、全てのケースに当てはまるわけではありませんが、大体このような流れで行っています。
工程が多く複雑かもしれませんが、ここまでやると手戻りを防げたり、新たなバグを生むことをかなり減らすことができると思います。複雑度が高く規模の大きいアプリだと、より高い効果が期待できると思います。
Discussion