テスト駆動開発のスタイルを取り入れているもののテストのことはあまりよくわかっていないプログラマーと、テストへの熱い情熱をもちつつプログラマーの事情はわかっていないテスターとが、小さな障害の発見をきっかけとして出会い、役割の壁を崩しながら少しずつ協調するようになっていく、小さなお話です。
登場人物
プロ之 … プログラマー
テス緒 … テスター
前回、テス緒さんがテスト中に偶然システムのおかしな挙動を見つけ、調査をして、プログラマーのプロ之さんに相談しました。問題意識は共有できましたが、プロ之さんはいまは手が離せないとのことでした。その後、テス緒さんがどう過ごしているか、見てみましょう。
テスターが網羅しまくる話
「50.0…49.9…50.0…49.9…」
テス緒さんは困っていました。このあいだ見つけた表示のちがいについて、同じ現象を起こせずに行き詰まっているのです。プロ之さんと話した後、自分の仕事もこなしながら、ときどき時間を見つけて既存テストケースを見直したり、自分でテストケースを増やしてみたり、思いついた入力を試したりしていました。しかし再現の方法は見つかっていません。
そうこうしているうちにテス緒さんも作業が立て込んできて、すぐに1週間が過ぎてしまいました。火曜日、プロ之さんのほうから、テス緒さんに声をかけてきました。今日明日なら30分くらい時間があるから話そうというのでした。
テス緒さん(以下、T)は自分が試したことを説明しました。「表示がおかしくなる入力のテストパターンを考えて、入力してみたけど、おかしくならないんだよね」テス緒さんはそう言って、自分が作ったテストパターンを見せました。
プロ之(以下、P)「183パターンもあるんですか？」
T「いろいろ考えてみてね。0秒とか1秒とか59分59秒とか境界値周りはあやしいし、日またぎや月またぎ、年またぎも問題になりやすいでしょう。画面でバーの位置を1ピクセルだけずらしたり、ウインドウやフォントの大きさを変えたり、遷移やリロードしながら入力したり。別々のブラウザで削除したり更新したり。触っているとこれはどうかな？ あっちならどうなる？ ってアイデアが湧いてくるんだよね」
P「そんなにたくさん観点あるんですね」
T「でもおかしくならない。他のパターンも考えないといけないなあ」
プロ之さんが突然目を見開いて大声を上げました。「テス緒さん！」
テス緒さんはびっくりして答えました。「なんですか！？」
P「もしやと思いますが、183件のテストは手で入力してませんよね？」
T「したよ？ 手で」
沈黙が5秒間続き、ネットワークが落ちたかなとテス緒さんが心配になったとき、プロ之さんが言いました。
P「開発チームはテストを自動化しています。テス緒さんにも役に立つと思います。いま説明します」
T「えっ、でもプログラムは書けなっ」
テス緒さんが言うのを待たずに、プロ之さんは自分の画面を共有しました。表示されたのはプログラミング言語で書かれた自動テストのコードです。テス緒さんはコードは読めませんが、テストデータらしき数字が並んでいて、日本語の補足も書いてあるのでなんとなく把握できます。
テス緒さんはテスターの目で見て、いろいろなパターンのテストケースがあるものの、十分な網羅ができているか判断が難しいと感じました。テストケースの内容も人工的というか不自然で、現実的なケースを足したいと感じます。テス緒さんはそう感想を言いました。
ポイント:
- テスト設計技法を用いて、さまざまなテストケースを作れる
- テスト駆動開発や探索的テストなど、手を動かしながら作ったテストケースは、その人やその作業独自の内容になる
プログラマーだってするテストをテスターもする話
P「テスト駆動開発で書いたテストなので、ロジックの確認がメインで、網羅は不十分だと思います。でもテストチームが十分なデータで網羅してくれるので、これでいいんです。実行すると、ほら、結果もこう整理されて表示されるのでわかりやすいんですよ」
T「え、すごい一瞬で終わったね。画面からいちいち入力しなくてもテストできるんだ！ テスト自動化すごい、やりたい…」
プロ之さんはうなずいて言いました。「できますよ。環境はコンテナ化してるから誰でも手元で動かせるし、テストケースを加えるだけなら、ここのパラメータをコピペしていじって実行するだけで…ほら」
プロ之さんは開発環境構築とテスト実行の手順を伝え、やり方を簡単に教えてくれました。どの画面にどのテストケースが対応していて、テストを足すならどこに書くといいのかも説明しました。そしてプロ之さんにしては珍しく、ためらいながらこう言いました。
P「それで…お願いなんですが…いや違うな、こうするといいのではないかと思ったのですが…テス緒さんやテストチームのテスト観点を、勉強…参考…その、教わりたいと思うんです。さっきの183件のテストケースも、どうやったら思いつくのか知りたいです。ですので、テス緒さんもコミットしてください」
T「ええ…ごめんなさい。もっと本気でコミットしないとだめか…」
プロ之さんがあわてて手を振り、その手がマイクに当たってボッという音がしました。「そのコミットじゃないです！ すみません。テス緒さんの観点でテストコードを書いて、共有してほしいと言いたいんです。gitは使ってないですか」
コミットという言葉が貢献や約束の意味ではなく、書いたコードを共有するためのgit commitコマンドのことだと2人は認識を合わせられました。そして相談して、テス緒さんが書いたテストを共有しつつ、ときどきテストケースの書き方を聞いたり、テストの意図を話したり、レビューしたりすることにしました。そしてテス緒さんは早速環境を作り、いろいろ引っかかりながらも自動テストをさわりはじめました。
ポイント:
- テストツールやテスト自動化を、役割の異なる人どうしをつなぐ架け橋にできる
- 共通の言葉を使いコメントも書いて、テストケースの意図や観点を把握しやすくできる
それは誰の問題？
その2日後、テス緒さんはテストチームリーダーから雑談に誘われました。
「テス緒さん、おつかれさま。最近どう？ 忙しいですか？」
「そうでもないですよー。むしろ余裕あるんで、前に気になったイシューの件を調べてます」
それを聞いたチームリーダーは、笑顔のままで目だけが恐くなりました。「そうだったんですか。それはちょっとよくないですね」
テス緒さんは息を呑みました。
今回のお話は、ここまでになります。テス緒さんはテスト技術者として、テスト技法を活用してテストケースを探しました。決まった観点からテストケースを作るだけではなく、自分で操作したり、使われている場面を想像したり、今までない観点を見つけようともしています。なかなか執念深い、ということもできそうです。
プロ之さんはテスターのそんな入れ込み方に感銘を受けて、プログラマーがテストをどう扱っているか説明し、そのテストをテスターのテス緒さんと一緒に良いものにしようと考えました。今までテストチーム任せにしていたところに、興味を持ったのかもしれません。
そんな2人はもはや、プログラマーとテスターという役割に縛られていません。それぞれが持っている知識やスキルを組み合わせて、ひとつの問題にチームとして立ち向かっています。「わたしの問題」でも「ひとの問題」でもない、「わたしたちの問題」です。今回の一つの問題だけでなく、今後起きるであろうプロダクトの問題にも、同じように立ち向かっていく基礎になることでしょう。
ポイント:
- お互いの知識、経験、スキル、働き方に興味を持ち、学ぼうという姿勢を持つ
- 相手の領域に一歩踏み込む勇気を持つ
次回は、そんな2人の前にあらたな障害が現れます。テストチームリーダーはテス緒さんにそれは大事なの？と問いかけます。テス緒さんはなんと答えるのでしょうか。
