テスターちゃん【4コマ漫画】

ソフトウェアテストの用語、やり方などを4コマ漫画でわかりやすく説明する(予定の)ブログです。脱線も多いです。



24. バグ票の書き方 その②

f:id:m_training:20170730212050p:plain

24. バグ票の書き方 その②

 

本文

まずバグ票の鉄則!

「バグの情報が明確に伝わるように」

「関係者が再現できるように」

 

バグ票はただ書き残せばいいものじゃないよ

バグ票の本質はバグを直してもらうこと。

相手にわかってもらえないと意味がないんだ。

 

「相手に伝わる」ということを踏まえて、まずは要約を見てみよう。

「正しく表示できない」ってどう表示されたんだっけ?

 

undefinedって出ました。

 

そうだね。

「正しくない」じゃなくて、具体的に「undefinedと表示される」の方が状況が伝わるよ。

 

そういやこれ、全部の辺の組み合わせでも起こるのか?

A=Cのときだけで、A=B、B=C、正三角形の時は三角形の名前が出ました。

ならその情報もあった方がいいな。

 

■要約

辺A=辺Cの場合のみ、答え欄に「undefined」と表示される

 

そうなると要約はこんな感じかな

場所にもよるけど、敬語は不要だよ。長くなっちゃう。

 

要約はね、

「どこで、どうしたら、どうなった」が基本かな

 

教え方

塾などでもそうだけど、こちらから一方的に話すと相手はわかっているようでわかっていない。

少人数に教えているのならば質問をするとよい。

「考える」という能動的な工程をはさむことで、ただ聞くよりも理解が上がる。

受動ではなく、能動の姿勢は大切である。

 

あと作者談。

こちらから一方的に話して「わかった?」と聞くとほぼ間違いなく「わかった」と返ってくる。

本当に分かったか知りたいときは

「じゃあ、簡単に説明してみて」

と聞くとよい。

 

要約(タイトル)

要約はパッと見でわかるような内容がベターである。

相手に伝わりやすい他に、バグの検索時に楽になる。

バグが500件とか溜っている場合の検索は割とつらい。

検索をかけると要約(タイトル)の一覧が表示されるのだが、そこでさらに「UIが不正である」が並んでいると、「このバグはどんなバグだったか……」と一個一個本文を覗いていく作業が発生する。

 

要約部分をわかりやすく、と伝えると、要約ですべてのステップを書いてしまう人もいたりするが、ほどほどが大切。

どこまで書くのか判断は必要。

 

ダンベルカール

ダンベルの筋トレを考えたときに真っ先に思い浮かぶ使い方。

 

肘は腰当たりの位置から動かさないようにし、ゆっくり持ち上げ、ゆっくり下げる。

肘はぶれないように注意しよう。

下げるときは肘を伸ばしてしまうと、ひじを痛めることもあるそうなので注意が必要。

(マンガの絵はあきらかに肘が動いているからアウトだ! ついついこう描いてしまったのだ…)

 

重さは正しい姿勢でできる程度の重さが良い。

(重くしたい気持ちはわかる!よーくわかる!)

けど、あまり重いダンベルを使うと反動で持ち上げたり(チーティング)してしまい、上腕二頭筋が上手に鍛えられなかったりする。

 

作者は重いダンベルを使うときは「コンセントレーションカール」を行ったりしているゾ。