実はかなり重要な章です
こんにちは。『システムテスト自動化 標準ガイド』第9章の翻訳を担当した松木です。第9章のタイトルは「その他の課題」と一見ぞんざいな印象を受けますが、この章にはまだこれといった標準が確立していない、さまざまな（そして、案外クリティカルな）課題とその解決案が提示されています。本稿ではその中から、いくつかを抜粋してご紹介します。
これらの課題に対するより良い解は、もしかしたら、これを読んでいるみなさまの現場に転がっているかもしれません。ぜひ「自分だったらどうするか？」を念頭に置きながらご参考いただければ幸いです。
どのテストから自動化するべきか？
いきなり非常に興味深いテーマです。実際に現場で自動化に取り組まれる際にも、比較的早期に課題となることが多いでしょう。ギア本の第9章では、テストタイプから見た優先度と、さらに機能テストにおけるテストの属性から見た優先度が紹介されています。
- とても重要なテスト※重要なテストタイプ
- 広範囲テスト（各システムの範囲を全体的にサンプリングするような）
- とても重要な機能に対するテスト※機能テストの中で優先度の高いテスト
- 手軽に自動化できそうなテスト
- 最も早く見返りの得られるテスト
- 実行頻度の最も高いテスト
（『システムテスト自動化 標準ガイド』9.1.3項より抜粋）
ギア本ではこれらに優先度をつけていませんが、あえて実感を述べるとするなら「広範囲テスト」が再優先でしょう。一般的に「スモークテスト」と呼ばれるテストタイプで、この種のテストは他に挙げられた属性のうち、「とても重要な機能に対するテスト」を同時に満たしている可能性が高いです。
重要な機能に対するテストは「最も早く見返りの得られるテスト」でもあります。スモークテストは実行コストさえ抑えられるなら、深刻なデグレードを防止するために極力数多く実行したいテストですから、「実行頻度の最も高いテスト」という属性も同時に満たすことになります。
逆にいえば、このような副次的な効果を狙いながらスモークテストを設計し、それを自動化することが、最も「手っ取り早い」成果を狙えることでしょう。
コラム：フィージビリティ・スタディとは？
テストの⾃動化に本格的に取り掛かる前に、必ず経ておかなければならないフェーズが「フィージビリティ・スタディ」です。これはプロジェクトを開始する前に、⼩規模で技術的実現性を検証する活動で、テスト⾃動化プロジェクトにおいても、⾃動化対象のソフトウェアが想定するツールで本当に操作、判定できるのか事前の検証が必要となります。
この検証で利⽤するテストスイートのサブセットとしても、「広範囲テスト」は⾮常に有効です。数あるテストケースの中から、なるべく広い範囲をカバーするように抜き出された、いわば「テストケース⾃体に同値分割を適⽤した」セットですので、テストスイートに登場するテスト⼿順や期待動作を粗くカバーできることが期待されます。
テストの分割と実行順序
作成した自動テストが仮に1000件あったとして、自動テストはどのような単位で実行されるでしょう。まさか1000件を1単位として、シーケンシャルに実行することはないと思います。では、どのように単位を考えればよいのでしょうか。ギア本では次のような単位が述べられています。
- 1ケースごとに独立して実行
- 特定のビジネスプロセスを一通り実行できるように
- テストレベルごと、ユニットテストから順に
- サブシステムごと
- テストタイプごと
- 実行時間ごと
- 前回失敗したテスト
ギア本でも述べられていますが、この中でも特に有効な単位は最後の「前回失敗したテスト」です。前回失敗したテストはその性質上、そうそう間を開けずに再実行される可能性が高いからです。
次点としては「サブシステムごと」が挙げられます。自動テストが開発される時期にもよりますが、仮に開発途中から実現できた場合、五月雨式にリリースされてくるサブシステムに対してタイムリーに自動テストを割り当てることができるのは魅力的です。
逆に、開発の後半になると「特定のビジネスプロセスを一通り」のセットの価値が相対的に高くなっていくでしょう。
次の課題は「セットをどのような順番で実行するか」です。優先して実行すべきセットは開発やテストの状況にも依存しますが、ギア本では比較的どのような場面でも有効≒優先すべきセットの構成が挙げられています。
最上位のセット、第1階層は極力広範囲をカバーする、いわゆる「浅く広く」テストが行き届くように設計されたテストセット。通常成功することが期待される、テストの現場によっては「ド正常系」とも呼ばれるセットです。ここから、第2階層、第3階層と、テストの粒度を小さくしていきます。前述の「ド正常系」に対応させるなら「正常系」、「準正常系」（第2階層）、「異常系」（第3階層）といった具合です。
この構造の優れた点は、第1階層で何らかの不具合が発見された時点で、第2階層以降を省略できる可能性があることです。なぜなら、製品の最も一般的な機能がまともに動作しない状況でより詳細な部分の検証を行っても、今後の主となる機能の修正によって細かい振る舞いが変わってしまう可能性が高いからです。このような理由から、とくに自動テストに限ったことではなく、ある程度習熟したテストリーダーであれば手動テストであっても、上位のサブセットから設計、実行されるように計画することでしょう。
テスト結果分析？
自動テストでFailが検出されたとき、そのままバグ管理システムに起票するでしょうか？ 詳細に設計されたテストケースであれば可能な場合もあるかと思いますが、やはり一度人間の目で確認しにいくことになるでしょう。
ただし、1件2件であればいいのですが、自動テストが波に乗り出すと、実行されるテストケースも100件、1000件、5000件とどんどん増加し、それにともなって検出されるFailの数も比例して増加していきます。
「100件、200件と検出されたFailが起票するに値するバグなのか？」を調査する活動を、自動テストの運用フェーズにおける「テスト結果分析」と呼びます。ギア本では「実行されるテストケース数と比例してテスト結果分析にかかる時間が増加する傾向は危険」と警告されています。前述の自動テストの構造化はこの分析時間をリニアに増加させないための対策としても非常に有効です。
自動テスト容易性を高める設計
テスト自動化エンジニアにとって、操作する・判定するためのインターフェースが対象ソフトウェアにどのように搭載されているかは死活問題です。WebアプリケーションであればID属性、AndroidやiOSのアプリケーションであればアクセシビリティラベル、といったある画面における部品が一意に指定できることが、自動テストの実現容易性、保守性、可用性に直結します。
自動テストもプログラムですので、画像を認識するよりは文字列を読むほうが得意です。自動化エンジニアの多くは、できることなら「判定」は文字列で行いたいと望むことでしょう。ギア本ではさらに、テストの実行中に対象ソフトウェアの「中間状態」を取得できるような設計が望ましいと述べられています。最もシンプルな「中間状態」の出力は動作ログでしょう。
そのほか、データの送受信の直前に、ソフトウェアがそのデータを「どのような形で解釈しているか」を示す情報や、ある振る舞いが内部的に成功したのか／失敗したのかを示す情報などに、自動テストからアクセスできると幸せになれます。
このような大量の情報を出力する構成の製品は、パフォーマンステストなどには向きませんが、機能テストの範囲であれば、自動テストのみならず、バグ報告の付帯情報とすることもできますし、何よりデバッグを行う開発者自身の大きな助けになることでしょう。
まとめ
今回は第9章で取り扱っている多彩なテーマの中から、比較的現場で実践しやすいテーマに絞って紹介しました。この他にもテストのステータスの扱いや、自動テストのモニタリング、ツール活用のためのテーラリング手法など、興味深いテーマが満載ですので、よろしければ本書を手にとり読んでみてください。
