The HIRO Says

If you smell what The HIRO is cooking!!!

DZoneの自動化テストのガイドブックを読んでみた

テスト自動化 Testing TDD CI CD DevOps

海外の知人からの紹介で、『DZone's 2019 Guide to Automated Testing: Facilitating Continuous Delivery』というガイドブックを読んでみました。

2019年版とちょっと古めではありますが、

  • 2021年の現時点でも、実務で参考になる／役立つ点が多かったこと
  • 日本国内で、同ガイドブックのまとめ記事を見つけられなかったこと
  • 自分用にメモを残しておきたかったこと

から、個人的に気になった点やポイントをまとめてみました。

What Is This Guide?

  • IT系情報サイトのDZoneが2019年に発行した、ソフトウェア業界における「自動化テスト」（Automated Testing）*1に関するガイドブックです。
  • DZoneの読者約500名に対するアンケートに基づく分析、および同調査に協力したソフトウェアベンダー各社の自動化テストに関する寄稿文で構成されています。
  • 同ガイドブックは、DZoneへメールアドレスを登録することで、無料で入手できます。


背景：なぜいま「自動化テスト」か？

  • 昨今のソフトウェアプロダクト・サービス（以下「プロダクト」と表記）は、サブスクリプションベースのSaaS（Software as a Service）であることが増え、常時機能追加や変更が行われるようになってきています。
  • 常時機能追加や変更を行えるようにするためには、自動化テスト・CD（Continuous Delivery/Deployment）・DevOpsが必須・前提となります。
  • 手動テストは、この開発・リリーススタイルでは、どうしてもボトルネックとなりがちです。


Executive Summary & Key Research Findings

読者のアンケート結果から、自動化テストに関する以下の傾向がみて取れます。

  • 「Shift Left」の拡大
    • SDLC（Software Development Life Cycle）において、自動化テストの開始時期が早期化しつつあります。
      • 開発フェーズから開始：54%（2018年）→66%（2019年）
      • ステージング／QA／テストフェーズから開始：31%（2018年）→22%（2019年）
    • 加えて、専任のQAを持たない会社・組織が増加しつつあります。（2018年：7%→2019年：44%）
      • テストに関する責務を、開発者が持つ傾向が拡大しつつあるとも言えます。
  • どのテストを自動／手動で行うか？
    • 自動
      • 統合テスト（Integration Tests）
      • コンポーネントテスト（Component Tests）
      • 性能テスト（Performance Tests）
      • ユーザストーリーテスト（Story-level Tests）
    • 手動
      • ユーザ受け入れテスト（User Acceptance Tests）
      • 使用性テスト（Usability Tests）
      • ユーザストーリーテスト（Story-level Tests）
      • Deploy後のテスト（Post-deployment Tests）
  • 自動化テストの優先度の向上
    • 過去の調査結果では、会社・組織における自動化テストの優先度が低くされがちという課題がみられました。
    • 一方で今回の調査結果では、自動化テストを優先しない会社・組織が減少しつつあります。（2018年：33%→2019年：28%）
  • TDD
    • 2018年の調査では、TDDを会社・組織内の全てのプロダクトの開発に適用するという回答者が多かったです。
    • 一方で2019年の調査では、TDDを全てのプロダクトの開発に適用する回答者は減り、選択して一部のものに適用する回答者が増えています。
    • TDDとDevOps専任組織との相関関係
      • 会社・組織内にDevOps専任組織がある場合の方が、ない場合よりもTDDの採用率が高いです。
  • DevOps専任組織の有無と、自動化テストを阻む要素との関係
    • DevOps専任組織がない場合：自動化テストの作成自体が大きな障壁になっています
      1. Test execution and Orchestration
      2. Test report and analysis
      3. Maintaining a stable and up-to-date test lab
      4. Test automation creation
    • DevOps専任組織がある場合：いかに自動化テストを（会社・組織全体に）広め、実施結果レポートを分析するかに視点が移っています
      1. Maintaining a stable and up-to-date test lab
      2. Test automation creation
      3. Test execution and Orchestration
      4. Test report and analysis


How to Test What Matters

テストカバレッジ（Test Coverage）に潜む品質面の課題を指摘し、その上で我々は如何にして品質の高いプロダクトを実装すべきか？についてまとめられた文章です。

  • 課題
    • テストカバレッジは、自動化テストの数的・量的情報ではあります。
    • 一方でテストカバレッジは、プロダクトの品質を必ずしも保証する情報ではありません。
    • テストカバレッジの数値を上げるためだけに、不必要なテストスクリプトを増産しているチームが世界的にみられます。これは、プロダクト開発の視点からは「作業のムダ」だと言えます。
  • 解決方針
    • 以下のようにプロダクト自体の実装を工夫することで、品質を高めることができます。加えて、ムダなテストスクリプトも減らすことができます。
      • 実際の（実システムの）データを使用してテストを行う
        • テスト用に作成した人工的データでは、イレギュラーなシナリオやバグを検知できない恐れがあります。
      • OSSのライブラリやフレームワークの機能はテストしない
        • これらは、既に十分にテストされリリースされているものと想定できます。したがって、これらのテストスクリプトをわざわざ作ることは、作業のムダになります。
        • 加えて、これらのテストスクリプトを作って残してしまうと、後にチームに加入したメンバーが事情を知らずに真似してしまい、結果同様のテストスクリプトがムダに増産される恐れが高まります。
      • ビジネスロジックを「Pure Functions」（＝ステートレスな実装）にする
        • ステートレスにすることで、実装とテストを容易にできます。
        • このことは、TDDで実装しやすくできることも意味します（後述）。
      • TDDで「Pure Functions」で実装する範囲を拡大することで、プロダクト全体をテストしやすい実装とする


The Four Keys to Achieving Parallelization in Automated Testing

自動化テスト、特にSelenium WebDriverのUI E2Eテストスクリプトを並列実行できるようにするためのポイントについてまとめられた文章です。

  • 課題
    • テストスクリプトが増えすぎると、テストの実行時間が延びてフィードバックを迅速に得られなくなる「Slow Test問題」が発生しがちです。
    • この問題を放置し続けると、自動化テストが敬遠されるようになり、最悪の場合自動化テストそのものが実施されなくなり破棄されることがあり得ます。
  • 解決方針
    • テストスクリプトを並列実行できるようにすることで、実行時間を短縮します。
      • Atomic
        • ユースケースシナリオに準拠した全ての画面遷移および全画面項目を検証するE2Eテストスクリプトではなく、そのうちの単一の画面遷移と項目だけを検証するテストスクリプトを作り実施することです。
        • E2Eテストの例
          • 1ケースで、以下の全てを検証する
            1. ログインページへ遷移する
            2. ユーザ名の入力欄が表示されていること
            3. パスワードの入力欄が表示されていること
            4. ログアウトのリンクが表示されていること
            5. 商品をショッピングカートへ追加できること
        • Atomicなテストの例
          • ログインページへ遷移し、ユーザ名の入力欄が表示されていること
          • ログインページへ遷移し、パスワードの入力欄が表示されていること
        • 同じ検証内容で、Atomicなテスト180ケースとE2Eテスト18ケースとを用意して実行時間を比較したところ、前者が後者よりも8倍速かったとのことです。
      • Autonomous
        • テストスクリプト間に実行順序の依存関係を作らないようにし、単独で実行できるようにするということです。
          • 実行順序に依存関係がある例（上から順番に実施が必要）
            1. 商品の注文を確定させる
            2. 上記の注文を取り消す
          • Autonomousな例（順番に関係なく実施可能）
            • 商品の注文を確定させる
            • （上記とは関係なく）商品の注文を取り消す
      • テストデータの冪等性
        • テストデータは、テストスクリプト実行前に読み込み、実行後に破棄するようにする、ということです。
        • 上述のautonomousなテストの前提にもなります。
      • Selenium WebDriverのテストスクリプトでは、Javaのstaticキーワードを使用した変数・メソッドの使用を避ける
        • これらは、Javaの仕様上全テストスクリプトで共有されるため、並列実行の妨げとなります。


Executive Insights on the State of Automated Testing

ガイドブックの締め括りとしての、自動化テストの今後の課題です。

  • 自動化テストのスピードと品質を高める必要がある
  • 自動化テストの標準・ベストプラクティスが不足しているため、これを充実させる必要がある
    • 例
      • コンポーネントは小さく実装し、テストのしやすさを向上させる
      • テストスクリプトは小さく実装し、実行時間を短くする
      • 何をテストすべきか／しないかの判断基準を用意・提供する
  • 自動化テストを、CI/CDパイプラインおよびDevOpsと統合することで、その効果をさらに高める必要がある
  • 自動化テストの焦点が、UIテストからAPIテストへシフトしつつある
  • 自動化テストを担う人材が不足している


個人的メモ

  • 自動化テストに関するメトリクス
    • 総テスト量
    • 単位時間あたりの実施テスト数
    • テストの実行時間
      • テスト全体
      • 1テストあたり
    • 手動テストの実施時間と自動化テストの実施時間との比率
  • ガイドブック内の「バズワード」
    • クラウド
      • テスト数の増加時、およびSlow Test問題発生時に、インフラのスケールアウトで解決を図る
      • Device Farmなどで、テスト対象端末の準備・管理を容易化する
    • AI/ML


*1:テストに関する用語の翻訳は、『ソフトウェアテスト標準用語集（日本語版）』（Version 2.3.J02、JSTQB技術委員会訳）を参考にしています。