はじめに
どうも、どうまずです。
今回の新アプリのTIME HACKERでは、テストを中心にプロジェクトへの参加をさせてもらいました。
テストで一番大変だったのは・・・不具合の報告です。
- メールで不具合を報告したのに、伝わらない。
- 不具合一覧の内容が何を書いているのかわからない。
そんな場合に参考にして下さい。
不具合報告の大変さ
なんで、不具合報告って大変なんでしょうか・・・
今までの不具合報告の内容から、何個かパターンを出して見ました。
画面名、機能名を適当に書いている
例えば、TIME HACKERを例にしますと、
レポート画面でレポートが表示されない。
こんな感じの不具合報告です。
この報告で何が一番困るかというと、
「レポート画面ってどこのこといっているの？」
って話になります。
TIME HACKERをお使いの方はわかるかと思いますが、TIME HACKERには
- レポート-行動履歴
- レポート-アクション毎
- レポート-時間管理
と３つのレポート画面があり、どの画面をさしているのかよくわからないのです。
簡単な話かもしれませんが、意外と出来ていない場合が多い失敗報告例です。
不確定要素が含まれる不具合報告
場合によっては、不具合解消までの時間が大幅に伸びるパターンです。
これは、過去私が会社で報告された内容です。
他に何も作業していないのに、A機能の処理が遅延した。
という報告ですが、ログを確認すると、裏でDBバックアップをやっており、遅くなっていたという問題でした。
このように確認していないけど、さも確認したかのような報告がされてしまうと、不具合の解析が大幅に遅れ、最悪迷宮入りです。
不具合を報告するときは、確実な情報を伝えましょう。
- 理論的に動かない
- 仕様的に動かない
という場合、ログなどで「動いていないこと」を確認しましょう。
だって、理論的に仕様的に完璧だと思って動かして、発生した不具合なのですから。
また、SEならば、
- ユーザからの報告
これも不確定要素です。
ユーザはシステムの細部までわかっていない場合が多いので、誤った内容になることが多いです。
そのため、ユーザからの報告はヒアリングしたり、実際に動かして確認を取らないといけません。
文章の不具合報告
これは実際にTIME HACKERで私どうまずが報告した内容を例に見て見ましょう。
レポート時間管理の下部の日付（6/15）をタップして、
リスト形式で「確保したいアクション」を表示している画面に移動して、
レポート時間管理画面に戻ると、日付が6/16になっている。
・・・自分でも分かり難い。
不具合を発見した当初はこれでも分かりやすい報告をしたつもりなのですが・・・
この報告は複数の動作をした結果、日付が正しくなかったと言っています。
しかし、複数の動作を１つの文にしてしまったため、どんな動作をしたのか分かりにくいです。
また、１つの文の中に不具合の内容も書いているので、結局何が不具合なのか分かりません。
もちろん、この不具合報告は「何いっているかわからない」という結果になってしまいました。
そのため、下記のように書き換えました。
1.レポート時間管理画面で日付をタップして6/15に変更
2.レポート時間管理画面のグラフの下の日付6/15をタップ
3.時間がリスト形式で表示される画面に遷移
4.レポート時間管理画面に戻る
5.レポート時間管理画面の日付が今日日付（6/16）になってる。
5の日付は6/15が正しいと思います。
箇条書きにすることで、以下のメリットがあります。
- 動作を１つずつ記載できる。
- 不具合の再現がし易い。
- 機械的に事実を淡々と記載することができる。
文章にすると、文章に含まれる意味や内容を読み解く必要があります。
箇条書きにすることで、事実のみを淡々と報告していることが伝わり、余計な労力は不要となります。
テキストハレーションを生まないようにする。
テキストのやりとりは相手の顔が見えません。
そのため、余計なハレーション（悪影響）を及ぼすことがあります。
これも実際の例です。
レポート時間管理のグラフが正しく表示されない不具合があり、その報告をslackで正しく表示されない画像を送付して、
こんな風になっちゃったよ
と、何気なく送ってしまったのです。
その後、
これは、煽ってるの？
と返信があり、全力で謝罪しました。
不具合報告は、嫌な言い方をすると、
相手の失敗を見つけて、指摘する、かなりネガティブな報告なのです。
かなり注意して報告しましょう。
あと、新人の時は、バグという言葉を使いたがる傾向にあるようですが、
「バグってる」
という報告は、悪く言うと「お前、ミスってんぞ」と同意義です。
軽々しく使うとテキストハレーション発生ですから要注意です。
(新人のときはバグと思っても自分が知らない仕様があると思って、「仕様か確認して下さい」と言った方がいいです。）
再テストの結果は早めに
不具合報告が終え、ソースを修正してもらったら、修正が正しく行われているか再テストをして、やっと不具合修正が完了です。
「ソース修正しました」
という報告を受けた側は、「修正終わったんだ〜」くらいに捉えてしまうことが多いです。
しかし、修正した側は
- 他に想定外や考慮不足の点がないか
- 修正した結果、他の不具合を発生しないか
- そもそも、修正した箇所とは別のところで不具合が発生してるんじゃ
と、気が気ではありません。
速やかに再テストを実施し、結果を報告しましょう。
結論
不具合報告をするときは、次のことを気をつけましょう
- 画面名・機能名は正確に記載する。
- 不確定要素は記載しない。（確認してから記載する。）
- 箇条書きで機械的に記載する。
- 不具合報告はテキストハレーションを起こしやすいから要注意する。
- 再テストの結果は速やかに報告する。
これだけで、かなりわかりやすい内容になると思います。
ぜひ参考にしてみて下さい。
最後に・・・
記載したようなハレーションや問題が数々ありましたが、
「いいものを作りたい」という目的を共有し、メンバー一丸となり完成させたTIME HACKERをぜひ使ってみてください！
