読者です 読者をやめる 読者になる 読者になる

プログラマとプロマネのあいだ

プログラマもやるし、プロマネもやるし、たまに似非アーキとか営業っぽいこともやる

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

IT

発端

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


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

自保守担当分

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

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

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


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


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

他人保守担当分

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

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

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


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


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

どっちが正しいのか

パターン1:最低限やる

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

  • 最低限これができないと業務が回らない機能
  • 以前バグが出たことのある機能
  • 改修箇所から調査して影響のある機能
パターン2:とりあえず全部やる

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


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

じゃあどうするか

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

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

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