2018年6月14日 / 最終更新日時 : 2020年9月3日 user 事例・ソリューション

プログラミングスキルなしでテストを自動化する方法 – 準備編

テストの自動化は、テスターの作業を効率化し、生産性を高めると考えられています。また、特定のシナリオのほぼすべてを自動化すると、テストカバレッジが大幅に向上することも知られています。特にプロジェクトチームやリリース規模が大きい場合、テストの自動化はプロジェクトスケジュールを間に合わせるために必須と言ってよいでしょう。

しかし、市場に提供されているテスト自動化ソリューションは、誤った認識を持たれるようになりました。多くのソリューションは、利用者がプログラミングおよび開発経験やスキルセットを持っていることを前提としています。しかし、そのようなスキルセットを持っている、あるいは身につけたいという手動テスターは多くありません。現在では、手動テスターと自動テスターは別の職種であり、2者の間には区別があるのです。（訳注：欧米では異なる職種であるため、スキルセットも異なります）

これら2つのロールを橋渡しするには、なにが必要でしょうか？どうすれば自動テスターは手動テスターから、より有用な情報を受け取れるでしょうか？どうすれば手動テスターは自動化に貢献して生産性を高められるでしょうか？それには、自動化の構造とフレームワークを理解することから始めなければなりません。

手動テスターが実際に自動化されたテストケースを作成するかどうかにかかわらず、いくつかの重要ポイントを理解するだけで、すぐに生産性を改善できます。手動テスターがすぐにテスト自動化に貢献できるキー領域とは何でしょうか？

今回を含め全3回の記事で、テスト自動化作業で重要な3つの領域について、1つずつ説明します。3つの領域とは、準備、実行、分析です。各領域には、3つの重要ポイントがあります。それについては、今後詳しく説明します。

はじめに
テスト自動化の領域
テストプロセスの計画にテスト自動化アクティビティを組み込む
自動化をデータ駆動するためのデータシートまたはSQL文を作成する
既存の手動テストを編集して自動化に利用する
次回に向けて

はじめに

このブログ記事は、既にある程度のテスト自動化が行われているという前提で書かれています。これまで、テストの自動化は開発アクティビティであるという認識が一般的で、手動テスターが貢献できる領域とは明確に理解されていないのが普通です。
手動テスターは技術的スキルは持っていても、開発やプログラミングのスキルはありません。しかし、この記事で説明するとおり、手動テスターがテスト自動化プロセスに貢献できる方法はたくさんあります。

たとえば、テスト自動化エンジニアにとっては、要件やテストドキュメントを入手するのが難しいという問題がある一方、機能テスターにとっては、手動テストケースと同じ条件を満たす自動テストを作成するのが難しいという問題があります。
その他のキーとなる前提としては、大部分のテストアナリストは、依然として手動テストに携わっているという点があります。テストアナリストが自動化に携わっているとしても、この後説明するとおり、完全にテスト自動化チームに所属しているわけではありません。

テスト自動化の領域

ここでは、手動テスターが自動化に着手できる3つの領域について概要を説明します。準備、実行、分析の各領域に、手動テスターがすぐに貢献できる3つの固有のセクションがあります。このブログ記事は、1つ目の領域である「準備」を取り上げます。

テストプロセスの計画にテスト自動化アクティビティを組み込む

QAチームがテストプロセスを定義するとき、テスト自動化はプロセスに組み込まれていないことがほとんどです。開発手法は、アジャイル、ウォーターフォール、その他のソフトウェア開発手法です。たいていは、手動テスターにとってはこれで十分です。多くの場合、テスト自動化アクティビティは手動プロセスに組み込まれることはありません。アクティビティの対応を図式化するには、単純なV字モデルが使用されます。このアクティビティ計画では、アジャイルとウォーターフォールを区別する必要はありません。

プロジェクト開始 – テスト戦略

QAリリースリーダーは、各自のリリースにテスト自動化アクティビティを含めることが推奨されます。テスト自動化アクティビティが長引いてもプロジェクトのスケジュールに影響がないと考えるのは非現実的です。テストケースの作成または実行に必要なテスト自動化アクティビティをリスト化し、リリース/マスターテスト計画、またはテスト戦略文書に記載すると、プロジェクトマネージャー/プロダクトオーナーは、特定のリリースでどのような自動化が計画されているかを知ることができます。

分析 – テストシナリオ

手動テストアナリストは、プロジェクトの分析フェーズでテストシナリオまたはテスト目標の原案を作成する際、シナリオを手動シナリオと自動シナリオに分けるべきです。プロジェクト関係者は目標を確認し、おのおの結果を出すために計画を立てます。

設計 – テストケース

通常、手動テストケースは、自動化に必要な特定のエラー処理条件を満たしていません。テストケースを準備する際に、この点を考慮しておくと、手動テストケースを自動化に流用することができます。

開発 – テストスクリプト

手動テストケースを作成する場合と同じ原則に従って自動テストケースを記録します。操作するオブジェクトをすべて認識できるよう、ゆっくりと記録します。

テスト – テスト結果

手動テストケースの実行とは異なり、自動テストを実行する場合、テストを何回か再生し、期待通り実行されるまで微調整や修正が必要な場合があります。

デプロイ – テストサマリー

テストシナリオ文書と同様に、自動テストケースと手動テストケースで実行された内容をリスト化します。この情報は、デプロイメントの前にテストサマリー文書に記載されます。

自動化をデータ駆動するためのデータシートまたはSQL文を作成する

多くの場合、テスト自動化担当者はテスト対象アプリケーション(AUT)に関するドメインエキスパートではありません。機能テスト自動化アナリストは、UIだけでなく基盤となるデータベースのテーブルやフィールドを理解しています。自動テストで動的データを使用するために機能テストアナリストの知識を活用することは、すべてのチームメンバーにとって利益になるでしょう。

また、テスト自動化アナリストが従う典型的なプロセスを理解することは、機能テストアナリストにとって重要です。これを知ることによって、どのようにテスト自動化テストケースが構成され、どのような場合に動的データ要素が必要とされるかについて、共通の理解が生まれます。これは3つのステップからなるプロセスです。

データ駆動する対象について変数を作成する

自動テストケースが選択する値、または特定のフィールドに入力する値があります。データソースによって駆動されない場合、それらのデータは静的であるか、ハードコードされています。テスト自動化担当者は、元のデータの代わりに変数を作成し、静的データが動的データに置き換えられるようにします。

データソースとデータの所在をリンクする

データは一元化された安全な場所に保管されるべきです。また、リレーショナルデータベース(RDBMS)、Excelシート、CSVファイルなど、さまざまな形式のデータをリンクできるようにするべきです。機能テストアナリストは、最も扱いやすいソースを選択するべきですが、なるべくすべてのデータ駆動テストで同じデータソースを使用します。別のデータシートまたはテーブルにあっても構いませんが、テスト自動化担当者が使用するコネクタは同じであるべきです。

データソース列と定義済み変数をマップする

フィールドおよびデータソースに対応する変数が定義されたら、データソースのフィールドと変数フィールドを接続するのは簡単なはずです。データ要素を正しくマッピングするために、この操作は必須です。

既存の手動テストを編集して自動化に利用する

たいていのQAチームには、自動化したい手動ケースが、何千とはいかないまでも、何百という単位であるでしょう。しかし多くの場合、それらのテストケースは、自動化に適した形式で作成されてはいません。機能テストアナリストは、あらゆるテストケースを編集しなければならないのかと心配する必要はありません。編集の対象としてフォーカスするべき領域は2つしかありません。つまり、テストステップとテストデータです。この段階では、テスト結果は重要ではありません。

テストステップ

テストステップは、レコーディングされるステップ、またはテスト自動化アナリストがコードによって作成するステップにそのまま相当します。すべてのステップを説明する必要があります。自動化担当者が次に何のステップを実行するかわかっていると仮定するべきではありません。また、通常の手動テストケースで使用される表現方法は、自動テストケースには必要ありません。キーワード駆動自動フレームワークを使用する場合、表現を制限するほうがよいでしょう。

たとえば、手動テストケースには次のように表現されたステップがあるかもしれません。

Cityフィールドをクリックし、つぎの州を入力する: Florida

自動テストケースでは、同じ機能ステップを次のように表現できます:

アクション -イベント -オブジェクトまたはリポジトリアイテム
マウス -クリック -CityEditBox
KeySequence (入力) -Florida

テストデータ

前のセクションで説明したとおり、データ駆動テストがベストプラクティスです。開発コードの中では、絶対に必要な場合を除いて、データのハードコーディングは避けるべきであるのと同様に、テストコードでもデータのハードコーディングは避けるべきです。もちろん、静的データ要素を使用するほうが有利な場合もありますが、全体としては、外部データソースを使用するほうがメンテナンスが容易です。この場合、チームメンバーが共同で責任を持ちます。テスト自動化アナリストはハーネスをメンテナンスし、機能テストアナリストはデータをメンテナンスします。

テスト結果

これが編集とメンテナンスが必要なステップとして挙げられていない理由は、テスト自動化ソリューションが、テスト実行のすべての結果を提示してくれると期待して構わないからです。テスト自動化ソリューションはより信頼性の高い情報ソースであるだけでなく、より意味のあるデータを提供します。テスト計画情報とテスト結果を分離するのがベストプラクティスです。通常、テストステップまたは検証が失敗した場合、赤いフラグか失敗したテストの結果が表示され、すべてが期待どおり処理された場合は緑のフラグが表示されます。