105. リグレッションテスト その③
影響があるところ
マンガで描いた通り、影響がある部分がどこかはとっっっても難しい問題。
JSTQBでは「影響度分析」という言葉で出ています。
影響度分析…変更が影響するすべての成果物を識別すること。変更を達成するために必要なリソースの見積りを含む。
変更が影響するすべての成果物を識別……とサクッと書いてくれてますが、そんなにサクッとはいかないのが現実です(^-^;
メソッド（プログラムだよ）を直したら、そのメソッドを呼び出しているところを探したり。
データベースのテーブル（表みたいなものだよ）をいじったなら、そのテーブルを使ってるところを探しまわったり。
APIをいじったら速度低下してないか計測したり。
バッチのSQL文を変えたらその影響で速度低下して、そのバッチがつきぬけて（時間オーバー）後続処理に影響ないんだっけって探ったり。
環境の変数をいじったら同じ環境にいるシステムでその変数使ってるところ探したり。
ガッツリやろうとすると時間がいくらあっても足りないところでもあります。
次のお話からは、こんなやり方をしてるところもあるよ、といったお話をしていくつもりです。
紐づけ
テストケースに、そのテストケースが何のテストベース（テストを考える元となる資料だよ）のどこから出したもの、と紐づけておくとよかったりします。
その元の資料にある場所に変更があったとき、どのテストケースの部分に影響がおよびそうかわかりやすくなったり、仕様変更時にどのテストケースを修正したらいいかわかりやすくなったりします。
テストの言葉だと「トレーサビリティの確立をする」なんて難しい言葉で言ったりします。
何を根拠としたものかたどれるようにしておく、ってことですね。
（ちなみに作者はweb系/ゲーム系にずーっと身を置いてますが、本を読み知識としては知っているものの、しっかり書かれている現物には出会ったことがなかったり）
