QAエンジニアがバックエンドの自動テストに踏み込めるようになるために —— タレントマネジメントユニットでの学びと実務での活用

品質保証本部タレントマネジメントユニット（以下、タレマネユニット）のhigashiです！

本記事ではユニットで直近取り組んだバックエンドの自動テスト関連のスキル強化と活用の取り組みを紹介します。タレマネユニットが普段どんな取り組みをしているかの参考になれば幸いです。

取り組みの背景・取り組み開始前のメンバーのスキル感

タレマネユニットでは私たちの目指す姿にむけて「プロダクト特性や状況に合わせた本質的な価値を見極め、その価値を守り、より最大化できるよう最適な手法を考え実行していく」ことを推し進めています。*1
管掌範囲の中でも特に事業インパクトが大きいチームに対してQAエンジニアをアサインし、チームの品質課題の発見・解決に向けて様々な活動をしています。

現状、1チームに対して1人でアサインされるケースも多いため、各メンバーが一定水準のスキルを身につけていなければ役割を果たしきれません。*2そこで「この水準は全員が満たそう」という目標ラインを定め、そのスキル獲得に取り組むことをユニットのミッションとして掲げています。

その中でも今回は、ユニットとして特に注力した「バックエンドの自動テスト」スキルについて触れていきます。
まずはユニットとして獲得を目指す目標ラインと、取り組み開始前のメンバーのスキル感を紹介します。

目標ライン

バックエンドの自動テストに対し、実装されている内容が把握できる
バックエンドの自動テストで守るべき責務の範囲を把握している
既に記載されている内容の類似であれば、テストを追加することができる

メンバーのスキル状況

筆者
- 基本的な文法はなんとなく理解しているが、解読には時間がかかる。守るべき責務の範囲は自分の中に落とし込みきれていない。
Bさん
- 内容の把握ができ、テストの追加経験もある。単体テストや結合テストレベルの責務も理解している。
Cさん
- Rubyの基本に自信なし。Cursor主導でテスト内容の把握経験はあり。
Dさん
- 自分が担当のプロダクトであればできそう。

基礎編

スキル可視化の結果、バックエンドの自動テストに関してはメンバー間で経験差があり、かつ業務でも求められる機会が多いスキルだったため、注力して取り組むこととしました。

RSpec勉強会の開催

エンジニア経験がありRSpecにも知見のあるBさんにリードしてもらい、RSpec勉強会を全6回で開催しました。

会の流れは概ね以下の内容で行いました。
1. 各回のテーマ（model, requestなど）に沿って、レビューの流れと観点をインプットする
2. 宿題として、各自該当レイヤーのテストが書かれているPRを1つ選び、実際にレビューしてみる（気になりは付箋に残す）
3. 付箋に対してBさんがコメントを付ける
4. 次回冒頭で宿題を振り返り、学びを共有する

今回筆者は参加者として参加したのですが、個人的に以下の点が学びに大きく寄与したと感じています。

レビューの流れや見る観点が言語化されていたことで「何を見れば良いか」が明確になった
宿題で実際に手を動かしたうえでフィードバックをもらえることで、理解が定着しやすかった
他のメンバーの着眼点を知れることで、自分だけでは気づけない見方が学べた

第1弾RSpec勉強会は終了しましたが、第2弾も検討しており近々開催予定です！

スキルアップ支援への参加

品質保証本部内で「スキルアップ支援制度」というものが存在しており、その取り組みへ筆者とCさんが参加し始めました。
スキルアップ支援制度とは、品質保証本部で行っているタレマネ施策の一つです。社外の専門性を有する方をメンターとして招き、週1〜2回・各30分程度、1on1または1on2の形式で学習・相談の機会を設けています。

会で取り組む内容は現在も模索しながらですが、「既存のテストを読み解けるようになること」「テストの過不足に気づいたらプロダクトエンジニアにフィードバックできる状態になること」を目指しています。
直近は基礎をインプットするためにRSpec関連の記事やRailsのテスティングガイドを見ていったり、PRを持ち込んでモブレビューしたりしています。

TDDの実践やRailsにおけるテストの書き方を学習したことで、以前よりもなんのテストをしているのか、どうやって検証しているのか、モックをどう作っているのかを意識できるようになったと感じています。

実践編

ここまではインプット中心でしたが、これまでの取り組みの成果がここ最近になって見え始めてきたのでそれらの実例を紹介します！

横断フィーチャーの品質保証戦略検討

複数のタレマネプロダクトを横断して進行している基盤まわりの改修があり、そちらの品質保証戦略をユニットで検討しました。
基盤という特性上、画面上の挙動だけでは影響範囲を捉えにくくバックエンドの自動テストにも踏み込んだ品質保証活動が必要になります。加えて、データの不整合が起きうるという点でリスクも大きいテーマでした。

「みんなで考えよう！」と声を上げたのは筆者だったのですが、以前の自分なら「自分には難しそう」と尻込みしていたところを、今回はここまでのインプットを経て「たたきの作成くらいなら自分でもできるかもしれない」と思い、たたき台の作成を申し出ました。
複数プロダクト間での結合テストのレイヤーに踏み込んだテスト戦略を検討したのはほぼ初めてだったのですが、以前の自分よりも解像度高く向き合えていることがわかり、自信につながりました。

作成したたたき台をベースに、「どこを誰がどのように守るのか」や、「ここではこういうリスクがありそう」といった洗い出しをすることができました。ユニットで検討後は内容をまとめて開発チームに展開し、それを元に各プロダクトではどうなのかを考えるベースとして活用をしています。

PRモブレビュー

前段で検討した品質保証戦略を踏まえて、実際にPRのレビューをみんなでするという取り組みも行いました。

「このエラーに対するテストはいらないのか？ / 本当に必要なのか？」「境界値のテストは不要？」といった気になりを各自挙げつつユニットメンバーと議論を進めました。

これらの取り組みの結果、実際に開発チームへフィードバックして修正につながった事例も生まれました。
あるAPIのPRレビュー中に「仕様書ではレスポンスのトップレベルがオブジェクト形式なのに、実装では配列が直接返ってきている」というズレを発見した例がそのひとつです。
RSpec勉強会でレスポンスの構造を意識する習慣がなければ、見過ごしていたかもしれない点でした。