CAT GETTING OUT OF A BAG

What the tester is thinking.

テスターが開発現場にいることのメリット

MTBF（平均故障間隔）とかMTTR（平均修理時間）とか、世の中には品質をあらわすための指標が数多く存在するようですが「バグを発見してからプログラマーに伝わるまでの時間」という指標は、あるのかな？

わたしたちのチームは、これが圧倒的に早いです。

といっても、どこかと比較したことはないのだけど、どれくらい圧倒的に早いのか、最近のツイートに補足しながら説明します。

テスターが開発現場にいるときの場合


テストしていると（はて、これはこういう仕様なのか、それともバグなのか？）と思うことがあります。その点、クラッシュは分かりやすいですよね。

一瞬で恋におちるような経験はないのだけど、クラッシュも何の前触れもなく突然起きることが多いので、まずは心を落ちつかせて、画面全体をスクリーンキャプチャします。

その後、テスターは担当のプログラマーに連絡し、クラッシュしているナマの状態を見てもらいながら、それまでにやっていた操作や、クラッシュする直前の状況を話します。プログラマーはエラーログや解析に必要なデータを採取していきます。テスターがバグを発見してからここまで５分くらいです。

それからテスターは、システムを再起動する間にチケットを発行します。このときはあるストーリーについてテストしていたので、既存のチケットに追記しました。（記載時間１分）

そして休憩したあと、別のテストに取り掛かります。

 


このときはですね、プロの無職が騒いだので、周りで作業していたプログラマーがわさわさと集まってきました。（担当のプログラマーは不在でした）
みんなで（メモリーリークする処理は）どこが考えられる？のような話をしていて、そのうちにプログラマー（←もうひとりのエース級）がコードを見ながら、解放もれの箇所とリークするであろうサイズを、実際の増加量と比較して、特定。

プロの無職が騒ぐ１分くらい前に（あれ？メモリー使用量がどんどん増えていくぞ）と思っていたので、テスターがバグを発見してから、プログラマーが原因を特定するまで５分くらいです。チケットには、それまでメモしていた、機能を実行する前と実行後のメモリー使用量（と増加量）を３回分、記録しました。（記載時間２分）

 

テスターが開発現場にいないときの場合

「バグを発見してからプログラマーに伝わるまでの時間」は、比較にならないので省略しますが、もしわたし（テスター）が開発現場から離れた場所（組織やプロセス的にという意味で）にいたら、どのようなことをするのか想像してみます。過去にそういうチームに所属していたこともあるので、かなりいい線いってると思う。

はじめのケースでは、クラッシュした直後、プログラマーが解析するのに必要なエラーログなどを取り、その他に参考になりそうな情報（もし何かを登録するような機能だった場合は、その登録処理自体はうまくいってるのか／いってないのか、など）を確認します。なお、わたしが思う「参考になりそうな情報」なので、ハズしている場合もあります。

その後、システムを再起動し、現象が再現するかどうか、もう一度同じような操作をしてみるはずです。（テスターとしては「確実に再現する手順」をプログラマーにお届けしたい）
で、すぐに再現すればよいのですが、単純な操作手順ではなく、そのときのシステムの状態や状況に起因していたりすると、再現しないのですな。わたしは非再現のバグに関しては（どちらかというと）執着するほうなので、再現するまでがんばっちゃう。プログラマーがエラーログを見たら、すぐにわかるかもしれないのに、ね。

次のメモリーリークのケースは、このときは３回でやめてますけど、念のため(?)１０回くらい実施してメモリー使用量の「ばらつき」を見たりするかもしれないですね。増加量の平均値とか出したりしてね。パッと見てわかるようにグラフとか書いちゃうかも。それから、与えるデータの大きさによってリークするサイズが変わるのかもしれないとか、いくつか気になることを試すと思います。すべては「バグの解析に役立つかもしれない」と思ってやるのですが、ハズしていることもあるよね。

そうやって試すことが増えていくと時間もかかりますし、報告する内容もそれなりに増えていくので、チケットを書く時間も当然かかります。


さいごに

特にまとめませんが、テスターが開発現場にいないことのデメリットというよりは「もしテスターが開発現場にいると、こんなメリットがあるのよ！」ということを、少しでも感じてもらえたらいいな、と思っています。

 

チームでテストを共有した話（ペアテスト）

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

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


ペアテストはその名の通り２名（以上）で行うテストですが、テスターだけのものではありません。一般にはテスター×テスターの組み合わせが多いのかもしれませんが、わたしは同僚のプログラマーと一緒にテストすることもあるし、開発環境の入っていないテストPCの前に２、３名のプログラマーが集まり、みんなでテストしているのも、よく見る風景です。


ペアテストはもうそれ自体が（実施者間での）テストの共有であり、ペアテストの実施内容（どのようなテストをして、どうだったのか）は、ペアテスト直後に一番知りたがっている人たちに話しますし、朝会やテストの夕会、また日常の会話の中でも話題にしています。

ですので、今回はテストの共有というよりは「ペアテストそのもの」について書いてみたいと思います。


どんなときにペアテストをするのか
わたしがこれまでペアテストしたのは、こんなときです。


ヤバいやつがコミットされたとき
「ヤバい」という言葉は、あまり使いたくないのだけど、他に言いようがない…というか、この場合はぴったりハマるので使います。ヤバいやつですよ、ヤバいやつ。プロセスやスレッドが何本も走っていて、複数の装置が絡んでいて、これまでも似たような機能で多くの不具合が見つかっていて、、、もうみんなが「これはヤバい！」と思ってるやつです。

そんなヤバいやつがコミットされたと知った朝会のあと、同僚（テスター）に目で合図します。

「今日やろう！」
「何時からやる？」

ペアテストはお互いに試してみたいことを、順番にやっていくことが多いです。（わたしがそうであるように同僚もまた、朝会などに参加しながら、試してみたいことを日々メモしているようです。）

わたしたちのテスト対象は、いくつかの装置が絡んでいて、注目するのは目の前のディスプレイモニターだけではないことが多いです。ペアテスト中は二人とも、自分が何をどう操作しているのか、装置にどのようなパラメータを与え、何を観察しているのか、いま何がどうなっているのか、それは正しい動きなのか、そうではないのか、お互いの言葉を聞き、相づちを打ちながら、ひとつのテストが終わるまで、ずっとしゃべり続けています。ふたりで同じモニターを見ていても「これはこうだから大丈夫」と、いちいち指を差し、声に出します。

そして、その結果（手応え）によって、確認する内容や順番を、その都度相談しながら変えていきます。

同僚とペアテストをすると、かなり高い確率でバグが見つかるので（ヤバいやつなので予想通りだから驚かない）「早めに見つけられて良かったねー」とホッとするのですが、他にも良いことがあります。

ペアテストをすると、同僚が何を心配していて、それをどのような手順で確認しようとしているのか、どこを気にして、何に注目しているのか、テストの息づかい、テストに関するノウハウ、テクニックのようなものが、それはもう手に取るように分かります。テストを共有している感覚は、まさにここにあり、とても勉強になります。（同僚もまたわたしから何かを得ていると良いのですが、どうでしょうか。）


テスト対象を知らないとき
現在のチームに異動したての頃は（ある程度のドメイン知識はあったものの）テスト対象のシステム、ソフトウェアについては、ほぼ知らない状態でした。

毎日１時間、プログラマーのYさんに「これはどのような機能なのか」を、レクチャーしてもらいながら一緒にテストしました。毎日テーマを変え、２か月くらい付き合ってもらいました。この間に、すこしずつテスト対象を理解していき、最低限のテストができるくらいにはなったと思います。ありがたかったなー。


いじめ方の程度を伝えるとき
例えば、テストケースに「◯◯ボタンを押してモードを変えた直後に◯◯スイッチを素早く押す」と書いてあったとします。おそらくテストする人によって、操作する速度が変わってきますよね。

このテストは「◯◯ボタンを押してモードを変えると、接続されている別の装置に命令が飛んでいき、その装置の状態も変わるのだけど、その状態が変わりきる途中（隙間）に、別のルートから◯◯スイッチが押されたよ、という信号が送られても、状態はまだ変わってないので、スイッチの信号は無視されること」を確認したい。


だからここでは「モードを変えたら間髪入れずに◯◯スイッチをものすごい速さで押す」という操作を求めています。単に「早い」くらいの操作では、狙いたいテストにならないのですね。

「間髪入れずに」「ものすごい速さで押す」のは、どういう操作なのかを実演し、表には見えないけどその裏では、どんなシーケンスが流れていて、何を心配しているのかを話しながら、新人テスターと一緒にテストしました。

これは１つの例ですけど、このシステムではどれくらいシビアないじめ方をテストに要求しているのか、が感覚的に伝わったようで、その後、その新人テスターはかなりひどい操作をしてくれるようになりました。（このときは、テストの共有というよりは「伝承」のような気持ちになりました。）


一人では確認できないとき
例えば、エレベーターの中と外でそれぞれのボタンを同時に押すようなテストをする場合ですが、これはペアテストというよりは、テストする上での準備に近いですね。


おわりに
わたしが経験した「ペアテスト」について、いくつか紹介しました。
若干大げさなものを取り上げて書いてしまった感もあるのですが、一番多いのは、いつものテストの最中に「これ一緒に見てもらえる？」「これおかしいと思うんだけど、どう思う？」と、同僚のテスター（たいてい隣にいます）に声をかけ、５～１０分くらいで行う、とてもカジュアルなペアテストです。


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

 

『基本から学ぶソフトウェアテスト』の読み方

 

基本から学ぶソフトウェアテスト

基本から学ぶソフトウェアテスト

 

 

この本に出逢ったのは10年くらい前なのだけど、今でもたまに取り出しては、読んでいる。
かなりボリュームがあるので「はじめからおわりまできっちり読む」というよりは、「気になるところから”軽い気持ちで”読みはじめる」のが、おすすめ。

読者の想像力（妄想力）を駆り立てるような文章になっていて（←わたしが、そう感じるだけかもしれないけど）読むたびに発見がある。きっと、そのときの自分が置かれている環境や状況、気分によっても感じ方が変わるのだろうな。

興味がなくパラパラと読み飛ばしていたページも（どんなことが書かれているのかな？）と、あるときフワッと好奇心がわいてきて、その結果、すっと読めてしまうのが、この本のすごいところ。（ただし、全部読むのに数年かかっています…）

巻末の付録「よくあるソフトウェア不具合」は「付録」とは思えないくらい読み応えがある。素晴らしい。（前回のエントリーに出てくる「テストの地図」のある部分の元ネタは、これを参考に再構築した）

現在は「ある特定の項目について読む」よりも、「ランダムに開いたところを読む」ことが多くなったかな。読んでいると不思議と気持ちが落ち着く、聖書みたいな本。持ち歩くには重すぎるのが難点。

わたしと同じように毎日毎日テストしていて、遠く離れていても、何か通じるものを感じる某テスターのウィッシュリストに、この本が入っているのを見つけて、ぜひ読んでもらいたくて贈りました。

お誕生日おめでとう！

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

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

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

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

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

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

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

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

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

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

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

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

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

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


 

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

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

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

 

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

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

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

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

 

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

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

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

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


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


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

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

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

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

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

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

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

 

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


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

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

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

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

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

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

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