はじめに
株式会社HRBrainでQAエンジニアをしております。
本記事は、アドベントカレンダー 7日目の記事です。
対象読者
- QAエンジニア
- テストエンジニア
- テスト工数の増大を感じている方
QA工数は加速度的に増加し続ける
新機能ケースは次回の回帰テストのケースとなる
プロダクトが成長すればするほど、QA工数は増えます。
加速度的に増加するように感じているQAエンジニアは、決して少なくないと思います。
テストケースを組むとき、以下のように大別して組むのではないでしょうか。
- 新機能に関するテスト（＝新機能テスト）
- 旧機能に関するテスト（＝回帰テスト）
新機能は次回リリース時には旧機能となっているため、回帰テストのケースに組み込まれます。
次回の新機能テストのケースも、さらにその次の回帰テストとして積まれていきます。
「回帰テスト」とは、過去に実施したテストケースの累積であり、リリースを重ねるごとにボリュームは肥大化していきます。
肥大化したQA工数にどう向き合うか
肥大化する回帰テスト工数に対して、QAエンジニアが最初にとるアクションは、以下のようなものだと思います。
私自身を含め、心当たりのある方も多いのではないでしょうか。
- 気合でなんとかする。
- 所定労働時間に収まらなくなったら残業で補う。
- 本当は旧機能全体を満遍なくテストしたいがまぁ無理なので
- モヤモヤしながら低リスクな領域のケースを削減する。
- 全体的な回帰テストを浅く実施して精神的安寧を保つ。
なんとか対応するものの、少しずつ限界を感じてくる・・・
肥大化し続ける回帰テストケース数に反して1人の人間のリソース上限は頭打ち・・・
実施すべき全体ケース数に対して削減ケースが占める割合は加速度的に上昇していく・・・
ｺﾝﾆﾁﾜ > 
QAエンジニアとして感じている課題
警告
個人の見解です。
人を増やせば解決するだろうか
QA工数が不足するならば、一見、新たな従業員を雇用すれば解決しそうにも思えますが、それほどシンプルな問題ではない気がしています。
なぜなら、QAエンジニアの頭数は圧倒的に少ないからです。
エンジニア市場にそもそもいないのであれば、従業員を雇用するという施策は早期に限界を迎える気がしてなりません。
短期的な緩和策に終止してしまう気がしています。
早めに手を打たねば手遅れとなる
半永久的に肥大化し続ける回帰テストの工数に対しては、人的リソースを割かなくてもよい構造にする必要がありそうです。
とはいえ、施策の実施自体にも相応の工数がかかるため、なんだかんだ後回しにしがちです。
回帰テスト工数が起爆すると、人間の速度を容易に凌駕していくため、手遅れとなる恐れもあります。
未来の工数爆発を防ぐために
二番煎じですが、人的リソースを割かないQA構造の鍵は「回帰テストの自動化」にあると考えています。
自動テストツールの見直しと選定
HRBrainでは、かねてから中核機能のテストを自動化し、リリース直前のmainブランチに対する最終検査に利用していました。
しかし、利用上の制約がかかったことや金銭的事情により、ツールそのものを見直しました。
スピーディな開発サイクルの中で回帰テストの自動化を推進するならば、実行回数が制限されないツールの選定が望まれます。
Selenium、Selenide、PlayWright等も視野に入れましたが、最終的には「mabl」を採用することにしました。
【選定理由】
- クライアント側のリソースで実行する方式(ローカル実行)は課金対象にならず実行し放題
- CLIからローカル実行できるため、shellスクリプトから複数のテストをキックできる。
- もちろんクラウド実行も可能(課金対象)
- UIに対する外部入力をレコーディングする方式のため、OSS系と比べて敷居が低い。
- オートヒーリングの調整が可能であり、メンテコストを削減できそう。
- 裏でPlayWrightが走っているので柔軟性が高そう。
回帰テスト自動化の3つの施策
現在、回帰テストの自動化推進にあたっては、中長期的に3つの施策を構想しています。
①ケースの過剰削減を抑止し、想定外なハレーションを検出
HRBrainのQAチームはインプロセスQAの体制をとっており、各プロダクトに対して担当QAが1人以上アサインされています。
プロダクト単位で、
- プロダクトの機能、QA観点を整理
- 自動テストシナリオに実装済みのQA観点と、未実装のQA観点を特定
- 未実装観点を自動テストシナリオに組み込む
・・・といったことを進めることで、肥大化する回帰テストを自動テストツールに委ねる状態を構想しています。
また、プロダクトの成長に伴って内部実装が複雑化すると、一見、依存性がなさそうな、誰も想定していない領域にハレーションが起き、
不具合が生じることがあります。
こうした事象は、回帰テストの過剰削減に由来することが多いように思えます。
QAエンジニアが後悔の念に苛まれる瞬間です。
②他プロダクトとデータ連携する箇所の自動テスト化
インプロセスQA体制の場合、良くも悪くもプロダクト知識に偏りが生じ、主担当領域以外の知識が不足しやすくなります。
他プロダクトにデータ連携した際の後続処理の挙動確認がなおざりになり、不具合を残すことに繋がり得ます。
都度都度、他プロダクトの主担当者に連携してQA依頼すれば対応できなくもないですが、基本的には回帰テストに該当するため、自動化できるポテンシャルは高いです。
連携データを処理するテストシナリオを準備した上で専用のテストテナントを用意する・・・
こうして連携先のプロダクト知識が乏しくても、回帰テストを必要十分に自動実行できる状態が理想と考えています。
③開発者による回帰テストの自動化
HRBrainには、QAエンジニアにテストを依頼をする前に、実装者によるテストステップを明確に定義しているチームがあります。
「開発者テスト」と読んでいます。
新機能に関するテストに加えて回帰テストも実施しているため、自動化のポテンシャルがあります。
実装者の工数削減につながるだけでなく、QAエンジニア視点の回帰テストシナリオを回すことで、テスト精度の向上も期待できます。
まとめ
【いままで】
自動テストツールの利用自体はしていたものの、十二分に活用できているとは言い難く、リリース前の最終検査に終止していました。
【これから】
将来的に訪れる回帰テスト工数の肥大化を抑止することを視野に入れ、自動テストの実施をよりシフトレフトすべく動き出しています。
人間のリソースは新機能領域のテストに費やし、肥大化する回帰テストはほぼ全て機械に任せる。
そんな持続可能な開発を目指しています。
最後に
HRBrainでは新しいメンバーを募集しています。