# 動作確認

## PR 作成時の動作確認

開発者は、PR を作成するときに、アサインされたチケットの要件を満たしているか、動作確認を行います。

動作確認は、正常系と異常系の両方を考えて、実施します。
正常系とは、期待するデータを受け取り、期待する結果が返ってくることを想定した場合のことです。
一方、通常ユーザーが入力しないであろうデータを送ったり、サーバー側でエラーが発生し、期待する結果が返ってこない場合を想定することを異常系と呼びます。

開発者は、動作確認を行い、チケットの要件を満たしているエビデンス（動画やスクショ）を PR に記載します。また、変更による影響範囲を考えて、デグレが発生していないか入念に確認してください。デグレとは、それまで正しく動作していたものが、他の対応によって動作不全になる現象です。

開発者は、担当したチケットの関連箇所の動作確認も行い、チケットに直接関係のない不具合やバグがあれば、PM に報告するようにします。

## バグが発生した際の行動指針

開発者は、バグが発生した際、下記の行動指針にそって対処します。

- 再現するかどうか確認
- 原因を考え切り分けをする
- 仮説検証をする
- 修正案を考える
- 修正案の影響範囲を考える
- 自動テストを実施する
- 手動テストを実施する

順番に解説していきます。

### 再現するかどうか確認

<Info>バグ発生までの手順、条件、環境を確認しよう</Info>

まずは発生したバグの再現性を確認します。
どんな手順を踏んだ際に、バグが発生するか確認をします。
また特定の条件下で発生するバグもあるので、「こういう条件でバグが起きるのではないか？」という仮説を立てます。
更に、環境に依存したバグかどうかも確認しましょう。
本番環境で発生するか、ステージング環境で発生するか、特定の OS で発生するのか、特定の端末で発生するのか、特定のブラウザで発生するのか、
バグの発生条件を確認をすることは、バグ解消において重要な１歩です。

### 原因を考え切り分けをする

バグ発生までの再現性や手順がわかった後に、原因を探っていきます。
フロントエンド側のバグなのか、バックエンド側のバグなのか確認します。
これはフロントエンド側のログを見たり、サーバーからのレスポンスの中身を見てどちら側の不具合なのか確認します。
※フロントエンド、バックエンドのそれぞれにバグがある複雑なケースもあります。

### 仮説検証をする

フロントエンド側に原因があるのか、バックエンド側に原因があるのか切り分けを行った後、どのファイルのどの部分に原因があるのか確認していきます。
原因が判明しない場合には、このあたりが原因なのでは？という仮説を立て探っていきます。
ブレイクポイントを貼ったり、ログを出力したりして、どの部分に不具合があるか、探っていきます。

### 修正案を考える

原因の特定ができた後、改善案を考えます。

### 修正案の影響範囲を考える

修正をかける際には、影響範囲を考えましょう。
その修正を加えることで、どこまでの影響があるのか、考えます。
プルリクエストを作成する時に、レビューワーに、その影響を伝えるのも効果的です。

この際、保守性も考える必要があります。
修正を加えることで読みにくいコードになっていないか気をつけましょう。
どうしても読みづらいコードになってしまう際には、コメントを書くことで、コードの意図を伝えます。

### 自動テストを実施する

自動テストが組んである場合は、自動テストを実施することで、他のソースコード部分への影響を検知できます。
必ず自動テストを実施してください。

### 手動テストを実施する

最終的には、開発者が実際に手を動かしてテストを行い確認をします。
バグ修正した際は、修正による影響範囲を考え、テストを行いましょう。