リグレッションテストはどこまでやるのか
発端
（たぶん政治的な理由で）jarを分割したいとかいう、イミフな案件をやるために、
大半の機能をリグレッションテストすることになった。
ごねたが、詳しい理由は隠されたまま、やることになってしまった。
政治力ってこわい。
人が少ないという理由で、
普段自分が保守を担当している部分＋他人が保守を担当している部分まで、
リグレッションテストすることになった。
自保守担当分
自分が担当している部分については、
- 最低限これができないと業務が回らない機能
- 業務が回らないバグ出したら、呼び出されるに決まってる
- 以前バグが出たことのある機能
- 本番で二回同じバグを出したらシャレにならない
をピックアップしたテストケースを用意してあり、
まずはこれを消化。
次に、今回jarを分割したことで影響の出る範囲を調査した上、
追加のテストケースを設定し、これを消化することで完了した。
工数は、合わせて1人日。
他人保守担当分
リグレッションテストケースが、
全機能を網羅的にテストするテストケースになっていた。
僕「なんでこんなにテストやる必要があるの？」
Ａ「なんか不安じゃないですか。」
僕「jarを分割するだけなのに？」
Ａ「なんか不安じゃないですか。」
話にならない。
まあ、他人担当分なので、あまり意見もできず、
コツコツとやることにした。
途中、明らかにバグなんだけど、運用上発生しないから大丈夫的な事象に見舞われつつ、
どうにか終えた。
工数は、10人日。
（それだけの期間があったから良かったけど）
どっちが正しいのか
パターン１：最低限やる
以下の部分だけリグレッションテストする
- 最低限これができないと業務が回らない機能
- 以前バグが出たことのある機能
- 改修箇所から調査して影響のある機能
パターン２：とりあえず全部やる
システムを構築したとき（保守に入る前）に行った、
システムテスト仕様書（のサブセット；抽出基準不明）を繰り返す。
結論から言うと、どちらも正しいのだと思う。
理想を言えば、全ての機能を再テストした上でリリースする方がいいし、
かと言って、リグレッションテストに割ける時間は限られている。
じゃあどうするか
そこで、ググってみたところ、以下のようにするのが良さそうという結論に達した。
- 自動化できるテストケースは自動化し、テストの工数を下げる。自動化したテストケースは実施コストが低いため、必ず行う。
- 手動で行うテストケースに優先度を付け、優先度ごとにテスト実施に必要な工数を見積もっておく。テストに割ける期間から、どの優先度のテストケースまで行うかを決め、テストを実施する。
- テストに割ける期間があまりにも短く、最優先のテストケースを全てこなせないような場合は、改修箇所から影響範囲を調査し、影響する機能のみテストを実施する。
- それでもムリっていう場合は、PMの引いた線がおかしいと思うので、文句を言う。
これで大体うまく行くんじゃないかって気がする。
