Testing Casual Talks #1 に行ってきた
Testing Casual Talks #1
http://atnd.org/events/40914
昨日補欠から繰上げになったので無事参加できた。よかった。
会社のメンバー6人で参加。全員参加できてよかった。
※セッションの内容は自分が変に理解してたらごめんなさい(´・ω・`)
会場
渋谷ヒカリエ。初ヒカリエ!
シャレオツでナウい感じでした。
入り口に証券取引所みたいな輪になった液晶ディスプレイあったり。
オフィスのフロアにローソンあったり。
格差社会ですね。
参加者160名ということで、会場もめちゃ広。
1会場にスクリーン4つとか裏山。
今回はUstreamでの配信もあるとのことで、
カメラで撮影があるんですが、ガチなカメラですげぇ。
撮影者用のブースあるし!
Wi-Fi完備、電源も使って良いなんて何て素晴らしい。
入り口でとりあえずステッカーとパンフと水もらった。
案内板の他スタッフの皆様の誘導もたくさん。
何てホスピタリティにあふれた勉強会なのかしら!
開会
まずは@ikasam_aさんのSoftware Engineer in Testをやって思ったことあらためSoftware Engineer in Test DeNA
No.1 Software Engineer in Test @DeNA
- Speaker:@ikasam_aさん
- DeNAでQA立ち上げたりされた方
- SWET(Software Engineer in Test)
- or TE(Test Engineer)
- テストに関するソフトウェア開発者のすべき役割
- a developer role for testing
- write test framework
- build test environments
- write tests
- Google Testing Blog
- SETの定義
- テストするだけ、実施するだけ、ではないテストに関わる活動全般
- ソフトウェアエンジニアをサポートするためにテストを実施したり
- 自分でテストを書いたり
- 呼び方いろいろ
- SWET @DeNA
- SET (Software Engineer in Test) @Google
- SDET (Software Development Engineer in Test)@Microsoft
- Developer Productivity
- 開発者の生産性の向上のための、チームが近年盛ん
- プロダクトにこだわらず横串でサポートするチーム
- たんぽぽチーム的な
- SWETはテストをサポート。横串に重なったり、重ならなかったり。
- 「生産性の向上」がゴールなのはサポート部隊と変わらない
- Tools
- テストしようとしてあるものだけだと足りない
- 自分で開発したりする必要ある時もあるよ
- 最近のRspecとかだとテストかけば簡単に実行できる
- Cのテストフレームワークとかだと自分でテストの数カウントしなきゃいけないとか
- tearDown/setUpなかったり(´・ω・`)
- 自分たちのテストを作るための、サポートツールを作るイメージで、monkey patch…
- Do Everything
- 自動化するためにあらゆるところにテストを書いた
- 全てにおいて自動化する
- Automation
- JS
- PhantomJS
- QUnit + qunit-tap.js @t_wada
- Java
- Maven2 + local repo
- モジュール管理とかまで自動化した
- テストにこだわらず生産性向上のために自動化自動化
- JS
- QA Process
- 従来型のプロセスと自動化プロセスが相容れないところがある
- 従来型のプロセスの壁
- QA部門と開発部門の壁
- Testing Activities SHOULD be in Developments
- テストは開発活動の中で行うべきではないか
- -> Google Testing Blog
- QAチーム
- QAチームなんだけど、やってることはSWET
- 開発者が機能をどんどん開発できるようにするためにプラットフォームの品質を守る事を宣言
- 自動テストを書く!
- →プラットフォーム全体のクオリティを保つ
- テスターじゃなくてテストエンジニアだよ
- Mobage Open Platform の Target & Level
- 外に出てる箇所(API, Gadget)は全部テストすべき
- Integration のテストが不足してる
- テスト用のブラウザゲームを作ってる
- テストを実行するためのスマホエミュレータ(ブラウザ)を自分たちで作ってる
- APIのクライアントツールも、モバゲーに特化したクライアントツールを作ってる
- techniques
- Gray Box Testing
- End2End test -> black box test & white box etxt
- Test fixture -> gray box test
- Gray Box Testing
- Policy
- Test Enginieering ( not tester)
- gray box ができる
- clean codes
- テストコードはキレイじゃないとメンテできない
- Gray box
- 非常にスキルを求められる
- black box を理解してテストする必要がある
- white box で中のこともわかってなきゃいけない(プロダクトコード含む)
- 第3者のテスターじゃなくて自分も開発者だって意識
- Code quality
- reqdable / writable / mentenable
- まとめ
- ここ1年半で E2E Testを書いてきた
- SWETとしてやる事を意識してきた
- 1年半かけてテストを整備してきた
- テストと開発者との距離は大分減った
- SWETのロールは理解する事がいっぱいあって、ハードでクレイジー
- 奥が深いから楽しい
- テスト
- テスティング自体の生産性、テストによる開発の生産性
- テストによる開発の生産性
- 新規開発にリソースを避ける
- テスティング自体の生産性
- テストコードのリファクタとかちゃんとやって、テストの生産性落ちないように頑張る
- プロダクトコードとテストコードのリファクタの違い
- プロダクトコードの方はビジネス要件によって捨てなきゃいけない事がある点が大きく違う
session 1 :: words
- CI/CD
- Webrat(カピパラさんの前身)
- sexyhook(Win32 APIのstabがあてれる!)
No.2 How to make easy and casual CI management
- @mrknさん
- COOKPAD
- 村田さん
- 開発基盤エンジニア
- 学生の皆さんは9月に5日間のインターンシップCOOKPADでやるから応募してねっ
- 学生じゃない皆さんはキャリア採用やってますので応募してねっ
- CIの管理を簡単かつカジュアルに取り組む
- 背景(1年前)
- 1年前にCookpad当時の状況を共有したことがある
- テストがめっちゃ増えた
- 8-core パラレルで1時間超える実行時間
- マシン台数14台に増やしたら実行時間短くなってよかったよかった
- そして現在
- Model 988個 ( before 861)
- LOC 17381 -> 19915
- Modelが毎月10個ずつ増えてく(´・ω・`)
- 13177テスト -> 10分以内に実行できてる
- 14台 -> 6台になった。
- そう、Ruby2.0ならね!
- 問題
- テストが増え続けてしまってる(1年で2倍に)
- 実行時間は減ったけど、それはたまたまRuby2.0で高速化したから\(^o^)/
- 対策うたないと来年死ぬ
- WHY
- Cookpadが巨大なRailsアプリケーションだから
- chanko -> product
- ちゃんこは仕様が固まるとテストが充実してきてプロダクトリリースされる
- 機能が増えてくー>テスト増えてくー>\(^o^)/
- 今後もCOOKPADは成長していく
- どうするか
- これからはCookpadのRailsを拡張する(single rails)のではなくて、複数のRailsアプリケーションを作るようにする
- 既存のモデルはAPI経由でアクセスできるようにした
- みんなのカフェ、おむすび犬とかが、そんな感じで(multiple rails)作られた
- 結果
- アプリケーションの単位で並行処理させればいいよね
- だけど
- アプリ増えすぎるとどうする?
- 現在
- 26個のジョブがある
- Nodeを分割してる
- 日中しか起動しないNode、深夜帯しか起動しないNode
- CIをパスしないとリリースできない仕組みがある
- Jobを自動で作成してくれるツールを作成中
- いろんな管理ルール含めて開発エンジニアがJob作るの大変だけど今後の事考えると2人が管理するの辛い
- アプリケーション固有の項目以外は、YAMLに設定した値が適用されるようなツール
- Whitesnake
- GitHubに公開済みだからforkしてねっ☆
- mrkn/whitesnake
No.3 私にとってのテスト
- @t_wadaさん
- 和田 卓人さん
- emo枠w
- 品質について
- 品質とは何か
- 難しい議論・発散する議論になりがち
- 「品質とは誰かにとっての価値である。」お、おう・・・
- 難しそうで学ぶことたくさなって、怖そうに見えがち
- 「「品質」っちゅうから難しく聞こえてしまうんや。「質」と言えば皆わかってくれる。」
- 「質」の事ならみんなしってるよねー
- 私達には、何か「良い物」を見抜く能力がそなわっている
- QWAN ( Quality without a name (名づけ得ぬ質))
- 品質とは何か
- TDDのTについて
- テストと一言にいってもいろいろ
- Brian Marick による四象限モデル
- TDDによるテスト
- 開発チームのサポート的なニュアンス
- マウスだけでひたすらテスト
- 創造的破壊行為
- TDDによるテスト
TDDのテストは創造的破壊してないんじゃないの?
- TDD == testing ? or checking ?
- TDD は checking
- んじゃ名前変えようぜ議論は大昔からずーっと。
- BDD
- Spec BDD (ex: Rspec)
- Scenario BDD (ex: Cucumber)
TDDのTは品質のどこを着にしてるのか
- メンテナビリティとか
- (TDDの)良いテストとは
- checking の文脈においての良いテスト
- FIRST is good test
- Fast independent repeatablity ,,,
- R > S >>> I >>>>>>>>> F >>> T
- A-TRIP
- 良質なテスト
- 自動, 徹底, 繰り返し可能, 独立, 専門的
- プロダクトコードと同じスタンスでメンテしましょう
- 偉人がいう良いテスト(diff / uniq)
- Indipendent(UnitTestが独立している)
- Repeatable(繰り返し可能・環境を選ばない)
- 良いエンジニア
- 「テストでは品質は上がらないよ。品質を上げるのはプログラミングです。」
- 技術で才能に立ち向かう
- 一筆書きで一発でバッチリなコードかける才能が無い人間はTDDで頑張る
- 目指すところ
- シンプルさ
- シンプルさは信頼性の前提である
- Simplicity matters
- 複雑さはシステムに損傷をもたらす
- まったく同じ予測をする2つの競合する理論があるときは、単純な方が優れている
- これにシステムでチャレンジしていくのがTDD
- シンプルさ
- 私にとってTDDとは何か
- 凡人が頑張るためのやり方
- Fowlerによる技術的負債の四象限モデル
- 無謀な・分別のある / 自覚的・無自覚
- 自動テストの良いところは、改善を我慢しなくても良くなった
- 動いてるコードに手をいれてはいけない!っていうのがなくなった
- 仕様が固まる事は無い
- 開発が終わる事は無い
- 理解は常に進化する
- スキルも常に進化する
- 技術も常に進化する
- 良いテスト
- 変化を妨げないテスト
- 変化を後押しするテスト
- TDDとは「悪あがき」。あきらめずに改善したい。自分のコードを嫌いたくない。
- TDDはスキルです。才能ではなく練習です。
休憩
5分間
第2部
すたーと
No.4 Casual CI Server
- @r7kamuraさん
- COOKPAD 中村さん
- Chankoリファクタして2.0にした
- Casual CI Server
- 家のあらゆる事を自動化したい
- Javaで自動でゴミ出すのは難しいw
- Jenkins Clone つくりたい
- 巨塔Jenkins
- Jenkins
- javaです
- CI Joe
- GitHubの社内でJenkinsから乗り換えようとした
- Git前提で、Sinatra製
- 2年前に開発を止めたらしい
- Ukigumo
- Amon2製
- by tokuhiromさん
- client / server
- clientで実行して、サーバーにはデータを保持するだけ的なあれやそれ
- 自分で作ろうと思ったもの
- Jenkinsほそ高機能じゃなくて良い
- Pluginで拡張
- もっとカジュアルにプラグイン書きたい
- Rails4盛り上げたい
- Altria
- https://github.com/r7kamura/altria
- 普通のWEBアプリっぽい感じ
- まとめ
- AltriaというCI Sererを作ってみました
- 普通のWEBアプリと同じように作れる
- カジュアルにプラグインが書ける
No.5 DevQUT!
- @snskさん
- @YasuharuNishiさん
- ASTER:ソフトウェアテストの団体
- 3日でテスト 〜軽量品質保証どうでしょう〜 あらため DevQUT!
- 中身はめっちゃ多いのでスライドシェアで読んでね
- 「品質保証」は厳しくて難しそうなおじさんがはんこ押す感じ?ー>重いねー
- 軽くできないかなー
- ただたんに軽くするだけだと、ヌケモレあんじゃねぇか疑惑
- わかった!無駄な事したくないだけなんだ!
- 重たい品質保証は一般的に壁を作る
- 重たいから「品質保証」なんだ!みたいな感じってない?
- 重い品質保証なんて時代じゃない
- 壁を壊そう
- QA・開発・っていうラベリングによる壁
- Dev + QA + User + Tools => DevQUT (でぶきゅーと)
- DevQUTができる組織ー>コミュニティ化する
- 提供側と消費者側の壁を壊して成功させる
- ミク的な何か
- このへんをソフトウェア開発におとしこめないか
- DevOpsと近いよねん
- 提供側と消費者側の壁を壊して成功させる
- examples
- Dev + QA
- QAが開発を信用してない
- お前ら何やってるかわかんないからプロセスに従え
- 開発者は「面倒くせぇ」と思ってる
- 良いプロセスを提案する事もしない
- 壁ができちゃってるよね *( 時間が無い\(^o^)/)
- Dev + QA
- 何が大事で何がやばいかをDevとQAで一緒に考える
- QAテスティングギャザリングシーズン っていうカードゲーム風何か
- 開発とQAが仲良くできると、良い感じ
No.6 serverspecによるテスト駆動サーバ構築+CI
- @gosukenator
- mizzy さん 宮下さん
- serverspec 作者
- 今日はserverspecの細かい説明はしないよ
- demo
- テスト駆動サーバー構築
- Puppet / Chef に TDD 持ち込む
- すげー。起動・サービス登録とかのチェックが超ラクチンじゃん。
- Docker (VM管理ツール)
- DockerのVMに対してChef/Puppet走らせてserverspec的な?
- Dockerは落とすと元に戻ってるので何回でもテストできる
まとめ
おもろかった。意識高まるわー。極まるわー。
スピーカー、スタッフ、ご関係者各位、ありがとうございました。