CAT GETTING OUT OF A BAG

What the tester is thinking.

バグが報告されたときにわたし（テスター）がやってること

こちらのツイートですが、思いがけずたくさんの方に見ていただきソフトウェア開発（特にテスト駆動開発）への思いやご意見を伺うことができました。ありがとうございます。


この記事では「バグが報告されたときにベテランプログラマーSさんではなくわたし（テスター）がやってること」をメモしておこうと思います。

自分以外の誰か（以降、同僚）がバグを見つけたときにあなたは何をしていますか。個人的に大変興味深いテーマですが、バグを見つけるための手法やプロセス、バグを見つけたあとの報告の仕方（バグ票の書き方など）と比べて取り上げられることが少ないように思います。もしかしたら当たり前すぎて話題にならないのかもしれませんが『当たり前にやってることに価値がある』と聞いたことがあります（これを書くモチベーションにしよう！）。

バグが報告されたときにやってること

以下にざっと列挙しましたが（★）は自分でバグを見つけたときにもやってることでした。消すのもなんなので載せておきます。（だいぶ書いてから気がついた）

  • どのようなバグなのかを知る（★）
  • どうやってそのバグを見つけたのかを教えてもらう
  • バグを再現させてみる
  • 自分ならそのバグを見つけられたかどうかを考える
  • どんな風に作るとそのバグが起きそうかを考える（★）
  • そのバグが起きるなら…（他のバグを探しに行く）（★）
  • バグを見つけた同僚を褒める

どのようなバグなのかを知る（★）

うちのチームは面白いバグや重大なバグが見つかるとザワつくことが多く（何かが起きたらしいぞ）を感知したプログラマーやテスターが発生源に集まってきます。そこで見つけたてのバグを再現方法も含めて披露してもらうのですが、バグそのものの現象を知るには一番早くて確実な方法ですね。

朝会の中で（昨日そんなバグが見つかったのかー）とはじめて知るものもあります。現象自体はなんとなく想像できるものが多いのですが、分からなかったらその場で聞いて教えてもらいます。嫌な現象は起きてないけど今の実装だとまずい（いつかアプリケーションがクラッシュする）というものも報告されます。

これらのバグを修正していく過程でどんどん明らかになっていく「バグの原因（どこをどう間違ったのか）」「何を実装したときにこのバグが入ってしまったのか」「どこをどのように直すのか」に耳を傾け、またそれに伴うディスカッション（その修正方法だとこういうケースでダメなのではないか etc ）も合わせ聞いたうえで、徐々に「こういうバグなんだな」が分かるようになります。*1

どうやってそのバグを見つけたのかを教えてもらう

これは操作手順のことではなく、なぜそんなことを試してみようと思ったのか、何を見ておかしいと思ったのかです。思考側（きっかけ、動機）ですね。

  • 前に開発していた製品でこんなバグを見たことがあったので
  • 画面の更新が一瞬遅くなったからあれ？と思った
  • 処理が遅すぎて（退屈で）やることがないので押せるものを押してた
  • チケットを ”クラッシュ” で全文検索して気になるものをやってみた
  • いつも同じデータで試していて問題を見つけられなかったことがあったので
  • 見た目はこんな画面構成だけど、内部的にはデータを二重管理しているから…

これを教えてもらうと、同僚が知っていることや経験してきたことや考えていることを（断片的ではありますが）自分のものにすることができます。例えば、これまで見てきたバグや自分自身の失敗談、いま何に注目し、何を心配しているのか、テストのやり方や得意なこと、こだわりや癖など。それを自身の開発（テスト）に活かすのです。これはオススメです。*2

ただ、実際に自分で経験したことではないので揮発性というか時間の経過と共に忘れてしまうことが多いです。そのことに気づいてからは専用のメモ帳に書いておき、ときどき読み返しては自分の脳にせっせと書き込んでいます。

バグを再現させてみる

先ほど ”朝会ではじめて知るバグも現象自体はなんとなく想像できるものが多い” と書きましたが、バグが直ったことを確認するときのために（このバグは自分の手で再現させて自分の目で見ておかなきゃ！）と思うものがあります。

  • タイミングを狙うような操作が必要なもの
  • 操作手順が複雑なもの
  • 現象自体が分かりづらいもの

これらのバグは練習して確実に再現できるようにしておきます。例えば「この処理の一瞬の隙間を狙ってボタンを素早く二回押す」といった操作です。”現象自体が分かりづらいもの” というのは「動作がもっさりする」「画面がパシャパシャする」「ボタンが一瞬チカッとする」のようにオノマトペで表現されるものが多いです（うちのチームだけの特性かもしれませんが）。自分で再現させる前にバグを見つけた同僚に目の前で再現させてもらったり、どこがどうおかしいのか説明してもらうこともあります。パシャパシャとはこの現象を言ってるのだな、とかね。プログラマーが優秀で翌日にはバグが直ってしまうこともあるので（見ておかなきゃ！）と思ったらすぐやるようにしています。

自分ならそのバグを見つけられたかどうかを考える

同僚が見つけたバグを「自分なら見つけられたかどうか」を考えます。

  • 自分ならその操作を試そうとしただろうか
  • 自分ならその状況を思いついただろうか
  • 目の前にそれ（バグ）が現れたときにおかしいと思えただろうか
  • 設計や実装を想像できただろうか

遅かれ早かれ「自分でも見つけられたかな」と思うものはそれでよしとします*3。そうでないものは、そのバグを見つけられないのはなぜか、自分でも見つけられるようになるにはどうすればよいかを考えます。

  • これから開発（テスト）するときに注目すべき点（観点）としてXXXを自分の中に取り入れよう
  • バージョンごとにそんな複雑な仕様になってることを知らなかった → その仕様に詳しいNさんに教えてもらう
  • この特殊な画像データを使うとおかしさに気がつきやすいのか！ → 使う
  • 設計や実装を知らないとそこが怪しいなんて絶対想像できない → プログラマーSさんに説明してもらう*4

どんな風に作るとそのバグが起きそうかを考える（★）

これは自分でバグを見つけたときにもやってることなので省略します。

そのバグが起きるなら…（他のバグを探しに行く）（★）

これも自分でバグを見つけたときにもやってることなので省略します。

バグを見つけた同僚を褒める 

「これはいいバグ！」「よく見つけたなー」と思ったら褒めます。わたしも誰かに褒められたら嬉しいですもん。最近だと入社２年目のエンジニアKさんが「丁寧にテストしないと見つからないバグ」を報告していたので褒めました。Kさん「だんだん慣れてきたらこんなに（丁寧に）テストしなくなるかもしれません」と馬鹿正直に言うので「１０年後もその丁寧さを忘れないでーーーー」とお願いしました。

同僚じゃなくても褒めてますね。

おわりに

バグが報告されたときにわたし（テスター）がやってることをメモしました。同僚がバグを見つけたときって今の自分には無いものに気づいたり、足りないものを学習したり、他人の経験（暗黙知を含む）を自分のものとして取り入れることができる良い機会だと思っています。

 

テスト駆動開発

テスト駆動開発

 
ソフトウェア・テストの技法 第2版

ソフトウェア・テストの技法 第2版

  • 作者: J.マイヤーズ,M.トーマス,T.バジェット,C.サンドラー,Glenford J. Myers,Todd M. Thomas,Tom Badgett,Corey Sandler,長尾真,松尾正信
  • 出版社/メーカー: 近代科学社
  • 発売日: 2006/08/01
  • メディア: 単行本
  • 購入: 7人 クリック: 267回
  • この商品を含むブログ (47件) を見る
 
ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

 
ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則

 
新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

 

*1:分かったことが「本当に正しいかどうか」は気にしすぎないようにしてます。もちろん正しいのが理想なんですけど、自分で（こうなんだな）と思えればまずはよし。あとから分からないことが出てきたり疑問に思ったときにまた調べたり誰かに聞いたり、間違いに気がついたときにエラー訂正します。

*2:自分でバグを見つけたときも、なぜそんなことを試してみようと思ったのか、何を見ておかしいと思ったのかを話すようにしています。

*3:見つけられたとは思うけどそのバグはもうすこし早い段階で見つけたかったな…と思うものがあります。何かの順番が間違っているのでしょうね。

*4:Sさんにもどのようなバグを見つけられるようになりたいのかを伝えます。Sさんはそれを踏まえてどう作られているのかの種明かしや秘密を暴露してくれるはずです。