前置き
2024/06/08にAutifyのオフラインコミュニティイベントが有り、
Autifyのユーザーである弊社、オシロ株式会社としてリードエンジニアである私が、LTさせていただきました。
その時の発表内容からサービス紹介以外の部分をテキストでまとめ、もうちょっと話しておきたかったところだったりを補足した記事になります。
LTで使用した資料は下記になるのでこちらも合わせてご覧ください。
また品質管理において、セオリーを外している運用方法だったりもありますが、弊社なりのやり方なので、生暖かい目で見ていただけると幸いです。
本編
具体的にAutify活用についてまずはどんな課題が弊プロダクトにはあったかを説明していきます。
プロダクトの機能が豊富
課題というか、なんというかという感じですが、
オンラインコミュニティはいろいろな機能が必要です。「プロダクトの思想」として「コミュニティに必要な機能をオールインワンで揃える」というものがあり、なかなか機能そのものを減らすということが難しいプロダクトであると理解しています。
コミュニティを運営するオーナーやコミュニティのエンドユーザーが発信する、コンテンツ・ブログ機能。
コミュニティのユーザー同士がやり取りするチャット機能、
さらにはオンライン・オフライン問わずイベントが活発に行われるコミュニティも多いので、イベント機能もあり、
イベントではいわゆるチケット管理もでき、オフラインイベントで費用を頂いて行なうようなイベントもOSIRO上で決済が行えたり、
カジュアルにコミュニティのグッズや関連商品を販売できる簡単なECの機能も提供しています。
リグレッションテスト
こんな豊富な機能の開発運用を当時は6名のエンジニアで開発しているというような状況でした。
シリーズAのスタートアップ企業ということもあって、QA専任のメンバーもいない状態です。
「じゃあリグレッションテストどうしていたの？？」という意見もあるかと思いますが、
当時の答えとしては「そもそもそんな言葉は知らない。やっていなかった」が答えです。
当然、リリース前に修正箇所や不具合の修正についてはやっていましたが、テスト手順書が無い中でエンジニアではないメンバーに手伝ってやってもらっていました。
テストの品質にばらつきがあり、修正が原因で発生した不具合に気づけずリリースしてしまったことが度々有ました。
Ruby on RailsでのE2Eのテストについては登録、決済周りなどが重要だったのは理解していたため、そのあたりのテストについては書いていました。
E2Eテストのメンテコストが高い
リグレッションテストができるくらいまでe2eテストを充実されば…と思うところですが、そう簡単でもないですよね。
Feature Specは時折よくわからない理由で失敗してしまったり、テストの内容にXPathだったり、HTML IDに依存するようなテストが多く、読みづらいということもあって、メンテコストがとにかく高かったです。
これらが理由で、短期間でFeature Specをリグレッションテストとして活用するまでのテスト量にするには時間がかかると判断しました。
リリースサイクルについて
Autifyでリグレッションテストを開始していくまでの経緯などを説明するにあたって、
次に弊社のリリースまでのサイクルについて紹介しておきます。
金曜日：翌週でリリースする予定のタスクなどのチェックを行う。
月曜日：Staging環境でコードフリーズ
火曜日：CSメンバーにリリース内容の展開・Stagingでのテスト開始
水曜日：Stagingでのテスト
木曜日：問題がなければリリース
金曜日にアサインに関わるMTGをしているため、金曜日が起点になっています。
ここでのテストはリグレッションではなくて、改善・修正した箇所にフォーカスを当てたテストです。
テストも他業種のメンバーが片手間にやってもらうという構図でしたので、定型的なリグレッションテストは少しお願いしづらいような感じでした。
Autify導入前の課題まとめ
- 機能が多いプロダクトを、少ないエンジニアで開発をしている。
- テストの手順書がなく、もれなくテストされるわけではないため、デグレが防げないことが度々。
- Railsでのe2eテストは実装・運用コストが高かった。
- メンバーの負荷を増やさずに品質を担保しながらも、リリースサイクルは守りたい
というのが導入前の課題でした。
特にE2Eテストのメンテコストや安定性、リグレッションテストについてはAutifyである程度解決できるのではないか？と思い、トライアルを経て本運用に移っていきました。
どのように導入していったか？
そんな中でAutifyを導入してこれら課題解決を進めていこうとなったので、
実際にどのように導入からリグレッションテストをある程度行えるようなったか？までを紹介していきます。
追加するシナリオの優先度を設定する
まずは追加していくシナリオの整理をして、優先度を設定して優先度を高いものから追加していくようにしました。
スライドにあるように、不具合が発生したときの重要度、複雑な機能は優先的に、すでにe2eテストが有るような機能は逆に優先度下げたりするような形でスコアリングを行って、優先度に沿ってメンバーに追加してもらっていきました。
この他には、不具合が発生したときに発生したケースをリグレッションテストとして登録するようにしたりしていきました。
Autify運用ルール
ある程度Autifyを運用していくためのルールを追加したりしました。
厳密に守らないと、というものよりは比較的ゆるいルールから始めていきましたが、
Autifyの追加自体は簡単なので、あまりむずかしい説明がいらなかったのですが、E2Eテストにおける勘所などについて記載したりしています。
どっちかというとルールとは書いてあるのですが、ガイドラインとかに近いかなって感じです。
改善後のリリースサイクルについて
金曜日：翌週でリリースする予定のタスクなどのチェックを行う。
月曜日：Staging環境でコードフリーズ
月曜日深夜：Autifyでのリグレッションテスト（コードフリーズ後
火曜日：CSメンバーにリリース内容の展開・Stagingでのテスト開始
水曜日：Stagingでのテスト
水曜日深夜：Autifyでのリグレッションテスト（リリース前
木曜日：問題がなければリリース
月曜日の深夜コードフリーズを行ったあとと、その後のコードの修正が行われ、
リリースする直前の水曜日の深夜にAutifyでのリグレッションテストを行うようにしました。
リグレッションテストの歴史
そんなこんなでAutifyを使ってリグレッションテストを開始していきました。
2022年の3月からAutifyの利用を本格的に開始していきました。ここではエンジニアメンバー全員に担当を割り振って追加していきました。
5月にはシナリオが24ケースに、半年後の11月には56ケースに育っていて、現在では68ケース程度に育っていきました。
このあたりの具体的な数値が多いのかはあまり私ではわからないのですが、このようにしてリリース前のリグレッションテストを運用しています。
今のところ、エンジニアがAutifyをメンテしているということもあって、機能の大幅なアップデートが理由で完全にメンテナンスできなくなったり、壊れたりということは無いという感じです。
よくなったこと
- E2Eテストの安定性が上がり、安定的にテストができるようなった。
- E2Eテストの追加ハードルがかなり下がり、ジュニアエンジニアでも簡単に追加できるようになった。
- 数時間、FeatureSpecの実装にかかっていたのが、動作チェック含めて15,30分くらいに
- リリース前にリグレッションテストを行えるようになりました。
- いくつかシナリオを作ったことをきっかけに不具合を見つけて対応できた
今後の展望・課題
今後Autifyをこんな活用ができるといいかなというところです。
テストプラン及びシナリオの整理
ある程度基本的な仕組みだったり、flakyなテストは有るにはあるものの、継続的にAutify自体は使えていることは良いことであると思っています。
しかし、ユニットテストで十分だったことをシナリオの作成自体はとても簡単なので、Autifyで実行してしまったり、
すこしメンテナンスが行き届かなくなっているテストがあったり、もうテストとして不要になりそうなものだったりがあります。
そういったシナリオであったりは継続的に整理やメンテナンスが必要だと考えています。
というような感じ本編は完了した感じです。
Autify自体は品質向上においても欠かせないツールになっている感じでした！
質問や補足など
あとはもらった質問や、これ喋ってなかったな…というようなのもあったので、それらについて書いています。
RSpec（Feature, SystemSpec）との使い分け
どのように考えているかを同じようにRailsを採用している企業の方から質問を受けました。
弊社では検討中だが、原則Autifyが品質の最終砦であって、リグレッションテストに類するものはすべてAutifyで良いと思いますし、弊社でも重複する観点のテストは削除すればいいかなと思います。
しかし、どうしてもAutifyだと実費的なコストが掛かったりというテストや網羅的にしておきたいこともあるはずなので、そこにFeature Specは利用するものかなと考えています。
Autify運用ルールの内容
具体的な運用ルールについての質問も受けました。ざっとこんなことが書かれています。
- どんなときにシナリオを作成するべきか？
- ステップ作成中に気にするべきこと
- シナリオが完成したらやること
- シナリオレビューなど
- シナリオ修正ルール
テスト手順書について
LTでは触れませんでしたが、テスト手順書については最初に作ったのか？
という質問をLT終わってから受けましたが、手順書は別に作ってないんですよね。
というのも、Autifyみればテスト手順分かるのではないか？というのが始まりで、
テスト手順書を作るよりもまずテスト作っちゃったほうが早いし、あとから手順書を作ればいいやの考えで始めたんですよね。あまりお行儀も良くないでしょうし、本職QAの方からお叱りをいただくようなやり方かも知れないですね…
しかしまぁ素早くリグレッションテストをぼちぼちの品質でいいから上げていくというようなポリシーなら、
このように割り切ってやってしまうのが一番早い方法かなと思いました。
メンテナーがWebエンジニアなので、テストの品質どーなの？
手順書がない中で、網羅的にテストが出来ているか？ということを言われるとコストの問題や、
やはり本職QAではないWebエンジニアがテストをメンテナンスしていることもあってまぁそこそこかなと言う感じですね。明らかな漏れだったり最低限のレビューだったりはするようにしてます。
絶対にやらないよりはいいし、ある程度品質確保できているのですが、もっと向上させようとなると、エンジニアがQA力を向上させるか、QAの方のお力添えが必要だと考えています。
ぶっちゃけCypressやPlaywrightは検討しなかったの？
CypressはともかくPlaywrightはリリースされて間もないとか、あんまり日の目を見てなかったのかな？というように思いました。
CypressであってもAutifyより学習コストは高いのと、結局コードでテストを管理しないといけないことは変わりないし、e2eの実行に対してのトラブルシューティングだったり、実行基盤は結局自分たちで作らないとことに変わりはないので、あまり検討しませんでした。とにかくe2eテストを本格的に行うためのハードルをとにかく下げたかったので、OSSツールを使うのは選定時点ではないかなーという感じでした。
さいごに
そんな感じで弊社ではAutifyがWebエンジニアがテストを作ったりみたいなことだったりをしています。
Autifyを色々使ってみたい、この記事を見て色々出来そうだ！！と思った方はカジュアル面談からでも結構ですので一度私とお話できればと思っています。よろしくお願いします！
Discussion