2015/11/26 に行われたクックパッドエンジニアのトークナイト〜テストエンジニアvol.2 Testing編〜 - connpass に運良く(倍率3倍)参加できて、とても内容が良かったので共有します。

当日の資料が公開されましたのでリンクしておきます。

感想

JaSST、Ques、TestingCasualに参加したことがあるのですが、品質とかテスト関係のイベントとしては今回はだいぶ新鮮というか、新しいアプローチというか、一言でいうと来て良かった。抽選に当たって良かった。vol.1ではBDDとかTDDとか、Checking(正しく動くことを確認する)視点での話がされたようで、なんで私は落選したのだろうかと。そこ(も)聞きたかったよと。

今回の発表で下記のワードが出たかどうか分かんないけど、私的なキーワードとしては

探索的テスト大事 (多分このワードは発表内に出てこなかったけど)
フィーリング大事
全員がテスター

でした。

今回の発表内容と、松尾さんからの「技術の寄った話は(勉強会などで)されるけど、人に寄った話はあまりされない」というようなコメントを聞いて、この視点での開発者-テスター両者共通のコミュニティができたら面白いなと思ったです。

今回の勉強会に対する私の感想をまとめると、「結局はユーザーの手元で(製品の形で)ユーザーがやりたいことができるのかが大事なんだから、テストする対象もユーザーに出るのと同じものでやるのが一番効率がいいし、最近の流れから言えばチーム内で役割を分けるより小さいチームでみんながいろんな役割をやれるほうが強いチームなんだからプロジェクトマネージャも企画も開発もテスターもみんなでテストすべきだし、良い(バグを多く見つける)テストをするためにはテストの時だけ頑張ればいいんじゃなくて日常の中から「なんか変だぞ」って感じるところを大事にすべきだし、そこについて追究できる文化・空気感がいいよね」って、まとめが長くなりました。

長い上に補足しちゃいます。(ごめんなさい、こんなテンションになっちゃうくらい楽しい会でした)

「フィーリング」の話は発表資料を読んでいただければニュアンスわかっていただけるかと思いますが、そのフィーリングの感度を高めるためにやってること(朝会での開発者との会話とか、過去チケットあさるとか)ってのがあって、そういう視点が自分に無かったなーって思いました。

印象的だったのは懇親会で関さんから聞いた "全員がテスター" の話。（クックパッドの例ではないですが）開発者も1日1時間テスト（システムテストレベルの手動テストね）をする時間が持つことで、最終成果物に自分たちで責任をもつ、と。クックパッドでも同じようなスタイルみたいです。(手動テスト専任の人はいないという意味で)

語弊があったり、誤解を生じる書き方かも知れませんが 敢えて書くと、その場合のテストには(テスト設計コンテストに出てくるようなちゃんとした)テスト計画とか、テスト設計とか、テストケースすらも必要ないんじゃないかと思うのです。(何がどうなったらその機能が動いてるといえるのか、みたいな「実装完了条件」みたいのはあるべきだけど)

...という話をする時の私の前提は

開発対象は週に一回リリースするWebサービスで
アジャイルっぽい開発プロセスを採用していて
開発チームは4,5人で(プrダクトオーナーは別なイメージ)
そのチーム内でテストOKになったらリリースする
テスト専任の人は1人いたりいなかったり
リリース後に不具合が見つかっても修正すれば即時に全ユーザーに適用される

というプロジェクトなのですが、そこに「テスコンのような"ちゃんとした"テスト設計(の活動)」が入り込む余地が無いと思っています。なぜならテストベースが(ドキュメントとしては)無い、あっても曖昧、話し合いの場で決まる、後で変わる、な上に週に一回リリースするというサイクルにマッチしないからです。

一方で「テストをする」という行為は存在するわけで「良いテスト＝少ない工数でバグが多く見つかるテスト」を行う際に、テスト(設計)技法を駆使したほうがより良いテストができるかもしれないとも思っています。テスト実施者がテスト設計を知っている・身につけていることは有効かもしれないと思います。わざわざ「かもしれない」と書いたのは、テスト技法を知らない人でもバグをいっぱい見つける人はいるので、技法を知っていることとバグをいっぱい見つけられることにどれくらいの相関関係があるのか(私の体感値として)不明だからです。なので「テスト設計うんぬんよりも、全員で製品を触ってみる(というテスト)」の方が有効なんじゃないか、って思ったわけです。

※ここは誤解してほしくありませんが、今回の勉強会でそう言っていたわけじゃなく、これは「この勉強会に参加して、私が思ったこと」です。

そういうプロジェクトの進め方をする時に大事なのが、今回の発表に出てくるフィーリングというか、なんか変だぞと感じれる能力と、そこに至るまでのアンテナ感度上げる努力と、それを追究できる能力なんじゃないかと。この能力とそれをやる時間（ステークホルダーみんなで）を取ったほうが、結果として短時間でいいものが出せるんじゃないかと思った次第です。また、それを先導できる人がいたら強いチームになれると思うです。

懇親会の最後の方で(過去に弊社でもTDD研修をしていただいた) @t_wadaさんとTDD普及の話もできてとても良い時間を過ごせましたクックパッドさん本当にありがとうございます！

※ 以下、発表のメモです。スライド内の気になったところと、スライドに乗ってないコメントとか会場とのやり取りをメモりました。スライドに関しては上記の資料を見てもらったほうが確実です。

関将俊さんの発表

設計とテスト

ソフトウェア開発に必要なことは「設計」と「テスト」の2つ
テストとはバグを出すこと。エラーを見つけるのが良いテスト、という定義

CheckingとTesting

Checking
- 既知の情報の確認
- 待ち伏せ
Testing
- 新しい情報を探す。未知の問題を
- 探しに行く

感じる、壊す

「あれ、この製品、どこかが悪い気がする。。。」とか、退屈、使いにくい、不親切、、、というフィーリング →なにか悪いものがある

テストの前にフィーリングがある。「なにかおかしいぞ」を感じるの大事

私達のテスト

「感じる」

ポイントは「いつ、対象は、感じた後どうする」

いつ

製品を目の前にして
- 意外な振る舞い、使いにくさ、カッコ悪さ、過去の問題類似性
朝会で話を聞いて
- 普段の会話
- PGの態度、言葉
  - 自信のなさ、アリすぎ
これまでの嫌なことから、、、

対象

製品、仕様、実装、プログラマ

感じた後どうするか

Feelingを理解する
- 使ってみる、聞いてみる
考えながら触ってみる
- こうしたらどうなるか
- こうなってたらユーザーは困るか

↑ 違和感を確信に変えていくフェーズ

松尾和昭さん

CookpadでどういうTestingをしているか。いつだれが、どこで何をどのようにどうなるかを観察

観察する

いつもと違う？
- (朝会とか)話の中で気づく。
- 眠い、疲れた、とかそういうのを拾う
- チーム、メンバーの雰囲気、空気、人のメンタル大事。
githubのissue
- やり取りが多い
- 関係者が多い
- 話が複雑になってる
- →これらの機能はエラーがおおい
チャット
- 相談、話題、新しいもの、その他
- 不具合対応とかで盛り上がってる→開発者が集中できていない
席周辺
- 人の往来、相談の回数
- 技術基盤チームの近くにいて、そこに相談に来るときは技術的に難しいところ→その人が関わるissueを眺める
製品を触る
- 感情の変化、違和感という直感 ←人の直感は当たりやすい。コンピューターにまさる

感じ方をどういうふうに拡げていくか

感じ方、知り方を拡張
- 多彩な経験、考え、歴史、に触れる　(本とかじゃなくて
- 話す、見る、におう、触れる
視点を動かして拡張
- 大局と局所、全体と部分、組織と事業
- 役割の切り替え、繋ぎ目(人の役割も、コードの繋ぎ目も)

何が変わるか、かわらないか

変わらない、変わりにくい
- 感性、考え方　←25歳までに固まる。それ以降は変わりにくい
- 変わるにはストレスがかかる
変化することを知る
- 動機（があれば変えられないことが変えられる
- 環境（が変わると
- 組み合わせ（が変わると　
ストレスを上回るだけの何かを見つけると動機付けになる
- 振り返りの改善効果

(質問すればよかったなと思ったこと) → 社内でどれくらいこういう話ができるひと、ついてくる人、興味ある人がいるのかなー。

深谷美和さんの発表

朝会で知ること（朝会は30分～45分くらい）

担当者のこと
- 誰がどこをやってるか
もめていること
PGが混乱していること
- チケット（実装予定）がわかりにくい
- 実装者にきいてもわかっていない
PGが心配していること
- ちゃんと作るし、ちゃんと作れるんでしょ？
- 周りの雰囲気、声のトーン、不安、
- 想像した心配ごとを開発者、テスターに話す
  - どんなテストをしようとしているのか

前提としてmiwaさんはコードはわからないけど、会話の雰囲気とかから感じる。その場でわからなければ朝会の後とかに聞きに行ってる。また、新人研修として、朝会で思ったことを2次会で報告することをやらせている。そこで鍛えられる、とのこと。なるほど。。。

報告されたバグから多くのことを知る
- 新しい視点
  - PGや他のテスターは何を気にしているか
  - 自分が思いつかなかったバグ
- 知らなかった過去
  - 昔のチケットに遡る
- 振る舞いをしり、誤解していた仕様

この辺り、miwaさんのブログ　テスターは朝会から何を知るのか - CAT GETTING OUT OF A BAG　に詳しく書かれてて参考になります。

Story2 あるチケットのTesting

チケットをよむ

<自分メモ> (チケットには実装要件が書かれてる。半日～二日間でできる粒度らしい）

何ができるようになるのか
できたことはどやってらわかるのか（完了条件）
実装中におきていること（実装中のことが書かれているのが前提ね)
朝会とかでの情報アップデートもね

</自分メモ>

あやしい匂い
- たくさん書いてある
- 説明がコードっぽい
- 調査中、苦戦中、、、
- あっさりしてる、うまくいきすぎてる　のも要注意

動かしてみる

チケットに書かれているテストケースを忠実に動かす

Checkingの気持ち
あまり見つからない

ファーストインプレッション

初見に感じる「何か」を大切に
- 自分の想像していたものとの「差分」
- しばらくすると初見の「これ」を感じにくい
このあたりからTestingの気持ち

Testing

チケットにあるテストケース（正常系）を変形する

何を与えたら、与えなかったら
処理の途中を想像しながら、操作のタイミングを図る
複雑なものほど丁寧に
面倒なものほど落ち着いて
匂いの種類、強さによってバリエーションを変える
などなど・・・

↑人によって得意なところが違う

テスターモードからユーザーモードへ

ユーザーはどんな気持ちでこれに触れるのか
触れた時の手触り、見た目、全体としての統一感
触れた後、ユーザーは何をしようと思うのか
ユーザーのユーザーのユーザー　（cookpadの場合、ユーザーは料理をする人で、その先のユーザーは料理を食べる人
やりたいことが本当にできているのか

Q:どこでやめるのか A:時間で切る。やるべき全体に対して、勘だけどバランスとって「ここまででいいかな」で止める

過去に起きた嫌なこと

自分のチームで起きたこと
- 開発者、テスターとの会話から
- 10年分の過去チケットから
隣のチーム
ニュースになってること
普段の生活から

これから起きるかもしれない嫌なこと

朝会や日々の会話から
試せない心配ごとは誰かに話す

昨日との違い

なんとなく遅くなったな、とか
昨日は動いていたのに
昨日と見え方が違う
誰も触ってないけどあの機能が動かない

プログラマとの会話

朝会の会話でわからないことを教えてもらう
朝会で言ってなかったけど、雑談の中で聞いたら不安とか教えてくれる
丁寧に教えてくれる
プログラマと一緒にTestingもある

プロと無職との会話

直球
- ここにバグがあるからためしてみて
私のテストを止めに来るかかり

テスターとの会話

気にするところが違う
おかしいと感じたことを同僚はどう感じるか
- 自分が感じるおかしさ、への疑い
テストで会話
- Testingを見せ合う
- ペアテスティング
おかしさを見つけたら開発者の元へGO
- 現象を見せる(手順を確定させなくても現象を見せる）
- 何かを知りたがってるときがある
  - その場でTesting、再テスト
- おかしさの原因がわかると嬉しそうに話に来てくれる

おかしさはいつどこからやってくるのだろう

まとめ

Feeling,感じたことを大切にしてくれる土壌
人はミスをするという事実を受け入れる空気

非開発者がプログラム技術を使ったQAを目指すブログ

クックパッドエンジニアのトークナイト〜テストエンジニアvol.2 Testing編〜　感想

感想