わたしは過去10年超、QAエンジニアとしてソフトウェアテストや品質保証に関わる仕事をしてきました。ソフトウェアテストを専門とするエンジニアの基本スキルとして“バグレポートを書く”があります。
バグレポートとは、ソフトウェア開発の現場でなんらかのバグが見つかったとき、バグの内容や再現手順などをチーム内で記録・共有するために書かれるものです。テストエンジニアにとって大事なこのバグレポートですが、実はテックチーム全員に必要なスキルでもあります。本記事では、上手なバグレポートの書き方や、なぜテストエンジニア以外のしごとに活きるのかについて解説します。
目次
バグレポートとは
上述の通り、バグが見つかった際にその詳細を報告するために記載するドキュメントのことです。
バグ票・不具合票・インシデントレポートなど、開発チームによっていろいろな呼ばれ方をします。
主にテストエンジニアがテストを行ってバグを見つけた際に記載し、開発者やプロジェクトマネジャーなど、開発チームの皆に見えるところで登録・管理するのが一般的です。管理にはRedmineやBacklog、Jiraなどのいわゆる「バグトラッキングツール（BTS）」を用いることが多いです。
登録されたバグレポートは開発者が確認し、バグの内容を把握したのち修正作業に入ります。プロジェクトによっては残念ながらたくさんのバグが出てしまう場合もあり、テスト担当者や開発者がバグレポートごとに重要度を設定し、重要なものから修正します。
バグレポートの内容や書き方に問題があると、重要度の判断を誤る場合も。さらに、開発者がバグの内容や再現方法を正しく理解できずに「これはどういう意味ですか？」など何往復ものやりとりが発生し、バグの修正がどんどん遅くなってしまう……という事態にもつながってしまいます。
バグレポートの書き方
バグの重要度を誤って判断したり、修正が遅くなってしまったりすることは、開発プロジェクト全体に悪影響を及ぼします。そのため、とくにテストエンジニアはバグレポートを上手に書くことが求められます。
では、どういった条件がそろえば上手なバグレポートと言えるでしょうか。
基本的な構成要素
詳細は会社やチームによって異なりますが、一般的には以下の要素が必要です。
- バグの概要（バグレポートのタイトルに相当）
- バグの再現手順
- 発生していること、現時点での動作
- 本来期待される動作
- 発生する環境・テスト対象のバージョン
- その他参考情報
- スクリーンショット
- システムのログやクラッシュレポート
まずはバグの概要です。レポートのタイトルに相当し、バグ管理システムなどではこのタイトルが一覧に表示されるため、ぱっと見てバグの内容がわかるようにまとめる必要があります。
そして次に書くのが、バグレポートの中でもとくに重要な再現手順です。
再現手順とは、バグを実際に発生させるためにおこなうべき操作を、順を追って記載したものです。どの画面で、どんな文字を入力して、どのボタンを押すか、などを具体的に書き起こします。
再現手順に沿って操作した結果どうなるのか（現時点での動作）。また、本当はどうなるべきなのか（期待される動作）。
この2点もあわせて記載します。
期待される動作が仕様書などに書かれている場合は、「このファイルのここが根拠です」と添えると親切です。もし仕様がわからず期待される動作が不明なときは、「ユーザーの視点ではこういう動作を期待すると思います」などの案を書くこともあります。
さて、次の「発生する環境・テスト対象のバージョン」は忘れられがちですが大事です。筆者個人の感覚ですが、この項目が書いてあると「おっ、わかってるな」という印象を持ちます。
というのも、テスト担当者と開発者との間で「動きません」「こちらでは動きますが？」というやりとりが続いてしまうのが「バグレポートの残念なあるある」だからです。たとえば、Internet Explorerでしか発生しないバグをテスト担当者が発見してバグレポートを書いたものの、発生する環境を正しく記載しなかった、とします。このとき、開発者がGoogle Chromeを使っていたら……。テスト担当者は「バグだから直してください」と言い、開発者は「そんなバグは起きない。ちゃんとテストしているのか？」と返す。険悪なムードのできあがりです。
こうした事態に陥らないように、どんな開発環境・ユーザー環境で発生するのかや、テスト対象のバージョン情報などをきちんと記載することが大事です。
また、その他の要素としてスクリーンショットやシステムログ、クラッシュレポートなど、開発者がバグの調査をおこなう上で参考になる情報があれば追加します。言葉だけでは説明が難しい内容であっても、画像や動画を見ればすぐに伝わることが多々あります。
気をつけるべきポイント
上記の構成要素をおさえることに加えて、バグレポートを書くうえで気をつけておきたいポイントがあります。
それは「あいまいさをなくし、誰が読んでもわかるように書くこと」です。
あいまいな表現、たとえば「うまく動かない」「正しくない」といった報告を受けても、開発者はなにをどう直せば正解なのかがわかりません。開発者が個人の想像でバグを修正してしまうと、別の箇所に新たなバグが起こってしまうこともあります。また、あいまいな表現のさらなるデメリットとして、開発者の意欲を削いでしまうことも挙げられます。バグレポートは、単にバグを記録・共有できればよいわけではありません。最終的にバグを修正し、開発しているサービスやアプリケーションをよりよいものにするところまでを考えなければなりません。開発者の心情としては、意味がわかりにくいバグレポートよりも、理解しやすいバグレポートを先に着手したくなるものです。つまり、バグレポートをあいまいに書いてしまうと、そのバグが修正されづらくなる、という可能性がでてきます。
その他、誰が読んでもわかるように書くためのテクニックはたくさんありますが、たとえば
- 事実と感想を区別する
- 短く簡潔に
- 調査済の事項も書く
などを意識して書くとよいでしょう。
テストエンジニア以外でも活用できる
ここまでバグレポートの書き方や注意点について説明してきましたが、これらはテストエンジニアだけが知っておけばいいわけではありません。むしろ、エンジニア以外も含めたテックチーム全員が身につけるべきスキルです。
こう言い切るのには2つの理由があります。
1つはテストエンジニアだけがテストをするわけではないからです。
かつては開発者＝つくる人、テストエンジニア＝テストする人、というように明確な分担も見られました。もちろん今でもゼロではありませんが、全体の傾向として、開発者やマネジャーなどテストエンジニア以外の職種も含めて、チーム全体でテストをすることが増えてきています。
そのため、テックチームに参加している場合は職種によらずテストをする機会がある＝バグレポートを書く機会がある、と言えるでしょう。チームの皆がバグレポートをうまく書ければ、バグの修正がスムーズに進むかもしれません。
もう1つは、バグレポートをきちんと書くためのスキルは仕事の基本スキルに通じるからです。
バグの内容を簡潔に要約することや、再現手順を順序だてて説明することなどは、そのまま仕事上のドキュメント作成のスキルと共通です。テックチームでも書く機会がある議事録や手順書などと基本は一緒だと言えるでしょう。
ある程度フォーマットが決まっているバグレポートは、ドキュメント作成のスキルを向上させるためにはよい練習になります。
参考情報として、プロのテストエンジニア・QAエンジニアの方が作成した「わざとバグを埋め込んだアプリケーション」をご紹介します。
テスト練習用のバグだらけWebAppを公開します【Finding bugs】 – テスターちゃん【4コマ漫画】
このアプリケーションを操作してバグを見つけ、バグレポートを書いてみるのもいいでしょう。チームでチャレンジして、「この書き方がわかりやすい！」とか「こう書いてくれると開発者としてはうれしい」など、話し合ってみるのも面白そうですね。
伝わるバグレポートを書けるようになろう！
今回はバグレポートの書き方について、そしてテストエンジニア以外にも関係があります、という説明をしました。
もしチーム内でバグレポートを記録・共有されているようであれば、ぜひ内容や書き方などに注目してみてください。また、テストエンジニア以外の方も本記事を参考にバグレポートの記載にチャレンジしてみてください。
（文・伊藤由貴）
