第124回：　テスト自動化の利点とリスク（後編）

≡ はじめに

「ASTERセミナー標準テキスト」の190ページについてです。

前回は、「テスト自動化の利点とリスク（前編）」として「利点」について書きました。今回は、「リスク」についてです。

でも、キャッチイメージに書いてあるものは全て「リスク」ではなく「ハザード」です。


「リスク」と「ハザード」の違いについて説明します。
例えば、パンを焼くトースター（上のイラストをイメージしてください）には、「パンを焼いた直後に隙間に手を突っ込むとヤケドする」というリスクがあります。
リスクは、「将来発生する＊かもしれない＊嫌なこと」です。この場合なら「ヤケドする」ことは発生するかもしれない嫌なことです。（そんなこと誰もしないよ、、、と思うかもしれませんが、乳幼児の火傷事故は、日本で年間200件くらい起こっているそうです。1〜2歳のお子さんをお持ちの方にとって、「トースターでの火傷」は気になる「リスク」の一つではないでしょうか？

リスクが何かわかったところで、次はハザードです。
「トースターで、パンを焼いた直後に手を隙間に突っ込むとヤケドする」のは何故か？　どういった危険な状態があるから火傷をするのでしょうか？
「（パンを焼いた直後は）トースターの内部がメッチャ熱い🔥」からです。この「熱い状況」をハザード（危険要素／リスクの要因になりうるもの）と呼びます。
※ ハザードが存在しても必ず嫌なことが起こるわけではありません。手を突っ込めないような工夫があればリスクは回避できます。

「洪水ハザードマップ」が自治体から各戸に配布されていると思う（町田市だけ？）のですが、「洪水」というリスク（発生するかもしれない嫌な事）の危険要因（ハザード）を知らせる地図です。例えば、氾濫しやすい河川の近くとか、海抜が低い谷のような場所が洪水になりやすい場所（ハザード）として危険予想されて、確率によって色分けしてある地図が洪水ハザードマップです。

今回のnoteのテキストの一行目は「テストツールの効果を過大に期待する（例えば、ツールの機能性や使いやすさなど） 。」です。
これは「リスク」でしょうか？　例えば「過度に期待してしまう事により、必要なテストリソースが不足してQCDの達成ができない」ことはリスクですが、「過度な期待」そのものはリスクではなく、「ハザード」です。

ところで、「リスク」が現実にならないために、どのような「ハザード」があるのかを知っておく事が大切です。洪水ハザードマップを思い出してください。

知っていれば、ハザードを無くすことや、ハザードに気をつけることで「リスクを回避すること」ができます。

今回は、「自分ならどうやってこのハザードに対応するかな？」という視点でお読みいただけると幸いです。

≡ ツールのリスク

キャッチイメージにはツールのリスクとして次の5点（以下のリストは要約）が挙げられています。

✔︎ テストツールの効果を過大に期待する 
✔︎ 導入に要する時間や工数を過小評価する
✔︎ 継続的に効果を上げるために要する時間や工数を過小評価する
✔︎ ツールのテスト資産を保守するために必要な工数を過小評価する
✔︎ ツールに過剰に依存する

順番に見ていきます。

■ テストツールの効果を過大に期待する

テキストには、

テストツールの効果を過大に期待する（例えば、ツールの機能性や使いやすさなど）

とあります。

くどいですが、これはハザードであり、このハザードが原因で、「（テストツールの効果を過度に見積もったがゆえに）計画と実績の乖離が発生して納期遅れとなり、ユーザーに迷惑をかけ、売上が立たない」といったリスクが起こることが予想される（リスクが現実のものとなる可能性がある）ということです。

このリスクを回避するためには、単純に「テストツールの効果を過大に期待しすぎない」事に全員が気をつければOKです。

ところで、テスト自動化ツールは昔は買取で、20万円〜200万円くらいしていたので、会社で予算をとって実施稟議を書いて買うものでした。

今は、サブスクリプション契約によって数万円/月と経費処理できるようになっているものも多いです。

価格がグッとリーズナブルになったとは言え、会社で（これまで購入した実績がない）新しいものを買う時には、「投資対効果」についての説明が求められます。

投資対効果までは求められなくても「なんで必要なの？」とか「何に使うの？」、「役に立つの？？」と聞かれることは多いものです。

社員の裁量で「10万円以下なら自由に買って、領収書精算で良い」というルールの会社もあります。良いルールですね。

上司などから購入理由を聞かれたときに、ツールベンダーの営業マンが言っていた「すぐに元が取れますよ。その証拠に〇〇社もガンガン使っています。こちらに〇〇社の人が書いた投資対効果のグラフがあります。90%のコスト削減効果が出たようですよ」という言葉（営業マンの言葉や事例の資料に一切嘘はありません）を思い出して、つい、すごい効果が出るように言ってしまうことがあります。

それを聞いた上司は『そう言えば、△△常務が「まだ、ウチの会社は手動でテストしているのか」って嘆いていたなあ』と思い出し、次に常務に会ったときに「今度、90%のコスト削減効果のあるツールを導入するので期待していてくださいね。」なんて言ってしまいます。

すると、そのツールのベストな活用事例による効果を初めから享受できる気になります。これが「テストツールの効果を過大に期待する」リスク（ハザード）が生まれる典型的な流れです。

どうしたら良いかというと、「ソフトウェアテスト自動化ツールで工数削減効果は普通は出ない。特にツール導入初回から出ることは稀である」という事実を知り、伝えることです。

前回書いた通り、

私の経験では、テスト自動化ツールの工数効果がでたのは次の5パターンだけでした。

1. 巨大な組み合わせテストの自動化（結果の自動判定を含む）
2. リグレッションテストの完全自動化（複数の重要シナリオを必ず実行）
3. ユニットテストの完全自動化（TDDとCI/CD）
4. テストデータやテストログ作成の自動化
5. 大規模負荷テスト（同時アクセスなど）

です。

そして上記5つをテスト自動化ツールの初回に実現することはとても困難です。車の運転と同じで、何度も練習して上手くできるようになるものだからです。

確かに上司を説得するときに、ネガティブな話をするのは『やる気が本当にあるのか？』と上司に思われそうな気がして躊躇してしまうものです。それでも、正しい情報を伝えるべきです。

そうしないと後で困るのは自分ですよ〜。

■ 導入に要する時間や工数を過小評価する

テキストには、

テストツールを初めて導入する場合に要する時間、コスト、工数を過小評価する。

とあります。

テスト自動化ツールはAIを搭載した賢い人型ロボットではありません。指示したことしかテストしてくれませんし、その指示はテストエンジニアがツールに入力しておく必要があります。

また、テストは、残念ながら、ジューサー（というツール）がジュースを作るような単純作業ではありません。

何かのプログラミング言語を使ってゼロからテストの自動化を実現するのに比べれば、テストの自動化ツールはめちゃくちゃ便利です。テスト対象の画面にあるアイテムを自動認識したり、テスト結果を期待値と比較する様々な方法が用意されているからです。さらに、近頃では、多少のGUIの変化であればツールがいい感じに吸収してくれます。

余談ですが、RPA（ロボティックプロセスオートメーション ＝ Robotic Process Automation）ツールが使えるんじゃね？って一瞬思った時がありました。

その時の自分を叱ってやりたいです。
例えば、GUIを使って大量のテストデータを登録するといった“動かすだけ”ならRPAでも良いけど。

しかしながら、「誰でも、１時間程度のレクチャーで自動化ツールを使ってテストの自動化ができる」と思ったら大間違いです。「導入に要する時間や工数を過小評価するな」と言いたいです。

とても優秀な講師が1日かけて良い教材を使って、何かのスクリプト言語を使ったことがあって、かつ、やる気もある人に教えるなら、一通りのことはできるようになります。

上記を基準に講師が優秀でなければ、倍の2日、さらに、スクリプト言語を使ったことがない人に伝えるのなら、倍の倍の4日、テスト対象が複数のタイプ（ウェブアプリとWindowsアプリの両方）なら、その種類を掛けて8日などなど、、、現実的には少なくともそのくらいの教育期間を考える必要があります。

さらにテスト自動化用にリッチなHWが必要となるかもしれません。

■ 継続的に効果を上げるために要する時間や工数を過小評価する

こちらは、その次の「ツールのテスト資産を保守するために必要な工数を過小評価する」と関係が深いので、合わせて説明します。テキストには、

✔︎ 大きな効果を継続的に上げるために必要な時間や工数を過小評価する。
✔︎ ツールが生成するテスト資産を保守するために必要な工数を過小評価する。

とあります。

上にも書きましたが、テスト自動化ツールを買っただけではテストの自動化はできません。ワープロを買ったからといって小説が勝手に生まれることがないのと同じです。

「テスト自動化ツールを使いながら自動実行を行うソフトウェア（＝テスト資産／テストウェア）を開発する」感覚を持ってください。（このnoteを読んでいる人には常識と思いますが……）

テストウェアはソフトウェアと同様にプログラムの開発行為ですので、テスト対象が変われば、作り直しです。

「トルネコの大冒険 不思議のダンジョン」というテレビゲームのように、テストウェアを作った人（トルネコ）にはノウハウが溜まりますので、テスト対象（ダンジョン）が変わっても早く上手く攻略できますが、基本は作り直しです。

継続的に効果を上げるための障壁となるのは、テストウェアを作った人（テスト自動化をした人）がいなくなることです。

いなくなる理由は様々です。
テストの自動化にはプログラミングのスキルが求められます。逆に言えば、プログラミングのスキルを持った人がテストの自動化を担当することが多いものです。
開発チームは常に高いプログラミングスキルを持った人をスカウトしたいと思っています。
そして、テストの自動化を成し遂げた人も、だんだん自動化に飽きてきて、もっと複雑なプログラミングをしたいと言う気持ちになってきます。
そして、気がつくとテストチームから開発チームに異動している、、、なんてことがよくあります。

この問題を解決するためには、テストの自動化を行う人の待遇を上げることが必要です。例えば“開発チームに異動したら給与が下がる”なら異動を思いとどまるかもしれません。そうこうしているうちに、テストの自動化の奥深さに気がついて、大好きな仕事となることが期待できるからです。

■ ツールに過剰に依存する

テキストには、

ツールに過剰に依存する（テスト設計と置き換えたり、手動テストの方が適したケースで自動テストを利用するなど）。

とあります。

何事も100%の数値にこだわるとろくな事になりません。

気になった人は、「ほどよし​信頼性工学」や「Good Enough（品質）」あたりのワードでググると色々と出てきます。
寿一さんは「てーげー品質」と言っていたような、、、。
その話もわかるのですが、ここで書かない理由は、私がこの概念のことを嫌いだからです。「お客様にお届けする品質が適切であること」だけを狙いたいからです。
品質を高い、低い、ほどよしで扱い始めると声の大きい人の主観に引きずられるおそれがあります。

さて、話を「ツールに過剰に依存する（テスト設計と置き換えたり、手動テストの方が適したケースで自動テストを利用するなど）。」に戻します。

「テスト設計と置き換えたり」は、ちょっと意味がわかりません。「テスト設計をしっかりしていた人がテスト自動化ツールを使うのをきっかけとしてテスト設計をおろそかにする」ということでしょうか？　私は見たことがありません。それとも、「自動化できたらテスト設計もできていると誤解する人がいる」ということでしょうか？ こちらはあるかもしれません。見たことないですが。

むしろ、「せっかく自動化するのなら、テスト技法を使ってテスト設計をしてできた網羅的なテストケースを自動化したい」という声を聞きます。私の周りだけの話なのかなあ？

「手動テストの方が適したケースで自動テストを利用する」は、陥りやすい罠です。

例えば、「例外シナリオ」を自動化するためには、例外が発生する条件を自動でプリセットする必要があります。

例えば、プリンターで言えば、様々なタイミングで紙詰まりを発生させる必要があります。こちらを自動化しようとすると、高機能なシミュレータの開発が必要となるのですが、高機能のシミュレータを開発することの必要性を考えることが大切です。

また、UXやユーザビリティなどの感覚的な評価が必要なテストを自動化する際にもツールで確認することと、人間が確認することをわけて考えることが必要です。

≣ 終わりに

今回は、「テスト自動化の利点とリスク」の「リスク」部分について書きました。

色々とネガティブなことを書きましたが、自動化できるところはどんどん自動化して「CI/CDパイプライン」に組み込んで毎日繰り返し自動実行すると良いです。自動化の件数が増えたら複数のハードウェアで自動化を分散実行する仕組みを作ります。

ハードウェアの価格が高いときには夜中に使っていない個人のワークステーションを立ち上げっぱなしにしておいて、そのCPU資源を使うこともありましたが、今のパソコンは安いので10台でも20台でも買ってしまう方が楽です。ディスプレイやキーボード・マウスは切り替え装置で共用すれば良いですし。

リグレッションテストは「手動でやらない」と決めてしまうのもありです。漏れたテストはその周辺のテストを含めて、自動のリグレッションテストに追加するようにします。

ユニットテストは自動化しやすいテストですが、TDDはするとしても、開発者には「もうバグはないはず」と確信を持つまで手動テストを追加してほしいです。

ユニットテストは人によってイメージが違いますので一概に言うことはできません。状況の理解が大切です。

次回は、「ツールを選択する際の基本原則」について書きます。テキストには8項目もリストされているのですが、抑えるべきポイントはもっと少ない、、、と言いますか、、、。