Tweet
Tweet

Slide 1

Slide 1 text

2年半ぶりのプロダクト開発で あらためて感じた 自動テストの大切さ Nozomi Takuma Android Test Online#1

Slide 2

Slide 2 text

自己紹介 ● Nozomi Takuma ● DeNA SWETグループ ○ 兼務: Pococha事業部システム部 ● Androidとテストが好き

Slide 3

Slide 3 text

自己紹介 ● Nozomi Takuma ● DeNA SWETグループ ○ 兼務: Pococha事業部システム部 ● Androidとテストが好き 自動テスト導入サポート等(50%)

Slide 4

Slide 4 text

自己紹介 ● Nozomi Takuma ● DeNA SWETグループ ○ 兼務: Pococha事業部システム部 ● Androidとテストが好き プロダクトの開発(50%)

Slide 5

Slide 5 text

今日話したいこと

Slide 6

Slide 6 text

今日話したいこと ● 2年半ぶりにプロダクト開発をしたら、 自動テストに助けられる場面がありました ● 改めて自動テストの大切さを実感すること ができたので、その体験を共有したいと思 います

Slide 7

Slide 7 text

● 2年半ぶりにプロダクト開発をしたら、 自動テストに助けられる場面がありました ● 改めて自動テストの大切さを実感すること ができたので、その体験を共有したいと思 います 今日話したいこと まずはこの期間の話をします 主にSWETで事業部への自動テスト導入を 行っていました

Slide 8

Slide 8 text

プロダクト開発から離れていた2年半

Slide 9

Slide 9 text

プロダクト開発から離れていた2年半 2018/3〜 SWETにjoin. 2019/2〜 自動テスト導入サポートの 取り組みを開始 2020/7〜 Pococha事業部システム部 兼務開始 メトリクス収集ツールの開発 2020/12〜 Pocochaのプロダクト開発

Slide 10

Slide 10 text

プロダクト開発から離れていた2年半 2018/3〜 SWETにjoin. 2019/2〜 自動テスト導入サポートの 取り組みを開始 2020/7〜 Pococha事業部システム部 兼務開始 メトリクス収集ツールの開発 2020/13〜 Pocochaのプロダクト開発

Slide 11

Slide 11 text

自動テスト導入サポートの取り組み ● 自動テストのないプロダクトに自動テスト を導入する ● 自動テストを導入することで、不具合の 早期発見や開発効率の向上を目指す

Slide 12

Slide 12 text

自動テスト導入サポートの取り組み ● 自動テストのないプロダクトに自動テスト を導入する ● 自動テストを導入することで、不具合の 早期発見や開発効率の向上を目指す

Slide 13

Slide 13 text

Androidプロダクトへの取り組み ● 開発者テストの整備をスコープ ● ユニットテストと インテグレーションテストの導入 ○ UIのテストもAPIとの連携はスタブ化している ● E2Eテストには手を出していない

Slide 14

Slide 14 text

自動テスト導入サポートの取り組み ● 自動テストのないプロダクトに自動テスト を導入する ● 自動テストを導入することで、不具合の 早期発見や開発効率の向上を目指す

Slide 15

Slide 15 text

自動テストによる不具合の早期発見 ● 開発段階で問題を発見できるように ● とはいっても、自動テスト導入がすぐに QAフェーズであがってくる不具合の減少に つながるとは限らない

Slide 16

Slide 16 text

プロダクトで発生する様々な不具合 ● 実際にAPIや外部サービスと結合しないと 発見が難しい ● 問題を再現するのにある程度UI操作が必要 ○ 自動テストやっても費用対効果が見合わない ● 仕様の認識ずれ

Slide 17

Slide 17 text

自分の心境 ● 現在スコープとしているテストでは発見が 難しい不具合も多い ● 自動テストの導入が開発チームの利益に きちんと繋がるか不安を感じていた

Slide 18

Slide 18 text

プロダクト開発から離れていた2年半 2018/3〜 SWETにjoin. 2019/2〜 自動テスト導入サポートの 取り組みを開始 2020/7〜 Pococha事業部システム部 兼務開始 メトリクス収集ツールの開発 2020/12〜 Pocochaのプロダクト開発

Slide 19

Slide 19 text

Pocochaでのプロダクト開発

Slide 20

Slide 20 text

改修を担当した機能 ● アイテム機能 ○ 視聴者はコインを消費することでライブ中に アイテムを送信できる ○ アイテムを送信することで画面にエフェクト を表示しライブを視覚的に盛り上げる

Slide 21

Slide 21 text

改修内容 アイテム素材はアプリ起動時に一括でDLされる ライブの中では基本的にはDLが完了している状態 旧仕様 新仕様 ライブ中にアイテムが利用されたタイミングで アイテム素材をDLする

Slide 22

Slide 22 text

自分がやったこと 1. 既存実装のリファクタリング 2. アイテム機能の不具合修正 3. 新仕様への改修

Slide 23

Slide 23 text

自分がやったこと 1. 既存実装のリファクタリング 2. アイテム機能の不具合修正 3. 新仕様への改修 3つのタイミング全てで 自動テストに助けられた

Slide 24

Slide 24 text

自分がやったこと 1. 既存実装のリファクタリング 2. アイテム機能の不具合修正 3. 新仕様への改修

Slide 25

Slide 25 text

既存実装のリファクタリング ● アイテム利用の実装がほとんどActivityに 書かれていた ○ 自動テストはない ● 新仕様に改修する前にユニットテストを書 けるようにするためリファクタリング

Slide 26

Slide 26 text

既存実装のリファクタリング Activityから処理の 切り出し ユニットテスト整備 繰り返し

Slide 27

Slide 27 text

既存実装のリファクタリング 既存実装の振る舞いが細かく わかっていなくてもある程度できる Activityから処理の 切り出し ユニットテスト整備

Slide 28

Slide 28 text

既存実装のリファクタリング テストパターンを作成するために 既存実装の振る舞いを把握する必要がある Activityから処理の 切り出し ユニットテスト整備

Slide 29

Slide 29 text

ユニットテストで振る舞いを理解する ● 内部処理がシンプルとは言い難いかつ コメントやドキュメントもほとんどなく、 自分の理解があっているか不安 ● 想定する挙動をテストケースにして、認識 があっているか検証する

Slide 30

Slide 30 text

ユニットテストで振る舞いを理解する ● 内部処理がシンプルとは言い難いかつ コメントやドキュメントもほとんどなく、 自分の理解があっているか不安 ● 想定する挙動をテストケースにして、認識 があっているか検証する 仕様化テスト

Slide 31

Slide 31 text

自動テストに何を助けられた？ ● 既存実装の振る舞いを理解するのを助けて もらった ○ ユニットテストを動かしてみて、ああ〜そう いうことなのか！となることもしばしば

Slide 32

Slide 32 text

自分がやったこと 1. 既存実装のリファクタリング 2. アイテム機能の不具合修正 3. 新仕様への改修

Slide 33

Slide 33 text

アイテム機能の不具合 ● アイテムが押せなくなるというお問い合わ せが複数件あった ● 一度発生するといったんライブを出ないと 解消されない ● 通信エラー起因で発生している可能性

Slide 34

Slide 34 text

既存実装の不具合調査でやったこと ● 実装を読んでもパッと原因はわからない ● リファクタリングでユニットテストを実装 できるようになっていたので、各APIリク エストでエラーが発生するパターンを追加

Slide 35

Slide 35 text

既存実装の不具合調査でやったこと ● 実装を読んでもパッと原因はわからない ● リファクタリングでユニットテストを実装 できるようになっていたので、各APIリク エストでエラーが発生するパターンを追加 結果がおかしいやつがある! 原因を特定して修正

Slide 36

Slide 36 text

既存実装の不具合調査でやったこと ● 実装を読んでもパッと原因はわからない ● リファクタリングでユニットテストを実装 できるようになっていたので、各APIリク エストでエラーが発生するパターンを追加 不具合の再現テスト

Slide 37

Slide 37 text

自動テストに何を助けられた？ ● 不具合の原因特定を助けてもらった ○ あやしいケースのテストを書いてOK/NGを確認 ● もう1つ別の要因でアイテムが利用できな くなる不具合の問い合わせもあったが、 そちらもユニットテストで再現 → 修正

Slide 38

Slide 38 text

自分がやったこと 1. 既存実装のリファクタリング 2. アイテム機能の不具合修正 3. 新仕様への改修

Slide 39

Slide 39 text

改修内容 アイテム素材はアプリ起動時に一括でDLされる ライブの中では基本的にはDLが完了している状態 旧仕様 新仕様 ライブ中にアイテムが利用されたタイミングで アイテム素材をDLする

Slide 40

Slide 40 text

機能改修時に実装した自動テスト ● 動作するか不安を感じる部分 ● 手動で動作確認をするのが面倒な部分

Slide 41

Slide 41 text

動作するか不安を感じる部分 ● 処理がそこそこ複雑なところ ● RxJavaであれこれやっているところ ● 自分は初歩的なミスをしやすいので、 そこまで複雑でなくても条件分岐が複数あ るところ

Slide 42

Slide 42 text

手動で動作確認をするのが面倒な部分 ● 様々なデータパターンで確認したいところ ● 連続する処理の中でピンポイントに動作を みたいところ ● 時間経過によって処理が変わるところ ● 状況を作り出すのが面倒なところ

Slide 43

Slide 43 text

実装したテストを具体的に ● 例:アイテムのダウンロード処理 ○ ファイルの解凍と保存 ○ 素材がDL済みの場合のスキップ処理 ○ 素材が変更された場合のファイル更新処理 ○ ダウンロードが並列で走るときの排他制御 ○ 一定期間使用されなかった素材の削除処理

Slide 44

Slide 44 text

自動テストに何を助けられた？ ● 動作するか不安な気持ちを払拭できた ● 手動で動作確認するコストを減らせた ● 機能改修の中で再度修正を入れることが あっても安心感を持って修正できた

Slide 45

Slide 45 text

自動テストに何を助けられた？ ● 動作するか不安な気持ちを払拭できた ● 手動で動作確認するコストを減らせた ● 機能改修の中で再度修正を入れることが あっても安心感を持って修正できた 精神的な治安を維持できた

Slide 46

Slide 46 text

自動テストに何を助けられた？ ● 動作するか不安な気持ちを払拭できた ● 手動で動作確認するコストを減らせた ● 機能改修の中で再度修正を入れることが あっても安心感を持って修正できた 良い開発体験を得られた 自分にとっては一番大きなモチベーション 精神的な治安を維持できた

Slide 47

Slide 47 text

自動テストに助けられたこと まとめ 1. 既存実装のリファクタリング ⇢ 振る舞いの理解を助けてもらった 2. アイテム機能の不具合修正 ⇢ 不具合の原因特定を助けてもらった 3. 新仕様への改修 ⇢ 精神的な治安を維持しながら開発ができた

Slide 48

Slide 48 text

いくつかの観点で自問自答

Slide 49

Slide 49 text

Q. 自動テストで発見できな かった不具合はあった？

Slide 50

Slide 50 text

A. あった

Slide 51

Slide 51 text

自動テストで見つけられなかった不具合 ● 認識ずれ ● 観点の見落とし ● スレッドの設定ミス ● リファクタリングがやりきれなくて、自動 テスト書けるはずなのに書けていない箇所

Slide 52

Slide 52 text

自動テストで見つけられなかった不具合 ● 認識ずれ ● 観点の見落とし ● スレッドの設定ミス ● リファクタリングがやりきれなくて、自動 テスト書けるはずなのに書けていない箇所 もっと自動テストが活用できた部分

Slide 53

Slide 53 text

Q. 開発していて不安に感じ ることが少ない場合は？

Slide 54

Slide 54 text

A. そういうときもある チームですり合わせは したほうがよさそう

Slide 55

Slide 55 text

開発していて不安に感じない問題 ● 不安に感じるレベルは人それぞれ ○ ズレを感じる場面はしばしばある ● PRレビューでも不安を感じたら提案して 不安感のすり合わせをするのがよさそう ○ 動作する自動テストがあるとレビュアーも安 心できる

Slide 56

Slide 56 text

Q. QAでも不安は払拭できる のでは？

Slide 57

Slide 57 text

A. できる ただ、自分が不安なパス を通るとは限らない

Slide 58

Slide 58 text

QAと自動テスト ● E2Eかつ手動の検証だと特定のケースを 発生させるのが難しい場合がある ● 内部の処理がどうなっているかをよく 知っている人による動作確認も重要

Slide 59

Slide 59 text

Q. 自動テストを実装するの は時間がかかる？

Slide 60

Slide 60 text

A. かかった

Slide 61

Slide 61 text

自動テストの実装に時間がかかる問題 ● テストコード上での設定ミスに気が付かず 時間を浪費してしまい断念しそうになった ● 自動テストをあきらめた場合の正常系〜 異常系の動作確認のコストを鑑みてテスト コードのデバッグを続けた

Slide 62

Slide 62 text

自動テストの実装に時間がかかる問題 ● テストコード上での設定ミスに気が付かず 時間を浪費してしまい断念しそうになった ● 自動テストをあきらめた場合の正常系〜 異常系の動作確認のコストを鑑みてテスト コードのデバッグを続けた 一時的に時間がかかるけど、 短期的に見てもその分のコストがペイすると踏んだ

Slide 63

Slide 63 text

まとめ

Slide 64

Slide 64 text

まとめ ● 自動テストで見つけられない不具合はある が、それでも自動テストはいいものだった ● 自動テストはいいものと感じられたのは、 マイナスの気持ちを自動テストを通じて 払拭できたのが大きい

Slide 65

Slide 65 text

宣伝

Slide 66

Slide 66 text

Androidエンジニアの採用始まりました ● PocochaではAndroidエンジニアを募集中 ○ ライブ配信サービスや技術に興味あるかた よかったら是非に ○ https://career.dena.jp/job.phtml?job_code=1573

Slide 67

Slide 67 text

ご清聴ありがとうございました！