CAT GETTING OUT OF A BAG

What the tester is thinking.

「バグの伝わり方」を知るということ

見た目は単純そうなバグでも、その生い立ちを知ると「バグの伝わり方」が見えてきて(面白いなー)と思うときがあります。

たとえば、アプリケーションの画面には、やりたいこと(処理)を実行するための「ボタン」があります。状況に応じて、ボタンを有効(enable)にしたり、無効(disable)にしたりするんですけど(Twitterクライアントアプリなどもそうですね。何か文字を入力すると「ツイートボタン」が押せるようになります)あるソフトウェアをテストしてたとき、そのボタンは使えない状況だったのに「有効」になっていたのです。ああ、無効にするのを忘れたのかな(単なるコーディングミス)と思ったのですが、実際はもうすこし複雑でした。

ボタンの有効/無効は「状態」によって決まり、4つの状態(A,B,C,D)を持っているモデルがありました。でも、使う側はBかCかそれ以外(D)で判断していました。だからAのときはDに倒れてしまう。Aのときはボタンを「無効」にしなければならないんですけど、Dに倒れたことで「有効」になってしまった。さらに、

  • 状態Aは開発の途中で後から追加した
  • これらの状態は複数の機能で使われている
  • 複数の機能は複数のプログラマーによって開発されている

というものでした。


開発の過程で様々な機能が作られていき、それによって新しい状態が生まれる。元からあった機能は新しい状態を知らない。これまでうまく動いていたものが、あるとき急に動かなくなる。「バグの伝わり方」が目に見えるようでした。

また、このときに思ったのは「外側から見えている状態」と「プログラムで扱っている状態」は必ずしも同じではないということでした。プログラムで扱っている状態は4つ(A,B,C,D)ですが、わたし(テスター)から見えていた状態は3つ(A,B,D)だった。わたしが想像するよりも、プログラムの世界はもっともっと複雑で繊細なのです。

今回の話は「バグの伝わり方」の一例ですが、それ以来、状態に関する変更が入りそうな時には「プログラム内部で持ってる状態が増えたりしますか?」とプログラマーに聞くようになりました。昨日より良いテストをするために(わたし自身が)知りたい!という気持ちが強いのですが、朝会などでわざとらしく聞くのは「このチケットがコミットされたら、状態も気にしてテストしますよ(だからみんなも気にしてね)」というメッセージでもあるのです。