日本語どんなテストから自動化すればいいの？自動化の対象となるテストを選ぶ際の方法3つ
こんにちは。MagicPodでエバンジェリストをしているYoshiki Itoです。
システムテストやE2Eテストと呼ばれる種類のテストを自動化しようと思ったとき、「どんなテストから自動化すればいいの？」「自動化に向いているテストってどんなテスト？」といった疑問が出てきます。
本記事では、自動化する対象のテストシナリオや機能などをどのように選択したらよいのかについて、公開されている手法を３つご紹介します。
前提：手動テストをそのまま自動化するのには注意が必要！
具体的な選定手法をご紹介する前に、テスト自動化を成功させるための重要な心構えを共有します。
手動テストをそのまま自動化するのは非効率
既にたくさん存在する手動実行用のテストケースをそのまま自動化ツールで実現しようとすると、うまくいかないことが多いという点に注意が必要です。
その主な理由としては、以下のようなものが挙げられます。
- テストケースの記載内容が曖昧で、そのままでは自動化できない/解釈のブレが発生する可能性がある
- 実行順序やデータの扱いが手動実行に最適化されていて、自動実行では効率が悪い
- 自動化率をKPIとし、自動化の目的や適合性を考える前に、自動化に不向きなテストまで無理に自動化してしまう
詳しくは以下の記事（外部サイト）でも触れていますので、よろしければご覧ください。
「自動化するテストを選ぶ」というときに気をつけたいこと #テスト自動化 - Qiita
本来であれば、自動・手動いずれで実行するのかについてテストプロセスのより前段で考慮しておくのが理想です。
テスト選定は「大きな粒度」で優先度を付ける
このあと解説する手法でも示されますが、テスト自動化の初期段階では、個々のテストケース単位で優先順位を決めるよりも、ユーザーストーリーの区分や機能単位など、テストケースよりも大きな粒度で優先度をつけるやり方が有効です。
現場レベルで取り入れる場合は、まずはユーザーストーリーや機能など大きな粒度で優先度付けをしたのち、そこに含まれる個別のテストケースについては、改めて自動化の 「適合性」 を判断するのが良いでしょう。
自動化対象となるテストを選ぶ方法3つ
いずれも、なんらかの基準に従ってテストにポイントをつけ、ポイントの高いほうから自動化をするという方法です。
1. 『リーン開発の現場』の方法
ひとつめは、リーン開発の現場 カンバンによる大規模プロジェクトの運営 | Ohmshaに出てくる方法です。
第18章テスト自動化の戦略という章で説明されており、以下のような手順で行います。
- テストケースを一覧にまとめる
- それぞれのテストをリスクによって分類する。それから、各テストを手動で実行した場合と、該当のテストを自動化する場合に、どのくらいのコストがかかるのかを明確にする。
- テストケースの一覧を優先順位をつけて並べ替える。
- 優先度が高いテストから、それぞれのイテレーションで少しずつ自動化していく。
ここではテストケースと記載されていますが、書籍中の例は「取引履歴」「新規ユーザー登録」などの粒度になっているのでこの点に注意が必要です。
引用：『リーン開発の現場』P135より
上で引用した図のうち、色がついているところが「高い」という意味です。 つまり、リスクが高く、手動テストのコストが高く、かつ自動化コストが低い順に自動化する、という方針です。
このように、「リスク」「手動テストのコスト」「自動化コスト」の3軸で検討・判断するというのは、比較的シンプルでわかりやすいのではないでしょうか。
2. Angie Jones "Which Tests Should We Automate?"の方法
続いては、アメリカで自動化エンジニアなどをされていたAngie Jones氏の提唱している方法です。
詳細は以下のスライドに記載されています。
ここではG, R, V, C, Hの5軸をもとに機能単位でスコアリングし、トータルスコアが一定のライン以上であれば自動化する、という方法が解説されています。
引用：Which Tests Should We Automate? より
引用：Which Tests Should We Automate? by Angie Jones | PPTXより
それぞれの軸は以下のように決まります。
- Gut Feeling（直感）：ユーザーにとって大事であろう機能は自動化する、なくても大事ではなさそうな機能については自動化しない、という決め方をします。
- RISK（リスク）：Probability（顧客の使用頻度）とImpact（もし壊れた場合に顧客に与える影響）をそれぞれ５段階で評価し、掛け算したものがスコアになります。
- VALUE（価値）：Distinctness（テストすることで新たな情報が得られるか）とInduction to Action（どのくらい速く故障が修正されるか、バグがあったときに開発者がどのくらい急いで直すか）を５段階評価し、掛け算します。
- COST-EFFICIENCY（費用対効果）：Quickness（どのくらいすぐ自動化できるか）と、Ease（どのくらい容易に自動化できるか）の５段階評価の掛け算です。
- HISTORY（過去の状況）：Similar to weak areas（関連するエリアで過去どのくらい故障があったか）と、Frequency of breaks（このテストで過去どのくらい故障が見つかったか）の５段階評価の掛け算です。
直感＋残り4つの評価で0~100のスコアが付き、67点以上であれば自動化する、34点～66点は可能であれば自動化する・自動化を検討する、33点以下は自動化しない。という決め方です。
こちら過去同様の内容を個人ブログにも書いていますのでよろしければご覧ください。＞自動化するテストの選択方法（自動化スコアで判断する方法） - テストウフ
こちらは先にご紹介した『リーン開発の現場』の方法と比べて、より細かくスコアリングしていますね。
3. LINEヤフーコミュニケーションズさんの方法
続いてはLINEヤフーコミュニケーションズさん（発表当時はLINE Fukuokaさん）がMagicPod Meetupで紹介してくださった方法です。
資料はこちら。
大筋のやり方は上記2つの方法と似ていて、一定の基準でスコアリングするというものです。
引用：Magic Pod 活用事例 より
スコアを設定する際のポイントは5つで、
- 実行頻度
- 変更可能性
- ヒューマンエラー
- テスト実施難易度
- 自動化難易度 です。
これらの基準をもとに、テストの大分類ごとにスコアをつけ、最終的には優先度ランクA, B, Cを設定します。
引用：Magic Pod 活用事例 より
こちらの方法も基準が明確ですし、チーム内で共通認識を持ちながら進められる点がありがたいですね。
まずはマネから入り、チーム内で基準の検討を
今回ご紹介した3つの方法は、それもすぐにマネできる方法です。とりあえず優先度をつけたい！という場合は、1番目のリーン開発の現場のやり方がシンプルで取り組みやすいです。 しかし、優先度の基準はそれぞれの方法で異なりますし、本当に自分たちに合った自動化優先度を設定しようと思うと、基準自体の検討が必要になるでしょう。
スタート時点ではいずれかの方法の基準をマネするのもよいですが、一定のテストを自動化した時点で、基準自体の見直しもぜひ行いましょう。
また、これらの方法は2020年ごろもしくはそれ以前に公開されたものであり、テスト自動化への生成AI活用が進んだ現在とは事情が異なっている点は注意が必要です。この点も、基準の検討の際に考慮できると良いですね。
