自動テストとJenkinsの活用Lazy Developerへの道

アジェンダ

● 自己紹介● 使用している開発ツールについて● Androidアプリ開発のちらみせ

o 自動テストo 継続的インテグレーション

● まとめ

自己紹介

飲食に特化した求人サイト

自己紹介

● 所属

● 経歴o 組み込みエンジニアo 携帯電話開発(9年)

ガラケーo Android Developer(5年)

Android端末開発 組み込み支援 Frameworkカスタマイズ アプリケーション開発

自己紹介(2)

● 日本Androidの会関西支部

● FirefoxOS 勉強会(1st - 3rd)

● TechInstituteアプリ開発者養成講座の講師

● その他諸々

執筆

プロの力が身につく Androidプログラミングの教科書

執筆

プロの力が身につく Androidプログラミングの教科書

執筆

プロの力が身につく Androidプログラミングの教科書

使用中の開発ツールと課題

何を使っているか誰が使っているかどう使っているか

ツールの紹介と状況

現在の開発ツール

メンバー

コミュニケーション

タスク管理

ソース管理

ドキュメント

現在の開発ツール

メンバー

コミュニケーション

タスク管理

ソース管理

ドキュメント

開発部の体制

● Webエンジニアo ７名

● デザイナーo ２名

● スマートフォンエンジニアo １名

※QA(品質管理部門)はありません

※QA(品質管理部門)はありません

一般的に品質が低いと...信頼を失う

● 納品後、大変な事になるo 検収NG

o 裁判

● サービス停止o 運営に関わるクリティカルなバグo ユーザーへの影響o スタッフへの影響

● 余計な作業が増えるo 関係者への謝罪行脚o 始末書の作成

みんなで品質保証・品質管理を考える

Androidアプリ開発でのテスト

Androidアプリの開発体制(※サーバー / デザイン除く)

● 要件/スケジュール管理o 要さん

● コーディングo 要さん

● テストo 要さん

● 品質管理o 要さん

● デプロイo 要さん

Androidアプリ開発チーム

品質保証・品質管理を考える

どうやれば効率的か

課題は品質を確保しつつ開発をする

● 絶対的なものo 品質確保

● MAXにしたい時間o 企画検討o 実装

● MINにしたい時間o テスト実施o 日々のデグレチェック作業

自動テストJUnitを取り入れた

● 目的o テスト項目数は維持

o 実施時間は最小限に

● やることo JUnitのお勉強をする

Androidの自動テストで必要なもの

● Androidアプリ開発o Android Studio標準のJUnit

o Espresso (android-test-kit)

Webサーバー側の自動テスト

● Webサイト開発o Codeception

o Selenium

AS標準のGradleコマンドで実行

● AndroidTestの実行o ./gradlew connectAndroidTest

o ./gradlew mergeAndroidReports --continue

複数Project構成の場合、Reportをまとめる

● コードカバレッジの集計o ./gradlew createDebugCoverageReport

JUnitのコードに対する実施率

自動テストはこんな感じ

https://flic.kr/p/pdyndn

JUnitの結果表示

項目数、実施時間、結果が定量的に確認できる

コードカバレッジの結果表示

コード量に対するテストの実施率

100%にする必要はないけど、モチベーションになる

コードカバレッジの結果表示(2)

● テストが実施されていない箇所がすぐにわかるo 赤ライン・・・テスト未実施o 緑ライン・・・テスト実施

テスト実施のコストを考える

テスト実施コスト＝ 実施時間 回数×

コミット前リリース前

項目数端末数テスター人数

要因

テスト実施のコストを抑える

テスト実施コスト＝

JUnit作成 メンテナンス+

ひたすらテストコードを作れ！作った分だけ楽になれる！

JUnit作成で苦労したこと

● テストコードをたくさん作るのは大変

● 痒いところにとどかない判定メソッドo Toast表示、テキスト文字色の判定は自作o 無ければ作ればいいじゃん！！

● Android端末によるテスト結果の違い

JUnit作成でよかったこと

● Espresso(android-test-kit)でのテスト作成は、いくぶんか楽o onView(withId())でViewを指定できる

● 慣れれば慣れるほど、時間は短縮

● コミット前のデグレチェックが楽々

テストコードによるテスト実施

要求分析

機能設計

詳細設計

基本設計

コーディング

Unit テスト

結合テスト

システムテスト

受入テスト

広い範囲のテストフェーズを実施

継続的インテグレーション

継続的インテグレーションって何だ？？？

継続的インテグレーション

Build

Test

InspectionDeploy

● 日々、継続して工程を実施し続ける。o 早期の問題発見と対応が目的

どうやって継続的インテグレーション

するの？？？

これを人の手で実施するのは大変

CIツールはたくさんあるよ

オープンソースのCIツールもあるよ。

Jenkinsに参画してもらっています

メンバー

コミュニケーション

タスク管理

ソース管理

ドキュメント

Jenkinsはたくさんの作業ができる

● Buildo ソースコードの取得、ビルド実行

● Inspectiono 静的コードチェック、コードメトリクス

● Testo 自動テストの実施

● その他o レポート作成

● ドキュメンテーション自動生成

これらの作業を『早朝、深夜残業』でやってくれる！！

Jenkinsの仕事の流れ

メンバー

コミュニケーション

タスク管理

ソース管理

ドキュメント

①ソースコードの取得

Jenkinsの仕事の流れ

メンバー

コミュニケーション

タスク管理

ソース管理

ドキュメント

②ビルド実行③Inspection実行④自動テスト実行⑤ドキュメント作成

Jenkinsの仕事の流れ -報告

メンバー

コミュニケーション

タスク管理

ソース管理

ドキュメント

⑥エラー報告など

「一晩でやってくれました」

● 労働基準法37条を考慮しなくていいo 深夜残の割増料金も不要

● ヒューマンエラーはなしo 同じテストでも実施毎に変わるテスターよ、さようなら

参考HP:大阪労働局http://osaka-roudoukyoku.jsite.mhlw.go.jp/yokuaru_goshitsumon/jigyounushi/jikangai.html

他にもいろいろと使い道はあります

● デイリーワークの自動化o DBのバックアップ作業o (誰も見ない)日報メールの自動作成と送信o (面倒な)Web勤怠の入力o 毎日、お弁当の注文メールを送信

ここからは実際のプロジェクト名が出るので

写真撮影NGで！！

Jenkinsの管理画面

プロジェクトの画面

プロジェクトTop画面、各Pluginの情報表示

ステップ数の確認

ステップ数やコメント行の集計も自動「かぞEちゃOが許されるのは小学生まで」

ソースコードの量を日々チェック

「PreFix過ぎてるのに、まだコーディングしてるの？」っていうのもバレてしまう。

ビルドの例

お仕事中のJenkinsさんを覗き見することも。

ビルドエラーを早期発見

犯人は、このコミットの誰か！！

激おこJenkins氏

深夜残、早朝出勤のJenkins氏もBuildエラー/テストNGには敏感です。

masterでビルドエラー発生させたときの損失っていくら？100人の作業が2時間止まるとき損失額は？

「それ、サバンナでも同じこと言えるの？」

Inspectionの例

静的コードチェックも自動で実施

Inspectionからコードの質を確認

Inspectionの指摘内容の確認

テスト実施で品質のチェック

自動テストによる品質維持

※事件が起こった証拠(ちなみに、テスト用アカウントの切り替え忘れ発生)

テスト実施で品質のチェック(2)

テスト結果の表示

ワークスペースを見ることもできる

チェックアウトしたソース、Build後のOuptut

ファイルは観覧可能です

JUnitの結果もそのまま観覧可能

./gradlewで実行した結果も観覧可能です。

Jenkinsを入れた結果

● 日々、自動で作業をしてくれるo 設定次第で毎朝、毎コミットごとにテスト実施o コードメトリクスの実施

● もし、問題があればすぐに通知o メール送信o Chatworkにメッセージo Backlogに課題登録

段階的に導入することが大事です

1. buildチェック2. Inspection

3.自動テストの実施4.デプロイ

プロジェクトに必要だと思われるものを、順番にJenkinsにさせる

Jenkinsを導入する際の注意

● 目的を明確にするo 何をさせたいか

● 数字の意味を理解するo プロジェクトがどう進んでいるのかo 問題は発生していないか

● フィードバックをするo 問題があればすぐに対応する

まとめ

エンジニアのポートフォリオ分析

花形(Lazy Developer)

問題児(Developer)

負け犬(ただの人)

金のなる木(未来に期待)

コスト

品質

企業として成長していく過程で、エンジニアとしての商品価値を高め、コスト意識を持ち高機能高品質なシステムを提供しつづけるとしたら、Lazy Developerは企業の花形商品である。

エンジニアなら開発の効率化、作業の自動化を考えよう

ソフトウェア工学を取り入れよう

効率的に開発を行い

時間と心の余裕を持って

新しい知識の習得へ

Good Engineer

is

Lazy!!

続きはPHPカンファレンス2015で

• PHPカンファレンス20155/30(土)開催

Webサービス開発で自動テストCodeception発表予定

フロちゃんが発表するよ！！

ご静聴、ありがとうございました。