回帰テストやるか： 解決 Should do Regression test

http://d.hatena.ne.jp/taka_2/20110615/p2

■[IT]リグレッションテストはどこまでやるのか

発端

（たぶん政治的な理由で）jarを分割したいとかいう、イミフな案件をやるために、
大半の機能をリグレッションテストすることになった。
ごねたが、詳しい理由は隠されたまま、やることになってしまった。
政治力ってこわい。


人が少ないという理由で、
普段自分が保守を担当している部分＋他人が保守を担当している部分まで、
リグレッションテストすることになった。

自保守担当分

自分が担当している部分については、

• 最低限これができないと業務が回らない機能
  • 業務が回らないバグ出したら、呼び出されるに決まってる
• 以前バグが出たことのある機能
  • 本番で二回同じバグを出したらシャレにならない

をピックアップしたテストケースを用意してあり、
まずはこれを消化。


次に、今回jarを分割したことで影響の出る範囲を調査した上、
追加のテストケースを設定し、これを消化することで完了した。


工数は、合わせて1人日。

他人保守担当分

リグレッションテストケースが、
全機能を網羅的にテストするテストケースになっていた。

僕「なんでこんなにテストやる必要があるの？」
Ａ「なんか不安じゃないですか。」
僕「jarを分割するだけなのに？」
Ａ「なんか不安じゃないですか。」

話にならない。
まあ、他人担当分なので、あまり意見もできず、
コツコツとやることにした。


途中、明らかにバグなんだけど、運用上発生しないから大丈夫的な事象に見舞われつつ、
どうにか終えた。


工数は、10人日。
（それだけの期間があったから良かったけど）

どっちが正しいのか

パターン１：最低限やる

以下の部分だけリグレッションテストする

• 最低限これができないと業務が回らない機能
• 以前バグが出たことのある機能
• 改修箇所から調査して影響のある機能

パターン２：とりあえず全部やる

システムを構築したとき（保守に入る前）に行った、
システムテスト仕様書（のサブセット；抽出基準不明）を繰り返す。


結論から言うと、どちらも正しいのだと思う。
理想を言えば、全ての機能を再テストした上でリリースする方がいいし、
かと言って、リグレッションテストに割ける時間は限られている。

じゃあどうするか

そこで、ググってみたところ、以下のようにするのが良さそうという結論に達した。

• 自動化できるテストケースは自動化し、テストの工数を下げる。自動化したテストケースは実施コストが低いため、必ず行う。
• 手動で行うテストケースに優先度を付け、優先度ごとにテスト実施に必要な工数を見積もっておく。テストに割ける期間から、どの優先度のテストケースまで行うかを決め、テストを実施する。
• テストに割ける期間があまりにも短く、最優先のテストケースを全てこなせないような場合は、改修箇所から影響範囲を調査し、影響する機能のみテストを実施する。
• それでもムリっていう場合は、PMの引いた線がおかしいと思うので、文句を言う。

これで大体うまく行くんじゃないかって気がする。