カミナシ エンジニアブログ

株式会社カミナシのエンジニアが色々書くブログです

バグを調査する勘所

カミナシのソフトウェアエンジニア @imu です。

いきなりですが、バグと聞いてどういう印象を持ったでしょうか?おそらく、ネガティブなイメージを持つ方が多いのではないかと思います。ですが、ソフトウェアエンジニアには付きものと言って過言ではないくらい、バグとは長く付き合っていくものですよね。

今回はバグを調査する勘所として、バグが発生してしまったときにどういう調査をしているのか、普段何に気をつけているのかを共有して、誰かの役に立てれば幸いです。

あくまで私個人の話であり、ソフトウェアテストプロセスの話はしないので予めご了承ください。

目次

前提

  • 自身が携わっているプロダクトが一つ
  • リリース日が決まっている(24時間365日リリース出来る環境ではない)

バグ調査の勘所

バグ発生前の心構え

本番環境に何がマージされたのかを、広く浅く把握しておく!

Pull Requestの内容をすべて把握する必要はなく、Pull Requestタイトルで良いので「頭の片隅」に置いておくことが大事だと思います。(目についたタイトルや、特定のキーワードだけでも良いと思います)

そうすることでバグ発生時に、あのPull Requestが影響しているのでは?と初速が早くなります。SlackとGitHubを連携してPull Requestの通知をチャンネルに流しておくのも良いですね。

リリース直後のバグ発生

カミナシのアプリケーションのエラー可視化・監視ツールは「Sentry」、「Datadog」を利用し、エラーと検知したらSlackへ通知を流しています。そのため、リリース直後に見慣れないエラーであったり、同じエラーが大量に発生しているなど気付ける環境になっています。

エラー内容とリリースしたPull Requestを比較して、バグになりえそうな Pull Requestを調査しましょう。バグを早く修正することが一番大事ですが、なぜこの状態になっているのかを把握するのも同じくらい大事だと思っています。(致命的なケースは早く直して、後で振り返りをしましょう)

バグの根源を把握しておくことで、普段の実装時にミスを防ぎやすくなったり、Pull Requestのレビューで指摘する観点にもなりますね。

既存バグ

監査・操作ログからデータの時系列を整理してユーザーがどういった操作やデータを入力したのかを事細かく洗い出しましょう。自身が知らない機能であれば、プロダクトを理解するチャンスになるので、ここぞとばかりに理解を深めて次に活かしましょう!

再現性の低いバグへのアプローチ

ユーザーの環境ではバグが起きやすいが、手元では再現しないケースが稀にあります。ユーザーヒアリングをして同じ操作をしているのにも関わらず起きなかったりします。

そういった場合のアプローチ方法はいくつか考えられます。

  • バグが発生した時期から判断する
    • 例)12/01 から起きているのであれば前後のリリースを疑う
  • 画面で操作できることはすべて試す。普段の操作で再現性を確認することが多いですが、ユーザー目線になって操作する。
    • Webアプリケーションであれば、複数タブ開いてみる
      • 複数タブで別のログインアカウントで操作してみる
    • ボタンクリックは1回だけだが、連打してみる。
      • マウスクリックでカチカチっと2回押されるケースを想定する
    • 登録中に色んな操作をする
      • 別のボタンを押す
      • 画面リロード
      • 別画面への遷移
      • ネットワークを切ってみる
      • アプリケーション終了など
  • どうしても分からない場合
    • アプリケーションログを増やして情報を取得する
    • 明日の自分が解決するかも知れないので、早く切り上げましょう!(一晩寝るとスッと解決することもあります)

ユーザーからの問い合わせ

弊社のアプリケーションはチャットサポートでお問い合わせを受けるため、テキストだけではユーザーの細かいニュアンスを読み取れずに、曖昧になるケースがあります。

プロダクト初期の頃は以下のようなケースがありました。

例)「マスタ登録画面で登録ボタンを押したけど登録できない」

と問い合わせをいただいたとき、考えられることは以下です。

  • 何かエラーメッセージが画面上に表示されていないか
    • どういったエラーメッセージが出ているのか
  • ネットワークは繋がっているのか
  • 登録処理自体は成功しているが、入力した内容が登録出来ていないのか
  • リロードしたら表示されるのか(再描画の問題)

など、一つの文章から複数のことが読み取れる場合は難しいです。

出来ることはカスタマーサポートチームに、ユーザーの事象の深堀りを依頼して、回答を待つ間に考えられる事象は確認しておきましょう。(画面のスクリーンショットや動画を送ってもらえる環境であれば活用しても良いですね)

※現在ではカスタマーサポートチームが事象の深堀りをしてくれているため、ユーザーの意図が読み取れないことは起きにくくなっています。カスタマーサポートチームには感謝しています。

まとめ

バグを調査するだけだとネガティブな印象ですが、そこから学ぶことは多いので決してネガティブなものではないと私は思っています。

調査するのが手間だな〜と思っていた方は、今回紹介した勘所が少しでも役に立てれば幸いです。

カミナシでは、ソフトウェアエンジニアを募集しています!カジュアル面談からでもご応募お待ちしています。