107.リグレッションテスト　その⑤

f:id:m_training:20210607074149p:plain

変更によって、他のテスト済みの機能に意図しない影響が出ていないか確認する目的のテスト全般がリグレッションテスト。

なので「これ！」といったやり方があるわけではないです。

ここで紹介しているのは作者が行った方法を並べています。

チャーターを使った探索的テストについてはこちら。

システムテストの後半に行ったりしていたリグレッションテスト。

修正されたバグの一覧をチャーター（テストの参考にする資料、方向性を決める資料といったところ）として確認していきます。

バグの再現確認だけでなく（これは「確認テスト」といいます）、そのバグ票の内容や修正コメントから、関連個所などを確認します。

テストケースに「紐づけ」（トレーサビリティの確立）をしていて、変更時の影響を追えるなら楽なのですが、そうもなっていないところが多いかなーと思っています。

その辺のお話↓

なのでよく「この機能を全体的に確認」とか「システムを全体的に確認」みたいにするのですがフルのテストケースを再実施するのは超大変です。

そこでどう絞り込むかというと「テストケースに優先度をつけておく」です。

そこがひとまず通ることを確認しておく、といった形ですね。

コレをやろうとすると「どれを優先するか？優先すべき項目とは！？」みたいな討論は始まったりしますが、それはみなさんでちゃんと話し合いましょう。

ツアーについては以下のカズさんのブログ、熊川さんの資料に色々お話が記載されています。

以下の資料の15P

観光ツアーに例えて探索的テストの方向性を定めています。

結構無理やり感もありますけれどｗ

作者がよく使ったのは「ガイドブックツアー」

ユーザーマニュアルに基づき、主要なポイントのみを外さないように操作を進める。

マニュアルに書いてるのに動かない！みたいな本番障害を起こした経験もございまして(^-^;

マニュアルに書いてあるところで問題が起きるのは絶対に避けたい、ということと一通りの主要な機能をめぐることができたので重宝しました。

今のウェブ系サービスだとあんまりマニュアルがないかもしれないですが……。

あとはガーベージコレクターズツアー（ゴミ収集車ツアー）

細部にはこだわらず、画面ごと、ダイアログごとに、明らかにおかしいことがないかをチェックする

セッションベースドの形で、画面ごとに見ていく探索的テストも重宝しました。

リグレッション、というより普通に新しいバグがいろいろ見つかっていたりしました(^-^;