全部テスト自動化ってできるの？～JSTQB TAEシラバスを読んで、テスト自動化を学んでみる Vo.6～ 1.1 テスト自動化の目的(5)

日本シリーズの最中で、なかなか自己研鑽に取り組めていないJimmyです。
オリックスバッファローズの試合結果も気になりますが、引き続き頑張っていきたいと思います。

はじめに

今回はJSTQBの1章のテスト自動化の制限について、見ていこうと思います。
タイトルでもありますが、テスト自動化はすべてのテストで導入できるのでしょうか。上の方からすべてのテストを自動化しろと言われることもあるかもしれません。

実際JSTQB TAEシラバスでは、テスト自動化には制限があるとしています。
今回はテスト自動化の制限そういう部分に着目して、読み進めていければなと思います。

【JSTQB TAEシラバス構成】
0.イントロダクション(完了)
1.テスト自動化の概要と目的
　1.1 テスト自動化の目的(←この続き)
　1.2 テスト自動化の成功要因
2.テスト自動化の準備
3.汎用テスト自動化アーキテクチャ
4.導入のリスクとリスクヘッジ計画
5.テスト自動化のレポートとメトリクス
6.手動テストから自動化環境への移行
7.TASの検証
8.継続的な改善

注意事項

・このシリーズの投稿は個人の意見であり、所属企業・部門見解を代表するものではありません。
・また、テスト自動化のエキスパートではありませんので予めご了承ください。

テスト自動化の制限

JSTQBシラバスでは、テスト自動化の制限は以下が含まれるとしています。

テスト自動化の制限①すべての手動テストを自動化にできない

テスト自動化の8原則の一つでもありますね。

【手動テストはなくならない】
ユーザビリティテストなど、そもそも自動化できないテストタイプが存在する。
システムに対してはじめて実行されるテストはテストケース自体の成熟度の観点から、手動で実施したほうがテスト実行の品質が高いケースが多い。
また、自動化がうまく進行している機能テストの残り数％など、テストを自動化するコストとベネフィットが釣り合わないケースもある。
これらの事情によって、手動で実施されるテストが無くなることはない。

この原則だと、1行目が今回の制限にあたると思います。
システムテスト自動化標準ガイドと知識ゼロから学ぶソフトウェアテスト【改訂版】では、自動化に向くテスト/向かないテストの一部を紹介しています。

＜自動化に向くテスト＞
・機能テスト
　┗結果が画面上で明白に示されるため、自動化しやすい
・性能テスト
　┗手動では実現が難しいものもできるので、手動より自動化の方が良い
・スモークテスト
　┗ソフトウェアの重要機能が動いているか否かを短い時間でチェックするテスト
・APIのテスト
　┗APIはそれほど変わらないため

＜自動化に向かないテスト＞
・ユーザビリティテスト
　┗見やすい、わかりやすいは自動化では判断できない
・ごくまれにしか実行されていないテスト
・テスト対象のソフトウェアが頻繁に変更される場合
・物理的なやり取りがあるテスト
　┗カードリーダーにカードを通す、何かの装置の接続を外す、電源をオフかオンにするなど

また、どのテストを自動化するか検討するには以下のような要因を検討する必要があるとしています。

・とても重要なテスト
・広範囲テスト(各システムの範囲を全体的にサンプリングするような)
・とても重要な機能に対するテスト
・手軽に自動化できそうなテスト
・最も早く見返りの得られるテスト
・実行頻度の最も高いテスト

テスト自動化の制限②自動化でチェックできるのは、ツールで解釈できる結果のみ

テスト自動化するためのツールはいろいろありますが、それでも、web画面の要素を取得できないものがあります。

例えば、以下のサイトを例に挙げると、赤丸部分の要素を取得できない場合があります。(HTMLのフォームバリデーションかな。。)
https://katalon-demo-cura.herokuapp.com/

そのため、手動テストで設定していた期待結果を変えて、実装する必要があります。
場合によっては、テストの目的が達成できない可能性もあります。

テスト自動化の制限③自動化によって、チェックできるのはあらかじめ定義された期待結果と検証可能な実行結果である

これもテスト自動化の8原則に入っていますね。

【自動テストは書いたことしかテストしない】
人間による手動テストは、テストケースの記述に対して驚くほど広範な要素を暗黙的にテストしている。
これに対し、操作、合否判定を厳密に記述する必要がある自動テストにおいては、おのずと視野は「記述された様に」限定される。
ユーザ名とパスワードを入力してログインする、といったテストが自動化されていたとして、その自動テストは仮にログイン画面に表示されているロゴが競合他社のものであったとしても、それに気づくことはない。

そのため、どの期待結果を採用するのかはステークホルダ全員の合意が必要になります。

テスト自動化の制限④探索テストを自動化に置き換えることは出来ない

私が好きなテストの一つですね。

【探索的テスト】
テスト担当者がテストアイテムや以前のテストの結果の知識や調査情報を使用して、テストを動的に設計、および実行するテストアプローチ
(ISTQB用語集)

WACATE2021Winterでも取り扱いますね。
まだ参加申し込みは締め切られていないはず（笑）

探索的テスト自体、繰り返して行うテストではないため、自動化をしてもコストがかかるだけで終わってしまいます。(自動化をする時間があれば、どんどん探索的テストを進めるはず。。)

終わりに

やっとテスト自動化の目的が終わりましたね。(笑)
ペースは遅いかもしれませんが、少しずつ継続的に続けたいと思います。

次回はテスト自動化の成功要因についてみていきたいと思います。(今度はnoteエディタの新機能を活用したいと思います。)
今日はこの辺で。

参考資料

・ISTQBテスト技術者資格制度 Advanced Level Specialist シラバス テスト自動化エンジニア 日本語版 Version 2016.J01

・ISTQB用語集

・システムテスト自動化標準ガイド

・知識ゼロから学ぶソフトウェアテスト【改訂版】

・テスト自動化の8原則