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

by shin

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© 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⽉:

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© kickﬂow, Inc. 8 Autify利⽤開始時点（2023年7⽉） ● CTO ○ 1名 ● 開発 ○ 社員1名 ○ 業務委託2名 ● QA ○ 社員1名 ○ 業務委託2名 ● デザイナー ○ 副業1名開発に関わるチーム構成現在（2025年3⽉） ● CTO ○ 1名 ● 開発 ○ 社員4名 ○ 業務委託1名 ● QA ○ 社員2名 ○ 業務委託3名 ● デザイナー ○ 社員1名 ○ 副業1名

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© kickﬂow, Inc. 11 前提（プロダクトの特性など） ● 動作環境 ○ Webのみ（Nativeアプリはない） ○ ブラウザ固有の不具合はほぼ出ないので、Chromeだけ⾒られれば⼗分 ○ PWAを提供しているが、スマホビュー固有の機能的な不具合もほぼ出ない ● 機能 ○ 稟議ツールの性質上、複数の機能が密接に絡み合っている ○ 影響範囲を特定しきれる新規機能開発は稀 ● 開発チームの特徴 ○ 開発が爆速 ○ 初期品質が⾼い ● リリース頻度 ○ 毎⽇（1⽇1~3回） ● 本番不具合 ○ 稟議は⽇常的に使われるツールなので、致命的な不具合はお客さまの業務に⼤きな⽀障が出る

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© kickﬂow, Inc. 13 リソースに関する課題 ● ⼿動テスト ○ リリースごと（毎⽇）に⼿動でリグレッションテストを実⾏するリソースがない ○ 全画⾯に影響のある修正のテストが⼤変 ■ ライブラリのアップデートや共通コンポーネントの変更など ○ そもそも開発が速すぎて検証が追いつかず、QAスキップで出す修正が多かった ○ 機能が増えていくに連れてQAを増やさないと回らなくなる ● ⾃動テスト ○ コードベースで⾃動テストを構築するリソースがない ○ 構築できたとしても保守していくリソースがない ■ 既存シナリオの保守 ■ 新機能のテスト追加 ■ テストカバレッジ向上のためのシナリオ追加 →やることが多い、時間がない

Slide 14

Slide 14 text

© kickﬂow, Inc. 14 ● ノーコードが必要な理由 ○ 完全QAスキップをなくすために基本シナリオは毎回実⾏しておきたい要望があった ○ リソースとプロダクト特性的にリグレッションの⾃動化は必須だった ○ コードベースは拡張‧保守⼈員を確保できる保証がないのでノーコードが必要だった ● Autifyにした理由 ○ 前職で使っていたので使いやすいのはわかっていた ○ 機能開発のスピードが速い印象があった ○ ⽇本語対応が他ツールより優れていた ○ サポートの返答が速い ○ ちょうどステップ数課⾦になった頃でタイミングがよかった ■ （機能的にも今後さらによくなって⾏きそうだった） Autifyを導⼊した理由

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© kickﬂow, Inc. 16 ⾃動テストの構成とAutifyの役割 ※QAチーム管轄の⾃動テストの話 ● Autify以外ではCypressとPostmanを使っている ● それぞれのツールの役割 ○ Autify ■ リグレッションテストの実装 ■ 新機能のテストの実装 ○ Cypress ■ Autifyでできない（or 安定しない）テストの実装（技術⾯） ■ 1⽇に何度も実⾏するようなテストの実装（コスト⾯） ○ Postman ■ REST APIの単体テスト、シナリオテスト

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© kickﬂow, Inc. 18 Autifyの利⽤範囲 ● 当初の想定 ○ 基本シナリオ（ハッピーパス） ○ リリースしたばかりの機能 ○ コードベースに不向きなシナリオ（要素が取りにくいコンポーネントのアサーションなど） →最低限のシナリオ ● 現在 ○ 全画⾯のリグレッション ○ 複雑な条件のテスト ○ パターン網羅的なテスト ○ 本番に流出した不具合の再発防⽌のためのシナリオ →Autifyの機能内で運⽤できるシナリオ全般

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© kickﬂow, Inc. 20 ● 思想的側⾯ ○ とにかく作って実⾏する ■ 構築フェーズはクレジットをケチらない ■ 頭の中のリグレッションシナリオをAutifyに落とし込むイメージでガンガン進める ○ ログイン1シナリオができたらその瞬間から運⽤を始める ○ 綺麗に完璧なものを作ろうとしない ○ 無理にテスト項⽬書と紐づけようとしない ● 技術的側⾯ ○ 最初はステップグループを使わない（ログイン以外） ○ JSステップはAPIによるデータ作成メインで使う、複雑なことはしない ○ クリーンアップステップはフル活⽤する爆速構築するためにやったほうが良いこと

Slide 21

Slide 21 text

© kickﬂow, Inc. 21 構築ストップした⽅がいいタイミング ● フレームワークやライブラリの⼤規模なアップデートが予定されている場合 ○ アップデート後に確実にE2Eシナリオが崩壊するので構築をストップしたほうがよい ○ 既存シナリオの修正より1から作り直した⽅が速いし運⽤も安定する ○ kickﬂowも2023年末にNuxt3移⾏があり、E2Eのシナリオ作成を3ヶ⽉ほど⽌めていた ● 現在のリソースで保守できない量のシナリオになってきたとき ○ カバレッジ上げたい気持ちはわかるが、拡張 < 保守が⼤前提 ○ 常にALL GREENである状態を維持する ○ 定期実⾏の結果通知がオオカミ少年状態になったら本末転倒

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© kickﬂow, Inc. 23 運⽤メンバー ● 新規シナリオの構築、既存シナリオの保守ともにQAプロパー（2⼈）のみで⾏なっている ● QAのプロパーだけで運⽤するメリット‧デメリット ○ メリット ■ QAチーム単独で意思決定できる ● 実⾏計画（シナリオの粒度や消費予定クレジットなどを含む） ● シナリオ拡張⽅針 ● シナリオ管理、実⾏結果管理⽅針の変更 ■ 他メンバー（開発やQA業務委託）の教育コストが不要 ■ ⼈員の⼊れ替わりがないので運⽤期間が⻑くなるに従って保守コストが下がる ● 保守メンバーがシナリオの作り⽅や不安定な箇所に慣れる ● 仕様変更への対応が早くなる ○ デメリット ■ どちらかが休むと保守メンバーがいなくなる ● ※運⽤メンバーのAutify歴 ○ 2⼈とも3年3ヶ⽉ほど

Slide 24

Slide 24 text

© kickﬂow, Inc. 24 リリースフローとE2Eの実⾏タイミング featureブランチでの開発内容がQA通過後にdevelopブランチに取り込まれるので、developに対してAutifyのE2Eテストを実⾏する。 E2Eテストで問題がなければmainブランチへマージされ、本番環境へリリースされる。 feature develop main QA環境 Sandbox環境本番環境 E2Eテスト実⾏ feature feature Passed

Slide 25

Slide 25 text

© kickflow, Inc. 25 ● kickflowは毎朝リリースがあるので、平⽇の早朝に定期実⾏を設定している ● 定期実⾏までの流れ ○ QAが⽇中にfeatureブランチでのテストを⾏い、完了したPRにQA Doneラベルをつける ○ 開発者が⼣⽅にQA DoneがついたPRをdevelopブランチへのマージ作業を⾏い、コードfixする ○ developブランチのコードはSandbox環境に⾃動デプロイされる ○ 次の⽇の朝にAutifyの定期実⾏設定がkickされてSandbox環境でE2Eテストが実⾏される ● 実⾏結果の確認とリリース判断 ○ QAが朝に実⾏結果を確認を⾏い、問題なければそのままリリースが⾏われる ○ ⾃動テストで不具合を検知した場合は以下の流れになる ■ 1. リリースブロッカーになる不具合と判断された場合 →修正してからリリース ■ 2. リリースブロッカーにはならない不具合と判断された場合 →そのままリリースして不具合修正は後⽇別でリリースする定期実⾏

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© kickﬂow, Inc. 29 仕様変更による保守作業 ● 影響範囲がわかりやすい仕様変更 ○ 事前にAutifyの対象のシナリオを修正する ○ ex) ⽂⾔変更や遷移先変更、初期表⽰値の変更など ● 影響範囲を特定するのに時間がかかる仕様変更 ○ わかる範囲で直して次の⽇の定期実⾏を迎え、落ちたシナリオを直す ○ 落ちるシナリオ数が多くなりそうだったら前⽇の夜に⼿動でテストプランをkickして直しておくこともある

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© kickﬂow, Inc. 32 ● できたこと ○ リリース判定への利⽤ ○ 不具合再発防⽌策への利⽤ ○ 新機能に対するE2Eの追随 ● できなかったこと ○ コードベースのE2E廃⽌ ■ ダウンロードしたファイルの中⾝のテスト ■ スナックバーのアサーション ■ UI上で発⾏したアクセストークンを利⽤したAPIリクエストのテスト ■ AIオプション機能の精度のチェックなど Autifyでできたこと‧できなかったこと

Slide 33

Slide 33 text

© kickﬂow, Inc. 33 ● ⾃動テストの合否結果を以って毎朝リリース可否を報告している ● ここ半年くらいで開発チームにもこの運⽤が浸透し、開発のリリース担当者はリリース前に必ずE2Eテストの実⾏結果を⾒に来てくれる ○ （勝⼿にリリースされるようなことがなくなった） ● リリースブランチでの最終チェックを⼈間でなく機械（=Autify）がやってくれるので、QAメンバーの⼼理的ストレスを低く運⽤できるできたこと① : リリース判定への利⽤

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© kickﬂow, Inc. 35 ● kickﬂowは機能改善のサイクルが速いので、新機能周りで不具合が出やすい ● Autifyで迅速にシナリオ整備できることで新機能のリリースに⾃動テストが追いつきやすくなった ● コードベースの⾃動テストではリソースがあっても難しいのでここはやはりノーコードが強い ○ ※新機能はリリース前後で⼩さな仕様変更が⼊ることが多いので、ノーコードで組むと⼿戻りが多くなり保守が難しいできたこと③ : 新機能に対するE2Eの追随

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© kickﬂow, Inc. 42 ● kickﬂow主要4機能の全機能網羅テストの構築を進⾏中 ○ チケット ○ ワークフロー ○ 経路 ○ 組織図 ● 2⽉~7⽉まででシナリオ本数を84本→150本にする計画 ○ ※1シナリオ平均60~65ステップ ● 今年の年始にはクレジットを追加 ○ 既存シナリオ運⽤分 + 拡張計画分に必要なステップ数を試算して不⾜分のクレジットを購⼊拡張計画 QAチームの主要施策として⽬標設定している

Slide 43

Slide 43 text

Slide 44

Slide 44 text