先日いつものようにテストしていたら、おかしな現象に遭遇したのでプログラマAさんに見てもらいました。
わたし「こんな条件で動かすと、ほらこうなっちゃう。」
Aさん「あー、なるほど、そうなりますねぇ。バグですね。」
Aさんの頭の中のエディタにはコードが表示されているんだろうね。どこがまずいのか、だいたい分かったような顔をしていたから、わたしもホッとして、Aさんにそのチケットを引き取ってもらいました。
数日後、そのバグが修正されてきたので、よし大丈夫だろう、というところまで一通りテストしたのだけど、どう直したのかとても気になる。直し方によっては、テストが変わることもあるからです。
例えば、こんなバグがあったとします。
処理がはじまると変数Aは0以外の値になるのですが、ある特殊な条件を与えると変数Aが0になってしまうことがわかりました。
初期状態ではないのに、変数Aが0なのでプログラムは初期状態だと判断してしまい、システムとしておかしな状態になります。
これが修正されてきたら、どんなテストをしますか？
バグが発生したときと同じように、特殊な条件を与えても、初期状態にならないことをテストしますよね。それから（特殊ではない）通常の条件を与えても、おかしな状態にならないこともテストしますね。
JSTQBで4つのテストレベルが定義されていますが、わたしはそこで言うところのシステムテストを担当しているので、ピンポイントな確認を行いつつ、システム全体として連携するような機能や状態に影響がないか、またユーザがやりそうなことも想像してテストします。
そして一通り確認して大丈夫かなーと思ったとき（このバグ、どう直したんだろう）と思うわけです。
変数Aの初期値を0以外に変えたのか、変えたとしたらどんな値にしたのか、その値は、また別の特殊な条件でその値（初期値）になったりはしないのか。それとも特殊な条件になったときに変数Aを0にしないようにしたのか。そうではなくて、初期状態の判断自体を変えたのか。まさか、システムの使われ方に応じて、初期値を変更できるように設定ファイルで外に出す、なんてことしてないよね…。
ほら、直し方ひとつで、気になることがガラッと変化し、テストすべき内容が変わってきませんか？
テストオラクル（test oracle）：テスト対象のソフトウェアが実際に出力した結果とを比較する期待結果のソース。オラクルは、実在する（ベンチマーク用の）システム、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
— ソフトウェアテスト用語集 (@software_test) 2015, 6月 5
「テストオラクル」は、わたしがなかなか理解できなかった用語のひとつです。今でも分かってないかもしれない。
”コードであってはならない”なんて書いてあるから、テストするときはコードを見てはならん！みたいな印象を受けてしまうのだけど、最近は（そうじゃないかもなー）と思うのです。
誤解を恐れずに書くと、コードを知ることで、それまで見えてなかったテストが見えてくることがあるのね。それは時として、あまりやる意味のないテストを実施してしまうこと、を適度に抑制する効果もある。（そこで浮いた時間で、別のテストができる）
だから「わたしはテスターだからコードは知らなくてもいい！」「テストオラクルの説明にもそう書いてあるし！」なーんてガチガチに思っている人がいたら、そうじゃないかもしれないんだよね、と言いたい。
はじめの話に戻るけど、わたしはAさんのところに行って、一通りテストして大丈夫そうなことと、今回こんなテストをしたんだけど、直し方によってはテストが足りてないかもしれないから、どんな風に直したのか、教えてほしいと伝えました。
Aさんはメモ用紙を取り出し、図を書きながら、①その処理の本来あるべき姿、②今回どこが問題だったのか、③それをどう直したのか、をコードも交えて説明してくれた。
それを聞いて、わたしがもう少しやろうかなと思っていたテストの話もして、そういう直し方をしたなら、そのテストはやらなくても大丈夫そうだねーということになりました。
コードを知ることで、省略してしまったテストで見つかるはずのバグが見つけられなくなる（かもしれない）という危険性を十分知った上で、コードを知ることのメリットも大切にしたい。
ブラックボックステストをきっちりカバーし、グレーボックスなテストの領域にも踏み込み、まだうまくできないけどグレーボックスとホワイトボックスの間のテスト（そんなテストの領域があるのかわからないけど）にも、果敢に挑戦していく。そんな勇気のあるテスターになりたいなぁと思う。
