テスト駆動開発のスタイルを取り入れているもののテストのことはあまりよくわかっていないプログラマーと、テストへの熱い情熱をもちつつプログラマーの事情はわかっていないテスターとが、小さな障害の発見をきっかけとして出会い、役割の壁を崩しながら少しずつ協調するようになっていく、小さなお話です。
登場人物
プロ之 … プログラマー
テス緒 … テスター
前回、テス緒さんとプロ之さんはそれぞれのリーダーから指摘を受け、プロダクトにとって大事なこと、チームにとって大事なことが何なのか考え直しました。そしていま調べている問題も大事なことだから、継続して調べようと2人で決意しました。
プログラマーが切り込む話
テス緒さんはテストチームリーダーと、プロ之さんは開発チームリーダーとそれぞれ交渉し、もうしばらくこの問題を追及していいことになりました。2人はそれぞれ自分の時間を使って調査を進め、これからお互いの発見を持ち寄って話し合うところです。
プロ之(以下、P)「total_hoursを更新する可能性がある箇所を、コールグラフを使って探したらAPIと画面合わせて4箇所ありました。APIはその先にUIがあるので、画面的には9箇所になります」
テス緒(以下、T)「えっそんなに？」
P「でも画面によっては他の項目を更新するだけなので、実際にtotal_hoursを変えられるのは4画面です」
T「あ、それならわかる」
P「4画面のどのパスもテストでカバーしているし、とりあえずおかしくは見えませんでした。ところがですね、念のためgrepしたら…」
T「ぐれーぷ？」
P「…リポジトリ横断して全検索したら、まったく別のアプリでtotal_hoursがヒットしました。更新していないバージョンで、どうやらIE対応のもののようです。現状稼働しているのか、よくわかりません」
プロ之さんはツールを駆使して、関係ありそうな箇所を絞り込みました。こうしたツールは開発中や、特にデバッグ時によく使うものです。
T「すごい！ よくそんな詳しく調べられたね」
P「基本的なことですよ」
T「ホームズみたい！」
P「カンバーバッチみたいですか？」プロ之さんの顔がちょっと嬉しそうになりました。
テス緒さんが「あ、ロバート・ダウニー・Jr.だと…」と言いかけるとプロ之さんの顔が曇ったので、あわてて話題を変えました。※1
ポイント:
- 問題の原因となり得る箇所を特定するために深く掘り下げるアプローチがある
- 開発者が原因追求に利用するツールはテストや調査でも利用価値がある
※1 著者はジェレミー・ブレット派です。
テスターが見逃さない話
テス緒さんはログを画面共有で表示しながら説明しました。「テストケースを増やすのはやめにして、表示がおかしいあたりのデータが登録されたときのログを500行くらい絞り込んで眺めたのね」
P「ただ眺めるんですか？」
T「他の仕事もあるからずっと眺めてたわけじゃないけど、ときどき引っ張り出してね。何度も見てると、だんだん“引っかかるな”って感じがしてきて、そうしたら！ 気がついたのよ」
P「ただ眺めるだけで？」
T「っていうか、絞り込んだログだけ眺めても何もわからなかったんだけど、別の条件にしたらログの出方が違っているのに気がついて。ほとんど同じなんだけど、あっちは”recorded”なのに、こっちは”record”になってて、スペルが違うでしょ。表示がおかしくなるのは、”record”って出ているときだけみたいで」
P「すごいですね。執念というか」
T「気になったから気にしてただけだけどね。これ、なんでだかわかる？」
ポイント:
- ログやデータなどを広範に調べ、問題の起きる条件を追求するアプローチもある
- 意味がわからなくても些細な違いや違和感を拾い上げると、突破口になることもある
ついに問題を突き止めた！
プロ之さんは少し考えて答えました。「わかりませんが、調べればわかると思います。その部分はログの固定文言だと思われるので、検索すればすぐ見つかると思います」
プロ之さんはそう言いながらもうキーボードを叩いています。テス緒さんはプロ之さんがどう作業を進めるのか知りたくなって、画面共有してもらうように頼みました。
T「タイピングすごい速いんだね。あ、検索ってコマンドで実行するの？ いつも検索ツールを使ってるけど、そっちの方が早いね」
P「ログを検索するのとコードを検索するのは違いますよ。でも良かったらあとで教えます。それはともかく、ログに”recorded”ではなく”record”と出力する箇所が見つかりました。total_hours更新で絞り込むと…やった、1箇所だけです。それに…先ほどのIE用サービスの中です。これはビンゴですよ」
T「じゃあそのサービスを使っている画面を使えば、現象を再現できるかも！」
プロ之さんはIE用のサービスを手元の開発環境で立ち上げて、テス緒さんは以前に作ったテストケースを実行しました。数件実行したところで、テス緒さんが声を上げました。
「出た！ できた！ こっちの画面で入力して、あっちの画面だと9.9だけど、この画面は10.0になってる。やったよプロ之さん！ 突き止めたよ！」
「やりましたね。古いモジュールが原因だったんですね。おめでとうございます」プロ之さんは表情はあまり変えず、しかしいつもより早口で言いました。
テス緒さんはくちびるを尖らせて言いました。「何言ってるの、おめでとうなんてひとごとみたいに。プロ之さんと私で一緒にやりとげたんだから、もっと喜んで！ ほら、やったーって言って！ やったーって」
「確かにそうですね。私も嬉しいです。でもやったーと言う必要は…言わないといけないんですか？…はい、では、や、や、ヤッター」
こうして、テス緒さんがテスト中に発見した不思議な挙動の原因が判明しました。まだ開発環境で確認しただけなので、本番環境でも同じ結果になるか追加の確認が必要です。また原因がわかったら、修正して正しく動くようにすることになります。問題の性質によっては、修正が難しいことがあったり、影響が軽微なら修正不要と判断する場合もあります。プロ之さんは既に、どう修正を進めるのが良さそうか考え始めています。
2人はここでいったん作業を終えることにしました。1週間後にまた集まることにして、それまでに本番環境での確認を進めたり、IE対応サービスがなぜ最近修正されていないのか調べたりしてくることにしました。テス緒さんもプロ之さんも、大きな壁を乗り越えた充実感と自信に満ちあふれて、明るくセッションを終了しました。
ポイント:
- 開発者にもテスターにもそれぞれの直感があり、両方を組み合わせて使う
- おたがいのスキルや経験、人間性を尊重しあうと能力を発揮できる
真の問題とは？(次回に続く)
テス緒さんはIE対応サービスを使うために、過去のテスト資料を調べていました。そこで見つけたテストケースには、なんと「IE対応終了のテスト」として、画面がすべて使えないと確認するテストケースが書いてありました。実際に試しても、本番環境ではIE対応サービスにアクセスできません。
テス緒さんは考えました。「(問題がある箇所を見つけたのに、アクセスできないんだったら実際には問題が起きるわけがない！ まったく違うところに問題があるのかなあ？ それじゃあ調べたのが全部ムダになってしまう。どうしよう…)」
同じ頃プロ之さんは先輩の開発メンバーから、IE対応は1年以上前に終了しており、サービスも停止していると教わっていました。それを聞いてプロ之さんも考えます。「(終了しているサービスなら問題は起き得ないし、修正しても意味はない。修正の検討は時間の無駄になった。ここまでの調査も無駄と言える。これ以上、時間を使う意味はない)」
本連載の次回では、2人がついに真の問題に到達し、連載も最終回となります。
