Exercise 2：自動化経験のないナンシーさんの悩み

　次のExerciseでは、「Test automation patterns wiki」にあるNancy Naive（経験不足のナンシーさん）というExerciseに取り組みます。

　まず、Wikiの説明を読み、Nancyさんが抱える問題を、以下の「Test Automation Issues Mind Map」のどの問題に該当するのかを見つけます。

　テスト自動化に取り組む際に突き当たる問題をまとめていくと、他の方も同じような問題を抱えている場合が多くあります。それらの問題をパターン化して整理したのが上記の図であり、ナレッジとして溜めていったのが「Test automation aatterns wiki」です。このWikiは、カンファレンス期間中の11月14日に書籍として発売されました。

　Wikiページには他のExerciseも含め、さまざまなコンテンツが掲載されており、テスト自動化に取り組まれている方や、これから導入を検討されている方にとって参考になる情報が多く掲載されています。

テスト自動化のパターン

　テストの自動化を進める上で重要なポイントをまとめたのが上記の図です。

　Execution、Design、Process、Managementの4つの区分があります。チュートリアルではこれらのパターンをケーススタディを交えて説明し、理解を深めていきます。その中から、印象に残ったものをいくつか抜粋してご紹介します。

独立したテストケース

　Designの区分にある「INDEPENDENT TEST CASES」は、「自動化されたテストは、独立したテストであるべき」という意味を指します。例えば、1つのテストでクラッシュしたとしても次のケースは実行できるべきであり、10あるテストの中でも、ある特定のテストを実行できる状態であるべきです。

　それを実現するために推奨されるのは以下のような考え方です。

• FRESH SETUP : テストの実行ごとにテスト環境をクリーンにする。例：
  • アプリを再起動する
  • 必要に応じたDB設定を行う
  • 必要なファイルをコピーし、ディレクトリに格納する
  • 実行環境を初期化する、など
• ONE CLEAR PURPOSE : 1つのテストで確認したいビジネス側面は1つであること
  • 開発しやすく、メンテナンス性も高く、最終的なバグが分かりやすいこと
• FAIL GRACEFULLY : 失敗するときも潔く
  • テストが失敗した場合は、システムと環境を復元して、連続するテストに影響を与えないようにする
  • クラッシュした時にはそのログやDBの状態を残しておく
  • テストが失敗した時にはアプリケーションを閉じる

テスト自動化のフレームワーク

　自動テストを導入するにあたり、大きな判断が必要となるのが、外部のツールを用いて自動テストを導入するのか、社内で自ら構築していくのかという部分です。

　改めて双方の良い点、悪い点を整理します。

外部のツールを用いる場合

• 自ら開発／メンテナンスする必要がない（ポジティブ）
• ツールでできることには限度がある （ネガティブ）

内製する場合

• 必要に応じて微調整することができる（ポジティブ）
• いつでも新しい機能を追加することができる（ポジティブ）
• Test Automatorのスペシャリストと、その工数が必要（ネガティブ）
• テストおよびテスト環境のサポート、管理が継続的に必要（ネガティブ）

　氏は、内製する場合に注意することとして以下の点を挙げています。

• チーム全体が要件を満たしていること
• メンテナンス工数についても計画され、予算化されていること
• ノウハウがチーム間で展開されていること
• 小さなものから始め、すべてをすぐに開発しようとしないこと

情報共有

　テストの自動化を進めるうえで、開発者、テストエンジニア、管理者など、関係者とのコミュニケーションは必要不可欠です。コミュニケーションは一方的ではなく、以下のように自ら与えるべき情報と、関係者から引き出すべき情報があります。そして、それら情報は相手の立場により異なります。

マネジメント

　「自動テストに何を期待しているのか？」を確認し、Automatorからは「自動テストで現実的にどんなことが提供できるのか」を共有すること。またテスト自動化プロジェクトの進捗状況を共有しておくことも重要となります。

開発者

　開発者の方が相手であれば、「彼らがどんなバグを見つけて欲しいと考えているか」を聞き、「新しいリリースでどんなことが変わったのか」も当然確認するべき情報です。逆に提供するべき情報としては、「どんな変更が自動テストに影響を与えるか」は伝えておくと良いでしょう。テストが失敗した情報を共有することも開発者にとって有益な情報になることがあります。

テスター

　相手がテスターであればどうでしょうか？ まずは自動化を行うテストケースについて、より詳しい情報は必要です。自動テストが変更される部分についての情報もどこまで必要か認識を合わせておくと良いでしょう。

　逆にAutomatorからは「どのようなテストが追加／変更されたのか」は共有し、実行結果はもちろん、実行結果の傾向もテスターにとっては有益な情報になるかもしれません。

Test Automotor

　当然ながらTest Automator同士では、「互いにどんな追加／変更を行っているのか」を共有し、彼らが必要な機能やフレームワークがないか引き出すことも重要です。

チュートリアルを終えて

　今回のチュートリアルは一日がかりでしたので、学んだことを挙げていくと今回のレポートでは書ききれないほど、大変多くの内容が詰まっており、非常に濃い時間を過ごすことができました。

　テスト自動化では、実際に進めていくと誰もが多くの問題に直面します。そんな時にAutomation Test Patternsから問題を整理し、ヒントとなる情報をWikiから見つけることで、そこから解決／改善に向けての気づきを得ることができるでしょう。

　また、これらのナレッジは、自動テストの歴史そのものです。欧米（特に英語圏の国々）は多くの情報が存在し、前述のWikiのようなサイトが誕生したのだと思います。そこからこのようなチュートリアルが開催されるようになり、さらに多くの自動化が進んでいきます。先人の知恵を活かしながら、課題を解決し、さらにそれを広げていく「Test automation patterns wiki」には、学ぶ点が多くあるように感じました。

　チュートリアルの最後には、無事に自動化認定ライセンスをいただくことができました。