2年半ぶりのプロダクト開発であらためて感じた自動テストの大切さ / realized the importance of automatic testing with product development for the first time in two and a half years

Android Test Online #1の発表資料です

Transcript

1. 2年半ぶりのプロダクト開発で あらためて感じた 自動テストの大切さ Nozomi Takuma Android Test Online#1
2. 自己紹介 • Nozomi Takuma • DeNA SWETグループ ◦ 兼務: Pococha事業部システム部 • Androidとテストが好き
3. 自己紹介 • Nozomi Takuma • DeNA SWETグループ ◦ 兼務: Pococha事業部システム部 • Androidとテストが好き 自動テスト導入サポート等(50%)
4. 自己紹介 • Nozomi Takuma • DeNA SWETグループ ◦ 兼務: Pococha事業部システム部 • Androidとテストが好き プロダクトの開発(50%)
5. 今日話したいこと
6. 今日話したいこと • 2年半ぶりにプロダクト開発をしたら、 自動テストに助けられる場面がありました • 改めて自動テストの大切さを実感すること ができたので、その体験を共有したいと思 います
7. • 2年半ぶりにプロダクト開発をしたら、 自動テストに助けられる場面がありました • 改めて自動テストの大切さを実感すること ができたので、その体験を共有したいと思 います 今日話したいこと まずはこの期間の話をします 主にSWETで事業部への自動テスト導入を 行っていました
8. プロダクト開発から離れていた2年半
9. プロダクト開発から離れていた2年半 2018/3〜 SWETにjoin. 2019/2〜 自動テスト導入サポートの 取り組みを開始 2020/7〜 Pococha事業部システム部 兼務開始 メトリクス収集ツールの開発 2020/12〜 Pocochaのプロダクト開発
10. プロダクト開発から離れていた2年半 2018/3〜 SWETにjoin. 2019/2〜 自動テスト導入サポートの 取り組みを開始 2020/7〜 Pococha事業部システム部 兼務開始 メトリクス収集ツールの開発 2020/13〜 Pocochaのプロダクト開発
11. 自動テスト導入サポートの取り組み • 自動テストのないプロダクトに自動テスト を導入する • 自動テストを導入することで、不具合の 早期発見や開発効率の向上を目指す
12. 自動テスト導入サポートの取り組み • 自動テストのないプロダクトに自動テスト を導入する • 自動テストを導入することで、不具合の 早期発見や開発効率の向上を目指す
13. Androidプロダクトへの取り組み • 開発者テストの整備をスコープ • ユニットテストと インテグレーションテストの導入 ◦ UIのテストもAPIとの連携はスタブ化している • E2Eテストには手を出していない
14. 自動テスト導入サポートの取り組み • 自動テストのないプロダクトに自動テスト を導入する • 自動テストを導入することで、不具合の 早期発見や開発効率の向上を目指す
15. 自動テストによる不具合の早期発見 • 開発段階で問題を発見できるように • とはいっても、自動テスト導入がすぐに QAフェーズであがってくる不具合の減少に つながるとは限らない
16. プロダクトで発生する様々な不具合 • 実際にAPIや外部サービスと結合しないと 発見が難しい • 問題を再現するのにある程度UI操作が必要 ◦ 自動テストやっても費用対効果が見合わない • 仕様の認識ずれ
17. 自分の心境 • 現在スコープとしているテストでは発見が 難しい不具合も多い • 自動テストの導入が開発チームの利益に きちんと繋がるか不安を感じていた
18. プロダクト開発から離れていた2年半 2018/3〜 SWETにjoin. 2019/2〜 自動テスト導入サポートの 取り組みを開始 2020/7〜 Pococha事業部システム部 兼務開始 メトリクス収集ツールの開発 2020/12〜 Pocochaのプロダクト開発
19. Pocochaでのプロダクト開発
20. 改修を担当した機能 • アイテム機能 ◦ 視聴者はコインを消費することでライブ中に アイテムを送信できる ◦ アイテムを送信することで画面にエフェクト を表示しライブを視覚的に盛り上げる
21. 改修内容 アイテム素材はアプリ起動時に一括でDLされる ライブの中では基本的にはDLが完了している状態 旧仕様 新仕様 ライブ中にアイテムが利用されたタイミングで アイテム素材をDLする
22. 自分がやったこと 1. 既存実装のリファクタリング 2. アイテム機能の不具合修正 3. 新仕様への改修
23. 自分がやったこと 1. 既存実装のリファクタリング 2. アイテム機能の不具合修正 3. 新仕様への改修 3つのタイミング全てで 自動テストに助けられた
24. 自分がやったこと 1. 既存実装のリファクタリング 2. アイテム機能の不具合修正 3. 新仕様への改修
25. 既存実装のリファクタリング • アイテム利用の実装がほとんどActivityに 書かれていた ◦ 自動テストはない • 新仕様に改修する前にユニットテストを書 けるようにするためリファクタリング
26. 既存実装のリファクタリング Activityから処理の 切り出し ユニットテスト整備 繰り返し
27. 既存実装のリファクタリング 既存実装の振る舞いが細かく わかっていなくてもある程度できる Activityから処理の 切り出し ユニットテスト整備
28. 既存実装のリファクタリング テストパターンを作成するために 既存実装の振る舞いを把握する必要がある Activityから処理の 切り出し ユニットテスト整備
29. ユニットテストで振る舞いを理解する • 内部処理がシンプルとは言い難いかつ コメントやドキュメントもほとんどなく、 自分の理解があっているか不安 • 想定する挙動をテストケースにして、認識 があっているか検証する
30. ユニットテストで振る舞いを理解する • 内部処理がシンプルとは言い難いかつ コメントやドキュメントもほとんどなく、 自分の理解があっているか不安 • 想定する挙動をテストケースにして、認識 があっているか検証する 仕様化テスト
31. 自動テストに何を助けられた？ • 既存実装の振る舞いを理解するのを助けて もらった ◦ ユニットテストを動かしてみて、ああ〜そう いうことなのか！となることもしばしば
32. 自分がやったこと 1. 既存実装のリファクタリング 2. アイテム機能の不具合修正 3. 新仕様への改修
33. アイテム機能の不具合 • アイテムが押せなくなるというお問い合わ せが複数件あった • 一度発生するといったんライブを出ないと 解消されない • 通信エラー起因で発生している可能性
34. 既存実装の不具合調査でやったこと • 実装を読んでもパッと原因はわからない • リファクタリングでユニットテストを実装 できるようになっていたので、各APIリク エストでエラーが発生するパターンを追加
35. 既存実装の不具合調査でやったこと • 実装を読んでもパッと原因はわからない • リファクタリングでユニットテストを実装 できるようになっていたので、各APIリク エストでエラーが発生するパターンを追加 結果がおかしいやつがある! 原因を特定して修正
36. 既存実装の不具合調査でやったこと • 実装を読んでもパッと原因はわからない • リファクタリングでユニットテストを実装 できるようになっていたので、各APIリク エストでエラーが発生するパターンを追加 不具合の再現テスト
37. 自動テストに何を助けられた？ • 不具合の原因特定を助けてもらった ◦ あやしいケースのテストを書いてOK/NGを確認 • もう1つ別の要因でアイテムが利用できな くなる不具合の問い合わせもあったが、 そちらもユニットテストで再現 → 修正
38. 自分がやったこと 1. 既存実装のリファクタリング 2. アイテム機能の不具合修正 3. 新仕様への改修
39. 改修内容 アイテム素材はアプリ起動時に一括でDLされる ライブの中では基本的にはDLが完了している状態 旧仕様 新仕様 ライブ中にアイテムが利用されたタイミングで アイテム素材をDLする
40. 機能改修時に実装した自動テスト • 動作するか不安を感じる部分 • 手動で動作確認をするのが面倒な部分
41. 動作するか不安を感じる部分 • 処理がそこそこ複雑なところ • RxJavaであれこれやっているところ • 自分は初歩的なミスをしやすいので、 そこまで複雑でなくても条件分岐が複数あ るところ
42. 手動で動作確認をするのが面倒な部分 • 様々なデータパターンで確認したいところ • 連続する処理の中でピンポイントに動作を みたいところ • 時間経過によって処理が変わるところ • 状況を作り出すのが面倒なところ
43. 実装したテストを具体的に • 例:アイテムのダウンロード処理 ◦ ファイルの解凍と保存 ◦ 素材がDL済みの場合のスキップ処理 ◦ 素材が変更された場合のファイル更新処理 ◦ ダウンロードが並列で走るときの排他制御 ◦ 一定期間使用されなかった素材の削除処理
44. 自動テストに何を助けられた？ • 動作するか不安な気持ちを払拭できた • 手動で動作確認するコストを減らせた • 機能改修の中で再度修正を入れることが あっても安心感を持って修正できた
45. 自動テストに何を助けられた？ • 動作するか不安な気持ちを払拭できた • 手動で動作確認するコストを減らせた • 機能改修の中で再度修正を入れることが あっても安心感を持って修正できた 精神的な治安を維持できた
46. 自動テストに何を助けられた？ • 動作するか不安な気持ちを払拭できた • 手動で動作確認するコストを減らせた • 機能改修の中で再度修正を入れることが あっても安心感を持って修正できた 良い開発体験を得られた 自分にとっては一番大きなモチベーション 精神的な治安を維持できた
47. 自動テストに助けられたこと まとめ 1. 既存実装のリファクタリング ⇢ 振る舞いの理解を助けてもらった 2. アイテム機能の不具合修正 ⇢ 不具合の原因特定を助けてもらった 3. 新仕様への改修 ⇢ 精神的な治安を維持しながら開発ができた
48. いくつかの観点で自問自答
49. Q. 自動テストで発見できな かった不具合はあった？
50. A. あった
51. 自動テストで見つけられなかった不具合 • 認識ずれ • 観点の見落とし • スレッドの設定ミス • リファクタリングがやりきれなくて、自動 テスト書けるはずなのに書けていない箇所
52. 自動テストで見つけられなかった不具合 • 認識ずれ • 観点の見落とし • スレッドの設定ミス • リファクタリングがやりきれなくて、自動 テスト書けるはずなのに書けていない箇所 もっと自動テストが活用できた部分
53. Q. 開発していて不安に感じ ることが少ない場合は？
54. A. そういうときもある チームですり合わせは したほうがよさそう
55. 開発していて不安に感じない問題 • 不安に感じるレベルは人それぞれ ◦ ズレを感じる場面はしばしばある • PRレビューでも不安を感じたら提案して 不安感のすり合わせをするのがよさそう ◦ 動作する自動テストがあるとレビュアーも安 心できる
56. Q. QAでも不安は払拭できる のでは？
57. A. できる ただ、自分が不安なパス を通るとは限らない
58. QAと自動テスト • E2Eかつ手動の検証だと特定のケースを 発生させるのが難しい場合がある • 内部の処理がどうなっているかをよく 知っている人による動作確認も重要
59. Q. 自動テストを実装するの は時間がかかる？
60. A. かかった
61. 自動テストの実装に時間がかかる問題 • テストコード上での設定ミスに気が付かず 時間を浪費してしまい断念しそうになった • 自動テストをあきらめた場合の正常系〜 異常系の動作確認のコストを鑑みてテスト コードのデバッグを続けた
62. 自動テストの実装に時間がかかる問題 • テストコード上での設定ミスに気が付かず 時間を浪費してしまい断念しそうになった • 自動テストをあきらめた場合の正常系〜 異常系の動作確認のコストを鑑みてテスト コードのデバッグを続けた 一時的に時間がかかるけど、 短期的に見てもその分のコストがペイすると踏んだ
63. まとめ
64. まとめ • 自動テストで見つけられない不具合はある が、それでも自動テストはいいものだった • 自動テストはいいものと感じられたのは、 マイナスの気持ちを自動テストを通じて 払拭できたのが大きい
65. 宣伝
66. Androidエンジニアの採用始まりました • PocochaではAndroidエンジニアを募集中 ◦ ライブ配信サービスや技術に興味あるかた よかったら是非に ◦ https://career.dena.jp/job.phtml?job_code=1573
67. ご清聴ありがとうございました！