106. リグレッションテスト その④
自動テスト
自動テストは、プログラムやツールを使って、決められた内容にそって行うテストの総称です。
例えば、プログラムと一緒に「テストするプログラム」を書いて、自分たちの書いたプログラムが思った通りに動くかテストするunit testがあります。
他にもAPIというデータ処理をして返してくれる窓口にデータを送って、返ってきたデータが正しいか確認するAPIテストなんかもあります。
あとは、作ったwebやアプリに対して、自動的にボタンクリックなどをするようなツールを使ってテストするE2E(エンドツーエンド / いーつーいー)自動テストもあります。
テスト業界いる人が「自動テスト」と話した場合はE2E自動テストを指すことが多いです。
開発の人が「自動テスト」と話した場合は、プルリクエスト（自分が書いたプログラムをみんなのプログラムとくっつけてください！というリクエストを投げたりします）したときに自動的に実行されるunit testを指したりしています。
リグレッションテストで自動テストが向いている場所
自動テストの強みのひとつに「同じテストを何度も繰り返しできること」があります。
リグレッションテストは、修正で周りに影響がないか確認することを目的にしたテストです。
なので以前に確認した場所を再チェックするわけですが、その活動と自動テストの強みがマッチしているわけです。
どんなところがリグレッションテストで自動化されることが多いかというと……
- 主要導線（想定しているシステムのメインとなる部分、使い方）
- バグったときにダメージが大きい場所（お金系とか）
- 仕様や実装が複雑な場所（ゴチャゴチャしてると変更の影響を受けやすかったり）
だいたいこの辺です。
毎度毎度確認しなきゃいけない大事な場所の確認、が自動テスト向けです。
逆に、テスト中に目が通りにくいマイナーな場所（地味な設定画面の一部とかあるよね…）は自動テストで済ましてしまう、という考え方もあります。
これは自動テストにしておくメリットがあるならにはなります。
柱にも書いたけど、ぶっちゃけ自動化が向いてる場所は
「このテスト……だるい……」
と思うところがメッチャ自動テスト向けです。
だるい＝機械的で同じ作業繰り返し部分だったりすることが多いわけですね。
自動テストのデメリット
自動テストはチェッキングの活動です。
同じ場所を同じ方法でしか確認できません。
なので、その通った道と通した確認方法で出るバグしか拾えないということは覚えておいた方が良いです。
自動テストには、修正内容や追加機能の内容から考えて「この場合大丈夫？」といったようなテスティングの活動は含まれません。
主要導線で問題がないことを確保してOKとしよう、というのならOKです。
（この辺は品質目標次第。「どこまでテストする問題」なところ）
けど「他にもバグがないか確認が必要」という場合には他のテストを組み合わせる必要があるので「自動テストさえあればもう何も怖くない」と妄信しないほうが良いです。
あと自動テストでみんなが引っかかるデメリット。
それは…修正コスト！！
自動テストを始めると、アレもコレもと自動化していきます。
なんだけど運用して気が付きます。
「ちょっとした変更でテストが壊れる！！」
と。
webなんかでしたらUIは結構頻繁に変わります。
自動テストの作り方にもよりますが、ちょっとした要素の変更でその要素を見つけられなくなっちゃって「あぁ、ここの要素の位置の指定し直さないと…」とかやったりします。
最初のうちは「ここが死んだらヤバイ！！」という部分だけ自動テストにするなどした方が効果的です。
エヴァ
次の序破急から実は見てないのです。
