みんな自分の話をして、聞いて、応えて、オトナだった。お客様がいない感じで、上質だったな。
しかし疲れた、オトナだから。
— seki at druby.org (@m_seki) 2015, 10月 11
みんな自分の話をして、聞いて、応えて、オトナだった。お客様がいない感じで、上質だったな。
しかし疲れた、オトナだから。
— seki at druby.org (@m_seki) 2015, 10月 11
この本は、先月開催されたソフトウェア品質シンポジウム 2015で、友人というか同僚に買ってきてもらったもので、翻訳者の湯本さんと皆川さんのサイン付きプレミアム本なのだけど、いつか薮田さんのサインももらいたいな。
わたしたちのチームは、毎朝同じ時間に同じ場所で、チケットの読み合わせをする。
朝会が終わる頃には、今日やるべきテストのイメージ(それはもしかしたらカジュアルなテスト設計のようなものかもしれないし、探索的テストの断片のようなものかもしれない)ができあがっていて、それをもとに毎日テストしている。
テストはラボで行う。ここにはチームのみんな(プログラマ、アーキテクト、プロの無職、テスターなど)がいて、それぞれが、それぞれの作業をしている。
たいてい複数のプロダクトが並行して走っているから、テストPCもその分だけ用意されている。テスターはテストするプロダクトに合わせて席を移動する。変わらないのは、隣にはいつもプログラマがいる、ということ。
これはテスターにとってとても心強いし、作業効率が良い。(無駄になるかもしれない時間が減らせるという意味でね。)
例えば(昨日と比べて動きがすこし違うような気がする…)と思うようなとき、これはチケットを発行して報告すべきだろうか、もう少し深追いしてもっと深刻なバグを探すべきだろうか…というようなことを考えたり、実際に作業して時間を消費してしまう前に、隣のプログラマにこう話しかければいいのだ。
「昨日と比べて動きがすこし違うような気がするのだけど、気のせいかな?」
そういえばこんな時もあったな。画面を見つめ(うーん)と首を傾げていたら、前に座っていたプログラマたちがザワザワしはじめて、心配して?見にきてくれた。言葉にしなくても伝わるって、素晴らしいと思う。
プロの無職がふらっと歩いているのを見つけたら、視線を合わせておいでおいでして(手で)、朝会で気にしていたチケットの動作を一緒に見たりする。
テスター同士の情報交換も、いつでもすぐにできる。
「いまこんなバグがでてるよ」
「これおかしくない?」「あー、おかしいね」「だとすると○○もヤバいかも」
「あのチケットのテストやってみたんだけど、まだ不安があるから一緒にテストしてほしいな(ペアテスト)」
次の日になれば、朝会でみんなの頭の中は同期されるのだけど、全員が同じ空間で作業しているからなんだろうね、それはチームに自然な会話と、適度なスピードをもたらしている。みんなが何をしているのか知っているし、わたしが何をしているのかも、みんなは知ってるはずだ。それがとても気持ちいい。
6月20日に開催した とちぎRuby会議06 - Regional RubyKaigi に 珈琲専門 猫廼舎さん が出張ドリップに来てくれました。どのようにして珈琲セッションをつくっていったのか、また当日の様子などを書き留めておきます。
用意したもの
公民館からお借りしたもの
用意したツール
あらかじめ決めておいたこと
珈琲の配送
当初、参加者が各自珈琲を取りに行くことも考えたのですが、タイミング的に難しそうでした。
結局、講演中に立ったり座ったりするのもねぇ…ということで、どれもボツ。スタッフが運ぶことにしました。
テーブルの配置
これまでの会議をふりかえると、コンテンツの内容によって、わざとテーブルを置かずに椅子だけでやったり、毎回こだわりを持って工夫してきたなと感じます。
今回はテーブルが必須ですね。会場の東那須野公民館は過去に何度か利用したことがあったので、広さや間取り、テーブルの大きさなどは把握していました。
参加人数から必要なテーブル数が決まり、さらにそこから動線を考慮して、だいたいの配置図をホワイトボードに書き、イメージをみんなで共有。あとは当日設営しながら調整しました。
珈琲飲みたいぜ!の見える化
例えば「前のテーブルから順番に珈琲を置いていく」なら簡単なのですが、中には珈琲が苦手な人もいるわけで「わたしは珈琲が飲みたいです!」の意思表示をしてもらう必要がありました。
今回は受付で全員に「珈琲引き換え券」を渡すことにしました。飲みたい人は引き換え券をテーブルに置き、スタッフはそれを目がけて運びます。そして、珈琲を置いたら引き換え券を回収します。
朝から珈琲セッションの状態遷移図を書いてる #toruby
— miwa (@miwa719) June 14, 2015
珈琲セッションのはじまりをいつにするか
事前に @ogijun さんから、珈琲4杯あたりの所要時間を教えてもらっていたので、タイムテーブルにここまでで何杯、ここまでで何杯…と書き入れてみたりしたのですが、頭の中でシミュレーションすればするほど、不確定要素が出てきてしまうんですね。これは、もう当日になってみないと分からないなぁ…て。
とりあえず「まつもとさんの基調講演がおわったら珈琲を淹れてもらう」ことにして、あとはその場の状況に応じてうまく動こう!と決めたら、気が楽になりました。
当日のオペレーション
準備
定刻どおり本会がはじまりましたが @ogijun さんと @arton さんが来なくてハラハラしました。関くんは「さすが、安定してるなー」と言ってました。
まつもとさんの基調講演がはじまって少しした頃に、お二人が現れたのでホッとしました。よかったー。用意しておいた作業台(テーブル)に @arton さんの車で運んできた器材、用品一式を並べながら、設営開始です。
そうそう、公民館には冷蔵庫がなく、たまたま持ってきていた 凍らせておいしいカルピス がミルクを冷やすのに活躍しました。わたしってすごい!と思いましたが、誰もミルクを使いませんでした。というか、ミルクやシュガーがあることをアナウンスしてなかった!(ごめんなさい)
準備段階ではまったく気が付きませんでしたが、保冷剤を入れた小さなクーラーボックスなどを、用意しておくとよいのかもしれませんね。
珈琲セッション
基調講演がおわり @ogijun さんからお店の紹介の後、休憩をはさみ、一般講演とマルチトラックで珈琲セッションがはじまりました。
はじめは何をどう手伝えばよいのか分からなかったので、見学してました。(経験値は"ネルドリップ生まれてはじめて見たー"とかそういうレベルです…)
わたしのミッションは「カップに注がれた淹れたての珈琲を各テーブルに運ぶこと」だったのですが、
…と、任せてもらえることが、少しずつ増えていきました。うれしい。
@ogijun さんがこの工程に入ったら、カップを温めておくとちょうどいいとか、まだあの工程に入ってないから、今のうちに下げたカップを洗ってこようとか、どのタイミングで何をしておくとよいのかが、少しずつ分かってきました。
また、何種類かのカップを持ってきてもらったのですが、このカップは小さいくせに口は広いから、運ぶときにこぼしちゃうかもしれない。だから、なるべく使わないようにしよう!とか、ふだんの開発の中で感じるような「ドライブ感」のようなものがそこにもあって楽しかったです。
それではりきりすぎて、カップを洗うときに力がはいり、持ち手の部分を破壊してしまいました。ごめんなさい。(わたしがノリノリで仕事しているとヤバい仮説、だいたいあってる)
途中、スタッフの池澤さんや中内さん、佐々木さんが手伝ってくれたので、心強かったです。また、飲み終わったカップを作業台まで持ってきてくれた人もいて、たいへん助かりました。
書籍『アンダースタンディング コンピュテーション』を使った、笹田さん音読&解説による「いつもの勉強会」が中盤にさしかかった頃、全ての珈琲が淹れ終わりました。(だいたい60杯くらい)
アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで
撤収作業
本会が閉会した後、懇親会会場に一番乗りしなくてはならなかったため、片づけや掃除は、ほとんどできませんでしたが、いつものようにみんなで協力して(参加者も巻き込んで)やったのだろうと思います。
床が少し汚れてしまったので(用意していたブルーシートを作業台の下に引けばよかったのかな…)と思ったのですが、ブルーシートはなんとなく猫廼舎に似合わない感じもする。床は拭いたらきれいになったので、今回は結果オーライということにします。
さいごに
はじめての試みで正直不安もありましたが、最後までやり切った!と感じられるセッションでした。@ogijun さんは、ほとんど休みなしだったのに、淡々とこなす所作がクールで素敵でした。でも、そのまなざしはあたたかい。
後日、この日のツイート(#toruby)を読み返してみました。みなさん美味しく飲んでいただけたようですね。
大きなトラブルもなく、うまくいってよかったなーと思っていたのですが、当日かなり緊張しながらも、司会業をがんばってくれた米澤さんが珈琲を飲めなかったことを、昨日、知りました。
バグが1つ見つかったら、大抵その周辺にもバグは存在しますので、他にも飲めなかった人がいるかもしれません。
わたしは味見と称して2杯、いや3杯は飲んだことをここに告白し、懺悔いたします。@ogijun さんから手渡しされた珈琲は、とても美味しかったです。
先日、ある機能をテストしていたときの話。
いつもなら瞬時に画像が表示されるのに、今日は5秒くらい待たされる。おかしいな?と思い、別の画像で試してみるとすぐに表示された。どちらも表示自体には問題ない。画像に依存してるのかなあ…(もしかしたらそういうものかもしれない)と思ったのだけど、担当のプログラマOさんに見てもらう。
「確かに遅いですね。チケットあげちゃってください」
結論から言ってしまうと、作り方に問題があるということが分かった。(雑すぎる説明だな。大抵の場合はそうよね。)
ええと、表示するときに「無駄な処理」をしてるっぽかった。
わたしはね、Oさんが問題の画像を別のテスト環境にコピーして、確認していたのを知ってる。(テスト環境に依存しているのかを切り分けるためだと思う)
それから、その画像の内部的な構成を調べて、同じような画像を作っていたのも知ってる。(その遅い画像だけに起こる特有の問題なのか、同じような構成の画像を作ったときも、同じように遅くなるのかを確認するためだと思う)
OさんとWさんでコードを見ながら、遅い原因を探っていたのも知ってるよ。
とにかく、その結論にいたるまでOさんが、地道にいろいろやっていたのを知っていた。
それから数日して、わたしは朝会でびっくりすることになる。(わたしたちのチームは毎朝チケットを読み合わせている)
画像表示が遅くなる件について、Oさんが話した内容はこんな感じ。
前にもブログに書いたけど、わたしが報告した問題を何がなんでも直してほしい、という気持ちはありません。
ここまできっちりやったのにコミットしないのかー。勿体無いにも似たような、驚きの気持ちというのかな。うん。
朝会が終わって自分の席に戻り、もうすることのないテストに思いを巡らせた。
(もし、これがコミットされたら、わたしや他のテスターがいつものようにテストするよね。あの修正方法だと、わりと基本的な部分にも手が入るから、問題のある画像だけを使用したテストだけでは済まされないな。影響を受けそうなところは、、、)
そうか、そういうことなんだ。もう、あの時にプロダクトとしてのコストや効果を考えて、修正しないことを選択したのだな…。
丁寧な仕事はチームに伝染する、と思う。
わたしたちのチームのプログラマは、テスターが報告した問題や、問題とまではいかないけど気になることに対して、いつも真摯な態度で向きあってくれる。そして、こんなにも丁寧に製品を作っているのだ。
だから、わたしは丁寧に製品を壊していきますね。
先日いつものようにテストしていたら、おかしな現象に遭遇したのでプログラマAさんに見てもらいました。
わたし「こんな条件で動かすと、ほらこうなっちゃう。」
Aさん「あー、なるほど、そうなりますねぇ。バグですね。」
Aさんの頭の中のエディタにはコードが表示されているんだろうね。どこがまずいのか、だいたい分かったような顔をしていたから、わたしもホッとして、Aさんにそのチケットを引き取ってもらいました。
数日後、そのバグが修正されてきたので、よし大丈夫だろう、というところまで一通りテストしたのだけど、どう直したのかとても気になる。直し方によっては、テストが変わることもあるからです。
例えば、こんなバグがあったとします。
これが修正されてきたら、どんなテストをしますか?
バグが発生したときと同じように、特殊な条件を与えても、初期状態にならないことをテストしますよね。それから(特殊ではない)通常の条件を与えても、おかしな状態にならないこともテストしますね。
JSTQBで4つのテストレベルが定義されていますが、わたしはそこで言うところのシステムテストを担当しているので、ピンポイントな確認を行いつつ、システム全体として連携するような機能や状態に影響がないか、またユーザがやりそうなことも想像してテストします。
そして一通り確認して大丈夫かなーと思ったとき(このバグ、どう直したんだろう)と思うわけです。
変数Aの初期値を0以外に変えたのか、変えたとしたらどんな値にしたのか、その値は、また別の特殊な条件でその値(初期値)になったりはしないのか。それとも特殊な条件になったときに変数Aを0にしないようにしたのか。そうではなくて、初期状態の判断自体を変えたのか。まさか、システムの使われ方に応じて、初期値を変更できるように設定ファイルで外に出す、なんてことしてないよね…。
ほら、直し方ひとつで、気になることがガラッと変化し、テストすべき内容が変わってきませんか?
テストオラクル(test oracle):テスト対象のソフトウェアが実際に出力した結果とを比較する期待結果のソース。オラクルは、実在する(ベンチマーク用の)システム、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
— ソフトウェアテスト用語集 (@software_test) 2015, 6月 5
「テストオラクル」は、わたしがなかなか理解できなかった用語のひとつです。今でも分かってないかもしれない。
”コードであってはならない”なんて書いてあるから、テストするときはコードを見てはならん!みたいな印象を受けてしまうのだけど、最近は(そうじゃないかもなー)と思うのです。
誤解を恐れずに書くと、コードを知ることで、それまで見えてなかったテストが見えてくることがあるのね。それは時として、あまりやる意味のないテストを実施してしまうこと、を適度に抑制する効果もある。(そこで浮いた時間で、別のテストができる)
だから「わたしはテスターだからコードは知らなくてもいい!」「テストオラクルの説明にもそう書いてあるし!」なーんてガチガチに思っている人がいたら、そうじゃないかもしれないんだよね、と言いたい。
はじめの話に戻るけど、わたしはAさんのところに行って、一通りテストして大丈夫そうなことと、今回こんなテストをしたんだけど、直し方によってはテストが足りてないかもしれないから、どんな風に直したのか、教えてほしいと伝えました。
Aさんはメモ用紙を取り出し、図を書きながら、①その処理の本来あるべき姿、②今回どこが問題だったのか、③それをどう直したのか、をコードも交えて説明してくれた。
それを聞いて、わたしがもう少しやろうかなと思っていたテストの話もして、そういう直し方をしたなら、そのテストはやらなくても大丈夫そうだねーということになりました。
コードを知ることで、省略してしまったテストで見つかるはずのバグが見つけられなくなる(かもしれない)という危険性を十分知った上で、コードを知ることのメリットも大切にしたい。
ブラックボックステストをきっちりカバーし、グレーボックスなテストの領域にも踏み込み、まだうまくできないけどグレーボックスとホワイトボックスの間のテスト(そんなテストの領域があるのかわからないけど)にも、果敢に挑戦していく。そんな勇気のあるテスターになりたいなぁと思う。
わたしはちょっと意地悪らしい。
例えば、あるテストケースを思いついたとする(しかもかなりの高確率でうまく動かなそうなやつ)。それをね、モノが出来上がって自分の目でちゃんと動くこと(気持ち的にはちゃんと動かないこと)を見届けるまで、プログラマに話さない。*1
とあるイベントのパネルディスカッションか何かで @m_seki から「それは意地悪だなー」と言われて、はじめてそれが意地悪なんだってことに気がつきました。そういうテストを思いついたらすぐに言ってよ!てことみたい。もしプログラマがそれを考慮しないで実装してしまったら確実にバグになるわけで、黙っていることは開発にとって何のメリットもない。
なぜ話さないのか。話せなかったのか。それなりに理由はあったんだけど、まあ、それはいいや。意地悪は良くない。それからは思いついた嫌なシチュエーションや心配事は、なるべく言うようにしてる。
ということは、わたし(テスター)が朝会でどんなことを気にして、プログラマの話を聞いてるのか、朝会で何を知り、どうテストしようとしているのかを、事前に表明しておいたら、何かいいことがあるのでは?
わたしたちのチームはチケットベースで朝会が進んでいく。だからわたしはそのチケットが、今どんな状況にあるのかを知ることができる。
誰が作っているのか。昨日は何をしたのか。今どのような問題があって困っているのか。昨日のあの問題はどうなったのか、どんな風に解決したのか。今日は何をするのか。
プログラマによる実装作業とテストが終わるまでは、わたしは触らないんだけど(触らないというかコミットされないから触れない)朝会でみんなの話しを聞きながら、近い将来テストしてみたいことを、ほぼ日手帳にメモしていく。
当たり前すぎて何を言っているのだ?と思うかもしれないけど、テストしていて、あれ?おかしいな?と思ったときに、誰にアクセスすればよいのか悩むようなことが、過去にあったということです。
わたしの疑問を、チームで一番よく知っているプログラマに聞いてもらい、その場ですぐに回答がもらえるのは、テスターにとって幸せで素晴らしいことなんですよ。
途中で仕様が変わったり、実装方法で揉めたりしたら、そこは丁寧にテストしようと思う。そういうところからバグが見つかることって、多いでしょう。
また、ある部分で炎上というか、議論が盛り上がってしまったチケットは、それ以外の部分があっさり流れてしまうことも少なくない。とにかくこんなチケットは要注意。まんべんなく見なきゃなーと思う。
チケットに書いてある内容がわかりづらかったり、やたら文章が長くて読むのが大変だったり、本人からの説明を聞いても、よくわからないやつ。これも要注意。チケット番号をメモして、さらに赤いペンでぐるっと囲む。
わからないこと自体、問題なんだけど「プログラマは混乱しています」が知れるので大変良い。混乱の見える化ですね。
もちろん、これについては具体的な対策がなされるので、混乱したまま実装完了ということは無いのだけど。
このようなチケットはテストするときに、もう一度チケットをはじめからおわりまで(根気強く)読み、書いてあるテストと付き合わせて、矛盾や抜けがないかを見たい。それから、もともとこのチケットで実現したかったことは何だったのか、それが本当にできるのかも確認したい。だって混乱してたやつだからね。
ここからわかることは、ポーカーフェイスなプログラマは損をしますってこと!
コードを見てやる実装の話しはほとんどついていけないのだけど、その場の雰囲気や周辺の話から、どの辺が危なそうなのかを想像(妄想)する。
だからプログラマが心配していることや、こう実装しちゃったらここに影響がでるかもしれないよね、といった話しは大変ありがたい、というか大好物。もっとやれ。
中には(ええっ!この修正がそんなところに影響するなんて・・・)と驚くこともある。プログラマは中身を知っているからそんなことはないのだろうけど、テスターはその関連性を絶対思いつけない。
いろんな歴史があってそんな(ワケが分からない)実装になっていることが(たまに)あるみたいですが、説明が多少面倒くさくても、教えてほしいなと思う。
わたしたちのチームはテスターだけでなくプログラマにもテストの時間が割り当てられている。ここで言うテストとは、自分の担当するチケットについてのテストではなく、システム全体のテストね。
わたし以外のテスターやプログラマが見つけたバグを知ることで、こんなところを気にしてテストしたんだなー(わたしも真似しよう)と思う。新しいテストの条件や観点が自分の中に溜まっていく感じがして、とても嬉しい。
また、そんなバグが出るなら、あそこのあれは大丈夫なのか?(朝会が終わったら試してみよう!)とテスト魂が炸裂し、数十分後の行動に結びつくこともある。
その他にも、これまで知らなかった(または誤解していた)仕様を知ったり、昔のチケットに遡り、わたしが知らない過去の開発で起きたことを知ったり、バグを起点として知ることはとても多い。
書籍『アジャイルサムライ』10.6 デイリースタンドアップ に、こんなことが書かれています。
デイリースタンドアップは、重要な情報をチーム内ですばやく共有することを目的とした集まりだ。あらゆるミーティングを無くすための究極のミーティングがデイリースタンドアップだ。
(中略)
大抵のアジャイル手法の解説書に載っているデイリースタンドアップのやり方はこうだ。全員で輪になって立ち、チームメンバーひとりひとりが、他のチームメンバー全員に対して次の3つを伝える。
- 昨日やったこと
- 今日やること
- チームの開発速度を下げてしまうことがあれば何でも
ああ、わたしたちのチームもだいたい同じことを話しているなぁと思うのだけど、ここに書かれている「朝会」から受ける印象より、もっと濃厚で、凝縮された時間が流れているように感じる。
とにかく朝会からテスターが知ることはとても多く、わたしが仕事をするうえで、それは無くてはならならないものになっています。
*1:バグなら報告するけどそうではないとき(ちゃんと動いたとき)は報告しないことが多いかも。それから探索的テストに多いんだけど、これは良いテストケースだなあと思っても自分のカラダにしか残らないテストケースってある。頭の中じゃないんだよね。これどうしたらいいんだろう。