不安定だったテストが信頼を取り戻すまで / The Road to Trustworthy Tests

2025/06/04 に開催された、Autify Community Meetup 2025 #2 でお話させていただきました。

Transcript

1. © Alp, Inc. 2025/06/04 Autify Community Meetup 2025 #2 不安定だったテストが 信頼を取り戻すまで
2. © Alp, Inc. はじめに 自己紹介 あきさん（Akihiro YOKOTA） • アルプ株式会社 QAエンジニア • X: @katawara 名刺管理の会社でバックエンドエンジニアやEMを経 て、QAチームの立ち上げから、全社横断のQA組織を 作るまでを経験。 2023年からアルプ株式会社に入社。社内唯一のQAエ ンジニアとしてできることは何かを日々模索する。
3. © Alp, Inc. BtoBサブスクリプションビジネスのための 販売管理システム 売上回収まで実現する法人向け 請求・決済システム 提供する2つのプロダクト 販売管理システム 請求‧決済システム
4. © Alp, Inc. 多くのビジネスがサービス化（XaaS）している • 顧客起点での継続的な関係が重要視され、またIoTやAIのようなデジタル技術の普及により、サービス型のビジネスモデルへのシフトが一層 進んでいる。 • SaaSを始めとして市場規模も右肩上がりで伸びており、今後もさらなる成長が見込まれる。 SaaS PaaS IaaS MaaS DaaS BPaaS ・ ・ ・ SaaS 1兆2,284億円 (2022年度） 1兆8,330億円 (2026年度予測） PaaS 4,221億円 (2022年度） 7,166億円 (2026年度予測） IaaS 6,272億円 (2022年度） 8763億円 (2026年度予測） 参照：株式会社富士通キメラ総研『2023 クラウドコンピューティングの現状と将来展望 市場編／ベンダー戦略編』
5. © Alp, Inc. サービス化に伴う変化と課題 • 従来のモノ売りからサービス化へのシフト伴い、プライシングや販売オペレーションに大きな変化が発生します。 • それらの変化に対しては、従来の仕組みでは対応できないことが多く、新たな販売管理の仕組みを整えることが必要です。 モノ 単一価格 一括売り サービス 月額課金　年額課金 毎月請求　一括前払い 日割り など 定額課金 従量課金 アカウント課金 利用実績に応じた課金 成果報酬に応じた課金 など 継続的なプライシング 戦略や顧客ニーズ、市場トレンドに合わせて流動的にプライシングも変化 プライシングの変化 オペレーションの変化 モノ 期間の概念なし サービス 契約管理 請求管理 請求/決済 入金管理・督促 事業分析 基本的に単価×数量の 1回課金 販売時に1回 請求書払いがメイン 1回課金の為頻度は少ない 新規販売の分析がメイン 期間の概念あり 時系列での管理が必要 継続的な課金が発生 従量課金の計算も必要 継続的な業務が発生 決済手段も多様化 継続的な課金の為高頻度 MRR/チャーンレート等 特有のKPI分析が必要 継続的な契約が前提となる為、販売オペレーションは複雑化する一方、正確性の担保は必要 新たに考慮が必要な要素が増加
6. © Alp, Inc. © Alp, Inc. 前提
7. © Alp, Inc. 手動テスト ローコードテスト 手動テスト・ローコードテスト・コードベーステストを場面に応じて使い分け アルプのテストの構成 コードベーステスト • 他社サービスとの連携が必要なテス トが主戦場 • コードベースで実装すると大変なも の（メール受信など）でも活用 • 新規開発で作ったものに対して実施 • 自社内で完結できるテストはこちら を優先的に検討 • ハッピーパスを中心に、マイナーな 操作でテストを忘れがちなシナリオ までをカバー
8. © Alp, Inc. • シナリオが成功したか失敗したかをまとめて見られる形で表示 ◦ 普段はテストプランをテーマごとに分割しているので、まとめて俯瞰したかった • 月あたりの各シナリオの成功率、シナリオ x 失敗原因のヒートマップ、一日のシナリオ失敗数をトラッキング ◦ 週次で集計して推移を見ている 社内向けにはLooker StudioやGoogle Spreadsheetで集計したものを共有している データ集計フロー
9. © Alp, Inc. 参考：ダッシュボード（Google Spreadsheet）
10. © Alp, Inc. 参考：ダッシュボード（一部抜粋：Looker Studio）
11. © Alp, Inc. © Alp, Inc. 1回目のチーム移譲
12. © Alp, Inc. • 先代QAエンジニアの卒業に伴い、QAエンジニア としては一人に • この時点ですでに、ローコードの自動テストと コードベースの自動テストは存在していた • しばらく自分が中心になって見てきたが、テスト が失敗しても一部の人だけが見ている状態が続く 入社3ヶ月目 〜 の状況
13. © Alp, Inc. もっとテストに関心を持ってほしい・・・ 募るもやもや 重要な失敗かもしれないのに・・・ みんなで面倒見る体制にしたい・・・ とはいえ、毎回メンションするのも・・・
14. © Alp, Inc. シナリオごとに担当チームを決めて 失敗したときに自動で通知すれば 自然と見てもらえるようになるのでは
15. © Alp, Inc.
16. © Alp, Inc. テストが失敗したら関係チームに メンションできるようになりました めでたしめでたし
17. © Alp, Inc. と思ったのもつかの間・・・
18. © Alp, Inc.
19. © Alp, Inc. • 問い合わせなどと混ざってしまい、テスト以上に反応しなければいけないメンションを見逃す事態が起きてし まった • チーム内で担当を決めたとて、そのスレッドで議論を始めてしまうと、それはそれで通知が飛んで、結局アテ ンションが奪われてしまった • 良かれと思ってやったことがチームの活動の足かせになってしまっていた ☠ 開発チームからのギブアップ宣言 ↓ • チームへのメンションはやめて、自分とそのチームのマネージャーだけのメンションに切り替え • 状況は巻き戻り、それどころかテストはむしろ信頼されなくなってしまった 🥺
20. © Alp, Inc. © Alp, Inc. 信頼を取り戻すために
21. © Alp, Inc. とはいえ、たしかに • 個人としても、あんまりうまくいってないかも、という体感は実はあった • が、数値的根拠がなかった ということで • まずはファクトを集めることから始めた • スプレッドシートに失敗のログを全部手動で転記 • 毎週集計して分析結果をつぶやくという活動を草の根的に開始 まずはファクト
22. © Alp, Inc.
23. © Alp, Inc.
24. © Alp, Inc. • 失敗している中で80%近くはflakyなテストで、再実行すれば大体通るが、たまに連続で失敗する • 多い日は10件近くの失敗の通知が来る • 引き継いだテストの中にはほとんど中身を見たことのないものもある 改めて状況を言語化してみると これではいけませんね？
25. © Alp, Inc. flaky testの撲滅を目指す ◦ Jenkins経由で行うバッチ実行に時間がかかることがある ◦ ステータス反映に時間がかかることがある ◦ 月をまたぐと、請求書の明細内容が変化して、月初になるたびに必ずテストが失敗する ◦ テストのタイミングによって外部サービスの認証トークンが切れていて、連携処理が継続できない など 信頼を取り戻す・1
26. © Alp, Inc.
27. © Alp, Inc. とにかく経過観察と発信を続ける ◦ 定点観測を続けて、変化を伝え続ける ◦ 続けていれば、気にしている人は案外見てくれている ◦ 何も失敗がない日はお祝いする 🎉🎉🎉 信頼を取り戻す・2
28. © Alp, Inc. 肥大化しすぎたテストの実行をやめる ◦ 改めて、開発チームを巻き込んで本当に必要なテストだけを精査する ◦ テストの意図を読み解き、自身でも説明できるテストだけが残るようにする ◦ Developer環境、Staging環境、それぞれに散っていたものをなるべくDeveloper環境に集約する ◦ 一部はコードベースのテストに移行する 信頼を取り戻す・3
29. © Alp, Inc. • ときには自己解決、ときには開発チームの改善に助けられながら、テストの失敗を大幅に低減 • 毎日数件の失敗したテストを確認する日々から、毎月数件の失敗したテストを確認する日々へ 結果
30. © Alp, Inc. © Alp, Inc. その後
31. © Alp, Inc. 自分が別のチームに軸足を移すことになり、改めてテストを開発チームに引き継ぐことになった 今度はメトリクスも見ているので、自信をもって引き渡しができた 基本的なメンテナンスは開発チームに移譲 アドバイスはさせてもらっているが、苦戦しながらも開発チーム中心に対応してくれている 後日談
32. © Alp, Inc.
33. © Alp, Inc. 信頼されるテストとは • 基本落ちない • 落ちるときは何かを検知したとき • あってよかった、見落としていた、という気付きを与えるもの 信頼を得るためには • 何度も繰り返し起きる失敗はちゃんと撲滅する ◦ 解決策を開発チームが知っていることも多いので、困ったときは相談する • 計測し、改善し、それを伝える • ときには、開発チームも巻き込みつつ既存のテストを見直すことも必要 まとめ
34. © Alp, Inc. © Alp, Inc. Thank you 🙇