Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

「最強」のチームを「造る」技術基盤 ディレクターズ・カット

9.843 Aufrufe

Veröffentlicht am

「Android Test Casual Talks」(2013-12-13・Fri)で発表させていただいたスライドです。
http://www.zusaar.com/event/1917003

CI/CD・TDD・ATDDといった技術基盤を活用して、
Android開発・テストのプロセスを構築し業務を効率化させた事例の紹介です。

楽天の実際の開発現場での、
「ホンモノ」・「本気」の改善の取り組みについて感じていただければ幸いです。

  • Login to see the comments

「最強」のチームを「造る」技術基盤 ディレクターズ・カット

  1. 1. 「最強」のチームを 「造る」技術基盤 ディレクターズ・カット -Android Test Casual TalksDec/13/2013 Hiroyuki Ito IT Department, Rakuten, Inc. http://www.rakuten.co.jp/
  2. 2. Hiroyuki Ito (伊藤 宏幸、The Hiro) 情報技術部 プロセス・品質課 テスト駆動開発グループ @hageyahhoo 2
  3. 3. Android Test Casual Talks 3
  4. 4. CI/CD TDD ATDD この3つを導入したお話を カジュアルにします 4
  5. 5. Agenda 1. 背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 5
  6. 6. 1. 背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 6
  7. 7. 1) スクラムのプロジェクトを始めたいというチームから、 アジャイルコーチとしてのサポート依頼を受けた 2) Android の既存アプリのエンハンス • ベースはあるものの、実質新アプリの作成。 • 自動テストがなく、テスト・リリースは手作業。 3) 私自身、Android を(プログラム・端末含め) 一切触ったことがない • JavaEE の開発経験あるから、何とかなるだろ~ 7
  8. 8. 超えるべき3つの壁 ここから WALL CI/CD WALL TDD WALL ATDD こう攻めることにしました 8
  9. 9. 1. 背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 9
  10. 10. 前提1 既にある仕組みの活用 手作業でとはいえ、 ビルドやデプロイをする 仕組みはあった。 これを Jenkins に肩代わりさせれば 良い。 10
  11. 11. 前提2 新たなアプリ配信の仕組み Android も使えるぞ~ スマートフォンのβ 版アプリを チームメンバーへ配信できるサービス 丁度他のメンバーが試験導入をしていたため、 これとコラボを組むことにしました 11
  12. 12. 具体的に実現した仕組み チェックインビルド (1時間おき) 私のノート PC チームメンバー全員に 最新版を配信 毎朝のデイリースクラムで、 最新版のアプリをステークホルダーに デモするようにしました 12
  13. 13. 振り返り 既存システムの拡張で改善を始める場合は、 TDD や ATDD よりも、CI/CD を先にやった方が ROI が高いです。 • 品質の作り込みには、もちろん価値があります。 • 回帰テストの自動化は、繰り返しリリースをする場合には間違いなく 必要です。 • 一方で、触れるものを先に提示する方が、 直感的に「進んでいるな」と思われ易いことも事実です。 これは善悪の話ではなく、そこから攻めた方が 改善を進め易いという意味です。 13
  14. 14. 1. 背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 14
  15. 15. Before TDD Dao Dao DB Dao Model Controller DB DB Activity • 全コンポーネントを開発しないと(手動)テスト出来なかった。 • 画面一式を開発するのに、それまでは1週間かかっていた。 15
  16. 16. Android の単体テストの課題 Android JUnit 使い辛すぎるだろ(怒) • java.lang.RuntimeException: Stub! (゚Д゚) • 単体テストなのに Emulator/ 実機を要求するな~ • コンポーネント単位での単体テストし辛いぞ~ ※Dao だけテストさせてくれ! 16
  17. 17. 解決策 ・Robolectric で、全ての UT を JVM 上で実行できる! • http://robolectric.org/ • Emulator も実機も不要。 ・Test Double フレームワークとして、 Robolectric との相性の良い Mockito を活用。 • http://code.google.com/p/mockito/ 17
  18. 18. Robolectric で Dao の UT を行うイメージ @Before public void setUp() { Create database for Test; Insert test data; } @Test public void findXxx() { Assertions; } @After public void tearDown() { Drop Database for Test; } 18
  19. 19. After TDD Dao Dao DB Dao Model Controller DB DB Activity • 個々のコンポーネント毎に独立・分割して(自動)テストが可能に。 • 画面一式を開発する期間を、1週間から1日に削減。 19
  20. 20. 成果 1) フィードバックを迅速化できた。 • デグレをすぐに発見し、問題を解決できるようになった。 • Emulator・実機が不要なため、テストが非常に容易&速い。 • 導入して4ヶ月以上経つが、Robolectric・Mockito 由来で 検証がうまく行かなかった箇所は特にない。 2) DB 周りを、開発の初期に一通り全て構築できた。 • UT 込みで一式完成させたため、 変更があっても容易に対応できるようになった。 3) 技術的にも心理的にも、エンジニアの負荷が減った。 • エンジニアが変更に積極的になった。 • 自発的にバグを見つけては解決してくれるようになった。 20
  21. 21. 気付き Activity の UT も実施は可能だが、ROI は低い。 • 後述の Calabash-Android の方が、 ウチのチームでは ROI が高いです。 • 検証したい機能・粒度に合わせて 別々のツール・技術を利用しても問題はない。 テストカバレッジを100%にすることや、 1つの方法に統一することが目的ではない。 テスト等を導入することで 開発を効率化出来ることの方が重要。 21
  22. 22. 1. 背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 22
  23. 23. なぜ ATDD か? 1) Activity を JUnit でつくるのが面倒… • 皆さん Activity の UT って本当に出来てる??? 2) ユースケース/ユーザーストーリーを 自動テストしたい • Activity のテストは、デザイン除けばユースケース /ユーザーストーリーのテストになることが多い。 3) 仕様がまとまりづらかったので、 テストケースから仕様をまとめようと考えた。 23
  24. 24. Calabash-android : Our answer • • • • Cucumber の Android 用 Wrapper です。 テスト仕様書を自動実行できるイメージです。 エンジニア以外でもテストケースをメンテナンスできます。 ビジネス・マネージャーが読めるため、 テストの妥当性を判断できます。 24
  25. 25. テストケースのイメージ Feature: Input Scenario: Input today’s data Given I kick drumroll Then drumroll show today When press next Then I should see ”xxx" screen テストケースの名称です このレベルの記述で 自動実行できます When I press keys and calculator should show like this: | 2 | 2 | | 0 | 20 | | 0 | 200 | 読みやすさを考慮した | * | 200 | 記述ができます | 3 | 3 | | = | 600 | Then take photo … 25
  26. 26. 試してみて分かったこと 1) 画面遷移やユースケースレベルのテストを、 繰り返し実行しやすくなった。 SmartPhone の場合、画面遷移・操作が複雑かつ複数のインタラクションを 含むことが多いため、UT よりは ATDD の方が ROI が高いと思います。 2) コミュニケーションツールとして有用。 • 外国人の開発メンバーに仕様を伝えるのが便利。 • ビジネスやデザイナーとの会話を整理することに使うこともある。 3) Silver bulletではない。 • 環境構築が意外と難しい。 • ライブラリが成熟していないため、そもそも自動化できない操作も多い。 • Excel のテスト仕様書の方が読んでくれる人が多い。 26
  27. 27. 現在取り組んでいること 1) メンバーがやってくれたバグ対応は、 基本全て ATDD 化する。 • 回帰テスト対策に加え、どういう仕様であるのかを動作&ロジックで 後々説明しやすいため。 • メンバーの努力を形として残す、チームビルディングの一環でもある。 2) テスト仕様書はキチンと作る。 • 対象読者数を考えると、Excel のテスト仕様書はやはり必要。 • 読んでもらうにはテスト仕様書、実行はなるべく ATDD のように、 状況に応じて使い分けた方が良い。 3) テスト仕様書はキチンと作る。 大事なことなので2回言いました。 27
  28. 28. とはいうものの… Emulator が遅くて 検証が辛い(´・ω ・) 28
  29. 29. Genymotion! 1) VirtualBox 上で動作する、超高速 Emulator です。 2) Calabash-Android からでも普通に使えます。 3) GPS やカメラも emulate できます。 4) 無料版があるので、試してみよう! 29
  30. 30. 1. 背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD 4. 3rd Stage : ATDD 5. 結論 30
  31. 31. Android のテストの自動化のポイント 1) 仕事の効率化に焦点を絞ろう 2) 自動化の導入自体を目的にしないようにしよう 3) 新しくてよいものは柔軟に取り入れよう 4) 簡単に失敗できるようにし、そこから学べるようにしよう 5) JavaEE の知識は使えるぞ! 31
  32. 32. 何のための 自動化か? 32
  33. 33. Be happy! 33

×