テスト自動化とテスト設計【前編】～作成済のテストケースの整理と加工

次で触れる作成済のテストケースを自動化するパターンとは違い、テスト分析やテスト設計時点で自動化に向いているところと手動実行に向いているところを分けて考えたり、自動化時の効率を考えてテストの設計を行ったりします。

興味がある方は、NPO法人ソフトウェアテスト技術振興協会が主催する「テスト設計コンテスト」決勝戦出場チームのプレゼン資料などを見ていただくと、おおまかなイメージがつかめるかと思います。

参考：ASTER-テスト設計コンテスト- テスト設計コンテスト’21 OPENクラス 決勝戦レポート

パターン2：作成済のテストケースを選んで自動化する

こちらは、手動実行のためにExcelやテスト管理ツールなどで用意してあるテストケース、つまりすでに作成済のテストケース（※以降、手動テストケースと表現します）の中から自動化対象を選ぶという方法です。

テスト自動化の経験がある、もしくは今まさにテスト自動化に着手しているという方は、多くがこちらの方法でおこなっているのではないでしょうか。

わたしがテスト自動化の普及をおこなう際は、パターン1を理想としてオススメしています。パターン2はテストを自動化する際はよいものの、作成した自動テストの運用を考えたときにいくつか問題があります。

しかし、これからテスト自動化を行おうという現場で「絶対にテスト設計からやり直してください！」と理想を押し付けてしまってはうまくいきませんし、組織内でさまざまな事情があることも理解しています。

そこで今回の記事では、理想的ではないけれども広く行われているであろうパターン2の方法について、問題を回避しながらなるべく無事にテスト自動化をするための考え方についてご説明します。

テストケースの整理と加工

手動テストケースを自動化する際には、テストケースの整理と加工が必要です。ここでは、何をテストするのかやどうテストするのかといったテスト分析やテスト設計にあたる部分を大きく変えずに、テスト自動化に向いたテストケース（※以降、自動テストケースと表現します）に変更をする、というニュアンスを表現するために「設計」ではなく「整理と加工」という表現をしています。JSTQBなどで用いられている用語ではない点にご注意ください。

手動テストケースを自動化に向いた形に整理・加工する際のポイントは以下です。

自動化可否判断と、自動化対象ケースの切り分け

ひとつめのポイントは、自動化可否の判断と、自動化可能なテストケースおよび自動化対象ケースの切り分けです。

手動実行用のテストケースの中には、コンピューターでの実行が難しいものが含まれるため、まずは「この操作・確認が含まれている部分は自動化できない」という点を挙げ、自動化対象から外します。

• 物理機器の操作を伴う手順
• 電源のOFFを伴う手順
• 実行のたびに正解が変化し、人間でなければ成否の判別が困難な結果

などが代表的な例です。

まずはこうした自動化困難なテストケースを切り出し、大きく「手動で実行するテスト」と「自動化の可能性があるテスト」とに分け、後者に対してこのあとの整理・加工を行います。

手順や期待結果の具体化

ふたつめは、手順や期待結果の具体化です。人間が暗黙におこなっていた操作手順や確認をコンピューターに行わせるため、細かいところまで具体化する必要があります。

ダメなテストケースの例としてよく挙げられる「結果が正しいこと」という記述などはもちろんとして、他にも

• 特定の画面に遷移したことを、何をもって確認するか
• 「メッセージが表示されること」という期待結果において、具体的なメッセージ内容は何か
• 表示文字列の確認は完全一致か、特定の文字を含んでいればよいのか
• 「検索をおこなう」という操作を、ヘッダーからおこなうかメニューからおこなうか
• 用いるテストデータに隠れた条件はないか

などを具体化する必要があります。

細かく見ていけばキリがありませんが、人間が実行していれば”察して”実行できていたところも、コンピューターで自動実行できるようにしなければなりません。

手動テストケース全体を見て、自動化するうえであいまいなところ、人によって方法が異なりそうなところがないかを確認するところからはじめましょう。自動化を担当するメンバーを集めて「自動化に向けたテストケースの確認会」を開催し、皆で手動テストケースを見ながらコメントしていくような場を設けるのもよいでしょう。前項の自動化可否判断・対象ケースの切り分けも、時間が許せばあわせて実施できます。

なお、手動テストケースの文面をすべて確認して一箇所ずつ詳細な記述に修正していく、というのは手間がかかりすぎるためオススメしません。それよりは、自動化時のルールを別で用意して「画面遷移の確認はココで判断」「よく出てくる操作はこの方法で」など記載しておくほうがスムーズに行えるでしょう。

テストケースの粒度の整理

もうひとつは、テストケースの粒度、構成などの整理です。

わたしがこれまで見てきた限りでは、自動テストケースよりも手動テストケースのほうが粒度が細かい傾向にあります。

たとえば、以下のログイン処理に関する手動テストケースについて考えてみましょう。

ログイン処理に関する一連の流れの中で、6つのテストケースを実行するように作られています。

では、このテストケースを自動化する場合、6つの自動テストを作ればよいでしょうか？

たとえばケースNo2と3、およびケースNo4と5は、上記のテストケースではそれぞれ1セット、連続して実行するように作成されています。これらのテストケースをケースNo每に分けて自動化する場合、ケースNo3の手順の前にログイン画面への遷移処理を入れるなどの修正が必要になります。

そのため、一般には以下のように複数のケースをまとめて、自動テストにおける1ケース、とする場合が多いでしょう。

ここまではごく単純な例なので当たり前のように感じられるかもしれません。しかし、実際のテストケースを自動化向けに整理する際は、もう少し複雑な変更が必要になることもあります。

たとえば上記のテストケースで、さらにケースNo2と3をまとめることも可能です。しかし、そうすると今度は自動テストの1ケースが長くなるのが問題です。一般的に、自動テストの1ケースが長くなると、バグがなくともテストが失敗する可能性も高まります。途中でテストが失敗すると、以降の期待結果の確認が行われず、結果的に手動での再実行が必要になることもあります。

そのため、「テストケースをまとめて、実行効率を高めること」と「テストケースを分割し、バグ以外の原因で失敗する可能性を減らすこと」との間でうまくバランスをとることが大切です。

テストケースの依存関係の整理

テストケースをまとめる以外にも、決まった順番でテストを実行する必要があるところを除く、つまり依存関係をなるべくなくすことも考えなければなりません。

手動でのテストを設計・実行する場合には、なるべく同じ手順を何度も行わなくていいような工夫をするものです。たとえばデータの新規登録・編集・削除という3つの機能についてテストをする場合、これらは一連の手順として実行するようテストケースを作成するでしょう。

つまり、

• ケース1：データAを新規作成
• ケース2：データAを編集
• ケース3：データAを削除

といった形です。

これをそのまま自動化した場合、どんな問題があるのでしょうか。

ひとつは、ケース1でなんらかのバグがあり、実行に失敗した場合。ケース2とケース3も自動テストは失敗してしまいます。手動テストであれば、「別のデータを使ってケース2と3を実行しよう」といったその場での対応が可能ですが、自動の場合はそうはいきません。

このように、手動実行を効率よくおこなうためにテストケースどうしに依存関係を持たせたり、決まった実行順序を前提とした作りにすることは、自動化した際にかえって効率が悪くなることがあります。

自動テストは、実行環境を複数用意して並列に実行させることで時間短縮ができます。そのため、テストケース間の依存関係はなるべくなくし、独立して・任意の順番で実行できるような作りが望ましいでしょう。

そのためには、たとえば

• 事前準備：データB, Cを登録
• ケース1：データAを新規作成
• ケース2：データBを編集
• ケース3：データCを削除

のように、テスト実行前につど必要なデータを登録し、そのデータに対して処理をおこなうなどの対応が有効です。

自動化の前のひと手間で、失敗・手戻りのリスクを抑えましょう

手動テストケースをそのまま自動化してもうまくいかない場合が多く、自動化に適した形に整理や加工をおこなう必要があります。

整理や加工は、まず自動化不可もしくは困難なテストケースを除いたものに対して

• 手順や期待結果の具体化
• テストケースを適切な粒度で統合
• テストケースの依存関係をなくす

ような工夫をおこなうこと、です。

手動テストケースをもとに自動化しながら上記の整理・加工をおこなってしまうと、手戻りが多くなったり、自動化したテストが非効率的になったりします。

そのため、事前に手動テストケースから自動テストケースへの整理・加工を行ったうえで、自動化に着手しましょう。

ただし、本記事冒頭でも述べたように、これは理想的な手段ではありません。できるだけ、テスト設計やテスト分析など、より前段階から自動化を前提としたテストを考えるのが理想です。この方法については、次回の記事でご紹介予定です。

参考

• テストを自動化するのをやめ、自動テストを作ろう – Speaker Deck
• JaSST nano vol.3 #4「初級自動化エンジニアが考える自動テストのためのテストケース加工」 – YouTube

連載一覧

テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか
テスト自動化ツールの選定【後編】～AI自動テストツールを選ぶ時に気をつけるべきポイント
テスト自動化の普及と推進【前編】～阻害要因と対策
テスト自動化の普及と推進【後編】～個人レベルでテスト自動化を学ぶ
テスト自動化とテスト設計【前編】～作成済のテストケースの整理と加工
テスト自動化とテスト設計【後編】～テスト自動化のためのテスト設計