クックパッドエンジニアのトークナイト〜クックパッドテストエンジニアのあり方〜に行ってきました #cooketn

クックパッド株式会社さんで開催された『クックパッドエンジニアのトークナイト〜クックパッドテストエンジニアのあり方〜』に行ってきたメモ。

connpass.com

クックパッドテストエンジニアのあり方

松尾さんのスライドに沿って、要所要所で t_wadaさん、諸橋さん、yoshioriさん含めたパネルディスカッションが入る進行。

20151021 cookpad talk_test_engineer from Kazuaki MATSUO

www.slideshare.net

以下、メモ。

クックパッドでは、"Quality Improvement"と位置づけられている。品質"保証"ではない
呼び方：QA、テストエンジニア、テスター、etc...
募集から見てみると、やはり様々
- Test Engineer @Google
- Senior Software Engineer @Netflix
- SWET @DeNA
- テストエンジニア @cookpad
Qualityとは？
- 「品質とは誰かにとっての価値である」
- あなたのビジネスは何を生業としていますか？
  - 自動車など、製造業：腐食など経年劣化まで含めて保証 -> Quality Assuranceという考え方
  - 受託開発：納品のため。合意形成した指標を満足する。また、それを示す。 -> これもQuality Assuranceでok
  - サービス業：利用時の品質、ISO 25000, ISO 9241, ITILなど。対人なので「保証」はそぐわないのでは？
    - 価値検証を「しっかり素早く」し、改善を繰り返して品質を「向上」させる
      - TDD/BDD、自動化されたテスト、内部品質を高める
TDDと品質
- 5年くらい前に炎上した話題。5年経過した今は？
- t_wadaさん：
  - 厳密なTDDをやってる人は少ないけど、自動テストを書いている人は増えている、という印象。業界/会社ごとに乖離している。
  - 炎上の原因。「テスト駆動開発」の「テスト」という言葉。testでなくchenkだよねという話。「テストとは対象を破壊しようとする試み」（マイヤーズ『ソフトウェアテストの技法』）を前提とすると、TDDのテストとはcheckingである。
    - see: Testing vs. Checking « Developsense Blog
    - see: Testing and Checking Refined | James Bach’s Blog
  - 開発者テストは書く習慣がつくと、なかなかやめない。
  - 割り切って考えられるエンジニアが増えた。「それはTDDじゃない」みたいなTDDの定義の話でなく、自分のスタイルでテストは書く、という方向。
サービスの開発速度を高めるために補完されるテスト
テストエンジニアに求めているもの
- t_wadaさん：テスト書きすぎ問題。適切に減らすのが難しい。どこまでテストするのか
  - see: 直交表、ペアワイズ法。ツールとして、PICT、PictMaster
- 諸橋さん：不具合のパターン、ユーザのイレギュラー操作を突くテストケース
サービスの開発速度を高めるための組織
- 専業化していく？ Quality Engineer, Software Engineer in Test, Test Engineer, etc...
- クックパッドでは、今：土台作り、テスト環境の改善。発展させていきたい

ソフトウェア・テストの技法第2版

作者: J.マイヤーズ,M.トーマス,T.バジェット,C.サンドラー,Glenford J. Myers,Todd M. Thomas,Tom Badgett,Corey Sandler,長尾真,松尾正信
出版社/メーカー: 近代科学社
発売日: 2006/08
メディア: 単行本
購入: 7人クリック: 267回
この商品を含むブログ (46件) を見る

質疑応答

テストエンジニアを募集したけど集まらなかった
- テストエンジニアはそもそも少ない
- 欲しいスキルセット、応募側のスキルセットの解離があるのでは？ GoogleやNetflixのように、ちゃんと名前をつけるべきでは？
- 海外/外資だとQAの地位が高い。知識も高い。まず松尾さんが高給取りになるべき
テストコードがないプロジェクト
- まず自分だけでもテストを書く。徐々にまわりに広げる
- 先にCIサーバを立てて、静的解析やインスペクションだけでもまわす。周りに、面白そう、楽そう、という印象を与えて広める
テストの過不足、十分性
- 足りている状態を定義、どこをokのラインとするか。正常系を優先とか。リスクの高低で評価する
- 組み合わせテストも、組み合わせ数の十分性がレポートとして出ているので基準にできる。判断根拠の資料は残すべき。
End to Endテストは誰が書くべきか
- 諸橋さん：E2Eのシナリオも開発者が書く限りchecking。テストエンジニアによってtestingに持っていく
- yoshioriさん：black box/white boxで考える。E2Eはblack boxで中身を知らない人が書くべきなので、分業が理想
- 松尾さん：checkingは自動で判断できるところまで。ユーザビリティなど人間がやるところがtestingという切り分け
- t_wadaさん：気付かないものは気付けないので、それが開発者テストの限界。テストエンジニアが探索テストで見つけた不具合を自動テストで再現して自動テストに取り込んでいく。checking を拡張してtestingに。ランダム性、揺らぎを取り入れることで自動テストを拡張する