Downloaded 12 times
Uploaded byKotaro Ogino
【楽天テックカンファ前夜祭2014】誰がテスト自動化をするべきか #rakutentech
誰がテスト自動化をするべきか 継続的システムテストスピンオフ企画第一弾 ~あなたのテスト自動化は大量のテストを高速実行するだけですか？〜 というタイトルのLT発表のスライドです。 詳細はこちらです。 http://kokotatata.hatenablog.com/entry/2014/10/24/190131
More Related Content
Similar to 【楽天テックカンファ前夜祭2014】誰がテスト自動化をするべきか #rakutentech
【楽天テックカンファ前夜祭2014】誰がテスト自動化をするべきか #rakutentech
- 1.
- 2. 2 「テストの自動化」 と聞くと 何をイメージしますか？
- 3. 3 「テストの自動化」 と聞くと 何をイメージしますか？ 大量のテストを 高速に実行する事
- 4. 4 “俺”のテスト自動化 開発PRJで •１万件のテストシナリオ •100時間の実行時間 のシステムテストを自動化
- 5. 5 “俺”のテスト自動化 開発PRJで •１万件のテストシナリオ •100時間の実行時間 のシステムテストを自動化 継続的システムテスト
- 6. 6 継続的システムテストについて社外講演 http://www.jasst.jp/ http://www.juse.jp/sqip/symposium/
- 7. 7 そろそろこのディスカッションに決着をつけようか 「テスト自動化って 誰がするべき？」
- 8. 8 テスト自動化の大変なところ 仕様 設計 レビュー テスト実装 プロセス 機能実装 プロセス レビューテスト
- 9. ①十分な量のテストを自動化 出来ないとバグを見逃してしまう 9 テスト自動化の大変なところ 仕様 設計 レビュー テスト実装 プロセス 機能実装 プロセス レビューテスト テスト自動化= 大量のテストの高速実行?
- 10. 10 ある開発PRJでの2013年のバグカーブ 100 80 60 40 20 0 0 500 1000 (検出バグ数) 累積コミット数
- 11. 11 大量のテストを高速実行しているだけだと… 100 80 60 40 20 0 0 500 1000 (検出バグ数) 累積コミット数
- 12. 12 大量のテストを高速実行しているだけだと… 100 80 60 40 20 0 イテレーション終了のギリギリまで バグが出続ける= 炎上 0 500 1000 (検出バグ数) 累積コミット数
- 13. ①十分な量のテストを自動化 出来ないとバグを見逃してしまう 13 テスト自動化の大変なところ 仕様 設計 レビュー テスト実装 プロセス 機能実装 プロセス レビューテスト
- 14. ①十分な量のテストを自動化 出来ないとバグを見逃してしまう 14 テスト自動化の大変なところ 仕様 設計 レビュー テスト実装 プロセス 機能実装 プロセス レビューテスト テスト自動化= 開発プロセスの品質改善
- 15. ①十分な量のテストを自動化 出来ないとバグを見逃してしまう 15 開発プロセスの品質改善からみた テスト自動化の大変なところ 仕様 設計 レビュー テスト実装 プロセス 機能実装 プロセス レビューテスト
- 16. ①十分な量のテストを自動化 出来ないとバグを見逃してしまう 16 開発プロセスの品質改善からみた テスト自動化の大変なところ 仕様 設計 レビュー テスト実装 プロセス 機能実装 プロセス レビューテスト ②抜け漏れや間違いが あると手戻りが大変 ③同時に終わらないと サイクルタイムが遅くなる！！ ④欠陥特定は 自動化が困難
- 17. 17 開発プロセスが品質改善されテスト自動化がうまく回ると 100 80 60 40 20 0 0 500 1000 (検出バグ数) 累積コミット数
- 18. 18 開発プロセスが品質改善されテスト自動化がうまく回ると 100 80 60 40 20 0 0 500 1000 (検出バグ数) 累積コミット数
- 19. 19 開発プロセスが品質改善されテスト自動化がうまく回ると 100 80 60 40 20 0 イテレーションの初期で バグが見つかる！！ 0 500 1000 (検出バグ数) 累積コミット数
- 20. 20 開発プロセスの品質改善とテスト自動化のスキルセット スキルセット ①抜け漏れや間違いレビュースキル （アプリケーション知識） （運用知識） （設計知識） （テスト容易性） ②網羅的な自動テス ト 様々なテスト設計技法 ソフトウェア開発スキル 網羅性評価 設計知識とメトリクス ③マネージメントテストの優先順位付け 設計知識とメトリクス スクラム ④欠陥特定テストアーキテクチャ アプリケーション知識
- 21. 21 開発プロセスの品質改善とテスト自動化のスキルセット スキルセット ①抜け漏れや間違いレビュースキル （アプリケーション知識） （運用知識） （設計知識） （テスト容易性） 開発とテスト両方の ②網羅的な自動テス スト キルセットが必要 様々なテスト設計技法 ソフトウェア開発スキル 網羅性評価 設計知識とメトリクス ③マネージメントテストの優先順位付け 設計知識とメトリクス スクラム ④欠陥特定テストアーキテクチャ アプリケーション知識
- 22. 22 色々言いたい事がある..例えば… 開発者への問い: - 非機能要件について運用やユーザ視点のテスト書けてる? - C1,C2とMutation testingを使って、 テストケースを減らす事、欠陥特定を行えている? テスターへの問い: - 仕様策定や設計の段階で不具合を見つけてる? - アプリケーション知識とソースコード、ログ、テスト結果から 素早く欠陥特定出来てる? マネージャーへの問い: - リスク、設計、バグ、プロダクトとプロセスメトリクスを 使用してテストプロセスの改善出来てる? - 機能とテスト実装が同時に終わるようタスク分割出来てる?
- 23. 23 LTでは時間がないので３つだけ 開発者への問い: - 非機能要件について運用やユーザ視点のテスト書けてる? - C1,C2とMutation testingを使って、 テストケースを減らす事、欠陥特定を行えている? テスターへの問い: - 仕様策定や設計の段階で不具合を見つけてる? - アプリケーション知識とソースコード、ログ、テスト結果から 素早く欠陥特定出来てる? マネージャーへの問い: - リスク、設計、バグ、プロダクトとプロセスメトリクスを 使用してテストプロセスの改善出来てる? - 機能とテスト実装が同時に終わるようタスク分割出来てる?
- 24. 24 LTでは時間がないので３つだけ 開発者への問い: - 非機能要件に一つい人て運で用全やユ部ーザや視点れのる テスト書けてる? - C1,C2とMutation testingを使って、 テスストケーースパを減ーらすエ事ン、欠ジ陥特ニ定アを行がえていいるる? なら テスそターのへ人のに問いお: 任せするのも選択肢 - 仕様策定や設計の段階で不具合を見つけてる? - アプリケーシでョンも知、識そとソうースじコゃードな、ロいグ、なテスら ト結果から 素早く欠陥特定出来てる? みんなが協力した方が マネージャーへの問い: - リスク、設計、いバグい、プんロダじクゃトとなプロいセスかメトな リクスを 使用してテストプロセスの改善出来てる? - 機能とテスト実装が同時に終わるようタスク分割出来てる?
- 25. 25 テスト自動化は誰がするべきか？ 大量のテストの高速実行が 目的ならば キーワード駆動テストとか PageObjectパターン使えば 誰がやっても同じ けど、確実に炎上しますw
- 26. 26 テスト自動化は誰がするべきか？ 開発プロセスの 品質改善活動として みんなが協力したら バグ修正日数や バグの早期発見で 高い効果が出るYO
- 27. 27 継続的システムテストについて社外講演 http://www.jasst.jp/ http://www.juse.jp/sqip/symposium/ メリット① バグが速く直せる！ メリット② バグを早期発見！
- 28.
- 29. 29 似たような話って他にもありますよね 「障害対応って 誰がするべき？」
- 30. 30 “10+ DeploysPer Day: Dev and Ops Cooperation at Flickr” http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
- 31.
- 32. 32 Continuous TestingやDevOpsの エンジニアを探してるんだった！！！
- 33. 33 Continuous TestingやDevOpsの エンジニアを探してるんだった！！！ ・ビジネスをさらにドライブさせていくための 開発スピードの高速化 （アジャイル、CD、Continuous Testing） ・レガシーシステムをテクノロジーで 変革を加えていく（テクニカルチャレンジ） ・開発スピードを殺さず、サービス/システムの 信頼性を向上させるためのさらなる取り組み （DevOps）
- 34. 34 Let’s improve quality