自動E2Eテストを活用した デプロイフロー改善

MagicPodミートアップの発表スライドです。
https://trident-qa.connpass.com/event/278843/

Transcript

1. 自動E2Eテストを活用した デプロイフロー改善 2023/04/26 @sukechannnn
2. ⾃⼰紹介 ⼩幡 洋介 （@sukechannnn） テックリード 2021年12⽉アルダグラムにジョイン • 昨年: 多⾔語対応（英語/タイ語/スペイン語） • 現在: SREチームでデプロイ基盤の改善 • ⾃動E2Eテストの整備をリード 趣味︓⾳楽 (ドラム)、焚き⽕ ⼦育て奮闘中
3. 会社・プロダクトの紹介
5. COMPANY 会社概要 5 会社名 設⽴ 代表者 所在地 従業員数 累計 調達⾦額 株主 株式会社アルダグラム 2019年5⽉8⽇ ⻑濱 光 (東京本社) 東京都港区芝浦⼀丁⽬ 1 番 1 号 浜松町ビルディング11階 (マドリードオフィス) Monasterio de Urdax, 49, 31011 Pamplona, Navarra, Spain 68名 (2023年4⽉1⽇時点) 21.4億円 ジャフコ / インキュベイトファンド 株式会社MonotaRO /株式会社LIFULL サンネクスタグループ/経営陣 ほか
6. HISTORY 会社沿⾰ 3⼈ 12⼈ 13⼈ 20⼈ 25⼈ 2019.05 2019.12 2020.07 2021.10 2022.03 2022.05 会社設⽴ プロジェクト管理アプリ 「KANNA」をリリース 神楽坂へ本社移転 ⽇本橋へ本社移転 「KANNA] 導⼊5,000社突 破 シリーズAで 約20億円の調 達 48⼈ 2022.11 52⼈ 2022.12 浜松町へ 本社移転 「KANNA] 導⼊10,000社突 破 30⼈
7. KANNA(カンナ) は、 建設業、不動産業、製造業など、 世界中のノンデスクワーク業界における 現場の⽣産性アップを実現する「プロジェクト管理アプリ」です。 事務作業や移動、コミュニケーションの⼿間を カンナのように削り、作業の⽣産性を最⼤化します。 スマホでの使いやすさが⽀持され、 業界・国境を越えて⾼い評価をいただいております。 PRODUCT
8. KANNA で解決できる課題 8 現場にいながら、スマホ・タブレットで業務効率化︕ 現場情報を ミスなく共有 最新の資料へ ワンクリック 移動コスト ⼤幅削減 チャットで 即やりとり 写真だけで 1分で報告書 PC。スマホ。タブレット。 最新情報をどこでも確認でき るから、メールや電話による ミスや⼿間がなくなります。 間違って古い資料を⾒てしま うなんてミスも解消。 迷うことなく最新資料にアク セスできます。 リアルタイムで現場状況をシ ェアできるため、確認のため に何度も現場と往来していた ⼿間が省けます。 これまでのメールや電話での やり取りをチャットでスピー ディーに︕ チャットの活⽤で連絡漏れも 防げます。 ExcelやWordでの報告書がす べて写真を選ぶだけのやりと りに。事務作業の負担が⼀気 に減ります。
9. 開発チームの現状と 今までのデプロイフロー
10. プロダクト開発本部 企画・デザイン 開発 KANNA プロジェクト管理 KANNA SRE KANNA アプリ 開発チーム構成 デザイナー 2名 PdM 2名 エンジニア 6名 エンジニア 7名 エンジニア 3名 KANNA グロース エンジニア 6名 KANN 新規プロダ エンジ エンジニアの⼈数は１年で倍以上に チームの数もすごく増えてきている
11. 課題 • どこか１つでもリリースできないバグが⾒つかると、別の機能の開発物もリ リースが遅れる • ２週間に１回しかデプロイしないので、バグ修正などの急いで出したいもの もなかなか本番反映できない • １回のリリース時の影響範囲が広く、テスト範囲が「全部」みたいになる ◦ ⇢ これは MagicPod である程度は解消した✨ 元々のデプロイフロー（Web） 今までは２週間に１回デプロイしか デプロイしていなかった
12. 今取り組んでること シン・デプロイフロー
13. リリーストレインの考え⽅を採⽤ 毎⽇決まった時間にデプロイ・その時点で出荷可能なものをリリース（乗り遅れたら置いていく）
14. シン・デプロイフロー • 開発した個別機能のチェックはqa環境で ⼿動テスト • 全体リグレッションテストは MagicPod で⾃動テスト 開発⇢テスト⇢デプロイ を⾼頻度に⾏うこと で価値を素早く届けバグを減らす QA 3名 デプロイ頻度を ２週間に１回⇢週１回⇢週２回⇢毎⽇ に増やす︕
15. qa環境 / pre-prod 環境の構築 • qa環境: 開発した機能毎に動作確認できる環境をたくさん作れる基盤を整備 • pre-prod環境: 本番環境に限りなく近い環境でテストできる基盤を整備 MagicPod によるE2Eテストの⾃動化 • 増え続ける機能のテストを全て⼿動で網羅するのは不可能なので、⾃動化して網 羅テストはMagicPod に置き換えていった • 昨年から継続して取り組んできていて、MagicPod のおかげでシン・デプロイフ ローが実現した シン・デプロイフロー実現のために取り組んできたこと
16. MagicPod の整備について
17. テスト整備の運⽤⽅法 ⼿動テストのシナリオをベースに MagicPod でテスト実装 • 元々は⼿動で全ての機能をテストしていて、そのシナリオがスプレッドシートにまとまっ ていたので活⽤ • ⾃動化できているものを判別できるようにして、テストの網羅率を判定 • ◯: ⾃動化済み ◆: ⾃動化可能だが未対応 - : ⾃動化できない（ダウンロード系な ど） • 機能追加されたら「テストシナリオ追加⇢⼿動テスト実施⇢問題なければ⾃動化」という 流れで継続的に整備
18. MagicPod が安定化するために data-testid の整備 • ロケータを特定するための情報がフロントエンドになく、E2Eを実装しても不安定だった • テスト⽤に data-testid を全ページに追加することで、テストが安定するようになった • data-testid は単体テストや Visual Regression Testing でも活⽤してる 毎⽇テストを回して落ちたテストを修正 • 毎⽇決まった時間に開発環境と本番環境の両⽅でテストを回して、落ちている箇所を確認 している • テストの結果は Slack 通知してQAエンジニアがチェック • テスト結果を⾒て、改修によるエラーであればテスト修正、そうでなければバグ報告 • 継続的にチェックし続けることがだいじ
19. デプロイOK/NGの判断 E2Eの結果は⼈が解釈する • E2Eテストが全てOKでなくてもリリースして良い場合はある • そのため「E2Eがオールグリーンになったらリリース」のような運⽤にはしていない E2Eをオールグリーンにすることが⽬的ではない • むしろ定期的にエラーになった⽅が、差分を検知できているという意味で安⼼感がある • シナリオ100個に対して5個くらいのエラーくらいがちょうど良い割合という肌感 • 同じところで継続的にエラーになっているのを放置すると割れ窓になる • そこはエンジニア側で改修する
20. ユニットテストとE2E (MagicPod) E2Eテストで全てのパターンを網羅することはできない • 権限周りや機能の組み合わせなどを全て網羅しようとすると組合せ爆発になる • そのため、ユニットテストの整備も継続して⾏っている ユニットテストでコードの振る舞いを、E2Eでユーザーの振る舞いをテスト • ユニットテストが書かれたロジックが積み上がることで、予期せぬ挙動を防ぐことができる • そのため、新規実装では基本的に全てテストを書いているし、過去のコードにテストを追加する 活動も⾏っている • フロントエンドも︕
21. まとめ
22. まとめ E2Eは⾃動化しないと増えていくテストに対応し続けられない • 機能が増え続けるとテスト⼯数は機能以上に増えていくことになる • ⼈がチェックするのは「機能が受け⼊れ条件を満たしているか」にフォーカスすべき • リグレッションテストは⾃動E2Eツールに任せよう MagicPod はエンジニアじゃなくてもテスト実装&運⽤できる強い味⽅ • 使えるコマンドが豊富なため、ノーコードで様々なシナリオに対応可能 • ⾃動修復が優秀なので、細かいUI変更には簡単に追従できて運⽤が回る • エンジニアの協⼒は不可⽋...E2Eしやすい実装にしよう MagicPodでリグレッションを検知できるから、デプロイ頻度を増やせる • 全てを⼿動でチェックしていたら不可能だが、ユニットテストだけではテストとして不完全 • ユニットテストでコードの振る舞いを、MagicPod でユーザーの振る舞いをカバー
23. 今後取り組みたいこと モバイルの E2E を MagicPod で安定してテストする • Android / iOS 両⽅あり、React Native + Native Module (Kotlin, Swift) という構成なのもあ り、現状 MagicPod がなかなか安定しない • Webに⽐べると data-testid に相当するものの整備もできておらず、なかなか安定しないので、 まずは id の整備からやっていきたい 機能のマージをトリガーに MagicPod でテストする • 最近、何もしてないのにテスト時間が 4時間 ⇢ 2時間ちょっとに短縮されたので、開発した機能 ごとに MagicPod を実⾏して結果を通知する、という運⽤の実現可能性が⾼くなってきた • 将来的には、差分のある機能のテストだけ MagicPod でテストするようにできれば、⾼頻度な E2E テストが実現できそうなので、やっていきたい