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

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

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

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

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

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

朝会から何を知るのか

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

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

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

担当者を知る

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

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

揉めていることを知る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

（中略）

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

昨日やったこと

今日やること

チームの開発速度を下げてしまうことがあれば何でも