テスターは朝会から何を知るのか

わたしはちょっと意地悪らしい。

例えば、あるテストケースを思いついたとする（しかもかなりの高確率でうまく動かなそうなやつ）。それをね、モノが出来上がって自分の目でちゃんと動くこと（気持ち的にはちゃんと動かないこと）を見届けるまで、プログラマに話さない。*1

とあるイベントのパネルディスカッションか何かで @m_seki から「それは意地悪だなー」と言われて、はじめてそれが意地悪なんだってことに気がつきました。そういうテストを思いついたらすぐに言ってよ！てことみたい。もしプログラマがそれを考慮しないで実装してしまったら確実にバグになるわけで、黙っていることは開発にとって何のメリットもない。

なぜ話さないのか。話せなかったのか。それなりに理由はあったんだけど、まあ、それはいいや。意地悪は良くない。それからは思いついた嫌なシチュエーションや心配事は、なるべく言うようにしてる。

ということは、わたし（テスター）が朝会でどんなことを気にして、プログラマの話を聞いてるのか、朝会で何を知り、どうテストしようとしているのかを、事前に表明しておいたら、何かいいことがあるのでは？

朝会から何を知るのか

わたしたちのチームはチケットベースで朝会が進んでいく。だからわたしはそのチケットが、今どんな状況にあるのかを知ることができる。

誰が作っているのか。昨日は何をしたのか。今どのような問題があって困っているのか。昨日のあの問題はどうなったのか、どんな風に解決したのか。今日は何をするのか。

プログラマによる実装作業とテストが終わるまでは、わたしは触らないんだけど（触らないというかコミットされないから触れない）朝会でみんなの話しを聞きながら、近い将来テストしてみたいことを、ほぼ日手帳にメモしていく。 

担当者を知る

当たり前すぎて何を言っているのだ？と思うかもしれないけど、テストしていて、あれ？おかしいな？と思ったときに、誰にアクセスすればよいのか悩むようなことが、過去にあったということです。

わたしの疑問を、チームで一番よく知っているプログラマに聞いてもらい、その場ですぐに回答がもらえるのは、テスターにとって幸せで素晴らしいことなんですよ。

揉めていることを知る

途中で仕様が変わったり、実装方法で揉めたりしたら、そこは丁寧にテストしようと思う。そういうところからバグが見つかることって、多いでしょう。
また、ある部分で炎上というか、議論が盛り上がってしまったチケットは、それ以外の部分があっさり流れてしまうことも少なくない。とにかくこんなチケットは要注意。まんべんなく見なきゃなーと思う。

プログラマが混乱していることを知る

チケットに書いてある内容がわかりづらかったり、やたら文章が長くて読むのが大変だったり、本人からの説明を聞いても、よくわからないやつ。これも要注意。チケット番号をメモして、さらに赤いペンでぐるっと囲む。

わからないこと自体、問題なんだけど「プログラマは混乱しています」が知れるので大変良い。混乱の見える化ですね。

もちろん、これについては具体的な対策がなされるので、混乱したまま実装完了ということは無いのだけど。

このようなチケットはテストするときに、もう一度チケットをはじめからおわりまで（根気強く）読み、書いてあるテストと付き合わせて、矛盾や抜けがないかを見たい。それから、もともとこのチケットで実現したかったことは何だったのか、それが本当にできるのかも確認したい。だって混乱してたやつだからね。

ここからわかることは、ポーカーフェイスなプログラマは損をしますってこと！

プログラマが心配してることを知る

コードを見てやる実装の話しはほとんどついていけないのだけど、その場の雰囲気や周辺の話から、どの辺が危なそうなのかを想像（妄想）する。

だからプログラマが心配していることや、こう実装しちゃったらここに影響がでるかもしれないよね、といった話しは大変ありがたい、というか大好物。もっとやれ。

中には（ええっ！この修正がそんなところに影響するなんて・・・）と驚くこともある。プログラマは中身を知っているからそんなことはないのだろうけど、テスターはその関連性を絶対思いつけない。

いろんな歴史があってそんな（ワケが分からない）実装になっていることが（たまに）あるみたいですが、説明が多少面倒くさくても、教えてほしいなと思う。

報告されたバグから多くのことを知る

わたしたちのチームはテスターだけでなくプログラマにもテストの時間が割り当てられている。ここで言うテストとは、自分の担当するチケットについてのテストではなく、システム全体のテストね。

わたし以外のテスターやプログラマが見つけたバグを知ることで、こんなところを気にしてテストしたんだなー（わたしも真似しよう）と思う。新しいテストの条件や観点が自分の中に溜まっていく感じがして、とても嬉しい。

また、そんなバグが出るなら、あそこのあれは大丈夫なのか？（朝会が終わったら試してみよう！）とテスト魂が炸裂し、数十分後の行動に結びつくこともある。

その他にも、これまで知らなかった（または誤解していた）仕様を知ったり、昔のチケットに遡り、わたしが知らない過去の開発で起きたことを知ったり、バグを起点として知ることはとても多い。

まとめ

書籍『アジャイルサムライ』10.6 デイリースタンドアップ に、こんなことが書かれています。  

デイリースタンドアップは、重要な情報をチーム内ですばやく共有することを目的とした集まりだ。あらゆるミーティングを無くすための究極のミーティングがデイリースタンドアップだ。

（中略）

大抵のアジャイル手法の解説書に載っているデイリースタンドアップのやり方はこうだ。全員で輪になって立ち、チームメンバーひとりひとりが、他のチームメンバー全員に対して次の3つを伝える。

• 昨日やったこと
• 今日やること
• チームの開発速度を下げてしまうことがあれば何でも

ああ、わたしたちのチームもだいたい同じことを話しているなぁと思うのだけど、ここに書かれている「朝会」から受ける印象より、もっと濃厚で、凝縮された時間が流れているように感じる。

とにかく朝会からテスターが知ることはとても多く、わたしが仕事をするうえで、それは無くてはならならないものになっています。

アジャイルサムライ−達人開発者への道−

*1:バグなら報告するけどそうではないとき（ちゃんと動いたとき）は報告しないことが多いかも。それから探索的テストに多いんだけど、これは良いテストケースだなあと思っても自分のカラダにしか残らないテストケースってある。頭の中じゃないんだよね。これどうしたらいいんだろう。

愛すべき不完全なテストケースについて

「完璧なテストケースなどといったものは存在しない。完璧な絶望が存在しないようにね。」村上春樹さん風 （『風の歌を聴け』より）

わたしはテストケースに完璧を求めていない派だけど、こうなる前までは”完璧”とか”漏れがない”とか…なんだろう理想のテストケースを追い求めていたように思います。

だから手を動かしてテストする時間より、理想のテストケースを作るために考える時間のほうが多くなる日もあって（テスターなのにテストしてないのでは！）と不安になることもありました。

何をどれくらいの密度や深さで、どのようにテストしたらよいのか、強弱は？テストする順番は？…それらを考えることもテストの一部なんだけど、やはり実際にシステムやソフトウェアを触って動かして、はじめてテストの価値が生まれるというか、生を与えられたように感じてしまう。

とにかく漏れのない完璧なテストケースを作って、きちんとテストしたい！と言う気持ちが強かったのは確かです。

そんなわたしが、なぜ、完璧なテストケースを求めなくなったのか、それで平気でいられるようになったのかを考えてみました。

1. イテレーション開発がそれを許してくれなかった

完璧なテストケースを考えてると、あっという間に開発に置いていかれます。

考えてみればウォーターフォールでの開発だって時間の制約があるんだから同じなんだけど、毎日、毎週締め切りがあるのは大きい。

で、どれくらいのスピードかと言うと、JSTQBのシラバスに載ってるテストプロセス（テスト計画、テスト分析、テスト設計、テスト実装、テスト実行、評価＆レポート）を短いときは1日で全部やるイメージです。とにかく今のチームの開発のスピードがめちゃくちゃ早いので、テストのサイクルも必然的に早くなります。

開発手法のせいで、完璧なテストケースを作らせてもらえないわけですからね、さぞかしモヤモヤするんだろうな…と思いきや、そうでもなかった。だいぶ適当な人間なんだなぁとあらためて思いました。*1

2. 不完全さが新しいテストケースをつくる

すでに存在するテストケースをそのまま実行してもバグはほとんど見つかりませんが、そのテストケースに対する疑問やテストの不足を補うようなテストをすることで、バグを見つけることができます。*2
プロダクト(テスト対象)の品質自体も大きく関係しそうですが、わたしたちのチームで見つかるバグのほとんどがこれです。

またチームのメンバーが完璧なテストケースではないことを知っていて、それを容認していることも大きいと思います。開発しながらテストケースも一緒に育つ感じ。子供を育てながら、親も一緒に成長するのと似ています。そこには愛がありますね。

3. 完璧なテストケースは存在しないことを受け入れた

1と2がわたしの中では大きいのですが、最後にこれも。

でも諦めているわけではないんですよね。より良いテストを目指して、不完全なテストケースと共に、これから先もまだまだ新しいテストケースを開発していくし、イテレーション開発に組み込んでみたい中長期のテストケースもある。だから（完璧なテストケースは存在しないんだから）やり過ぎに注意しなさいよ！くらいに思えるようになったんじゃないかな、と。

テストケースについて書いてみたくなったのは、これを読んだからでした。残り2回も楽しみです。

*1:適応能力が高いことにしたい。

*2:このことは多くの人がそう感じているようなので、そろそろこの現象に名前をつけてもいいと思う。

気の持ちようを変えるのは大変なんだよねって話し

これとてもおもしろいエントリでした。気の持ちようを変えるための、具体的でお手軽なアイデアですね。

過去にわたしも「そんなの気の持ちようなんじゃないの？」と言われたことが何度もあるし（それはそれで勇気づけられたことも確かなんだけれど）本屋さんにずらりと並んでいる自己啓発書やスピリチュアル本にも、確かそんなことが書いてありますね。
だから世界は気の持ちようでどーにでもなるんだと思います。

でもね、気の持ちようを変えるために、わざわざ自分で自分の気持ちを高めたりすること自体が大変なんですよ。そのうちそんな自分で自分の気持ちを高めている自分を冷めた目で見る自分が現れて（なにやってんの？）（ミサワなの？）などと言い出すので、当初の目的も忘れ、お恥ずかしくなってきます。*1

あれ、何の話しをしてたんだっけ？
ああ、気の持ちようを変えるのは大変なんだよねって話しでした。

ところで、うちのチームはバグはドラゴンではなくバグと呼んでいますが、チーム内でしか通用しない言い回しというか隠語みたいなものが、いくつも存在します。朝会とか、開発中の普段の会話の中でそれを使っては、みんなでクスクスしてる。わりとシリアスな場面でも関係なくそれは使われるんだけど、そんなときは必要以上に入っていたチカラがふっと抜けたりしてね、精神衛生上とても良いのです。開発に笑いは必要だね。

*1:だいぶ大人になったので自分自身のことを冷静に観察できるようになっている。

JaSST'15 東北に参加します

JaSSTソフトウェアテストシンポジウム-JaSST'15 Tohoku

今回のテーマは「レビュー」なんですね。楽しみだなー。

参加申込みしたときにレビューに関するアンケートがあったので、こんなことを書いてみました。安達さんのお話（ウォークスルーで疑似体験）や倉貫さんと西見さんのライブコードレビューから何か見えてくるといいなあ。

Q7. プロジェクトで作成されるドキュメントについてレビューを実施されているか教えてください。

◎レビューをしている

Q7でレビューしている方はレビューのやり方について具体的にご記入ください。

状況に応じて対面、机上レビューを実施しています。

はじめに何についてレビューしてもらいたいのかを宣言します。逆にレビューしてもらいたくないことを宣言するときもあります。

対面でのレビューは、あらかじめ時間割りやゴールを示しておくことが多いです。

朝会でのチケットの読み合わせもいわゆるドキュメントではないですが、レビューの要素が強いです。

Q8. プロジェクトで作成されるソースコードについてレビューを実施されているか教えてください。

◎レビューをしている

Q8でレビューしている方はレビューのやり方について具体的にご記入ください。

わたし自身はテスターなので参加してませんが、周りのプログラマを見ているとしょっちゅうレビューしてる感じ。ペアプロはよく見かける光景だし、誰かのモニタを数人で囲んでコードを見てなんかやってます。必要だからやってるんだと思います。

Q9.レビューする場合、困ったこと、うまくいかなかったことがあれば教えてください。

レビューで指摘されるとムキになって反論？というか言い訳？いや説明する人がいます。こちらは単にコメントしただけで責めるつもりは全くないので、びっくりしてしまいます。なんか悪いことしたような気持ちになってしまうときがあるので、どうにかなるなら、どうにかしたいです。

Q10.レビューについて何かお聞きしたいことがありましたら、ご自由にご記入ください。

レビューはレビュー自体というかみんなで意見を出し合って紆余曲折しながらすり合わせをしていく過程そのものが大切というか肝だと思ってますが、レビューすることが目的になってしまう残念なレビューもあります。ふたつのレビューの分かれ道はどこにあるのでしょうか？

品質特性とバグの聞こえる化

午前中に見つかったクリティカルな問題が、お昼休み前には原因が分かり一安心。

会話(問題が起きる前にどんなことをしていたか)とログでだいたいのことは分かるんだなあ。これって品質特性で言うところの「保守性(解析性)が高い」ということだよね？すばらしいなあ。

午後になって、対応してくれたプログラマSさんに「もう原因が分かっちゃったんですねー。早くてびっくりした。すごーい！」と言ったらSさん、

隣でmiwaさんがテストしながら「あ…」て言ったでしょう。気になって(コーディングする手を止めて)miwaさんの画面を見たらあれ(深刻な状態)ですからねー。その場でログとらせてもらってすぐに見れたからですよ！

なんだかわたしまでほめられた気分。うれしいな。

今回のケースは”テスターが問題を検出してからプログラマに伝わるまでの時間”がゼロでした。世の中にはこんなメトリクスがあるのかどうかわからないけど、とにかくコードは日々変化してしまうので、この時間は短ければ短いほどいい。多分みんなそう思ってるはずです。

ところで、わたしはほぼ毎日プログラマの隣でテストしているのだけど、あれ？おかしいな？と思った時、真剣にコードをかいてるプログラマに話しかけるのは、少々気が引けてしまうのですよね。

朝会で今日対応してるチケットがどれとかだいたい把握してるので、今まさに重要で繊細なところを直してるのかもしれない、ここで声をかけたら思考を妨げちゃうかも…と思うわけ。

さっき検出した問題がプログラマに伝わるまでの時間は短ければ短いほどいいと書いたけど、そうなの。アタマでは良いと分かってはいても、なかなか行動に移せないことって、ある。(それはわたし自身の内面的な問題で他人にはどうでもいいような些細なことだったりするのだけど…)

そんなこと、ありませんか？

だからそんな時は問題の大きさによって「ん？」とか「あれ？」とか「あわわわ」とか声に出してみようと思います。これなら気が引けないね。だって独り言だもん。

うまくいけば周りのプログラマたちがシグナルを受信して、わたしのモニタを覗きこんでくれるはずだ。

誰も気がついてくれないときは、いつも通りチケットを発行しますね。

Feelingを大切にするということ

先日行われたJaSST'15 Tokyoのマイケル・ボルトンさんの基調講演はとても良かった。なにが良かったのかって。それはわたし（たち）のやってるテストが間違ってないんだな、ということがわかったから。

うーん「間違ってない」というのは言葉の選び方として適切じゃないな。正しくはボルトンさんの提唱してるRapid Software Testingのアイデアのいくつかをわたしたちのチームでは（たまたま）行っていて、はじめて聞くボルトンさんの話しに「うんうん」「そうだよね」「わかるわ～」という風に共感できてしまい、単純に嬉しかったのかもしれない。

そう、わたしたちのチームでFeelingはとても大切にされている。それは表示がちょっとずれてて気持ち悪いだとか、ボタンが一瞬チカチカするとか、この画面だけ雰囲気が違うなーとかいった視覚に関するものから、なんとなく動きがもっさりしている、昨日より応答が1、2秒遅くなったような気がするんだけど・・・といった体感速度に関するものなど実にさまざま。（そういうチケットにはオノマトペが使用されることが多い）

そしてこのFeelingを適用する範囲は製品そのものだけにとどまらず、仕事のやり方や態度についても同じだったりする。

わたしたちは毎朝チケットを読み合わせるんだけど「その直し方だとヤバいかも」と設計のおかしさや将来的な危うさに関する匂いを嗅ぎつけたり、今日の作業内容（どう実装する）を話すその○○さんの言動から「○○さんは混乱してるっぽい」ということが分かったりする。今日は一度も視線を合わせてこないんだよなーといったことで、そのシグナルが立ったりもするらしいし、体調や機嫌もバレる。

ちなみに、わたしがノリノリでテストしてたりすると異常値っぽいフラグが立つようですよ。気をつけなければ。

そうした「おかしさ」を感じることができたとしても、それを受け取る側の態度も重要で、例えば、テスターが見つけた「おかしさ」や「違和感」を、プログラマが「それはそういう仕様だから」とか（そんなのどうでもいいじゃん、面倒くさいなぁ）とかいったスタイルで接してしまうと（そういうのは言葉になってなくても分かるのよ）、それ以降テスターはそういったFeelingを起点とした報告はしなくなる。きっとね。

そして、これはわたしの場合だけど、わたしの感じる「おかしさ」や「違和感」を何がなんでも直して欲しい、という気持ちはない。わたしがなぜこれをおかしいと感じるのか。それをチームのメンバーにも分かってほしい。うん。それだけです。

幸いわたしが属している2つのチームはFeelingを共有する基盤みたいなものができていて、テスターから報告されたFeeling（例えば「おかしさ」）についてどう取り扱うのかをチームのみんなで話し合っている。

ちなみに、こういった報告はテスターだけじゃなくてプログラマからも報告される。思ったことや感じたことを素直に表現してもいいチームの雰囲気ができあがっているのは、わりとポイントかもしれないね。

話を戻すと、その結果コードが修正されることもあれば、仕様から見直しが入ることもあるし、時には「おかしさ」をチームで受け入れることもある。そのようなときは「おかしさ」の発生頻度やユーザーの困り具合、それを修正するためのコスト、修正しない場合のリスクなど様々な観点で話し合う。いずれにせよ「おかしさ」について、チームとしてその時点でのベストと思われる判断がなされる。

もちろん「おかしさ」自体が間違っていることもあって、その場合はテスター自身が製品やテストのやり方について学べる機会となる。

Feelingを大切にするということは、自分たちの作る製品やチームのメンバーの仕事のやり方や態度に興味を持ち続け、日々こころの目で感じながら注意深く観察し、みんなが感じたFeelingに対し真摯に向き合い、チームとしてそれをどう取り扱うのかを決めていくことなんだと、2つのチームを見てわたしはそう思う。

品質とは何か

大学生の娘が夏休みで帰ってきたので、宇都宮まで映画をみに行ったときの話し。

目的地まであと20分というところで、車のエアコンの挙動がおかしくなりました。

熱風しかでてこない。

車内の温度と湿度が急上昇する中、落ち着いて関連しそうな機能をいじくってみた。

 

• 温度、風量、風向きの設定を変化させる
• エアコン機能のオン／オフ切り替え（上記設定との組み合わせ）
• AUTO機能のオン／オフ切り替え
• 車の再起動（エンジンを切る→エンジンをかける）

やっぱり熱風しかでてこない。

壊れたな...。

エアコンを止めて窓を開けたら、もっとひどいことになったので閉めました。20分後、ふたりとも汗だらだらになりながら目的地に到着しました。久しぶりに娘とデートできる嬉しさもあり、先に車屋さんに行って見てもらうという発想はありませんでした。今日は涼しくなってから帰ろう。それに、地下の駐車場に何時間か入れとけば、エアコン直るかもしれない。

 

6時間後。

やっぱりエアコン直ってなかった。

むむー。

 

窓全開にして走り出したら、少し前に降った雨（夕立）のおかげで、ぬるい風がビュンビュン入ってくる。後部座席で「とーばーさーれーるー」とか言って、長いストレートの黒髪をなびかせてはしゃぐ娘。

 

運転しながら、考えてました。

 

ちょっとした不具合の原因を調べていったら、システム上の大きな問題が見つかった、というようなケースもあるよなー。走行中いきなりエンジンが止まったりしたらそれこそ困るし、やっぱり早めに見てもらおう。

 

近くのトヨタカローラ店とトヨペット店に行ってみたけど、やってませんでした。

そうか、お盆休みか！

しかたないなー。直るまで極力出かけないで、ひきこもろう。

1時間後。

 

薄暗くなってきたのでスモールライトを点けて、今日の映画楽しかったねぇなんて話していたら、オレンジ色の明かりのついたトヨタカローラ矢板店が見えた。

 

受付のそばにいた、日焼けしたエンジニアに声をかけました。

 

「あの、エアコンが効かなくなってしまって。予約してないんですけど、見ていただけますか？」

「大丈夫ですよ。中でお待ちくださいね。」

 

15分後。

 

「この部品が壊れてました。」

 

iPhoneのキューブ型のAC充電器のようなものを見せてもらう。

 

「部品を交換して確認してみたんですが、特に問題なくエアコンも使えるんで、もう大丈夫です。」

 

ほっ。よかった。

 

「ありがとうございました。本当に助かりました。」

「おいくらになりますか？」

 

「ああ、交換した部品は新品ではないので、いいですよ。」

 

エンジンをかけるとエアコンから冷たい風が出てきました。

 

嬉しかったこと

 

• 受付時間ぎりぎりで、しかも飛び込みだったのに、嫌な顔せずに丁寧に応対してくれたこと
• 原因を突き止めてくれたこと（しかも短時間）
• エアコンを直してくれたこと（しかもタダ）
• 帰るとき、深々とおじぎをして見送ってくれたこと

 

当たり前のことなのかもしれないけど、どれもこれもすばらしい。たぶんエアコンが直らなくても、感動して帰ってきたんだろうなあ。

 

これはいったい何品質なんだ？

 

品質を語るときはデータで語れってよく言われます。今回の件だって、MTBFやMTTRを出そうと思えば出せるけど、そういうのじゃないんだよなあ。どこかで見た「顧客満足度No.1」とかいうキャッチフレーズでもない。

 

数値では表せないけど、体験したらそれはもう強烈な記憶として刻まれてしまう品質って、何なのかしら？