CAT GETTING OUT OF A BAG

What the tester is thinking.

ベテランプログラマーとバグの調査をしたときのこと


これ、ツイートではさらっと書いてますけど、とても複雑な状況だったんですよ。非常に多くの入力項目があり、さらにROI*1 も設定できる。わたし自身、どの操作(入力)が引き金になったのか、予想もつきませんでした。すぐに、隣のチームのベテランプログラマーSさんを呼んで、現象を見てもらいました。*2 

プログラマーに状況を説明する

おかしな状態になる前に、どんな操作(入力)をしていたのか。たまたま、関係しそうな画面を4枚ほどキャプチャーしていたので、それを1枚ずつ見せながら、Sさんに説明しました。

miwa「次にこの画面ですけど、Aの値は、デフォルトの値が XX だったんですが、YY に変更しました。で、Bの値は、Aを変えたことで自動的に ZZ になったので、それを 1.4 に変更して、、
Sさん「うわあああ、ここに 1.4(小数点の値)を入れたんですね
miwa「入れました。小数点の値、嫌なんですか?
Sさん「嫌かも、というか、小数点の値はあまり試してません…


その後も

「きゃーーー、やめてーーー
「こわい、こわい、こわい
「これは、何が起きるかわからない


Sさんのリアクションは、控え目に言って最高
でした。こういうのって(テスターにとって)ものすごく有難いんですよ。

  • プログラマーが「やって欲しくないこと、嫌なこと」を知ることができる
    わたしの脳内:ここは大したことしてないと思っていたんだけど、内部の処理は、想像以上に複雑なのかも。もしかしたら、Sさんもまだ不安なところがあるのかもしれないな。もう少し時間をとって、テストしたほうが良さそう。
  • プログラマーが「まだ試してないこと、試しづらいこと」を知ることができる
    こんなことを聞いたら(テスターだったら)とりあえず、すべての入力項目に、小数点の値を入れてみようと思いますよね。それから 1.4 以外の値は大丈夫なのか、数値を丸めているのだとしたら、どのような丸め処理をしているのか、有効桁数はいくつなのか、いろいろ気になってきます。

このような情報は、当然、設計ドキュメントには載ってない。だから大変貴重です。*3

どの操作が引き金になっているのかを探る

わたしがやったことを一通り話した後に、どの操作が引き金になっているのかを探りました。*4いま思うと、もうこの時点で「この現象が起きるのなら、どの操作(入力)が関係しているのか」が、Sさんにはある程度わかっていたんだと思います。話を聞きながら、Sさんの頭の中には、プログラム(コード)が浮かんでいたのでしょうね。


今度はSさんの話を聞きながら、わたしが手を動かします。ペアテストに似ていますね。

「まず、ここは関係ないはずなので、ここの設定は全部オフにしてみましょう
(カチャカチャ、ターン)
「はい、再現しますね(想定どおり)
「では、ここも関係ないと思うので、ここもオフにしましょう
(カチャカチャ、ターン)
「はい、再現しますね(想定どおり)
「この現象が出るのは、◉◉の値がおかしくなっている、ということなんです
「◉◉の値は、AとB、あとCの値が関係してるんですよ
「ということで、AとBとCの値を変えてやってみましょう
(カチャカチャ、カチャカチャ、ターン)
「再現しなくなりましたね。ということは…


すこしずつ条件を変えながら「これだ!」という操作(入力)に迫っていきます。いくつかのパターンを試しました。引き金になる操作を特定したのは、それから10分後くらい。やっぱり早いわー。

今回のケースは、入力値だけでなく、操作順も関係していたので、再現手順を見つけるのが大変なバグでした。同じ値を設定しているのに、再現するときと、再現しないときがあるのです。こういうのは難しいですね。Sさんのナビゲーションがなければ、1時間かけても、たどり着かないかも…。*5

「実は、AとBに値を入れた後に、ある計算をしていて、ほら画面にも計算結果を表示してますけど、これ以外にもいろいろ計算してるんですよ。表には見えないんですけどね。裏でものすごい計算が走ってる。特にBね。だから、Bに値を入れた直後に、おかしなことになっているのかもしれないな。


わたしの脳内に「Bはヤバい、Bに注意」が刻まれました。こういう情報も、テスターにとっては貴重です。

Sさんの予想どおり、Bにある値を入れた直後に処理を実行すると、再現しました。Bにある値を入れた後に、違う項目(例えば C)に値を入れてから処理を実行すると、再現しませんでした。

こんなのを目の前で見せられると、プログラマーすごいなあ、これは真似できない、と思いますね。鮮やかでした。素晴らしかった!

ベテランプログラマーに共通する、ある行動

確信はないのだけど、前々から(もしかしてそうなのかな?)と思っていることがあります。それは「ベテランプログラマーほど、不安なところを包み隠さず、丁寧に教えてくれる」(傾向がある)ということなんですけど、今回のことで、うちのチームだけではなく、隣のチームでも観測することができたので(やはり、そうなのかもしれない)と思っている、今日この頃です。*6

おまけ

今回の「再現手順を見つけるのが大変なバグ」を説明するのに、簡単な画面を作りました。でも、文章で伝わりそうだから、いらなかったですね。せっかく作ったので、貼っておきます。(ラベルの枠のコーナーを丸くするやり方を覚えました!)

f:id:miwa719:20180805204133j:plain

プログラマーとお仕事をするということ

プログラマーとお仕事をするということ

 

*1:Region of Interest:操作の対象として選ぶ領域(関心領域)のことで、画像処理などで使われる用語です。

*2:ここのところ、隣のチームで絶賛開発中の「ある機能」をテストしている。

*3:この情報は、同僚のテスターや、隣のチームのテスターにも伝えます。

*4:Sさんがいちいち悲鳴をあげるので、観客が2名もついた。

*5:まあ、その前にうちのチームの誰かが、わたしの異変に気がついて、1時間もやらせてもらえないと思うけど。

*6:観測範囲がものすごく狭いので、気のせいかもしれません。書籍『プログラマーとお仕事をするということ』にも、そんなことは書いてなかった。