こんにちは。SEQ（Software Engineer in Quality）のharashinです。
記念すべきfreee QA Advent Calendar2023 1日目です。
前置き
私が、QA Advent Calendar2023の発起人です。
QAエンジニアだけで Advent Calendarをやると面白そうやん？という好奇心だけで企画しました。 いろんな人に「書きませんか？」とメンションする日々でパワハラで訴えられないか怯えながらも、なんとかスタートラインに立つことができました。
これから、25日までfreeeで働くQAエンジニアが様々な内容でアドベントカレンダーを更新します。
少しでもfreeeで働くQAエンジニアの様子が伝わったり、皆さまに役に立つ内容があれば嬉しいです！
QA Advent Calendarの発起人が何か書かないと始まらないので、私がファーストペンギンになります。
自己紹介
2021年6月にfreeeに入社しました。 入社してからはモバイルや会計でQAエンジニアとしてキャリアを積んで、今年の7月からSEQに異動しました。 働き始めてからずっとQAエンジニアをしていました。
ブログにインタビュー記事があるので良ければご覧ください。
また以前、freeeのテックカンファレンスであるfreee 技術の日にて「freeeのwebとモバイルでのテスト自動化の取り組み 」というタイトルで話していますので、こちらも良ければご覧ください。
QAエンジニアのキャリアパスについて
QAエンジニアのキャリアパスに関して様々なキャリアパスは想定されますが、まだ比較的新しい職種のためか実際の事例はまだ少ないように感じます。 私自身、QAエンジニアをやっていて「30年後、自分はどうやってご飯を食べているんだろう」と考えることがよくあります。 今回QAエンジニアをしていた私がたまたまSEQに異動したので、私の体験した事例についてお話しします。
freee におけるSEQ がやること
SEQと言われてもピンとこない人もいると思うので、SEQのやることを簡単に書いておこうと思います。
SEQがやることは主に
- 自動テスト基盤の構築・メンテナンス
- テスト環境の構築・メンテナンス
- 自動テストの普及・メンテナンス
基本的には自動テスト関連のタスクが多いですが、個人的には「品質保証のためなら、なんでもやる人たち」といった印象が強いです。
異動のきっかけ
元々自動テストに興味があり、 実際にスクラム開発の中でQAエンジニアとしてテストシナリオを書きながらテストをしていました。 その中でCI/CDにも興味が出てきて、もう少し基盤の知識を身につけてみたいと思っていたタイミングで、 SEQ内でメンバーの入れ替えがあり、SEQに異動することになりました。
なぜ自動テストに興味を持ったのか
プロダクトの規模が大きくなればなるほどリグレッションテストが増えていくので、テストプロセスがリリースのボトルネックになることがあります。
プロダクトを品質が高い状態で素早くリリースするために「自動テスト」という手段があることを知ったことがきっかけでした。 テストプロセスのボトルネックをマンパワーではなく、テックで解消する取り組みに興味を持ちました。
いまSEQとしてやっていること
これまでもこれからも自動テストの普及
プロダクトのドメインをよく知っている開発・QAエンジニアチームで自動テストを作成・運用していくことが最善であると考えています。 異なるプロダクトでも基本的にテストスクリプトは同じ書き方で作成できる自動テスト（E2Eテスト）の基盤があり、多くのプロダクトで自動テストの導入が可能な状況になっています。 しかしプロダクトの規模が大きかったりプロダクトの数が増えていたりまだまだ自動テストを活用できていないチームは多くあります。
SEQが自動テストのカスタマーサクセス的な役割を担ったり、より使いやすく基盤の構築をすることでプロダクトを品質よく最速でマジ価値を届けるためのサポートをしていきます。これまでもこれからも自動テストを普及していくために力を注いでいます。
APIテスト基盤の構築
現在freeeではE2Eテストが書く人が増えていき、シナリオも増えていき、実行時間も増えています。実行時間が増えるとリリースまでに時間がかかってしまいます。テストシナリオの最適化を行うことで実行数を減らすなどの取り組みはしていますが、それだけでは実行時間の増加に対するアプローチとしては不完全です。E2Eテストしかない状態だと本来E2Eテストで確認するべきではないような簡潔なテストシナリオも作成することになり、結果として実行時間が増加してしまいます。
そのためE2EテストだけではなくPrivate/Internal APIテストの自動化に取り組む必要があると考えています。E2Eテストでの確認を最小限にし、APIテストでも確認できるテストシナリオを移行することで実行時間の短縮に取り組もうとしています。
しかし、社内では一部のチームでAPIテストを実施しているチームがありますが、まだまだナレッジが溜まっておらず多くのプロダクトチームで実施できてないのが現状です。 私もこれまでAPIテストちゃんとやってこなかったので、現在すでにAPIテストの実施とその自動化に挑戦している権限管理基盤マイクロサービスのチームと一緒にAPIテストを実施しつつ、自動テスト基盤の構築・運用を担当しています。
今後社内の他サービスでも利用できるAPIテスト基盤を構築するために、現在は絶賛探索中です。
告知①：権限管理基盤マイクロサービスでのテストに関しては、freee QA Advent Calendar2023の後半に権限管理基盤のQAエンジニアのyukky-san の記事が出てくるのでお楽しみに！（12/21 10:00公開予定 ）
告知②：一緒に働いてる権限管理基盤チームのAdvent Calendarの記事もあるので是非お読みください！ * freee 権限管理基盤を開発するチームの今を語ろう！（12/2 9:00 公開予定） * freee 権限管理基盤を開発するチームのこれまでを語ろう！（12/5 9:00 公開予定）
QAエンジニアとの違い
私がfreeeで体験した違いは以下です。
- QAエンジニアは各プロダクトのロードマップに基づく機能開発のテスト計画・設計・実行を実施。
- SEQは自動テスト基盤という自社プロダクトをユーザ（開発者・QAエンジニア）に向けて提供している
- ユーザにとって何が必要なのか考えてロードマップを作成していく、プロダクトマネージャーの役割
- プロダクトとして自動テスト基盤を構築・運用していく、エンジニアの役割
- 自動テスト基盤をプロダクトチームで利用できるようにサポートする、カスタマーサクセスの役割
自動テスト基盤が自社プロダクトとして捉えると、SEQにはプロダクト開発のほとんどの工程とその立ち上げ支援など多くの役割を一つのチームで担っています。
SEQに異動して苦労したこと
求められる知識・技術の違い
やはり求められる知識・技術がQAエンジニアとは異なることは苦労したことの一つであります。 QAエンジニアは特定のプロダクトにアサインされていたので、担当するプロダクトと関連するプロダクトの仕様や動作確認などはしていました。 しかしSEQになるとプロダクト共通の自動テスト基盤を構築しているので横断的にほぼすべてのプロダクトを担当することになります。 今まで触ったことのないプロダクトを担当することもあり、システムアーキテクチャやプロダクトのドメインのキャッチアップに苦労することもありました。 たまたま私の異動とテスト環境の移行のタイミングが重なり、テスト環境の構築を通して手順書を作成していくことを通して実際にプロダクトのコードを読んだり、ドキュメントを読み漁りながらキャッチアップを行いました。
プロダクト開発の難しさ
自社プロダクトとしての自動テスト基盤は、SaaSと同じだと思っています。自動テスト基盤のユーザは開発者・QAエンジニアです。ユーザが自動テストに価値を感じなければ継続的に利用してもらえません。不安定な自動テストは利用されなくなるので継続的に利用して価値を生み出すために、安定した自動テストとその自動テスト基盤を提供する必要があります。またユーザに自動テストを使いこなして価値を感じてもらうために、シナリオの安定化などはユーザ自身で行えるようにしていかないといけません。
ユーザにとっての価値とは？そのために今後どのように開発を進めてのかというのを自分たちで決めていかないといけないのはとても流動的で、これまで上流工程でプロダクト開発をしてこなかった私にはとても新鮮で難しいところでした。（今もこれからも難しいと思います。）
どうすればfreee会計などのサービスプロダクトに良い価値・インパクトは与えられるのか・誰のどのようなペインを解消するための施策を実施するのかを短期的・中長期的に考えていかないといけないのは、私がプロダクトチームでQAエンジニアをしている時はあまり考えていなかった観点でした。 そういった方針や思いをメンバーと共有するというのも、これまで経験していなかった要素でとても苦労しています。
QAエンジニアがSEQを経験することのメリット
QAエンジニアよりも基盤や自動テストに触れる機会が多いので、そういった知識を得られることは個人的にはメリットでした。 SEQは自動テストに関する業務が多いのでテストに関する知識やユースケースを把握している方が、よりプロダクトチームに寄り添ったアプローチができるのでQAエンジニアからSEQに異動した時に強みを活かせるポイントになります。 自動テストは手段なので、自動テストに関して知っていることで普段の手動テストで「このテストは自動テストにできる」「こうすれば自動テストがやりやすくなる」など自動テストの観点・アプローチが普段のQAエンジニアの業務に活かせると思っています。
SEQは必要なチームなのか
現状freeeでは組織のミッションを達成するために、自動テストを専門とするチームが必要なのではないかという仮説をもとに検証している段階だと思っています。なので、その仮説検証の結果により将来的には個別のチームは必要なく開発・QAエンジニアにマージされる可能性もあると個人的には思っています。
ただfreeeは統合型クラウドERPなので多くのサービスの連携が必要となり、それぞれのチームで独自に自動テスト基盤を構築してしまうとサービス間のつながりがうまく確認できていなかったり、また重複したテストが発生したり様々な問題が発生する可能性があるので、現時点ではSEQの役割をそれぞれのプロダクトチームが持つのではなく、一つのチームが担当した方が良いのではないかと思っています。
これからの私のキャリアについて
いつか、QAエンジニアに戻ります。
私は冒頭でのインタビュー記事の中で「SaaS QAエンジニアのロールモデルになる。」と目標を掲げていました。その目標に対して、SaaSのQAエンジニアには自動テストに関する知識やスキルが必須だという1つの仮説を立てた上で、その仮説を検証するためにSEQを経験しています段階です。
freeeではSEQが自動テスト基盤を構築するという役割を担当していますが、「 役割分担しているから知らなくてもいい」ではなく、理解している上で、より自分が得意な領域で勝負する状態にしておくことが大事なのかなと思っています。 なので今回私は、自動テストに関する役割の多くを担っているSEQに異動することで役割を理解し、理解した状態でSaaSのQAエンジニアのロールモデルの1人になれるように今度は自動テストという手段を使って、プロダクトを品質よく最速でマジ価値を届けることに挑戦したいと思っています。
最後まで読んでいただきありがとうございました！
明日は、freee販売のQAエンジニアのtomi-san が「freeeのQAオンボーディング」について記事を書いてくれます。 JaSST'23 Niigata で話したfreeeのQAオンボーディングがtomi-san 視点で書かれています！お楽しみに〜！
