こんにちは。決済プロダクトでQAエンジニアをしているtonchanです。
freee QA Advent Calendar 2024 - Adventarの10日目です。
はじめに
私はfreee初の新卒QAエンジニアの１人として入社しました。7月に決済プロダクトにアサインされ、2024/12/10 時点で5ヶ月目の新米QAです。
今回の記事ではfreee新卒QAの一部業務をお伝えできればと思います。 QAエンジニアの仕事とか実際何するんだろうと想像しづらい面もあると思いますので、就活中の方にもぜひ参考の１つにしていただけると幸いです。
なぜ最初のキャリアとしてQAを選んだのか
新卒でいきなりQAエンジニアを第一志望で目指す方と言うのはあまり多くないのかなぁと思います。
当時（2022年頃）の就活を思い返してみると、QAエンジニア枠として、新卒を募集している会社はあまり多くなかったと記憶しています。学生に向けた露出も少ないですし、またQAエンジニアという役職自体を知らない人が大多数を占めていました。
就活の軸としては、自分に合っていて裁量の大きい仕事をやりたいなぁという思いが一番でした。
色々調べていく中で、たまたま参加したfreeeのQAの方も交えたQAトークセッションが契機になりました。その話の中で、ブルーオーシャンいいな、SaaSいいな、ユーザー目線で考えるのいいな、と単純に思いまして、そこからはQAエンジニア第一志望で就活しました。
またQAサマーインターンシップ*1にも参加させていただき、QAの業務や考え方が自分に合ってるかもなというのも大きかったです！
結果、ありがたいことにQAエンジニアとしてfreeeに入社できました。
freeeのQAプロセスについて
決済プロダクトにアサインが決定してからはメンターの方に業務を教えていただきながら同じチームで行なっているQAプロセスを経験していきました。
これからお話しする中で出てくるQAプロセスはあくまで私の所属するチームでのプロセスになります。freeeのQA組織全体で同じわけではありません。*2
私の所属するチームでのプロセスは大まかに以下になります。
- 開発情報キャッチアップ
- 開発内容理解／仕様把握
- リスク洗い出し
- テスト計画
- テスト分析
- 受入基準
- テスト設計
- テストチャーター
- テスト実装（テスト実行準備）
- テスト実行
またfreeeのQAでは、「起こしちゃいけない不具合が起きにくい体質にすることで“マジ価値”*3を継続的に届け続ける」をミッションに掲げ、当たり前品質の高速フィードバックを実現することでお客様に“マジ価値”を提供できるように取り組んでいます。 チームではこれを実現すべく、アジャイルQA・バックエンドQA*4を実践しています。
なぜひとりでプロダクトを担当したのか
freeeではQAのスキルアセスメントシートがあり、そこに書かれているジュニアQAエンジニア相当のスキルと自身のスキル（アサインされて3ヶ月目）とを比較して必要なスキルとそのために達成すべき経験は、「プロジェクトの主担当となってQAプロセスを一通りこなすこと」でした。たまたま開発計画の中で新プロジェクト（開発工数見積：３週間程度）があったため、そのプロジェクトに自らを主担当としてアサインしてほしいと相談をしてアサインが決定しました。 以下には主に苦戦した部分や学びになった部分を切り出してお話しさせていただきます。
開発情報・仕様のキャッチアップ
チームでは要求仕様書、要件仕様書、UI仕様が作成されるとPdM, Eng, QA, PDで読み合わせ会を実施し、そこで認識合わせや疑問、検討もれがないかを行なっています。つまりここまでにはある程度のプロジェクトに対する知識を保有しておけば、この段階で欠陥を指摘することができシフトレフトの実現が可能になります。
ここで学んだ大切なことは要求仕様->要件仕様の順番で理解することです。
例えば、要求仕様の理解度が70%の状態で要件仕様を読み込んでレビューをしようとしても、要件仕様の欠陥に気づく可能性は30%分小さくなるからです。 当たり前のことかもしれませんが、実際に経験して初めて理解できた気がしました。
そのための要求仕様キャッチアップは必然ですが、仕様を読み込みその中で考慮漏れ等を指摘することは新米の自分には難しいです。 今回のプロジェクトは既存プロダクトに対する新機能開発であり、前提として既存プロダクトの知識がないと既存実装と結合する部分等で起こりうる動作の予想ができませんし、抜け漏れがあっても気づくことができません。
ただ偉大な先人の方々が残してくださったデータモデリング・テーブル構造・状態遷移図等の資料によりなんとか、既存プロダクトを理解することができました。
いまだに仕様のレビューは難しい、、、
リスク洗い出し
事前にリスクを洗い出すためにfreeeではリスク洗い出し会*5と銘打って、ステークホルダー（セールス、サポート、マーケティング、PM、Engなど）を集めてリスクを洗い出すための会議をします。この会議でのQAの主な役割は、事前にリスクになりそう・不安な部分のリストアップ、会議の開催、ファシリテーターになります。
初めてこの会議で機能の概要を知るステークホルダーもいるため、簡単に新機能の概要を説明しながら皆さんにリスクをリストアップしていただいてます。
なぜ上記のようなやり方になったかというと、私が初めてリスク洗い出し会のファシリをした時に担当EngとQA以外の方々から意見をもらうことができず、議論がうまく発散しなかったことからの反省です、、、
このタイミングで私の方から、開発する新機能が悪用されないかと議論したところ要求から検討し直すことになりました。理想を言えば上記の仕様書読み合わせの段階でできていればよりシフトレフトですが本格的に実装が始まる前で良かったなと思ってます。
また今回のプロジェクトで発生する可能性のある重篤度*6の決定をし、低リスクであるという認識合わせを行いました。ここで意思決定したおかげで、高品質とスピードを両立しながらQAや開発を安心して進められたと思っています。
テスト分析・設計
テスト分析・設計は、仕様変更や開発が進むごとに見直していたので、並行してやっていました。
テスト分析
テームではユーザーストーリー単位でのテスト分析と、ユーザーストーリーの受け入れ基準をQAが書いています。そこでは「正常系（ポジティブシナリオ）」「準正常系（ネガティブシナリオ）」「非機能系」といった観点からストーリーの成果物への期待値と、unit test, integration test, E2Eを書くかどうかを記入して「受け入れ基準sync会」を実施して完了となります。
前回のプロジェクトでの反省点として受け入れ基準で明確に決まっていない細かい要件部分にまで言及してしまいEngの方を困惑させてしまいました。なので受け入れ基準とは何かを理解できていないと思い、JSTQBシラバスで確認してみると、
受け入れ基準は、以下のように使う：
ユーザーストーリーのスコープの定義
ステークホルダー間の合意形成
ポジティブシナリオとネガティブシナリオの両方に対する説明
...
と書かれていました。
ユーザーストーリーのスコープの定義やステークホルダー間の合意形成に使える状態ではなかったということですね。
失敗した要因は受け入れ基準の理解不足だけでなく、要求・要件仕様の理解不足もあると考えています。なぜなら仕様を理解していれば、「明確に決まっていない細かい要件部分」を記入する前にステークホルダーに質問することで解決できたと考えられるからです。
繰り返しになりますが、やはり仕様に詳しくなることはとても大事であると再認識するいい経験だったと思います。
ということで上記を念頭におきつつ、テスト分析の段階で出た疑問をPdMやEngの方と密なコミュニケーションを行い、ユーザーストーリーも見直したりしながら受け入れ基準を作成しました。 無事に受け入れ基準は完成し、受け入れ基準sync会ではどの機能・シナリオでunit test, integration test, E2Eを書くのかの認識合わせも問題なく終えることができました。
テスト設計・実装
freeeでは経験ベーステストの一つである探索的テストを行うので、テスト設計で作成するのは主にテストチャーターになります。テストチャーターとはテストの方向性を示すものでチェックリストではありません。
ただAPIテストでは非機能テストも行い、抜け漏れなくチェックしたいためデシジョンテーブルを作成しました。新規のAPIが開発された場合にはデシジョンテーブルを新たに作成しています。
新機能のテストを実施しようと思ったところ、今まで蓄積してきたテストデータではできず、また手動で作成するのはかなり時間がかかるとわかったため、大量のテストデータを素早く作成する必要がありました。
freeeではEngと同じ開発環境をQAも使用できるようになっているので、そこでスクリプトを作成して大量のテストデータを作成しました。
ただ、テストデータを何度も作成して試すようなことは、時間がかかるため事前にPdMの方と相談してどのようなテストデータがあればいいのかを聞き、ローカル環境で練習して問題ないことを確認してからintegration環境で実施しました。
その結果、性能・信頼性テストも簡単に実施できるような状態でテスト実行に臨むことができました。
テスト分析でどのようなデータを作成・使用するのか理解していたおかげで、テスト実行可能な状態を待たなくてもテスト実装を行うことができると学ぶことができましたし、テスト実行での工数を削減することにも繋がるなぁと実感しました。
テスト実行
前述のバックエンドQAをチームでは実践して行っています。なのでそれに則るべくテスト実行単位はPR単位でテスト実行を実施していきました。
PR単位でテスト実行していく中で、私の認識や理解が間違っていないかの確認もEngと頻繁にやり取りを行ってました。
今回のプロジェクトではAPIを新規作成するのでEngと相談して、APIを優先して開発してもらい早期にテスト実行を行いました。その結果、新規作成したAPIは早い段階から信頼性があるという前提で他のテストに臨むことができました。
ひとりでやってみた感想
このプロジェクトを通じて得たことは、一言で言うと「仕様の静的テストが後のプロセス全てに影響してくる」と言うことです。
シフトレフトの観点でも早期にテストを実施して早い段階で修正することは重要である、ことはQAの方であれば常識だと思いますし、私も本などで知ってはいたのですが、こんなにも全てのプロセスで影響するんだぁと初めて実感して重要であると再認識できました。
また今回のプロジェクトとは違い、バグチケットの分析をやっていたのですが、そこでもバグの原因はなんだったのかを正しく分析するためには、実装漏れ、要件漏れ、要求漏れ、etc、の何に当たるかを判断する際にも重要だなあと気づきました。
ここまで読んでくださってありがとうございます。
明日は、SEQ(Software Engineering in Quality)のエンジニアのnakamu-san が「ページオブジェクトモデルを採用しているE2Eテスト基盤の実装Tips」について記事を書いてくれます。お楽しみに〜！
よい品質を〜
*1:https://developers.freee.co.jp/entry/2023/02/27/100000
*2:freeeではQA組織全体で標準プロセスガイドラインがあります。しかしあくまでガイドラインなので具体的なプロセスに関しては各チームで作成されています。
*3:マジ価値：ユーザーにとって本質的に価値があると自信を持って言えること
*4:バックエンドに焦点を当てたテスト活動のことhttps://developers.freee.co.jp/entry/freee-qa-advent-calendar-day11
*5:freeeの品質トゥギャザー：リスク洗い出し編 https://developers.freee.co.jp/entry/risk-together
*6:https://developers.freee.co.jp/entry/freee-qa-advent-calendar2024-day8
