[kickflow]20250319_少人数チームでのAutify活用

Transcript

1. © kickflow, Inc. 1 少⼈数チームでのAutify活⽤ 20250319_Autify Community Event 株式会社kickflow プロダクト開発本部 川村 進太郎
2. © kickflow, Inc. 2 ⽬次 • kickflowについて • 開発チームの構成とリリースフロー • Autify導⼊の背景 • ⾃動テストの構成 • 構築編 • 運⽤編 • 成果 • 最近の取り組み • これから • Q&A
3. © kickflow, Inc. 3 kickflowについて
4. © kickflow, Inc. 4 株式会社SmartHRの新規事業⼦会社として創業 β版ローンチ、サービス販売開始 MBO（経営陣による買収）、シードラウンドの資⾦調達、⼀般公開 プレシリーズAラウンドの資⾦調達 株式会社kickflow 2021年8⽉ ※事業開始は2020年2⽉ クラウド稟議‧ワークフロー「kickflow」の開発‧運営 640,554,800円（資本準備⾦含む） Headline Asia, mint, グリーベンチャーズ, HENNGE株式会社、 Sansan株式会社、三菱UFJキャピタル、SMBCベンチャーキャピタル 会社概要 会社情報 社名: 設⽴: 事業内容: 資本⾦: 投資家: 沿革 2020年02⽉: 2020年05⽉: 2021年10⽉: 2023年10⽉:
5. © kickflow, Inc. 5 kickflow エンタープライズ企業向けの稟議‧ワークフローのク ラウドサービスです。
6. © kickflow, Inc. 6 技術スタック https://tech.kickflow.co.jp/entry/2022/10/12/132716
7. © kickflow, Inc. 7 開発チームの構成とリリースフロー
8. © kickflow, Inc. 8 Autify利⽤開始時点（2023年7⽉） • CTO ◦ 1名 • 開発 ◦ 社員1名 ◦ 業務委託2名 • QA ◦ 社員1名 ◦ 業務委託2名 • デザイナー ◦ 副業1名 開発に関わるチーム構成 現在（2025年3⽉） • CTO ◦ 1名 • 開発 ◦ 社員4名 ◦ 業務委託1名 • QA ◦ 社員2名 ◦ 業務委託3名 • デザイナー ◦ 社員1名 ◦ 副業1名
9. © kickflow, Inc. 9 リリースフロー featureブランチで新規機能の開発がされ、QAが通ったらdevelopにマージされてリリースされる運⽤。 feature develop main QA環境 Sandbox環境 本番環境 feature feature
10. © kickflow, Inc. 10 Autify導⼊の背景
11. © kickflow, Inc. 11 前提（プロダクトの特性など） • 動作環境 ◦ Webのみ（Nativeアプリはない） ◦ ブラウザ固有の不具合はほぼ出ないので、Chromeだけ⾒られれば⼗分 ◦ PWAを提供しているが、スマホビュー固有の機能的な不具合もほぼ出ない • 機能 ◦ 稟議ツールの性質上、複数の機能が密接に絡み合っている ◦ 影響範囲を特定しきれる新規機能開発は稀 • 開発チームの特徴 ◦ 開発が爆速 ◦ 初期品質が⾼い • リリース頻度 ◦ 毎⽇（1⽇1~3回） • 本番不具合 ◦ 稟議は⽇常的に使われるツールなので、致命的な不具合はお客さまの業務に⼤きな⽀障が出る
12. © kickflow, Inc. 12 品質に関する課題 • 影響範囲の考慮漏れで、致命的な不具合が本番に流出する • ライブラリのアップデートでデグレが発⽣する • featureブランチをマージしたあとの統合ブランチで不具合が発⽣する • 本番でお客さまに指摘されて不具合に気づく →リリースが怖い
13. © kickflow, Inc. 13 リソースに関する課題 • ⼿動テスト ◦ リリースごと（毎⽇）に⼿動でリグレッションテストを実⾏するリソースがない ◦ 全画⾯に影響のある修正のテストが⼤変 ▪ ライブラリのアップデートや共通コンポーネントの変更など ◦ そもそも開発が速すぎて検証が追いつかず、QAスキップで出す修正が多かった ◦ 機能が増えていくに連れてQAを増やさないと回らなくなる • ⾃動テスト ◦ コードベースで⾃動テストを構築するリソースがない ◦ 構築できたとしても保守していくリソースがない ▪ 既存シナリオの保守 ▪ 新機能のテスト追加 ▪ テストカバレッジ向上のためのシナリオ追加 →やることが多い、時間がない
14. © kickflow, Inc. 14 • ノーコードが必要な理由 ◦ 完全QAスキップをなくすために基本シナリオは毎回実⾏しておきたい要望があった ◦ リソースとプロダクト特性的にリグレッションの⾃動化は必須だった ◦ コードベースは拡張‧保守⼈員を確保できる保証がないのでノーコードが必要だった • Autifyにした理由 ◦ 前職で使っていたので使いやすいのはわかっていた ◦ 機能開発のスピードが速い印象があった ◦ ⽇本語対応が他ツールより優れていた ◦ サポートの返答が速い ◦ ちょうどステップ数課⾦になった頃でタイミングがよかった ▪ （機能的にも今後さらによくなって⾏きそうだった） Autifyを導⼊した理由
15. © kickflow, Inc. 15 ⾃動テストの構成
16. © kickflow, Inc. 16 ⾃動テストの構成とAutifyの役割 ※QAチーム管轄の⾃動テストの話 • Autify以外ではCypressとPostmanを使っている • それぞれのツールの役割 ◦ Autify ▪ リグレッションテストの実装 ▪ 新機能のテストの実装 ◦ Cypress ▪ Autifyでできない（or 安定しない）テストの実装（技術⾯） ▪ 1⽇に何度も実⾏するようなテストの実装（コスト⾯） ◦ Postman ▪ REST APIの単体テスト、シナリオテスト
17. © kickflow, Inc. 17 構築編
18. © kickflow, Inc. 18 Autifyの利⽤範囲 • 当初の想定 ◦ 基本シナリオ（ハッピーパス） ◦ リリースしたばかりの機能 ◦ コードベースに不向きなシナリオ（要素が取りにくいコンポーネントのアサーションなど） →最低限のシナリオ • 現在 ◦ 全画⾯のリグレッション ◦ 複雑な条件のテスト ◦ パターン網羅的なテスト ◦ 本番に流出した不具合の再発防⽌のためのシナリオ →Autifyの機能内で運⽤できるシナリオ全般
19. © kickflow, Inc. 19 構築期間とシナリオ数 • リソース ◦ 1⼈（⽚⼿間） • 期間 ◦ Autifyだけに絞ると3~4ヶ⽉ほど • シナリオ数 ◦ 50~60シナリオほど ◦ 平均ステップ数60~70
20. © kickflow, Inc. 20 • 思想的側⾯ ◦ とにかく作って実⾏する ▪ 構築フェーズはクレジットをケチらない ▪ 頭の中のリグレッションシナリオをAutifyに落とし込むイメージでガンガン進める ◦ ログイン1シナリオができたらその瞬間から運⽤を始める ◦ 綺麗に完璧なものを作ろうとしない ◦ 無理にテスト項⽬書と紐づけようとしない • 技術的側⾯ ◦ 最初はステップグループを使わない（ログイン以外） ◦ JSステップはAPIによるデータ作成メインで使う、複雑なことはしない ◦ クリーンアップステップはフル活⽤する 爆速構築するためにやったほうが良いこと
21. © kickflow, Inc. 21 構築ストップした⽅がいいタイミング • フレームワークやライブラリの⼤規模なアップデートが予定されている場合 ◦ アップデート後に確実にE2Eシナリオが崩壊するので構築をストップしたほうがよい ◦ 既存シナリオの修正より1から作り直した⽅が速いし運⽤も安定する ◦ kickflowも2023年末にNuxt3移⾏があり、E2Eのシナリオ作成を3ヶ⽉ほど⽌めていた • 現在のリソースで保守できない量のシナリオになってきたとき ◦ カバレッジ上げたい気持ちはわかるが、拡張 < 保守 が⼤前提 ◦ 常にALL GREENである状態を維持する ◦ 定期実⾏の結果通知がオオカミ少年状態になったら本末転倒
22. © kickflow, Inc. 22 運⽤編
23. © kickflow, Inc. 23 運⽤メンバー • 新規シナリオの構築、既存シナリオの保守ともにQAプロパー（2⼈）のみで⾏なっている • QAのプロパーだけで運⽤するメリット‧デメリット ◦ メリット ▪ QAチーム単独で意思決定できる • 実⾏計画（シナリオの粒度や消費予定クレジットなどを含む） • シナリオ拡張⽅針 • シナリオ管理、実⾏結果管理⽅針の変更 ▪ 他メンバー（開発やQA業務委託）の教育コストが不要 ▪ ⼈員の⼊れ替わりがないので運⽤期間が⻑くなるに従って保守コストが下がる • 保守メンバーがシナリオの作り⽅や不安定な箇所に慣れる • 仕様変更への対応が早くなる ◦ デメリット ▪ どちらかが休むと保守メンバーがいなくなる • ※運⽤メンバーのAutify歴 ◦ 2⼈とも3年3ヶ⽉ほど
24. © kickflow, Inc. 24 リリースフローとE2Eの実⾏タイミング featureブランチでの開発内容がQA通過後にdevelopブランチに取り込まれるので、developに対してAutifyのE2Eテストを実⾏する。 E2Eテストで問題がなければmainブランチへマージされ、本番環境へリリースされる。 feature develop main QA環境 Sandbox環境 本番環境 E2Eテスト 実⾏ feature feature Passed
25. © kickflow, Inc. 25 • kickflowは毎朝リリースがあるので、平⽇の早朝に定期実⾏を設定している • 定期実⾏までの流れ ◦ QAが⽇中にfeatureブランチでのテストを⾏い、完了したPRにQA Doneラベルをつける ◦ 開発者が⼣⽅にQA DoneがついたPRをdevelopブランチへのマージ作業を⾏い、コードfixする ◦ developブランチのコードはSandbox環境に⾃動デプロイされる ◦ 次の⽇の朝にAutifyの定期実⾏設定がkickされてSandbox環境でE2Eテストが実⾏される • 実⾏結果の確認とリリース判断 ◦ QAが朝に実⾏結果を確認を⾏い、問題なければそのままリリースが⾏われる ◦ ⾃動テストで不具合を検知した場合は以下の流れになる ▪ 1. リリースブロッカーになる不具合と判断された場合 →修正してからリリース ▪ 2. リリースブロッカーにはならない不具合と判断された場合 →そのままリリースして不具合修正は後⽇別でリリースする 定期実⾏
26. © kickflow, Inc. 26 • Cypress, Postman含む全ての⾃動テストの結果はSlackチャンネルに通知するようにしている • Autifyだけ2つのチャンネルを使っていて、ワークスペースのデフォルトの通知先の他に定期実⾏のテストプラ ンの通知先を作ってる 実⾏結果の確認 デフォルト テストプラン⽤
27. © kickflow, Inc. 27 実⾏結果の確認 : ワークスペースのデフォルト
28. © kickflow, Inc. 28 実⾏結果の確認 : 定期実⾏テストプラン専⽤
29. © kickflow, Inc. 29 仕様変更による保守作業 • 影響範囲がわかりやすい仕様変更 ◦ 事前にAutifyの対象のシナリオを修正する ◦ ex) ⽂⾔変更や遷移先変更、初期表⽰値の変更など • 影響範囲を特定するのに時間がかかる仕様変更 ◦ わかる範囲で直して次の⽇の定期実⾏を迎え、落ちたシナリオを直す ◦ 落ちるシナリオ数が多くなりそうだったら前⽇の夜に⼿動でテストプランをkickして直しておくことも ある
30. © kickflow, Inc. 30 成果
31. © kickflow, Inc. 31 最近の運⽤周りの数値データ（概算） • 運⽤中のシナリオ数 ◦ 84本（平均ステップ数 60） • 定期実⾏の所要時間 ◦ 約1時間 • 直近のテスト失敗率 ◦ 4.76%（ = 成功率 95.24%） • 保守にかかる時間 ◦ 15分/⽇ • E2Eでの不具合検知件数 ◦ 3件/⽉
32. © kickflow, Inc. 32 • できたこと ◦ リリース判定への利⽤ ◦ 不具合再発防⽌策への利⽤ ◦ 新機能に対するE2Eの追随 • できなかったこと ◦ コードベースのE2E廃⽌ ▪ ダウンロードしたファイルの中⾝のテスト ▪ スナックバーのアサーション ▪ UI上で発⾏したアクセストークンを利⽤したAPIリクエストのテスト ▪ AIオプション機能の精度のチェック など Autifyでできたこと‧できなかったこと
33. © kickflow, Inc. 33 • ⾃動テストの合否結果を以って毎朝リリース可否を報告している • ここ半年くらいで開発チームにもこの運⽤が浸透し、開発のリリース担当者はリリース前に必ずE2Eテストの実 ⾏結果を⾒に来てくれる ◦ （勝⼿にリリースされるようなことがなくなった） • リリースブランチでの最終チェックを⼈間でなく機械（=Autify）がやってくれるので、QAメンバーの⼼理的 ストレスを低く運⽤できる できたこと① : リリース判定への利⽤
34. © kickflow, Inc. 34 できたこと② : 不具合再発防⽌策への利⽤ • 本番インシデント発⽣時の再発防⽌策の1つとして、「E2Eへの追加」を選択肢として取れるようになった • 本番リリース前に必ずAutifyのテストを回す運⽤になっているので、Autifyに不具合対策⽤のシナリオを追加し て回しておけば同じ不具合は2度と出ないとコミットしやすい
35. © kickflow, Inc. 35 • kickflowは機能改善のサイクルが速いので、新機能周りで不具合が出やすい • Autifyで迅速にシナリオ整備できることで新機能のリリースに⾃動テストが追いつきやすくなった • コードベースの⾃動テストではリソースがあっても難しいのでここはやはりノーコードが強い ◦ ※新機能はリリース前後で⼩さな仕様変更が⼊ることが多いので、ノーコードで組むと⼿戻りが多くな り保守が難しい できたこと③ : 新機能に対するE2Eの追随
36. © kickflow, Inc. 36 Autifyにして良かったこと • 要素の変更に強い ◦ 多少のUI変更なら勝⼿に正しい要素を⾒つけ直してくれる • シナリオの修正が楽 ◦ 実⾏結果詳細画⾯から要素を指定できる機能が便利 • 要確認の精度が⾼い • ツール起因のテスト失敗がほとんどない • 新機能をたくさん出してくれてどんどん便利になっている
37. © kickflow, Inc. 37 最近の取り組み
38. © kickflow, Inc. 38 チケット管理ツールでのE2E検知バグ集計 Asanaのフィールドに「E2E」検知を追加し、⾃動テストで検知された不具合を集計できるようにした
39. © kickflow, Inc. 39 全シナリオの並列実⾏ 並列化して 1本のテストプランに集約
40. © kickflow, Inc. 40 シナリオラベルの整理 ⽬的別に必要なラベルを決め直し、全シナリオに振り直した • シナリオ区分 • 機能区分 • コンポーネント • テストデータのサブドメイン （例）
41. © kickflow, Inc. 41 これから
42. © kickflow, Inc. 42 • kickflow主要4機能の全機能網羅テストの構築を進⾏中 ◦ チケット ◦ ワークフロー ◦ 経路 ◦ 組織図 • 2⽉~7⽉まででシナリオ本数を84本→150本にする計画 ◦ ※1シナリオ平均60~65ステップ • 今年の年始にはクレジットを追加 ◦ 既存シナリオ運⽤分 + 拡張計画分 に必要なステップ数を試算して不⾜分のクレジットを購⼊ 拡張計画 QAチームの主要施策として⽬標設定している
43. © kickflow, Inc. 43 Q&A
44. © kickflow, Inc. 44 kickflow採⽤ページ https://herp.careers/v1/kickflow 会社Wantedly https://www.wantedly.com/companies/kickflow 登壇者メールアドレス shintaro.kawamura@kickflow.com