【テストにまつわるエトセトラ #1】「障害レポート」の話

こんにちは。HumanCrestの荒川です。
私は現在、ソーシャルプラットフォーマーのQA業務に携わっています。

前々から自分が関わっているQAという業務について何かしらの形で発信したいと思っており、この度Quesブログに寄稿する機会をいただきました。
特に若手~中堅どころのQAエンジニアの方に読んでいただきご意見いただけるとうれしいです。

ネタが尽きるまで不定期連載していきたいと思っていますのでよろしくお願いします。

さて今回は「障害レポート」の話です。

テストをすれば多かれ少なかれバグが見つかります。

バグを見つけた人はその内容を関係者に報告しなければいけません。
報告の手段はBTSのチケットだったりExcelシートだったり様々だと思いますが、いずれの手段においてもしっかりとした情報を伝える事が必要不可欠であることに変わりはありません。

書籍「ソフトウェアテスト293の鉄則(日経BP社)」には、バグの報告に関して以下のような事が書かれています。

<鉄則055> 報告の内容でテストをした“人”がわかる
<鉄則057> 障害レポートを商売道具として活かせ
<鉄則058> 障害レポートはテスト実施者の名刺である

私は障害レポートを作成する時、これらの鉄則を意識するようにしています。

良いバグを見つけても読み手に「ん?ちょっと何言ってるかわからない」と思わせてしまうのは非常にもったいなく、QAとしてはとても悔しい事です。
質の低い障害レポートは、無駄な質問のやりとりを生み、責任者の優先度判断を鈍らせ、開発担当者の修正までの道のりを困難なものにします。

では質の高い障害レポートを書くためにはどういった事を心掛ければよいでしょうか。

再び鉄則本からいくつか抜粋します。

<鉄則056> 正しく伝えてこそ修正がなされる
<鉄則059> 障害レポートの価値を高めるための手間暇を惜しむな
<鉄則083> 障害レポートはタイトルで決まる
<鉄則084> バグをありのままに報告せよ
<鉄則087> 疲労困ぱいで不機嫌な人に読まれると思え。障害レポートは極力読みやすく

これらの鉄則を私なりに分解して再構築した結果、下記のポイントを押さえておけば障害レポートの質はかなり向上するという結論に至りました。

————————————–

<ポイント1:簡潔な文章を心掛ける>
難しい表現や熟語を使う必要はありません。
1つの文章が長くならないように心掛け、まとまらない場合は箇条書きにしましょう。

<ポイント2:抽象的、主観的/文芸的な表現は避ける>
再現手順やバグの説明に「~かもしれない」や「ログインを試みたところ~」や「○○にもかかわらず□□になる」といった記述をしばしば目にします。
「~かもしれない」というのは明らかに論外ですが、「試みる」や「にもかかわらず」といった主観的な表現も障害レポートにはふさわしくありません。「ログイン操作後~」「○○だが□□になる」などとすべきです。

<ポイント3:読み手が必要な情報を記載する>
ポイント1と2に留意しながら、以下の3つの要素を記載する事が重要です。

・タイトル
・バグの情報
・環境の情報

タイトルは、読み手がそれを見ただけで内容が把握できるように工夫しましょう。
バグの情報や環境の情報に何を記載するかはテスト対象やプロジェクトによって様々だとは思いますが、大切なのは「読み手が次のアクションを起こすために有益となる情報を提供する」という事です。

例えば現在私が携わっているプロジェクトでは以下のような項目を本文に記載しています。

■バグの情報
├【概要】
├【発生箇所】
├【再現手順】
├【実際の結果】
└【期待する結果】

■環境の情報
├【検証環境】
├【ブラウザorアプリ?】
├【ユーザID】
├【OSのバージョン】
├【アプリやブラウザのバージョン】
└【通信環境】

————————————–
以上、「文章は機械的に。内容は思いやりを持って」といったところでしょうか。

良い障害レポートはバグを円滑に収束させるだけなく、関係者との信頼関係を構築することができるという素晴らしい副作用もあります。
そこで得た信頼は最終的にQAの地位向上にもつながります。

バグを見つけた時は自分が「テストのプロ」であることをアピールする絶好の機会です。
価値ある障害レポートを作成して、QAエンジニアとしてさらなる高みを目指していきましょう。

参考文献:ソフトウェアテスト293の鉄則(日経BP社)

======================================
<おまけ>
この他にもバグ報告関連ではこんな鉄則もあります。

<鉄則073> 優先度と重要度を区別せよ
<鉄則077> 再現できないバグはない
<鉄則078> 障害レポートの処理コストにも注意を払え
<鉄則092> ときには障害を実演してみせる
<鉄則093> 「直した」と言われたら,別の所に問題が出てきていないか確認せよ

また機会があれば掘り下げてみたいと思います。
======================================

このエントリーをはてなブックマークに追加