TABOKガイド スキルカテゴリー2は、「テスト自動化の種類とインターフェース」です。
テスト自動化と一口にいっても、実は多様。自動化エンジニアは、おのおの得意分野以外の分野についても広く、基本的なことを知っておく必要があります。
2.1 テスト自動化の種類
TABOKガイドでは、テスト自動化を以下の4つに区分しています。
- ユニットテストの自動化
- 統合テストの自動化
- 機能システムテストの自動化
- 性能テストの自動化
カテゴリー2では、それぞれのテストの具体的な自動化の話より、それぞれのテストの定義・位置づけの意識合わせって側面が強いです。JSTQBの勉強をしたことのある人であれば、ほとんどはわかってる話ですね。
ただ、TABOKガイドって何だか怖いくらい一度も「ISTQB」という単語が出てこない。せっかくなので、TABOKガイドでの区分と、I/JSTQBのそれを比べてみましょう。ちなみにJSTQBの用語集はコチラ（PDF）。
ただ、TABOKガイドって何だか怖いくらい一度も「ISTQB」という単語が出てこない。せっかくなので、TABOKガイドでの区分と、I/JSTQBのそれを比べてみましょう。ちなみにJSTQBの用語集はコチラ（PDF）。
ユニットテスト(unit testing)の自動化
ユニットテストは、ISTQBで component testing・unit testing と言われているものと考えてよいでしょう。コードの最小単位の機能を検証するものです。重要な工程ですが、手動や目視ですべての入出力を確認するのは辛く、退屈。できる部分は自動化しましょう。
自動化で使うテストコードは普通、テスト対象のコードと同じ言語で書かれます。両者は同時にメンテされていって、ともにバージョン管理の対象となります。
自動化で使うテストコードは普通、テスト対象のコードと同じ言語で書かれます。両者は同時にメンテされていって、ともにバージョン管理の対象となります。
統合テスト(integration testing)の自動化
ISTQBのintegration testingと同じでしょう。
コンポーネント同士を統合して、それぞれが正しく動作すること、使いまわすパラメターやデータを壊さないことなどを検証します。
コンポーネント同士を統合して、それぞれが正しく動作すること、使いまわすパラメターやデータを壊さないことなどを検証します。
機能システムテスト(functional system test)の自動化
この「機能システムテスト」という訳は保留扱いとします。ガイドではこの言葉について、「functional」と「system」の両方の表現が入っていることが重要、とこだわっています。「機能テスト」でも「システムテスト」でもなく、「機能システムテスト」と呼びたい！と。
それが何を指すかというと、「テスト自動化といったときに多くの人が思い浮かべるテスト」とあります。統合テストとの違いは、機能システムテストが主に、要件に基づいてブラックボックステストを行うことにあるようです。統合テストはホワイトボックス。
それが何を指すかというと、「テスト自動化といったときに多くの人が思い浮かべるテスト」とあります。統合テストとの違いは、機能システムテストが主に、要件に基づいてブラックボックステストを行うことにあるようです。統合テストはホワイトボックス。
TABOKガイドとJSTQB用語集で対比してみると、
TABOKガイド : JSTQB
統合テスト : コンポーネント統合テスト (ホワイトボックス)
機能システムテスト : 機能テスト (ブラックボックス)
になるように思います。
JSTQBにおいて「コンポーネント統合テスト」は、テストレベルの1つである「統合テスト」の一つであるのに対し、「機能テスト」はテストタイプの1つなので、並べること自体おかしいかも知れませんが・・・。
JSTQBにおいて「コンポーネント統合テスト」は、テストレベルの1つである「統合テスト」の一つであるのに対し、「機能テスト」はテストタイプの1つなので、並べること自体おかしいかも知れませんが・・・。
性能テスト(performance testing)の自動化
上の3つと違って性能テストの主な目的は、欠陥の摘出ではありません。アプリケーションが性能要件を満たすことを確認するために、レスポンスなりスループットなりを測定するものですね。これは自動化なしには実現の難しいものが多いです。
性能テストと負荷テスト(Load Testing)とストレステスト(Stress Testing)は、それぞれ少しずつ異なるものとして説明されています。
ざっくり言うと、性能テストは性能要件を満たしていることの確認。負荷テストは、負荷を徐々に上げていって、想定される負荷の上限に耐えられることを確認。ストレステストは、上限OKを前提として、実際のところアプリはどこまでがんばれるのかを見る。という感じに区別しているようです。
ざっくり言うと、性能テストは性能要件を満たしていることの確認。負荷テストは、負荷を徐々に上げていって、想定される負荷の上限に耐えられることを確認。ストレステストは、上限OKを前提として、実際のところアプリはどこまでがんばれるのかを見る。という感じに区別しているようです。
2.2 アプリケーションのインタフェース
アプリケーションのインタフェース、つまり手動にしろ自動にしろ、どのように入力を行うかについて、以下の4つを挙げています。
- CUI（Command Line Interface）
- API（Application Programming Interface）
- GUI（Fraphical User Interface)
- Webサービスインタフェース（Web Service Interface）
CUIとAPIについては、多くのスクリプト言語が自動化のためのメカニズムをもっているため、自動化が容易としています。
GUIは、「エンドユーザの画面操作をコピーする」という手法自体は直感的にわかりやすいのですが、ツールをGUIと適切にやりとりさせることにまず難しさがあり、さらに、単なる操作コピーでは、画面設計が変わるたびにスクリプトのメンテナンスが発生するという問題を挙げています。
GUIは、「エンドユーザの画面操作をコピーする」という手法自体は直感的にわかりやすいのですが、ツールをGUIと適切にやりとりさせることにまず難しさがあり、さらに、単なる操作コピーでは、画面設計が変わるたびにスクリプトのメンテナンスが発生するという問題を挙げています。
それぞれの種類の自動化の、具体的な方法については、これ以降のカテゴリで説明されるでしょう。
