非常に適当なエントリーですので、タバコでも吸いながら適当に読んでください。
日々QAエンジニアとして、テスト計画からテスト設計、手動テスト実施とその後の品質評価まで一生懸命テスト業務に携わっています。ただ、最近はリグレッションテスト部分の自動化を進めるプロジェクトも進んでいてなかなか大変です。
なんとなく「QAエンジニア 転職」をキーワードに検索してみると、必須ではないけれど自動化経験があると良いという募集要項を見かけるし、あとは単純にSET（Software Engineer in Test）エンジニアの募集も結構ある。
ただ今まで通りの手動テストやってるだけでは、品質保証という世界で置いてけぼりになるんじゃないかという漠然とした不安がある。手動テストが廃れる、と言うことはないだろうけどプロダクトの進歩は想像以上なのでいつの日か手動テストという工程そのものがスパッと完全に自動化に切り替わる可能性があるかもしれない。
とはいえ日本語という曖昧性が高い言語で書かれている機能仕様書からテスト観点を起こすのは難易度が高いとは思うので、すぐにそういう時代が来るとは思えない部分もあるんですけど。
現時点でテスト自動化を有用に使う場面というのはテストフェーズの中で、「リグレッションテスト」という認識を持っていて、まずはそこで得られるもの/失うものをなんとなく考えてみよう。
リグレッションテストとは、プログラムになんらかの追加や修正など更新があったときに、他のプログラム箇所に影響がないことを確認するテストのこと。回帰テストともいう
他のプログラム箇所に影響がないことを確認するテスト、というだけあって非常に範囲が広いのがリグレッションテストだと思っている。なので普段のテスト対象プロダクトのテスト実施時には影響範囲の全てはリグレッションテストは実施できていない。だいたい「コード的な影響はない」ということで無視されることがほとんど。
例えばショッピングサイトという大きなシステムがあったとして、カートシステムのクレジット決済処理部分に改修が入った場合、クレジットカード以外の決済処理部分は決済できることだけは確認するが、細かい部分まではテストしないことが多い。
もしテスト自動化が導入された暁には、クレジットカード以外の決済パターン（銀行決済、QRコード決済とか）の全てのテストパターンを実施することになるのだと思う。場合によっては決済処理だけではなくショッピングサイトシステム全てをテストする可能性も考えられる。
テスト自動化で得られるもの
- 今までリグレッションテスト実行にかけていた時間
- 想定してないバグ
- 自動化の経験
今までリグレッションテスト実行にかけていた時間
手動テストで実施していた時間がそのままゼロになるといえる。規模にもよるが最低でも１人日は工数として計上していたのでそれがなくなるので、その分早くリリースできることになる。
早くリリースできる、と思ったが実際の自分が関わってる業務では
- 通常のテスト：今まで通り
- バグチケット起票→バグ修正→修正確認：今まで通り
- テスト完了後に再度テスト（リグレッションテスト）：ここが自動化
というフローを進むので、テスト実施者がテストを人力で行わないだけでリグレッションテストは行われるのでリリースがギュンと早まるわけではない。リグレッションテストは実施するタイミングというものがある。
リグレッションテストを実施すべきタイミング
リグレッションテストを行うタイミングとしては、それぞれのテストを行った後やバグ発生時、不具合修正後が最適です。テストで不具合があった場合は修正し、再度テストを行って不具合がないかどうかを確認します。
テスト工程の段階でリグレッションテストを行うことで、不具合やバグを早期に発見し、適切に修正できるようになります。
リグレッションテストの意味とは？ 目的や実施すべきタイミングなどを解説 - お役立ち情報詳細 | クラウドECサイト構築プラットフォーム【メルカート】
想定してないバグ
現在私が関わる現場では、通常リグレッションテスト実施というと（時間も取りにくいということもあり）全てのテストパターンを実施することは少ない。プライオリティ（テスト優先度）が上位のもののみを実施している。
当然これは、「手動でテストを実施する必要があるため」だからだ。日中にテストをQAが時間をかけて実施する関係上実施できる範囲に限界があるため、実施範囲を絞っている。つまり、実施範囲外でバグが見つかる可能性が残っているわけです。
自動化により全範囲をテスト範囲にすることで、手動テストではこぼれてしまった拾えることになる。上記でも書いたが、リグレッションテストは大体通常のテスト完了後に行うことを前提とするため、テストで検出したバグとそれに伴うバグ修正によるデグレなどが発生する可能性がある。そういったデグレは予期しないところで出るものだったりするので、全範囲をもう一度確認できれば非常に心強い。
自動化の経験
あと何より、自動化テストを運用した経験というのは手動テストだけ実施していては得られない貴重なもの。自動化テストツールの導入から経験できればさらに大きな経験になると思う。なにしろ最初から自動化テストが環境として用意されている場合とそうでない場合は全然違うものだからだ。
自動化ツールを導入するためには決めないといけないこと、確認しなくてはいけないことが様々にある。
導入検討中作業リスト（順不同）
- サーバー（ブラウザタイプかそうでないかなど）
- 利用ユーザーがどれだけいるか
- ツール選定（ノーコード系かそうでないかなど）
- ライセンス料（ユーザー数による）
- 導入することの意義があるかどうか
- 予算確保や稟議を通す
- テスト対象とするプロダクト選定（ツール相性）
- テスト対象テストケース選定（既存を流用、新規で作成するかなど）
- テストツールのPOC（Proof of Conseptの略、運用前段階の検証プロセスのこと）
他にもあると思う。QAチーム全員で取り掛かることもないはずなので誰がその検討作業に入ることができるか？なども決めておかないといけないし。こういったものはやはり導入前でないと得られない経験になる。
失うもの
自動化テスト導入により失うもの、実はまだよくわからない。得られるものが多そうな気がしているが、実際問題として自動化テストに適したテストというものの範囲自体あまり大きくないのでは？という気がしている。
自動化テスト＝リグレッションテスト、という理解でいるが普段のテストスケジュールにおいてリグレッションテストの期間は全体の10％程度で元々あまり大きいものではない。新規プロダクトや既存プロダクトの改修プロジェクトで自動化テストを導入しにくいとなると、自動化テストで得られるメリットは想像以上に低いのでは？という気持ちになってきた。
むしろ、何度も実施するためのリグレッションテスト用のメンテナンスに関わる時間が増える、つまり普段のスケジュールからメンテ時間を奪われることになる、のではないか？と思う。そういう意味では非常に漠然としているけど、「時間」が失われるのかも。
得られるものとして「リグレッションテスト実施に費やしていた時間」だとしたら、ここでメンテナンスの時間を使うことになるので、結果トントンになりそうですね。ほんとかな？？
