はじめに
HRBrainでQAエンジニアをしております。
今回は、QAチームの中長期的な構想について、お伝えできればと思います。
なお、本記事の内容は、現時点で思い描く「未来のイメージ」に過ぎません。
開発組織全体の変化にフィットするよう、随時、軌道修正していく所存であり、未来構想をお約束するものではありません。
QAチームの現状が気になる方は、@hh_hrb さんの以下の記事をご覧ください🙏
開発組織の加速に、QA組織も追いついていく
ChatGPTをはじめとする生成AIにより、AIコーディングが当たり前となりました。
実装作業はもちろんのこと、自動レビュー、単体テストの自動化など、エンジニアの実装速度は格段に加速すると思われます。
HRBrainも、事業計画の一つとしてAIを開発工程に活用する動きがあり、例外ではないでしょう。
また、HRBrainのプロダクト数は増え続けており、サービスの利用者数も伸び続けております。
開発中プロダクトも考慮すると、現在いくつのプロダクトが動いているのか、もはや明確に答えるのが難しいです。
会社のこうした喜ばしい変化は、QAの担うべき仕事が肥大化することも示唆します。
その理由はたくさんありますが、パっと思いつくものだけでも、
- 仕様拡張の度に複雑性が増して難解となり、テストの難易度が上がる
- 回帰テスト工数が増える
- 利用者が増えれば、より網羅的なテストが必要になり、品質基準も厳しくなる
- プロダクト間のデータ連携が密になれば、双方の「間」という新たな検証範囲が生まれる
などが挙げられるでしょう。
多少の語弊を許すならば、プロダクト数の増加よりも、必要なQAリソースの増加速度のほうが高いと言えるかもしれません。
このような目まぐるしい変化に、QA組織も追いついてく必要があります。
でなければ、QAプロセスがプロダクトリリースのボトルネックになってしまいます。
QAサイクルの最適化
HRBrainのQAエンジニアは各々様々な強い想いを持って入社されるため、「QAとして何をしたいか」と問えば、十人十色の答えが返ってくると思います。
しかし、QAプロセス、引いては開発プロセスの「最適化」を目指す姿勢は、最大公約数として見出せる気がしています。
【最適化①】テスト自動化の拡充で回帰テスト工数を削減
所要QAリソースが増加する状況を止めることは不可能だと思う反面、緩和は可能だと考えています。
その手段の一つで注力しているのが、回帰テスト領域の自動化です。
昨年度までは、Stg環境に対してリリース前の最終チェック、すなわちブランチをマージした後に致命的な不整合が生じていないことを確認するために、自動テストを回していました。
これを、Dev環境に対して回せるように整備することで、今までQAエンジニアが手動で行っていたテストの一部を、自動テストに置換しようとしています。
1. QA依頼が来る
2. 自動テストでカバーできる領域と手動テストすべき領域を区別する
3. QAエンジニアは手動テスト必須のケースだけ実施
なお、自動テストシナリオがDev環境とStg環境で別管理されていると、メンテナンス性が低下します。
そのため、両環境で同一のテストシナリオを共通利用できるよう、整備も進めています。
【最適化②】テスト観点を標準化し、テスト品質を保証する
回帰テストの自動化によって所要QAリソースの増加を緩和することはできても、依然としてQAエンジニアを増やしていく必要性は残ります。
現状、HRBrainのQAは個々の知識や経験への依存度が高く、どうしてもテスト観点の広さと深さにバラツキが生じやすい状態です。
QAエンジニアが増えれば、このバラツキはより顕著なものになるでしょう。
こうした課題に対応するため、「こういうときは、大体こういったテストが必要になるよね！」が分かる「標準観点カタログ」の作成を進めています。
この「カタログ」をテスト設計時の共通文書として活用し、テスト品質を均一化することを目指しています。
また、エンジニアへの観点共有にも活用できれば理想的です。
設計・実装段階で、QA観点をエンジニアに事前共有することは、バグの作り込みの抑止に効果的と言われます。
しかし、QAリソースは常態的に不足しがちな状況であり、1つ1つの実装に対して、テスト観点をテキストに起こして共有することはなかなか難しいのが実情です。
そこで、QAエンジニアからエンジニアに、「こういうバグが作り込まれやすそうだから気をつけて」と伝達する共通文書としても、標準観点カタログを活用することを考えています。
1. 仕様や設計をQAが確認する
2. バグが作り込まれやすいポイント、テスト観点を考える
3. 標準観点カタログのIDやURLを共有する
「IDやURLを共有するだけ」という形にすることで、QAエンジニア側の負荷を極力増やさない仕組みにできればハッピーです。
また、標準観点カタログは、一度作っただけで満足したら非常にもったいないです。
QAエンジニアが横串で観点を蓄積していくことはもちろんのこと、プロダクトチーム側でも、プロダクト固有の観点を自発的・継続的に蓄積していける仕組みも必要です。
【最適化③】仕様書インスペクションによるバグの作り込みの抑止
系統的なテストケースを組むには、仕様を正確に理解し、パターンを洗い出す必要があります。
QAが日常的に行っているこの「整理」という作業は、エンジニアによる設計段階にも役立つと考えています。
前項で述べた、「エンジニアへの観点事前共有」を実現するには、早期からQAが仕様書・設計書をキャッチアップすることが前提となります。
今まで下流工程（ケース作成）で行っていた「仕様整理」というアクションを上流にシフトし、エンジニアにフィードバックしたり、QA自身が仕様書に加筆できれば、ドキュメントはより精緻化され、バグの作り込みを抑止できるかもしれません。
これを「仕様書インスペクション」と呼んでいます。
仕様書インスペクションは、テスト設計と同様に実施者によりバラツキが出やすい領域と予想されます。
そのため、ここでも標準観点カタログを活用し、インスペクション品質を均一化できると理想です。
【最適化④】AIを活用したQAスコープの精度向上
上流・下流工程の最適化を目指しつつ、テストスコープもより高精度に狭められれば、さらにQAリソースは削減できます。
現状、QAエンジニアはテストスコープを以下のように定めています。
1. 新規実装範囲、改修範囲をテストスコープに含める
2. さらに、その周辺機能も（なんとなく心配だから）含める
3. 類似した処理、UI画面があれば、（なんとなく心配だから）含める
4. その他、心配なところも一応
実のところ、②～④は、本人の勘や経験則に頼っている部分が大きいです。
このような範囲から不具合が検出されることもありますが、いわゆる「オーバヘッド」が大きいのも現状です。
この「オーバーヘッド」を低減する、すなわちテストスコープを高精度に狭める一案として、生成AIの利用が候補として上がっています。
Pull Requestとmainブランチのコード差分をベースとして、その関数の呼び出し元や後続処理をAIに追尾解析してもらい、影響範囲(テストスコープ)をサジェストしてもらえないか、などと考えています。
最適化されたQAサイクルとして目指す全体像
QA観点を上流工程に活用し、バグの作り込みや混入を予防できれば、テスト工程での不正挙動調査やチケット起票が減り、トータルのQA工数は削減されるでしょう。
また、自動テスト領域を拡大しつつ、テストスコープの理論的な絞り込みが実現すれば、手動テストの工数がダイレクトに減ります。
このように、上流工程から下流工程まで、満遍なく最適化していくことを目指しています。
QA組織の最適化
QAエンジニアは、各々様々な施策を推進していますが、その進捗は残念ながら芳しいとは言えません。
定常的に発生するプロダクトQAに追われているため、時間・体力的・認知資源的に改善施策にまでリソースを回せないためです。
この状況は昨年度から継続しており、プロダクト数が増加していくことを考慮すると、今後も続いていくと推察されます。
これを打破するには、プロダクトQAを遂行する役割と、改善施策の推進を担う役割を分離する必要があるかもしれません。
QA Strategy Enablement(仮称)
HRBrainのQAエンジニアは、各々1つ以上のプロダクトを担当しています。
（詳しくは以下を御覧ください。）
将来的には、プロダクトQAをゴリゴリ回す人物と、QA最適化プロセスの適用を担う人物を分ける未来が来るかもしれません。
このQA Strategy Enablementと仮称するチームは、各プロダクトチームで自律的にQA最適化プロセスが駆動するよう支援したり、よりチームにフィットする仕組みを構築する役割を担います。
QA Strategy Enablement：
プロダクトQAと伴走し、QAプロセスの最適化を支援する。
- 各プロダクトの仕様を理解・整理
- テスト自動化領域の定義、自動テストシナリオ設計・実装
- 定常的なテスト業務に、自動テストを有効活用する仕組みの構築
- プロダクト固有の標準観点カタログの強化
- 開発プロセスへの仕様書インスペクション工程のインストール
名称はさておき、プロダクトQAが定常業務に追われて進められない最適化施策を、強力にサポートしていく部隊を作れたら理想的かなと思います。
おわりに
今回は、ブログという形でQAチームの目指す方向性を紹介させていただきました。
冒頭で述べた通り、「未来のイメージ」に過ぎず、将来の姿としてお約束することはできません。
しかし、こうした施策へ共感してくださったり、ご興味を持っていただけましたら、ぜひ選考にご応募いただけますと幸いです。