Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
組織にテストを書く 文化を根付かせる 戦略と戦術 和田 卓人 (@t_wada) Feb 16, 2016 @ 日本OSS推進フォーラム
和田 卓人 id: t-wada @t_wada github: twada
gihyo.jpの連載 『［動画で解説］和田卓人の テスト駆動開発 講座』 http://gihyo.jp/dev/serial/01/tdd/ 全20回すべて動画付き解説 ニコニコ動画でも見れます WEB+DB過去記事の特設サイトと動画も
Do you write tests?
戦略編
• レガシーコード改善に正解はない • テスト自動化は銀の弾丸ではない • 導入方法にも銀の弾丸はない • 導入を目的にしてはならない • 状況は現場によって全て異なる 銀の弾丸は無い
ストレス テスト
自動テスト ストレス
テストを書く時間がないので はなく、テストを書かないか ら時間がなくなるのです。 James Grenning
• 文化の醸成は年単位の事業になる • 「テストを書く時間がない」のでは なく「テストを書かないから時間が なくなる」 • 「動くコードに触れるな」と戦う。 触れなければコードは緩やかに死ん でいく 文化を変える
動くコードに触れなければ死あるのみ
• ToBe ではなく AsIs と NotToBe からはじめる • 隣の芝は青い。気にしないこと • 人は自分の速度でしか成長できない • プロジェクトもプロジェクトの速度でしか成長 できない • 「まわりはもうみんなやっていますよ」は劇薬...
• 快不快で動く人、損得で動く人 • リファクタリングの快感 • 回帰テストのお得感 • メトリクスの達成感 • そしてビジネス価値 人を知る
• 人はそれぞれの度合いで変化に対して 身構える • 前例がない、事例がない • 「リファクタリングのジレンマ」 • リファクタリングを独立タスクにす ると、そのタスクは着手されない 変えることの難しさ
事前に許可を得るより、あと で許してもらう方が楽 Grace Hopper It is easier to ask forgiveness than it is to get permission
• 仕様が固まることはない • 開発が終わることはない • 理解は常に深化する • スキルも常に深化する • 技術も常に進化する すべては変化する
技術的負債の四象限 設計する時間がないん だからしょうがない 今すぐリリースしない といけない。あとでど うにかしよう レイヤー化？ なにそ れ？ もっとこうすべきだっ たなぁ 無鉄砲 慎重 意図的 不注意 http://bliki-ja.gi...
• 品質が「わかる」ようになる • わかることこそ大事 • 体重計に乗るだけでは痩せない • テストを書くだけでは、良くはならない • 品質を上げるのは設計とプログラミング • 再設計とリファクタリングをテストで支える テストは品質を上げない
戦術編
• 「何が一番やばいですか？」 • 最も困っているところから • お金、個人情報、…… • 新機能開発から • バグ修正のところから • 静的解析でピンポイントに どこからやるか
• リスク • 手動テストのコスト • 自動化コスト 塹壕からのテスト戦術
• 一度に多くの人を変えるのは難しい • 育てるのではなく、自ら育つように • 教えられる人を増やす • ペアプロで一人ずつ • 若手のホープか、ベテランからか だれとやるか
• 最初から全部やろうとしない • テスト駆動にこだわるな • テストファーストにこだわるな • 「ユニット」テストにこだわるな • テストの実行速度にこだわるな • テストの網羅性にこだわるな こだわるな
• 良いユニットテストの指標にも優先 度がある • 再現、繰り返し可能 (Repeatable) • 独立している (Independent) • 他はそれからでいい こだわろう
• 何はなくとも読むべし • 「仕様化テスト」のススメ • 「絞り込み点」を探す レガシーコード改善ガイド
• 割れ窓理論 • メトリクスを取ろう • カバレッジが低いうちは測定は効果大 • 小うるさいツールを乗りこなす • 分母分子を見ない。時間を追った変化 を見る。傾きを見る。 見える化
• 動的テストと静的テスト • 全体のメトリクスを計測して俯瞰の 視点を得る • 部分的なメトリクスを計測し続けて 傾向を見る • PMD, rubocop, Coverity,… 静的解析を使いこなす
• コードレビューのインフラに投資す る • github, gitlab, gitbucket • WIP pull request • コードを見る文化、見られる文化を 育てる コードレビュー
• テストがないのは既に設計が悪い兆候 • 設計/実装を変えるのが前提 • 実装のテストを書かないこと • テストがカバーする範囲に遊びを持た せ、カバー範囲内をリファクタリング • 状況に応じて E2E テストを使いこなす 設計の可動域を確保...
• サンプルとデモが大事 • 真似してもらう土台を作る • 最初はサンプルのコピペでも良い • テストのある生活を体験してもらう ことが大事 • 次にテストのメンテナンスを学ぶ 背中を見せる
• できるからやるのではない • やるからできるようになる • あなたが書けるようにならなければ、 誰も書けるようにはならない Social Change starts with YOU
テストはプロの嗜み ご清聴ありがとうございました
組織にテストを書く文化を根付かせる戦略と戦術
Upcoming SlideShare
Loading in …5
×

組織にテストを書く文化を根付かせる戦略と戦術

70,267 views

Published on

組織にテストを書く文化を根付かせる戦略と戦術
Feb 16, 2016 @ 日本OSS推進フォーラム

Published in: Technology
License: CC Attribution License
no profile picture user

  • Login to see the comments

Show More

組織にテストを書く文化を根付かせる戦略と戦術

  1. 1. 組織にテストを書く 文化を根付かせる 戦略と戦術 和田 卓人 (@t_wada) Feb 16, 2016 @ 日本OSS推進フォーラム
  2. 2. 和田 卓人 id: t-wada @t_wada github: twada
  3. 3. gihyo.jpの連載 『［動画で解説］和田卓人の テスト駆動開発 講座』 http://gihyo.jp/dev/serial/01/tdd/ 全20回すべて動画付き解説 ニコニコ動画でも見れます WEB+DB過去記事の特設サイトと動画も
  4. 4. Do you write tests?
  5. 5. 戦略編
  6. 6. • レガシーコード改善に正解はない • テスト自動化は銀の弾丸ではない • 導入方法にも銀の弾丸はない • 導入を目的にしてはならない • 状況は現場によって全て異なる 銀の弾丸は無い
  7. 7. ストレス テスト
  8. 8. 自動テスト ストレス
  9. 9. テストを書く時間がないので はなく、テストを書かないか ら時間がなくなるのです。 James Grenning
  10. 10. • 文化の醸成は年単位の事業になる • 「テストを書く時間がない」のでは なく「テストを書かないから時間が なくなる」 • 「動くコードに触れるな」と戦う。 触れなければコードは緩やかに死ん でいく 文化を変える
  11. 11. 動くコードに触れなければ死あるのみ
  12. 12. • ToBe ではなく AsIs と NotToBe からはじめる • 隣の芝は青い。気にしないこと • 人は自分の速度でしか成長できない • プロジェクトもプロジェクトの速度でしか成長 できない • 「まわりはもうみんなやっていますよ」は劇薬 なので用法用量を守って使うこと イマココから始める
  13. 13. • 快不快で動く人、損得で動く人 • リファクタリングの快感 • 回帰テストのお得感 • メトリクスの達成感 • そしてビジネス価値 人を知る
  14. 14. • 人はそれぞれの度合いで変化に対して 身構える • 前例がない、事例がない • 「リファクタリングのジレンマ」 • リファクタリングを独立タスクにす ると、そのタスクは着手されない 変えることの難しさ
  15. 15. 事前に許可を得るより、あと で許してもらう方が楽 Grace Hopper It is easier to ask forgiveness than it is to get permission
  16. 16. • 仕様が固まることはない • 開発が終わることはない • 理解は常に深化する • スキルも常に深化する • 技術も常に進化する すべては変化する
  17. 17. 技術的負債の四象限 設計する時間がないん だからしょうがない 今すぐリリースしない といけない。あとでど うにかしよう レイヤー化？ なにそ れ？ もっとこうすべきだっ たなぁ 無鉄砲 慎重 意図的 不注意 http://bliki-ja.github.io/TechnicalDebtQuadrant/
  18. 18. • 品質が「わかる」ようになる • わかることこそ大事 • 体重計に乗るだけでは痩せない • テストを書くだけでは、良くはならない • 品質を上げるのは設計とプログラミング • 再設計とリファクタリングをテストで支える テストは品質を上げない
  19. 19. 戦術編
  20. 20. • 「何が一番やばいですか？」 • 最も困っているところから • お金、個人情報、…… • 新機能開発から • バグ修正のところから • 静的解析でピンポイントに どこからやるか
  21. 21. • リスク • 手動テストのコスト • 自動化コスト 塹壕からのテスト戦術
  22. 22. • 一度に多くの人を変えるのは難しい • 育てるのではなく、自ら育つように • 教えられる人を増やす • ペアプロで一人ずつ • 若手のホープか、ベテランからか だれとやるか
  23. 23. • 最初から全部やろうとしない • テスト駆動にこだわるな • テストファーストにこだわるな • 「ユニット」テストにこだわるな • テストの実行速度にこだわるな • テストの網羅性にこだわるな こだわるな
  24. 24. • 良いユニットテストの指標にも優先 度がある • 再現、繰り返し可能 (Repeatable) • 独立している (Independent) • 他はそれからでいい こだわろう
  25. 25. • 何はなくとも読むべし • 「仕様化テスト」のススメ • 「絞り込み点」を探す レガシーコード改善ガイド
  26. 26. • 割れ窓理論 • メトリクスを取ろう • カバレッジが低いうちは測定は効果大 • 小うるさいツールを乗りこなす • 分母分子を見ない。時間を追った変化 を見る。傾きを見る。 見える化
  27. 27. • 動的テストと静的テスト • 全体のメトリクスを計測して俯瞰の 視点を得る • 部分的なメトリクスを計測し続けて 傾向を見る • PMD, rubocop, Coverity,… 静的解析を使いこなす
  28. 28. • コードレビューのインフラに投資す る • github, gitlab, gitbucket • WIP pull request • コードを見る文化、見られる文化を 育てる コードレビュー
  29. 29. • テストがないのは既に設計が悪い兆候 • 設計/実装を変えるのが前提 • 実装のテストを書かないこと • テストがカバーする範囲に遊びを持た せ、カバー範囲内をリファクタリング • 状況に応じて E2E テストを使いこなす 設計の可動域を確保する
  30. 30. • サンプルとデモが大事 • 真似してもらう土台を作る • 最初はサンプルのコピペでも良い • テストのある生活を体験してもらう ことが大事 • 次にテストのメンテナンスを学ぶ 背中を見せる
  31. 31. • できるからやるのではない • やるからできるようになる • あなたが書けるようにならなければ、 誰も書けるようにはならない Social Change starts with YOU
  32. 32. テストはプロの嗜み ご清聴ありがとうございました

×