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

7,369
-1

Published on

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

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

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

0 Comments
19 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,369
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
20
Comments
0
Likes
19
Embeds 0
No embeds

No notes for slide

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

  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

×