見出し画像

第123回: テスト自動化の利点とリスク(前編)

≡ はじめに

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

前回は、「テストツールの種類」について書きました。今回は、「テスト自動化の利点とリスク」についてです。ちょっと長くなってしまったので、前編と後編に分けて、前編では「利点」について書きます。「リスク」は後編に書きます。

前回は、様々なテストツールについて書きましたが、今回は「テスト実行ツール」に絞っています。

というのはテストツールの中で、「テストの自動実行」に対する期待が最も大きいからです。

私がそれを痛感したのは「テスト実行を90%自動化したらテスターを90%削減できる」と思っている人がいることに気がついたときです。
もしも、テスターが、“テスト実行”しかしていないのなら90%削減できますが、そうではありません。当時はテスト分析やテスト設計はしていませんでしたが、手動のテストスクリプトの作成や、テストデータの準備はしていましたので、90%削減はあり得ないことが明らかでしたが、そう思わない人がいるのかと驚きました。

他にも、バグが出たら不具合票を起票しますし、テスト環境の構築にも時間がかかります。もちろん仕様の理解や週報会、メールのチェックと返信も積み重なると工数を削ります。割り込み作業はそれ自体はごく僅かな手間でも作業のスイッチングコストが馬鹿になりません。

テスターがしている典型的な作業について、時系列に並べてみます。
・ 仕様の理解
・ 手動のテストスクリプトの作成
・ テストデータの準備
・ テスト環境の構築
・ テスト実行
・ 不具合票の起票
・ 会議やメールなど

さて、「テスト実行」は、テスターの全業務時間の何%だったと思いますか?
私の計測結果はこのnoteの終わりに書きます。知っておいてほしいのは、仮に「テスト実行」が50%あったとして、さらに、その90%を自動化できたとしても、テスターの全工数に対しては45%の省力化だということです。

工場の生産(組み立てなど)の自動化では、働いている人はほぼ100%組み立て作業をしていますので、組み立てを自動化した分、人を減らせます。←ソフトウェアのテストでも同様のイメージで語っている人を多くみます。

ソフトウェアのテストの現場を視察した偉い人が「手が動いていない人が多すぎる」と言ったそうです。視察する偉い人にソフトウェアテストは、ルーチンワークではないことを説明しておく必要があります。

そこで、今回と次回のnoteでは、「テスト自動化の利点とリスク」と題してテスト実行ツールに対して過大な期待はしないようにという話を書きます。

なお、テスト実行ツールは、リグレッションテストを完全自動化するなど、使い方によっては非常に有効なツールです。


≡ ツールの利点

キャッチイメージにはツールの利点として次の4点が挙げられています。

✔︎ 反復作業が減る。特に「データ駆動方式」。 
✔︎ 一貫性や再実行性が増加する。 
✔︎ 客観的な評価が可能になる。 
✔︎ テストやテストケースの情報へのアクセスが容易になる。

順番に見ていきます。

■ 反復作業が減る。特に「データ駆動方式」

テスト実行の自動化は、一度っきりのテストでは工数効果がありません。「自動化をし終わったときにテストは終わっています」ので、言われてみたら当たり前のことです。

逆に言えば、「同じようなことを何度もなんども手動で実行するの、地獄だな」というものがあれば、それを自動化すると大きな工数効果につながります。これが見出しの「反復作業が減る」の意味です。

実際には、人間は同じようなことを続けると退屈で注意力が落ちます。そういう面でも自動化をした方が良いです。『社会調査の入力ミスの発生率について』によると、「ごく単純な入力ミスですら、 熟練の作業員でも 0.1%、経験の浅い者だと 1.6%の発生率を示す」という報告があるとのことです。
厳しいほうの数値の0.1%で考えたとしても、1000箇所の入力があれば、1件の入力ミスを起こすということです。1つのテストケースには5つくらいは入力がありますので、200テストケースを実行したらそのうちの1つはテスト入力ミスでおかしな結果となるということです。(テストは新しいソフトウェアに対して行いますので、テスト対象の操作について熟練しているとは考えにくいです。実感としても、私なら、20件のテストに1回くらいは入力ミスをしそうな気がします)
テスト自動化ツールは、退屈せずに愚直に実行しますので、人間が手動で行う時の入力ミス相当の物は起こりません。

見出しの後半は【特に「データ駆動方式」】となっています。「データ駆動方式」とは、例えばAmazonのようなEコマースサイトをテストするときに、「商品名」や「購入個数」などのテストデータを自動化テストスクリプトとは別に表(PV表)にしておいて、その表から一行ずつ読み取りながらテストを繰り返す方法です。

特に組み合わせテスト(オールペアや直交表でテストマトリクスを生成し、そのマトリクスを一行ずつ実行するテスト)の自動化は一行分だけテスト自動化ツールでスクリプトを作ることで、マトリクスが大きくても全ての行のテストを自動実行するので有効です。

この話をすると、「マトリクスを自動実行するのは良いけれど、期待結果を書けないので、結果確認まで自動化できない」という人がいます。
結論から言えば、問題なくできます。何故なら、組み合わせテストは無則のパラメータ(因子)の組み合わせだからです。つまり、組み合わせることによって特別な結果は出ないので、全ての水準の期待結果を用意するだけで良いためです。
上の方で書いたAmazonの例で言えば、「商品名」と「購入個数」の関係はありません(=無則です)。シャンプーを3本購入したら、「届いた品がシャンプーであること」と「届いた品物の個数が3であること」を期待結果として、自動化スクリプトを書きます。「設定項目=期待結果」です。
つまり、単機能テストの時に作った期待結果との比較ルーチンをそのまま流用できます。


■ 一貫性や再実行性が増加する

人間が手動でテストをすると、同じテストケースであっても違うテストをしてしまうことがあります。

その結果、「バグが出た!」と思って同じテストケースを再実行(再現テスト)をした時に再現しないことがあります。

これは、「直前のテストの影響」、「操作の順番の違い」、「操作のタイミングの違い」などによって発生します。

テスト自動化ツールは同じことを同じ操作順序で、同じ速度(同じタイミング)で一貫して実行しますので、再実行性が増加します。(再現性の向上になります)

さらに、手動であれば、いちいちスクリーンショットを撮るのが面倒と思っても、テスト自動化ツールは疲れることがありませんから、ジャンジャン、スクリーンショットを撮ったり、テストケース実行前後の時刻やメモリーの空き容量をログに記録できます。
(このように、デバッグに役立つ情報を容易に残せることもテスト自動化の利点の一つです)


■ 客観的な評価が可能になる

上にも書きましたが、例えばテスト前後の時刻を記録することによってテストで処理にかかった時間を残すことができます。また、特にユニットテストを自動化するツールではカバレッジ率を自動で測ることによって客観的な評価につながります。
(制御フローのパス網羅が品質にどれだけ因果関係があるかは、ケースバイケースですが、一般にモデルに対する網羅性は客観的評価につながります)

バグの報告を受けるプログラマーとしても、「デバッグに必要な操作と結果」の情報だけで、「誰が見つけた」という情報がないので余計な気遣いなしにバグに向き合えるメリットがあります。


■ テストやテストケースの情報へのアクセスが容易になる

人間が手動でテストをする場合には、必ずしもテスト手順書通りに実施するとは限りません。

テストの途中で電話がかかって長話となり、操作Aと操作Bの間に10分くらい時間があくかもしれません。
他にも、Slackの通知が割り込んだり、テストを実行中のノートPCを閉じてサスペンドにしたかもしれません。
「実際にあったこと」へのアクセスはテスト実行の自動化ツールのほうが確実です。


≣ 終わりに

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

はじめにのところに、

さて、「テスト実行」は、テスターの業務時間の何%だったと思いますか? 私の計測結果はこのnoteの終わりに書きます。

と書きました。その答えは、「14%」です。

つまり、テスト実行を仮に100%自動化したとしても、14%の工数改善にしかならないということです。さらに言えば、自動化スクリプトの作成工数とメンテナンス工数もかかります。

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

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

自動化ツールを工数の削減を狙いとして導入した場合、上記以外については「オフショアやニアショアの労働力」、もしくは、「テスト分析・設計によるテストケースの削減」に負けて続かないことが多いものです。次回の後編では、そのような話を書くことになりそうです。

もちろん、上記5つを上手くやれば、相当の効率化と品質向上が実現できますので、「自動化しない」という選択肢はありません。

次回は、「テスト自動化の利点とリスク」の「リスク」部分について書きます。自動化を行ったすべての人にあるあるな話なのですが、自分だけじゃないと知っておくことも大切です。

この記事が気に入ったらサポートをしてみませんか?