ワニがバグ票書く時に心がけていること
この記事は
24日目、12/24の記事です。
ワニはバグ票ワープラというコミュニティに属してはいますが、個人的に思っていることをつらつらとまとめてみます。2017年12月時点の所感です。来月や来年はまた違うことを思っているかもしれませんが、それはそれで良いと思います。
１．バグ票1枚で完結すること
一番心がけているのはこれですね。バグ票1枚でバグの報告が完結すること。「複数のバグ票にまたがって１つのバグを報告をしませんよ」ということではなくて、そのバグを理解するうえでの情報がすべてバグ票1枚に収まっているかどうかです。
バグ票を読む上での手間を減らしたいわけなんですね。
"期待する動作"の項目に「仕様と異なる」の一言書いてあったとしましょう。
こう書かれるとそのバグ票以外の参照ドキュメントが必要になり、開く手間、探す手間がどうしても発生してしまう。バグ票起票者が修正に必要な情報を知っていて教えないことに何のメリットもないんです。
自分の理解のチェックにもなるので、良いですよ。
けっこうミスするものです。人間って。
参照仕様のページ数の入力ミスだとか、リンクの貼り付けミスとか。
２．やったことを書く。書くことに躊躇しないキモチを持つ
発生しにくいバグに発生しやすい手順、発生しにくい手順があることがわかったら書こう。バグの原因を探す上でブラックボックスであっても、いろいろな実施結果があればそれがヒントになる。情報の与え過ぎはダメだけど。
とはいえ、あまり不確かなことを報告したくないのもすごくわかる話です。ひとつほころびがあると、他の記述もちょっと大丈夫・・？というような疑いをかけられてしまう。
じゃあその不安をどう拭えば良いのかと言うと、いきなりバグ票という本番に流す前に、周りのテストメンバーや開発と話をしてみる。自分が見えていなかった観点や切り口での話が聞けるかもしれないし、密に情報交換を図ろうという姿勢で口を開いてくれることもあるでしょう。一人で考えている時って恐ろしいほど視野が狭くなっていたりするので。
やった、やってない、発生した、発生していない、X回中Y回発生する、体感だが手順Ｚの方が発生しやすいなどの実施結果を、まずは自分でまとめてからコミュニケーション取ると良いですね。話しながらまとめるのはいきなりは難しいです。
【余談】
そんなことを言いつつも、ワニも結局のところ「再現性がないし、面倒だなぁ。これ以上やっても出なければ報告出来ないから、なかったことにしよう」と諦めた、諦めざるを得なかったバグ報告もあります。その後、同じようなシチュエーションに出くわすと、諦めた経験がつい顔を出して「どうせ再現しないから」と諦めることがクセになってしまう。
アプリの機能が出来ている出来ていない、品質の良い悪いをジャッジする人に心のカゲがあると、テストに支障が出ることは明白。なるべく心はクリアにして挑みたいですね。
３．ログがあれば良い、動画があれば良いに負けない
アプリの操作ログや動画が取れるならば、取る。ここに否定はまったくないのだけれども、それがあればバグ票としてOKかと言うと違うと思う。
操作ログ取得や動画をもれなく取れていれば、それは完全な情報源で良いですが、バグ票を読むのは人間。より伝わりやすい表現や方法があると思うんですね。野球で例えるとわかってくれる人とか、スター・ウォーズで例えるとわかってくれる人とか。
このプロジェクト、組織ではこの方が"より"わかってもらえるということがあるので、
過去の成功体験をごり押しし過ぎない心のやわらかさを持っておきたい。
まとめ
気になっていることを３つ書いてみましたが、バグ票を書く上でもコミュニケーション必要だぜ！一人で考え込まずに周りと話をしてみようぜ！という感じでしょうか。
この記事を読んで、なにか今一度バグ票を見つめ直すきっかけ、話のタネになればうれしいです。「ワニの言うことなんて全然間違ってるぞ、俺が考える心がけていることはこうだ！」とかね笑
それではみなさま良い聖夜をお過ごしくださいませ。
以上ワニ！
