自動受け入れテストに関する実用的ヒント

同値分割、境界値分析、リスクベーステストのようなテスト技術は、何をテストして、いつテストを自動化するかを決めるのに役立つ。新製品を開発している時、最初はあまり自動化しないほうがよいだろうと、Adrian Bolboaca氏は主張する。Bolboaca氏は、すでに確立した製品をテストする時は、不具合が発生する部分で、より多くの自動テストを書くように提案する。

Mozaic Worksで、組織的なテクニカルコーチでありトレーナのAdrian Bolboaca氏が、ヨーロッパテストカンファレンス 2017において、様々な種類の自動テストについて話をした。InfoQは、このカンファレンスをQ&A、要約、記事で扱う。

自動テストの目的というブログで、Bolboaca氏は受け入れテストの目的を定義する。

受け入れテストは、通常、テスタが書き、システムの特定の機能を検証します。おかしなことに、大抵の人は、自動テストについて話す時に、受け入れテストだけに言及します。

受け入れテストは、モジュールレベル、モジュール間、システムレベル、システム間等で実施できます。モジュール間やシステム間(2つよりも多くのモジュールに注目している)の受け入れテストがある場合は、それは総合的なテストです。例えば、別のモジュールの上にあるGUIを通して、ふるまいにアクセスするテストは、総合的なテストです。このようなテストは安定性を欠き、GUIに依存します。これらは望ましいものではありません。

これらのテストは、第一に、製品担当者やスポンサー、第二に、テスタ、やっと第三に、技術チームの興味を引きます。

InfoQは、様々な種類のテスト、十分によい受け入れテストを書くこと、テストの自動化を決める基準、テスト自動化の適用方法と実行可能な仕様の作成方法について、Adrian Bolboaca氏に話を聞いた。

InfoQ:よいテストはどのように見えるべきですか?

Adrian Bolboaca氏:1つのテストは、はっきりと分かるものでなければなりません。テストの名前とその内容に始まり、なぜそのテストが必要か、どのように役に立つか、存在する目的は何かを、誰でも理解できるようにすべきです。このような理由で、受け入れテストは、短く、理想を言えば、技術的な言葉を含まないようにしましょう。例えば、「exception」という変数を使う代わりに、「error」という変数を使った方がよいでしょう。

数多くの小さな、独立したテストを持つことで、問題がどこで起きたかを見つけるのに役立ちます。しかし、そのためには、1つのふるまいだけに注目した、小さく、原子的なテストを書く必要があります。1つのテストで、多くのふるまいをテストした場合、それは、ユニットテストではありません。それは、結合テスト、受け入れテスト、総合的なテスト、エンドツーエンドテスト、または、他のタイプのテストになります。そして、もちろん、よいユニットテストは、最小1つ、最大1つの検証をすべきです。

InfoQ:総合的なテストと、受け入れテストやエンドツーエンドテストの違いは何でしょうか?

Bolboaca氏:まず、エンドツーエンドテストについて答えましょう。エンドツーエンドテストは、システムのより多くのモジュールが、一緒にうまく動作するかどうかを確認することを意図しています。このテストは、モジュールの小さなふるまいに注目してはいけません。技術的なテストであり、設定、セキュリティ設定、データベース接続、ウェブサイトへのリンク等が正しいかどうかを知るのに役立ちます。エンドツーエンドテストを見るのは、技術チームです。

受け入れテストは、機能に注目していて、主に、製品関係の人たちが見ます。これらのテストは、機能がうまく動くことを示す必要があります。製品関係の人たちは、機能を製品に配置する前に、受け入れるか、受け入れないかを判断するのに、これらのテストを利用します。受け入れテストはモジュールレベルで、複数のモジュールを通してもよく、また、システムレベルでもかまいません。それは、何を受け入れたいか、アーキテクチャがどのようになっているかによります。受け入れテストが大きくなればなるほど、メンテナンスするのは難しくなります。受け入れテストを持つコストは、そのサイズによって増加します。受け入れテストはモジュールに注目し、エンドツーエンドテストは一緒にうまく動作するかを見るために利用することをお勧めします。

総合的なテストは、2つ以上のモジュールを通り、より多くのモジュールの中の、小さなふるまいを確認するために使われます。総合的なテストは最悪です。変更が多く、各モジュールの小さなこと1つ1つに依存するからです。

多くのモジュールがあって、各モジュールに、確認しなければならないふるまいがいくつかあると考えてみましょう。

モジュール 1:確認するふるまいが16個
モジュール2:確認するふるまいが21個
モジュール3:確認するふるまいが36個

総合的なテストですべてのふるまいを確認したい場合、1つのふるまいを変更した時に、残りのふるまいは変更しないようにする必要があります。つまり、単純計算で、16×21×36 = 12096 の総合的なテストが必要です。これらのテストは、GUIや、実際のデータベースやシステムを使うから、動作も遅くなります。

もう1つのアプローチは、モジュール毎に受け入れテストを分離し、構成、「くっつけたもの」が正しいことを確認するために、いくつかのエンドツーエンドテストを書くことです。単純計算では、16+21+36=73 の分離した受け入れテスト + 2-10 のエンドツーエンドテストになります。私のアドバイスは、決して総合的なテストを使わないことです!

InfoQ:十分なよい受け入れテストを書くためのアドバイスはありますか?

Bolboaca氏:1つの特定の機能について、100%のカバレッジを持つことが何を意味するのかを分析することから始めるとよいでしょう。同値分割、境界値分析、ポジティブテスト、ネガティブテストのような技術を使いましょう。ユーザーがここで何をする必要があるのかという、ポジティブテストに最初に注目することは重要です。それから、うまくいかなくなることは何かというネガティブテストに注目します。

2番目のステップは、これらのテストのリストを作ることです。

私がお勧めする、3番目のステップはリスク分析をすることです。リスクとその影響の2つの軸で、各テストに目的を与えましょう。大きなリスクと強い衝撃を与えるものは、自動化する必要があります。このような場合にとても役に立つ、リスクベーステストについて、さらに学ぶとよいでしょう。

それから、4番目のステップは、テストを選んで自動化を始めます。テストは、小さくて、はっきりとしていて、ビジネスドメイン言語に注目したものしましょう。あなたがユーザーで、それらのテストを読んだ時に、理解できるかどうか想像してみましょう。

そして、5番目のステップは、同僚のテスタ、アナリスト、プログラマ、製品関係の人たちにレビューしてもらいます。

いつテストが十分になるかを知るのは、いつもバランスが難しいものです。重要なテストを忘れたり、余分なテストを追加したりすることがあります。そのような場合に、レビューのプロセスによりバランスをとることができます。2つの頭は1つよりもよいという原則をいつも使いましょう。チームは自分よりも賢いのです。

InfoQ:テストを自動化することを決めるために、どの基準を使いますか?

Bolboaca氏:先程言ったように、何を自動化するべきかを決めるのに、リスクベーステストをお勧めします。

また、他にもいろいろあります。

新製品を作っていますか? それならば、どのテストが必要で、それらのテストがどのように役立つのかを理解するまで、おそらくそれほど自動化する必要はありません。しかし、それが分かったら、以前の機能のテストを増やし、新しい機能はそのペースを維持する必要があります。2-5カ月で、チームがどこで間違い、リスクは何かについて、よく分かるようになるでしょう。

すでに確立した製品を持っていますか? それならば、過去からの知識を使い、どこで不具合が現れ、なぜそれが起こるかを見て、その分野で自動テストをより多く書きましょう。

新しいツール/フレームワークを追加していますか? さらに数個の自動テストを書きましょう。最初に間違えるのは分かっていますから。人々は、これらの間違いを不具合と呼びます :)

InfoQ:実行可能な仕様を作成するために、どのようにテストの自動化を適用しますか?

Bolboaca氏:第一に、テストは、技術的な言語ではなく、ドメイン特化言語を使うべきです。テストの名前は、製品関係の人たちや顧客が理解できるものにしましょう。

第二に、様々なグループの人たちが理解できるように、テストを分類する必要があります。そのため、1つのパッケージにユニットテスト、もう1つのパッケージに結合テスト、また別のパッケージに受け入れテストを分類します。