開発スケジュールに余裕の少ない今日のシステム開発現場では、テスト工数の増大は大きなリスクとなります。システムの品質を担保しつつ納期を厳守するために、開発部門やQA部門が取り組むべき重要課題は、「テスト自動化」による工数削減です。

連載第2回では、テスト自動化の実現方法である「エンジニアの人手」「テスト自動化ツールの利用」についてそれぞれ解説しました。詳しくは、前回の記事をご一読ください。

開発・QA現場向け「テスト自動化」のススメ　【第2回】：テスト自動化の実現方法

しかしテストの種類は多岐にわたり、常に同じ方法で自動化できるとは限りません。テストは大きく分けると「テストレベル」「テストタイプ」の2つにより分類されます。実施するテストの種類によって、自動化に適した実現方法は変わります。

テスト自動化を実現する上で、テスト種類ごとに適した自動化方法を把握することが重要です。そこで第3回となる本記事では、各テスト種類の特徴や自動化の実現方法についてご紹介します。

テストレベルによる分類および自動化方法

「テストレベル」とは、テスト対象となるシステムの範囲や粒度を指します。テストレベルにより分類した場合、テストの種類は下記の通りです。

　・単体テスト
　・結合テスト
　・総合テスト (システムテスト)
　・受け入れテスト

ひとつずつ、テスト種類の特徴や自動化方法を解説します。

単体テスト

単体テストでは、プログラムにおける関数・クラスといった個々のコンポーネントがテスト対象となります。条件分岐などの制御が正しく行われることを検証する必要があり、プログラムの内部構造に着目するのが特徴です。一般的な開発プロセスでいえば、詳細設計の内容に対応しています。
テスト自動化ツールの多くは、プログラムレベルでのテストをあまり得意としていません。したがって、エンジニアの人手により自動化していくことが一般的です。多くの場合OSSの単体テストツールを使用しますが、基本的にテストプログラムをエンジニアが記述する必要があります。

結合テスト

結合テストでは、複数コンポーネント間におけるインタフェース部分がテスト対象となります。データの受け渡し (入出力値) や、複数コンポーネントの連携動作が基本設計 (概要設計) 通りかを検証するのが主な観点です。基本的に、単体テストが問題なく完了した後に実施されます。
データの受け渡しはプログラムレベルでの確認が必要となる場合が多いため、単体テスト同様に人手による自動化が適しています。一方で連携動作の確認には、『ADOC Testing Service (ATS) for Eggplant』などのテスト自動化サービスの活用が有力です。VNCやRDPといった技術により、異なるデバイス間の結合テストでも非侵襲的なテスト実行が可能となります。

総合テスト (システムテスト)

総合テスト (システムテスト) では、すべてのコンポーネントやサブシステムを含むシステム全体がテスト対象となります。システムの動作が要件定義で決められた要件を満たすことを確認するのが主な内容です。総合テストを実施するためには、結合テストをすべて完了している必要があります。
総合テストではシステムの画面操作や表示確認が発生するため、テスト自動化ツールの活用が効果的です。操作内容を記録して再現するツールや、AIにより結果確認が行えるツールを用いれば、大幅な工数削減に加えてテスト品質の向上も期待できます。前述したATS for Eggplantでは、AIの活用により高精度なバグの自動抽出や結果確認が可能となります。

受け入れテスト

受け入れテストでは、総合テストを完了したシステムがテスト対象となります。総合テストと異なるのは、クライアントのニーズを満たしているかを実運用に近い環境で確認する点です。クライアント側での実施が一般的ですが、最近では総合テストと併せてシステム開発側で実施するケースも増えています。
自動化の実現については総合テストと同様、テスト自動化ツールが適しています。ATS for Eggplantなどの適用により、メインフレームからスマートデバイスまであらゆるデバイス・OS・ブラウザの連携が容易となり、実運用に近い環境を構築できます。

テストタイプによる分類および自動化方法

「テストタイプ」とは、テストの目的や観点を指します。テストタイプにより分類した場合、主なテストの種類は下記の2つです。

　・機能テスト
　・非機能テスト

ひとつずつ、テスト種類の特徴や自動化方法を解説します。

機能テスト

機能テストでは、システムの動作が機能要件を満たしているかどうか確認します。主な内容は、要件定義書や要求仕様書に明記された機能項目の確認です。テストの粒度としては、結合テストにおける連携動作の確認や総合テストに近く、主にユーザーから見える部分の確認となります。
そのため、テスト自動化ツールの活用による自動化が適しています。エンジニアの人手による自動化のように、多くのテストプログラムを記述する必要がありません。また、システムの変更が既存機能に影響しないことを確認する「回帰テスト」でも、テストケースのメンテナンスの省力化が期待できます。

非機能テスト

非機能テストでは、前述した機能要件に当てはまらない非機能要件を確認します。非機能要件は多岐にわたりますが、主なテスト種類は下記の通りです。

クライアントから非機能要件が明確に提示されることは少ないため、合否の判定基準は多くの場合システム開発側で定める必要があります。非機能テストは明確な判定基準の定義や結果の確認が難しく、特に自動化が困難なテスト種類です。ほとんどのテスト自動化ツールが、非機能テストの自動化を苦手としています。
機能テスト・非機能テストの自動化を両立させる解決策として有力なのは、ATS for Eggplantの適用によるテスト自動化です。従来の自動化アプローチと異なる画像認識をはじめとしたAI技術により、目視では難しい表示の判断が高精度に行え、操作遅延などの異常も検出できます。また「探索的テスト」の自動化により、テスト実行と並行してテストケースの自動生成が可能です。テスターの手作業では再現困難なユーザー体験 (UX：User eXperience) を網羅し、ユーザビリティテストの自動化を容易にします。
ユーザビリティにおいて最も留意すべきポイントのひとつは、昨今の製品やサービスを実際に利用するユーザーには、それぞれ固有のユーザー体験が伴う点です。ATS for Eggplantの場合は、再現が難しいUXレベルの検証が行えます。そのため、開発者やテスターが思いもよらないユーザージャーニーの実行を通じて、飛躍的なサービス品質向上に寄与します。

その他のテストタイプ

その他、重要な2つのテストタイプについても解説します。

ホワイトボックステスト

主に単体テストや結合テストの一部として、プログラムの内部構造を確認するためのテストです。基本的な機能や制御フロー、データフローなどが意図した通りとなっているかを確認します。一般に、カバレッジ (網羅性) やテスト手法を意識してテストケースを作成することが重要です。ホワイトボックステストで見つけるべきバグが見逃されると後工程への影響が大きいため、品質を担保する上で重要なテストとなります。

ブラックボックステスト

主に総合テストや受け入れテストにおいて、システム全体の入出力や仕様に照らした動作の確認を行うテストです。ホワイトボックステストのようにプログラムの内部構造には着目せず、多くは開発者以外 (第三者検証含む) によって実施されます。ブラックボックステストを人力のみで実施することには限界も多く、テスト自動化の適用によって効率的にテスト領域を拡大し、品質向上へ取り組むケースが増えつつあります。

テスト自動化の導入における課題とは？

今回は自動化可能なテストの種類や、それぞれにおける自動化の実現方法について解説しました。自動化を実現する上で、テストの種類に合わせて適切な自動化方法を選択することが重要です。またテスト自動化を適用する場合は、幅広いテスト種類をカバーできるツールや導入サービスの選択により自動化の範囲を拡大でき、そのメリットを初めて享受できます。

テスト自動化は、開発サイクルの短い現代の開発現場では積極的に適用すべき取り組みです。しかし従来のテスト自動化の手法や自動化ツールの適用には課題も多く存在します。実際の開発現場ではあまり適用が進んでいない、もしくは適用しても期待した自動化の効果が得られないなどの現状があります。次回はテスト自動化の障壁となる課題について考察したいと思いますので、ぜひご一読ください。

■ ADOC Testing Service for Eggplantの概要へ
■ ADOC Testing Service for Eggplantの資料請求へ

• 開発・QA現場向け「テスト自動化」のススメ