読者です 読者をやめる 読者になる 読者になる

>& STDOUT

主にソフトウェアに関する日々の標準出力+標準エラー出力

TABOK - テスト自動化のスキルカテゴリ 2, 3, 4

ソフトウェアテスト システムテスト自動化


http://www.automatedtestinginstitute.com/home/index.php?


前回に引き続きTABOKより。上記のサイトに12のスキルカテゴリというエントリがあったのでいくつかピックアップしてご紹介したいと思います。

  • Skill Category 2: Test Automation Types And Interfaces(テスト自動化の種類とインターフェース)
  • Skill Category 3: Automation Tools(自動化ツール)
  • Skill Category 4: Test Automation Frameworks(テスト自動化フレームワーク)

1〜7はテストリード向け、8〜12はテスト自動化エンジニアに向けたスキルセットらしいです。TABOK本編ではもう少し掘り下げられている事でしょう。大意を外さないように訳しているつもりですが、おかしい点があればご指摘お願いします。

Skill Category 2: Test Automation Types And Interfaces

テスト自動化の種類

よくある簡単な分類として機能(回帰)テスト、ユニットテスト、インテグレーションテスト、パフォーマンステストなどがありますが、これらはしばしば「自動テスト」と一纏めに呼称されています。もしあなたがこれら全ての専門家では無かったとしても、それぞれの自動テストの種類とその基本的な違いを理解しておくことはとても重要です。さもなくば、組織のすべての自動化作業に悪影響を及ぼす事があります。さらには、自動化のさまざまなタイプの最低限の知識を得ることで、あなたのスキル向上や新しい自動化の試みが容易になることでしょう。

テスト自動化のインターフェース

アプリケーションの自動テストに利用できる主なインターフェースは次のとおり

  • コマンドライン
  • アプリケーション・プログラミング・インターフェース(API)
  • グラフィカル・ユーザー・インターフェース(GUI)

GUIはユーザの実際の操作をシミュレートして自動テストを実装するためのインターフェースとして、恐らく最も有名なものでしょう。コマンドラインAPIはシンプルなテスト自動化のインターフェースとして優れています。

Skill Category 3: Automation Tools

テスト自動化の専門家はテストライフサイクルのあらゆる側面をサポートするツールへの洞察を提供する必要があります。これは各テストライフサイクルにおいてどんなツールが相応しいのかを理解するだけでなく、異なる種類のツールを適正に評価できなければならないことを意味します。

下記のような種類のツールが含まれます:

Skill Category 4: Test Automation Frameworks

自動化の範囲

自動化のコストは開発コスト、メンテナンスコストの両方で構成されています。通常、スクリプトが複雑になればなるほど開発コストが向上するため、自動化の範囲が広がるたびにメンテナンス性の重要さが増していきます。全体の自動化コストを削減するために、テスト自動化のフレームワークは総体において常に先進的である必要があり、それゆえに、テスト自動化に利用するフレームワークを選定する際には組織による明示的、暗黙的な要求を満たす必要があります。

ロールと責任

フレームワークはその構築や実装において下記の1つ以上のロールが関係します。

  • Team Lead
  • Test Engineer
  • Lead Automation Architect
  • Cross Coverage Coordinator
  • Automation Engineer (Automator)
  • Very often, one person may hold multiple roles.
ここは日本ではあまり馴染みのないロールが多かったので敢えて訳しませんでした。
Lead Automation Architect や Cross Coverage Coordinator っていうロールが
定義されていること自体がスゴイですね。
テスト自動化の3世代

長年にわたりテスト自動化はそれぞれの進化の段階についてその定義を議論されてきました。段階は概ね下記の三世代の観点から成ります。

  • 第1世代
    • 本書では「一般的なアプローチ」と読んでいます。これは主にレコードとプレイバックで駆動します。
  • 第2世代
    • 第2世代は第1世代から多くのことを学びました。この世代ではテスト自動化のフレームワークを伴い、それにはテストベッドにおけるテスト実行時の基本的なアクションをサポートする機能が組み込まれています。これらのアクションはときに独立して実行することが可能です。また、この世代はパラメータ化による自動化コードとテストデータの分離が特に進みました。
  • 第3世代
    • 第3世代は第2世代の概念の上に構築されています。それは機能分割に強く依存しながらも、各所でのテストコードの再利用性を高めるため、高レベルの抽象化を実現しています。これは、自動化コードからテストデータと特定のアプリケーション機能を独立させることで実現しています。
実はTABOKを学ぶ時に今更レコードとプレイバック(JSTQBではキャプチャ・プレイバック)を
切々と語られたらどうしようと思っていたのですが、この章で払拭されました。
ちゃんと世間の最新の自動化の概念を抑えてますね。…ってどんだけ上から目線だ。

設計の段階において、どの世代の自動テストフレームワークを定義するのかを決定しなければなりません。