はじめまして、4月に入社した21卒エンジニアです!
4月に入社し、あっという間に3カ月が経過しました。
短い期間ですが、デモフロントやCDM、MVV合宿など研修で様々なことを学びました。
今回はその中で、研修が終わり実際に現在業務でも携わっている「バグ改修」について、4点書かせていただきます。
バグ改修について
バグ改修は名前からも推測しやすいとは思いますが、バグを直していく業務になります。
w2の製品は業界トップクラスで機能が多く、もちろんバグも発生します。
お客様に満足して使用していただくためにも、バグ改修はとても重要な業務の1つになります。
バグ改修の流れ
次に、バグ改修の流れについて話そうと思います。
1.TFS(Team Foundation Server)で解決するバグを選択して、担当者を自分の名前に変更する。
2.バグを解決したら、シェルブを作成し(関係ないまたは変更のないファイルを全部除外する)、backlogでコードレビューの課題を作成し、レビュアーの割り振りを要求する。
3.レビュアーが割り振られたら、TFSでそのシェルブのレビューの要求をレビュアーに送信する。
4.レビュアーから、バックログで「OK!」をもらったら、チェックインを行う。
注意:1.チェックイン前に必ず「最新バージョンを取得」を行う
2.リリース版のバグ改修は開発版へのマージを忘れないこと
5.確認項目チェックシートへの記入
6.バックログの課題に「バグチェックインテンプレート]を記入する。
7.課題の状態を「完了」にする。
8.最後はチャットワークで「バグをチェックインしました、ご確認よろしくお願いします。」と送信することで、完了!
バグ改修を通して学んだこと
バグ改修を通して、製品知識の大切さを学びました。
バグは様々あるため、いかに正確にかつ素早く直していくかが重要になります。
そのため、このバグはどこをどのように修正すればいいのか最短の近道を見つけだすためには、製品知識をインプットしておく必要があります。
おわりに
ここまで読んでいただきありがとうございます。
少しでもバグ改修について興味をもっていただけたら幸いです。
バグ改修はw2の製品の完成度を高めていくために必要不可欠なことであり、引き続きお客様に喜んでいただけるよう努めていきます。
コメント