みんな！何のために"リグレッションテスト"やってる！？
この記事は hacomono advent calendar 2024 の22日目の記事です。
みなさんこんにちは。QAエンジニアのpiroちゃんこと廣田です。
2024年も年の瀬ですね。寒くなってきましたがいかがお過ごしでしょうか？私は振り返りやら来年の準備やら、何かとバタバタしております。
12月のことを師走と言いますが、逆に言えばあちこち忙しくしている私は「師」なのかもしれません。
なーんて、調子に乗るもんじゃないですね。
さて、今年は何やったかなーとざっと振り返ってみて、
自分が新たな気付きを得たことについて書いてみようと思います。
"リグレッションテスト"の目的
リグレッションテストって案外奥深いテーマですよね。
チームによって目的も、手段も、対象とする範囲も様々です。
世のQAチームの方々に片っ端から聞いて収集してみたいくらいです。
興味深さと同時に、結構難しいテーマだな、とも思っています。
そもそもリグレッションテストとは？については、
Wikipediaの説明を引用してみましょう。
回帰テスト (かいきテスト、英: regression testing) とは、前にテストしたソフトウェアが変更後もまだ動作するかどうかを、機能テストと非機能テストを再度実行して確認する作業のこと[1]。退行テスト、リグレッションテストとも呼ばれる。
説明だけ読むと単純明快ですね。
ただ、実際にプロダクト開発におけるリグレッションテストを考えると、
どんな手段で？どの範囲まで？いつ？何のために？
何を持って変更後のソフトが動作していると言えるのか？
など、チームや状況に合わせ考えなければいけないことが多いです。
今回は肝となる「目的」にフォーカスを当てて話をします。
さて皆さんは何のために、リグレッションテストを実施していますか？
私が所属するチームでは、リグレッションテストの目的をこう定めました。
実はこれ、
最近QAメンバーで議論を重ね、ようやく明確に言語化できたものなんです。
というのも何を隠そう我々のQAチームでは、リグレッションテストに
大きな問題を抱えていました。少し、その背景についてお話します。
リグレッションテストの歴史
我々のリグレッションテストのざっくり年表です。
始まりは我々のプロダクトがまだ小さかった頃です。
「プロダクトの網羅性に着目した全機能テストを作ること」
が最初の設計思想でした。
ですがそこからプロダクトが大きくなるにつれ、メンテナンスにも実施にもより多くのコストがかかるようになり、いかにコストを下げるかという戦いに苛まれます。
優先度付けをしてケースを取捨選択したり、ツールで自動化したりと
色々な策を講じてきましたが、最初に作り、積み上げられてきた
「全機能テスト」を捨てることができませんでした。
その結果今、我々のリグレッションテストは課題まみれに！
具体的にどんな課題がメンバーから上がったかお見せします。
もう出るわ出るわ。
全機能テストという思想のまま肥大化してしまったリグレッションテストは、もはや我々の手には負えなくなってしまっていたのです。
そこで、リグレッションテスト改善委員会というものを立ち上げ、
「そもそも何のためにリグレッションテストってやるんだっけ？」
というところから議論をスタートしました。
その結論が先ほどお見せしたこちらです。
我々が提供するシステムによって、
お客様の業務が停止しないことを確認する
"ソフトウェアに変更を加えた後、まだ動作するかどうかを確認する作業"
というのがWikiによるリグレッションテストの説明でしたね。
過去我々は、ソフトウェアが動くかどうかに着目をして、
できるだけ広い機能を網羅するように作っていました。
しかしそうではなく、顧客のユースケースにこそ着目すべきなのでは、
と気付いたのです。
いくらソフトウェアとして正しい挙動をしていても、
それにより顧客の業務が停止してしまっては、
顧客にとってそれは不具合も同然です。
逆も然りで、いくらソフトウェアが不具合を起こしていても、
それをうまく使っている顧客がいることもあります。
また、そもそも不具合があっても顧客の業務に何ら支障がないものは、
そもそも機能として価値を提供できていない可能性もあります。
だから我々は、「機能の網羅性」よりも「顧客の業務」に着目した
リグレッションテストが必要だという結論に至りました。
網羅的じゃなくていいの？
という問いは出てくると思います。
これに対しては、「リグレッションテストにおいては」網羅的にしない、
と書いておきます。
リグレッションテストではなく、それよりももっと前のフェーズで繰り返し検証を行い、不具合を検出しておくのが良いと考えているからです。
「手戻りコストの法則」と世に言われているものがあります。
不具合の修正は後工程になるほどコストがかかり、出荷後の修正ともなると
要件定義フェーズと比較して200倍ほどかかる！というものです。
リグレッションテストは概ね出荷前、後工程にやることを考えると、
そのフェーズででバグを拾おうとしてたら、百何倍のコストをかける前提で
テストをしていることになりませんか？
最後にして最強の砦を作るのではなく、プロセスの中で継続的に
検証をすることが、効率の良い品質保証に繋がるのではないかと考えています。
まとめ
伝えたかったことは2つです！
リグレッションテストは、機能の網羅性よりも顧客の業務（ユースケース）にこそ着目すべきだということ
リグレッションテストは、最後の砦ではなく、それ以前のフェーズで継続的な検証が必要であること
今回の私の気付きは最初の一歩に過ぎません。
これからこの目的に沿って、リグレッションテストの課題と戦っていきます。
みなさんは何のために、リグレッションテストをやっていますか？
今一度向き合ってみると、新たな気付きがあるかもしれません。
以上、piroちゃんでした！