告知ページ
スライド
www.slideshare.net
自己紹介
発表者
- 松尾和昭
登壇者
- 和田卓人
- 今日は開発者視点のテストについて話していきたい
- 諸橋恭介
- 開発者だが、Cucumberに興味あり
- 庄司嘉織
- E2Eテストが大嫌い
経歴
テストとクックパッドの働き方
- 大学時代は暗号系・分散コンピューティング系を研究
- 教授の影響でQAに興味を持つように
ACCESS入社
- テストを志向して入社
- 主にサーバーサイドをやっていた
- 異動したけど、テストをやり続けたかった
クックパッド入社
- Cookpadでは品質を向上させるためにテストを行う
QAとは何をする役割なのか？
Googleの場合
- Test Engineerはマニュアルテストをする人ではない
- QAの役割についてこれから議論すべきところ
Netflixの場合
- いかなるサーバ障害が発生してもお客様に提供できるようにする
- Computer scienceの修士を持っている人が資格
SWET(@DeNA)の場合
- テスト自動化する人
- Checkingを自動化する人
Cookpadの場合
- SWETよりも広い視点で募集している
- 自動化技術だけでなく、テスト設計や品質メトリクスなどの視点も必要
Qualityって？
- 品質とは誰かにとっての価値である
あなたのビジネスは何を生業にしていますか？
製造業から発展した方面の品質
- 物理的に壊れないこと
- 自然界を基準に計測可能
- 網羅的なテストが実施可能
受託開発からの品質
- 納品のために検査的なテストを行う
- お客さんとの合意形成のもと
- 顧客に数値を示す必要があるため
サービス業からの品質
- 合意形成したものはなかなか難しい
- 品質保証とは違う
サービス開発における品質の向上
- 価値検証をしっかり素早くできるようにし、
- 改善を繰り返して品質を向上させていく
サービスの開発速度を高めるためのTDD/BDD、自動化されたテスト
- TDDをやっていくようなエンジニアチームを作りたい
- ソフトウェアの内部品質を高める
ディスカッションの議題
この5年のTDDにまつわる話題について（和田さん）
- TDD/BDDというと、サイクルを回してないとダメみたいな感じ
- TDDはやってないけど、テストはやっているのが現状
- コードの形を表した自動テストは行ってきている
- やっている会社とやっていない会社の格差が離れていっている
- テストコードを書く文化、コードレビューをする文化があるかどうか
- 「テスト駆動開発」がtogetterで炎上していた原因は名前が悪い
- 「テストしてないじゃないか」と言われる
TestingとChecking（和田さん）
- 『ソフトウェアテストの技法』によると、Testingとは対象を破壊しようと試みてみることである
- 開発者はそのような思いでやっていない
- 「こう動いたら良いな」と思って書いている
- 破壊しようとしていない
- 開発者はそのような思いでやっていない
- 我々がやっているのはTestingではなくCheckingである
- 自動テストによって、過去にチェックしたものが今もチェックできるのが革命的だった
- コードに自信を持つことができた
- Testingには踏み込んでいない
- Checkingを高速化する時代は続いている
- Checkingを書き続けているプログラマーは定着率が高い
ここ5年間で変わったこと（和田さん）
- 会社として根付くところと根付かないところがある
- 5年間で使う人がすごい増えた
- 技術的にはすごい進歩は無い
- サイクルを回すというところに関しては、ちゃんと割りきって考えられるエンジニアが増えた印象
- 「それはTDDじゃない」というしょーもない燃え方も出てきた
- 狭義のテスト駆動開発と広義のテスト駆動開発を切り分けて考えるようになった
- テストを書くタイミングはバラバラだが、テストは書いている人は多い
Checkingは好き(庄司さん)
- 品質を担保しようとは思っていない
- 品質を保証するのは嫌いだが、仕事なので書く
- Checkingが終わる（想定通りに動く）と思った時点で興味が失せる
参考スライド speakerdeck.com
前職は人海戦術する必要があったりした
- ものを積み重なっていくほうが勝る時が来る
- 数年後にテストコードが無いためにバグを調査するコストがすごい現れる
サービスの開発速度を高めるために補完されるテスト
- 最短で道を駆け抜けるためのテスト
- テストを書いたことによって足かせになることも
再び、ディスカッションの議題
テストエンジニアの人と一緒にやるときに、どういうことを期待するのか
和田さんの思い
- スキルは相互補完するもの
- 自分が書くものをCheckingすることは開発者が得意
- 何をテストすべきか、どこまでテストすべきかは分からないことが多い
- Checkingの世界は自動化できるがゆえに力技でできるようになってしまった
- 沢山の重複なテストケースが残る
- 開発者は増やすのは得意だが減らすのが下手
- 開発者にとってはテストは無駄と漏れが分からない
- 組み合わせが減っていくはず
- 開発者がその部分もやるためには、勉強しないと分からない
諸橋さんの思い
- 不具合のパターン化
- Checkingの1プロセスは共通化していくようにする
- 何をテストすべきかを考えて欲しい
テストの保証をするということ
- テストの組み合わせだと膨大なのは確か
- コンパイルしたものを保証することを前提としてやっているが、本当に大丈夫なのか
サービス開発ならではの制約
- サービス開発はワンタイムではなく、長い間走って行かないといけないのが強い制約
- その中でどうやってやれば良いか
- 組織を作っていくことも必要
サービスや組織の発展に伴い進行する専業化
- クックパッドにおけるテストエンジニア、テストの形
現在
- 向上させるための土台作り
- 組織の潤滑油
今後
分散した組織における開発速度を保った成長の土台作り
日本はこういうことを共有できる人が少ないので仲良くしていきましょう
質疑応答
テストエンジニアの募集が集まらないのですが…
- なかなか集まらない
- 考え方が特殊と言われる
- マニュアルのテストエンジニアが多い
- そんな中で求めるのは難しい
- テクニカルな部分を求めると集まりにくい
クックパッドでは？
- 一人だけ
和田さんの考え
- Jobタイトルがテストエンジニアだと、ミスマッチが起こりやすい
- エンジニアの呼称を変えたほうが良いかも
- 違うスキルセットを求めているなら呼び方を変えたほうが良いかも
- 「リファクタリングエンジニア」と呼ぶのはどうか（松尾さんの意見）
QAエンジニアの価値について（庄司さん）
- 組み込みのQAエンジニアをやっていたら、外資のQAエンジニアの価値がすごい高かった
- 海外では1000万を超えるのがテストエンジニア
- 普通の開発エンジニアよりもものを知っている
- 例えば、Objectを握りつぶしてObjectを作り続けるとどうなるのか知っている
- そこから15年経ったが、まだまだ低く扱われているように感じる
- この状況を変えるには、松尾さんが鬼のように金を稼ぐのが良い
- お金ください（松尾さん）
テストコードが1個もない3ヶ月ぐらいで納品するSIなんですが、CIとかをどこで提供すべきなのか
庄司さんの考え
- 自分の業務（会社）にどのように当てはめるのか
- SIは昔からそういう状況だった
- 気にしないで自分でテストコードを書きだした
- 最初はコミットすらしなかった
- 少しずつコミットしたりしていった
- その後CIを使ったりした
諸橋さんの考え
- CIが無かった頃は延々と手動でテストしていた
- やっていったことで自動化が大事だと気づいていった
- まずは1人から始める
- 「周りに教えてから」という考えは良くない
- CIサーバも一人で立てられる時代になっている（野良CIサーバ）
和田さんの考え
- テストコードを書かないと動的検査ができないが、テストコードが無くても、静的検証ができるものもある
テストコードの書き方について。QAが入ることで必要最低限を知ることができると言っていたが、必要最低限についての情報はどこに書くのか
- 足りている状態を定義しなければならない
- 大体動けば良いよね、というのがWEB系サービス
- 落とし所を探すべき
- 組み込み系はリリース後の損害と網羅性の天秤がかけられる
- 適用のサイクルが短ければ、不具合のリスクが小さいので、網羅性が犠牲にできる
- 組み合わせの中である程度絞ってあげると、潜在的な不具合の8割が潰せる（OSSだと6割）という論文もある
- 因子水準などから導き出せる表をヘッダーに貼ったり、ドキュメントが書いてあるGitHubのURLを載せたり
エンジニアの開発者テストはCheckingが多いと言っていたが、シナリオテストは開発者がやるべきなのかテストエンジニアがやるべきなのか
諸橋さんの考え
- シナリオテストもTestingとCheckingを作るのが良い
- Checkingの土台を使ってTestingを行うと良い
庄司さんの考え
- E2Eテストはブラックボックステストに値するので、中の仕様が知らない人が書くべきである
- 開発者はホワイトボックステストを書くべきである
- 両方を区別して書けるエンジニアがいたら、スーパーエンジニアだと思う
松尾さんの考え
- Testingは人の感情が入っていると思う
- Checkingは機械的に判断できる
- UIの気持ちよさは機械で判断できない
認知の話（和田さん）
- 人間は気づかないことを判断できない
- TDDで完璧という人は、自分が想定している中だけの完璧
- 第三者機関はそういうためにある
- Testingは感覚・感情・センスが必要
- その人が見つけたことをCheckingで再現することは可能
- 気づかないことを気付くことが大事
- ランダム性や全数など、Checkingにゆらぎを持たせる試みもある
- どうやって気づかせるのかは考える必要がある