チームでテストを共有した話（テストの地図）

探索的テストを含む「テスト」をチームで共有したときに、やってみたことを紹介します。キーワードはこの４つ。

・テストの地図（今回はこれ！）
・ペアテスト
・テストの渡航履歴
・朝会とテストの夕会

チームでテストを共有した話
「テストの地図」はテストチャーター（のようなもの）を想像してください。
つくりはじめるタイミングは、ざっくりしたユーザー要件と、大雑把な仕様が出てきて「これから○○という機能を作りはじめるよー」というくらいのときです（プログラマーが実装してからだと遅い）。「テストの地図」は、国境と国名と主要な都市くらいしかない、白地図のようなものから、はじまります。

「こんなものを作るんだよね？」
「ここはこんなふるまいをするのかな？」
「仮にユーザーがこういう使い方をするとして、どうなるのがいいんだろう？」
「これまでのデータの持ち方を変えたりする？」
「前にこんなバグ、あったよね」
「もともとある○○機能には手を入れないの？」
「こんな問題が起きそう」
「わたしならこういうテストをしたくなるかも」

これからつくるモノのイメージを、チームのみんなでディスカッションしながら具体化していき、白地図にどんどん書き込んでいきます。当然（あれ、ここの仕様はどうなっているんだろう？）と分からないところも出てきます。それらは「不明点」として地図に残し、仕様が明らかになった時点で書き換えていきます。

このディスカッション自体が「テストの共有」です。わたしはテスターなので「テスト」を共有したつもりでいるのだけど、これから開発するモノに対してのすべて（要件、機能仕様、ふるまい、テスト、スケジュール、リソース、みんなの疑問 etc）を共有しているのかもしれません。こう書いてみると当たり前というか（なあんだ）という感じですが、こういったアナログで地味な活動がとても大事。他にも良いことがあるので、列挙しておきます。

完璧な仕様(書)がなくてもはじめられる
だから「ドキュメントがないからテストできない」「テストの計画、設計ができない」という事態に陥りません。わたしは自社製品の組み込みシステムを開発しているからできることなのかもしれないけど。でもそんな環境でも、開発チームとテストチームが分かれていたりすると、そういうことが容易に起きたりします。ドキュメントができてからだと遅いんですよ。完璧なソフトウェアがないように、完璧なドキュメントもないんです。（ああ、こんなことを書いたらまた叱られちゃうかも、、、）

暗黙の要件が見つかる
仕様書には明記されないけど一般的にはこう動くべきだよね、といったものを「暗黙の要件」と（わたしは）呼んでいます。この「暗黙の要件」について考えたり、実装そのものや、それに関するテストがポロッと抜けてしまうことがあるんですよね。例えば、マウスダウンのときに動作すべきなのか、それともマウスアップのときに動作すべきなのかとか、そういうの。

つくるモノの要件や仕様がガシッと決まってから考えはじめると、どうしてもそっち（決まっているもの）にみんなの目が行きがちなのかもしれない。

心配ごとが次の行動の入力になる
起きたら嫌なこと（心配ごと）は、それが「起きない」要件なり、テストに展開して、地図に追加していきます。テスターの心配ごとを聞いたプログラマーは、それが起きないように設計、実装していくだろうし、テスターはプログラマーの心配ごとが起きないことを試すために、どうテストしていくのかを考えたり、準備する。データの互換性が心配なら「今のバージョンでデータを取っておいてテストデータにしよう」「どのような種類のデータを取っておけばいいかな」のようにね。

おわりに
「テストの地図」を使い、チームのみんなでディスカッションをしながら「テストを共有」した話をしました。「テストの地図」はディスカッションするためのツールです。「テストの地図を作ること」を目的にしてしまうと、うまくいかなそうなので注意してくださいね。

そうそう「テストの地図」を使ってテストを共有したのは、わたしがいま所属している（ハズれ値かもしれない）チームではない！ので、導入しやすいプラクティスのひとつかもしれないな、と思っています。

「テストの地図」について興味のある方は @miwa719 にメンションしてください。4月23日(土)に開催するとちぎテストの会議に参加していただけると、もっと丁寧にお話しできます！

今日は何の日？

今日は２月２２日。猫の日なんですってねー。このブログのタイトルも猫っぽいでしょ。こちらの洋書のタイトルをそのままそっくりまねっこです。

Cat Getting Out of a Bag and Other Observations

探索的テストを記録することについて

昨年クックパッドでお話をさせていただいたときに複数の方から「Testingの記録は残しているのですか？」と質問がありました。そのときは「残してません」と回答したのですが、ずっとどこかで気になっています。（以降、Testingは「探索的テスト」と記載します）

わたしたちのチームでは「探索的テストを記録すること」は求められていないですし、仮にですよ、今日から突然記録しはじめたら「なにやってんの？」「miwaさんがおかしなことをやりはじめた！」と大騒ぎになるのは目に見えています。だから、これまで考えてみることすらしなかったのですが、あれから二ヶ月たった今でも、どこかで気になっているのは、もともと「探索的テストが好き」で、だから「探索的テストをもっと知りたい」ということなのかもしれません。好きな人のことは、どんなことでも知りたくなるのと、きっと同じです。

「探索的テスト」をテストケースに換算してみる

わたしが行う探索的テストをテストケースに換算したら、いったいどれくらいになるのか。考えてみました。

１日にクローズするのは４チケットくらいでしょうか。そのほかに、テストしたけど問題があってクローズできないチケットや、まだストーリーとしては完了してないけど、朝会で聞いたことについてピンポイントで心配ごとがあるから、いまできてる部分だけにフォーカスして触ってみるチケットなどがあります。
それらを全部合わせて１日８チケットとしましょう。
１チケットあたり４探索的テストケースとすると、１日に３２個の探索的テストケースをまわしていることになります。

これをお読みくださっているあなたとわたしの１チケットの考え方や、テストケースの粒度はおそらく違いますので、なんのメトリクスにもなりませんが、以前あるシステム開発で、探索的テストではなく、事前にテスト設計、仕様化を経て出来上がったテストケースを使ってテストしたことがあります（以降「テストケースを使ったテスト」と記載します）。このとき、わたしは１日で２０テストケースくらいしかできなかったと記憶しているので、それと比較すると探索的テストで１日３２テストケースというのは（わたしの中では）まあまあ妥当な値だな、と思っています。

「テストケースを使ったテスト」のほうが実施できるテスト数が少ない理由

探索的テストとテストケースを使ったテストでは、それぞれのテストの性質も違いますし、そもそも同じテスト対象で比べているわけではないので、数値だけを見てあれこれ言うのもなんですが、差分の１２テストケースは何なのか。ちょっと気になります。

テストケースを理解する時間
テストケースを使ったテストの場合は、これは当たり前のことですが、まず目の前にあるテストケース（手順、期待する結果など）を読み、どのようなことを目的としたテストなのかを理解する時間、がどうしても必要です。探索的テストは、それらがすでにあたまの中にあるため、そのような時間はいりません。

探索的テストもしていた
テストケースを使ったテストをしたあと、やはりわたしはテストケースに書いてないことを、勝手に追加してテストしていたように思います。となると１テストケースにかかる時間は自ずと増えますよね。「miwaさんはテストを消化するのが遅い」と思われていたかもしれませんが、テストしているとどうしても気になることが出てきてしまう。そのまま放っておくことはできません。

「探索的テスト」をテストケースに展開してみる
いま、わたしが行っている探索的テストに「探索的テストの記録」を入れると、こんな感じになりそうです。

①チケットを読む
タイトル、概要、これまでの活動内容を、ざっと全部読んで、ああ、こんなことあったな、と頭の中を整理する。

関連するチケットがあれば、それも読む。気になるキーワードでチケットを全文検索して、ひっかかったチケットを拾い読む。これは探索的テストの最中に必要であれば、キーワードを変えて何度でも実施する。

②テストを読む
そのストーリーが「正しく作られたこと」を確かめることのできるテストが、チケットに書かれている（プログラマーが記載）ので、それを読む。

③テストを実行する
書かれているテストを忠実に実行する。
テストの正しさ（ストーリーと合っているか、テストの書き方がわかりづらくないかなど）もついでにテストする。誤りや不足があれば、担当のプログラマーに直してもらう。

④探索的テストを実施する
③で手を動かしてテストしている最中に、次に試してみたいことが浮かび、それがあたまの中にある。それを実施する。

⑤探索的テストを記録する（想像）
④でテストしたことを、ひとつひとつ展開し記録する。
チケットに書いてあるテストとは別のセクションに追加テストとして「なにを確認することを目的としたテストなのか」「前提条件」「テストの手順や方法」「使用するテストデータ」「期待する結果」などを書き込んでいく。

以降、そのチケットの探索的テストが終わるまで、④と⑤の作業を繰り返す。

想像してみて思うこと
実際にやったわけではないので、なんとも言えませんが、記録することにより探索のための思考がその都度中断されてしまうことは確かで、これについてはかなりストレスがかかりそうです。
記録しないときと同じようなテンション、思考回路が保てるのか？こぼれ落ちてしまうテストはないのだろうか？（バグを見つけるためにテストしているので、同じような探索的テストができない＝バグを取りこぼすかもしれない、と考えてしまい、不安な気持ちになります）

もうひとつ心配なことがあります。これはわたしだけかもしれませんが、テストケースを書くのってわりと時間がかかるのですよ。テストケースだけではなく、あらゆる文章はそうだけど、あとから誰が読んでもわかるように書くことって、とても難しい。
完璧なものは書けないにしても、合格点をもらえるくらいのものは書きたい。これには罠もあって、いくらでも時間がかけられる作業は、たいてい危険です。（このブログもそうです）

テストケースを書いたらそれで終わりではないですよね。その書いたテストケースを他人が読んで、わたしがやった探索的テストを再現できるのか（できそうか）を確認すると思います。数分前にも同じ探索的テストをしてるけど、きっと書いたテストケースをはじめて見るつもりで確認するんだろうな、と。そして、テストを書いてるときや、その書いたテストを確認する最中にも、わたしは新しいテストを思いつくのだろうな、と。

「探索的テスト」を記録することの目的とは
さて、１探索的テストケースを記録して記録したものを確認するのに１５分かかるとすると、単純計算で１日にできるのは１６探索的テストケースになります。記録しないときと比べて半減ですね。

組織やチームの中で、記録したテストケースを使って達成したい「何か」があり、探索的テストを半減してでもやる価値があると判断されたのなら、それもありなのかもしれません。

「探索的テスト」の目的とは

はじめにも書いたように、わたしたちのチームでは、探索的テストを記録することは求められていないし、どちらかというと、既にあるテストケースではなく「チームやテスト対象の今の状態」に応じた、誰もまだやったことのない「未知のテスト」を求められているように思います。それは、探索的テストを含む「テスト」で「未知のバグを見つける」ということを目的にしているから、とも言えます。

探索的テストは「その人にしかできない特別なテスト」だからこそ価値がある、とわたしは思っていますが、一方で「その人にしかできない」ことがデメリットのように語られてしまうこともあります。属人性というものですね。

わたしたちのチームでは、テスターがどのようなテストをしているのか、どこを心配しているかは、ふだんから話してますし、プログラマーもテスターも同じ場所で作業しているので、やってることが全部丸見えです。隣に座っているテスターがどんなテストをするのか見ていたり、見られたり、一緒にテストすることもあります。

「miwaさんならこういうテストをしてくるはずだ」とプログラマーが予想することもあるらしく、わたしのあたまの中にしか存在しないと思っていた探索的テストもチラチラ見えるものなんだなあと感じています。

おわりに
属人性によることのデメリットも、わからないわけでもないのです。探索的テストに関わらず、良いテストや考え方は、より多くの人に知ってもらいたいし、活かしたいですよね。

今回は、探索的テストを（厳密に）記録することを想像して書いてみましたが、テストチャーター（のようなもの）を使い、探索的テストをチームで共有したことがあり、これもなかなか面白かったので、次回はこれについてお話ししようかと思っています。

ペアテストと情報の共有について

朝会のあとの二次会で、Sさん（テスター）が、最近追加したとある機能がものすごく心配でたまらないと言う。新しい機能というのは、なんていうか若いから、もうそれだけで危なっかしいのだけど、そんなことを言うSさんの顔を見ていると”なんとなく心配”というよりは、もっと具体的な何かを心配しているようだった。

「Sさんの心配事をわたしも実感したいから、一緒にテストしよう！」

結果から言うと、ふたりで1時間くらいテストして、かなり深刻な問題を3つ見つけ、それはすぐに開発側に伝えられた。

予想通りSさんはかなり具体的なテスト（テスト対象に与える複数の条件や状況）をすでに思い描いていて、ペアテストを通してわたしはSさんの心配事を実感できたし、こんな問題が起きるなら…と、わたしはわたしで新しい心配事が湧いてくる。もちろんちゃんと動いたケースもふたりで見ているから、それはそれで安心した。

「早めに見つかってよかったね」
「でも、これまだまだバグでそう」
「でるよね」
「今日のが直ってきたらまたやろうよ」

そうそう、先月クックパッドでテストの話をしたときの懇親会で、なんと４名もの方から「（探索的）テストの具体的な内容は、どこかに残して共有されているのですか？」と聞かれたんだっけ。あのときは「バグならチケットに残るけど、正しく動いちゃったやつをひとつひとつテストケースに再展開して、改めてどこかに書き残すことはしてないなあ」と言ったのだけど、今回の場合だと、ペアテストの様子は数名のプログラマーにも話しているし（ああ、こういう日常で、それぞれの記憶の中に残し合ってるんだよなあ）と思った次第です。

情報の共有ってなんだろうね。

テストを漢字一文字で表すと？

今年もまた一年の世相を漢字一字で表現する「今年の漢字」の季節がやってきましたが、先日秋山さんがこんなツイートをしてたので、わたしも考えてみました。

@akiyama924 わたしは「知」にしておこっと。これ毎年12月にやるといいですね。

— miwa (@miwa719) 2015, 12月 5

twitter.com

テストを通して「知ること」「知れること」が多いこと。それらがテストするときの入力になっていること。テストするときに知覚（視覚、聴覚、嗅覚など）諸々から伝わってくる感覚を大切にしていること、あたりから「知」を選んでみました。

「テスト」という言葉自体が広義であり「漢字一文字でなんか表せない！」というのが正直なところですが、だから正解もなく、気楽でとてもよいですね。来年もまたこの時期に考えてみたいと思います。

モネ展

東京都美術館で開催されている「モネ展」をみてきました。とても大きな睡蓮の絵は、近くから見ると「淡い色彩の何か」でしかないのに、数歩下がって全体を眺めると、水面に映る空や、木々の影、池そのものがはっきりと浮かび上がってきます。絵自体はもちろん無音ですが、空や風や水の音が聴こえます。キャンバスを斜めから覗き込むようにして見たときの、絵の具の凹凸やその筆のタッチから、モネ自身がどのような気持ちで描いたのか、想像することができます。

見えないものを見る、聞こえない音を聞く、作者からのメッセージを想像して受け取る。

あれ？ Testing に似ていませんか？

こちらの画像は http://www.ntv.co.jp/monet/ からお借りしました

miwa style 裏話

connpass.com

ゲストとして @m_seki と一緒に登壇させて頂きました。初めてお会いする方も多く、いろいろ話せて楽しかったです。

Testingを伝える、ということの難しさ
わたし(たち)の Testing の話しをするにあたり、どのように伝えたらよいのか、とても悩みました。だってテスト対象を触っていると秒速でテストを思いつき、もうその瞬間に手が動いているのです。

これはもしかしたら「脊髄反射」というやつかも！と思って調べたら「大して考えず反応してしまうこと」を慣用的に「脊髄反射」というらしい。「大して考えず」の意味が時間的なものを指すのか、思考の深浅を指すのかよく分からなくて、結局スライドやトークで「反射」という言葉は使わないようにしました。

話を元に戻すけど、みなさんが一度は聞いたことのある「テスト分析」とか「テスト設計」のようなフェーズにリンクさせながら、探索的テストっぽい話しをしたら理解しやすいのかもしれない、それは分かっていたのですが、そうではないんですよね。それだと実体と合わないというか、嘘っぽくなっちゃう。

わたしの脳内で起きていることは何がきっかけになっているのか、そのテストを思いつけるのはどうしてなのか、いきなり目の前に現れたおかしさについて「あれ？」と思えるのはなぜなのか、というところを聞いてもらえば、もしかしたら半分くらいは伝わるかもしれない…。そんなことを思いながら「ひらめきのヒント」のようなものを、ひとつひとつ言語化していきました。

わたし自身、朝会からヒントを得ていることがとても多く、このことは言語化する前から分かっていました。「朝会」と「Testing」は別物のようにも見えますが、これはお話しする上で外せないなぁと思い、以前書いたブログから抜粋することにしました。

朝会のこと
そうそう、朝会の時間が長い！と感じた方もいらっしゃったみたいですね。二次会の15分間を入れて45分間。わたしたちの朝会は、単に顔合わせをして昨日や今日の作業を確認するだけでなく、その作業内容にまで鋭くフォーカスしていきます。
みんなで作り方(設計)のレビューのようなこともするし、必要があればコードも見ます。そもそも要件自体が怪しいんじゃないの？なんて話しもします。扱うチケットの数は40くらい。それを30分で回すのですから、かなり濃厚で濃密な時間が流れます。今回はっきりと分かりましたが、わたしたちは朝会で Testing をしてたんですね。そしてわたしは朝会が長いと思ったことは一度もありません。

ハンコでアソンダ
当日使用したスライドがこちら（P.25～60）です。脳内にひらめきのヒントがどんどん溜まっていく感じを表現したくて「ハンコでアソブ」を使いました。

このハンコ、とても可愛くて、どれを使おうか選んだり、配置したりしてると楽しくて、それだけで時間があっという間に過ぎてしまいます。時間がないときに使うと大変危険です。

今回たくさんの方に応募していただき、とても嬉しかったのですが、落選してしまう方も当然いらっしゃる。せめてスライドを見ていただき、わたし(たち)の Testing を少しでも感じてもらえたら、という思いもあり、説明も多めに入れたつもりです。分からないことがありましたら Twitter で聞いてくださいね。

当日のこと
当初わたしの発表は15～20分の予定だったのですが、そんなこんなで到底収まらないボリュームになってしまいました。当日の打ち合わせで話す順番を急遽変えてもらい「懇親会のターンで勝手に喋ってる」作戦にしたのですが、予想？に反してみなさんちゃんと椅子に座り、分かりづらい話しを理解しようと聴いてくださっている。それがこちらにも伝わってくるんです。とても嬉しかったな。ありがとうございました。

お話したいことはもっともっとありました。今回の内容をより具体的なテストに落とした例とかね。いつかどこかで話せたらいいなと思っています。