そんな自動化で大丈夫?「システムテスト自動化 標準ガイド」で自動テストを点検しよう!

このエントリーをはてなブックマークに追加

はじめに

こんにちは、 chappie です。
久々の投稿ですが、今回は半分書評のような内容でひとつ記事を書いてみます。

自動化されたテストは基本的には貴重な財産であり資産です。しかし、対象システムの運用を続けるうちにメンテナンスコストが高くなるなど、負債としての側面を持ち始める場合もあります。
シャノンが提供するプロダクトもリリースから 8年ほど経過し、自動テストの量が増えると同時に課題の質も変わってきています。プロダクト本体と同様に、それに付随する自動テストも継続的な改善が必要です。

今回は、書籍「システムテスト自動化標準ガイド」(以下、標準ガイド)を参考に、自動テストをどのように点検・改善していくかということを考えてみたいと思います。

ちなみに、当ブログでは昨年 inomata も自動テストのコツについてまとめた記事をポストしているので、ぜひあわせて参照ください。

「システムテスト自動化標準ガイド」本の紹介


和訳は 2014年12月に出たばかりですが、原著は 1999 年(!)発行。「システムテスト自動化カンファレンス」を主催しているコミュニティでもある、「テスト自動化研究会」のメンバーが翻訳しています。
本書は2部構成になっています。

  • 第1部: テスト自動化の一般的なガイドライン。15年前の内容ながら、現在にも通用する普遍的な指針となっている
  • 第2部: 具体的な自動化取り組みのケーススタディ。原著の2部の内容は古くなりすぎているので、和訳本では日本のエンジニアが独自に書き下ろしている

本書自体のより詳しい紹介は、本の発売と同時期に開催された「システムテスト自動化カンファレンス2014」のレポートなどを参照ください。(私は残念ながら参加できなかったのですが…)

以下では、本書から自動テストの良し悪しを検討する上で役立つ枠組みとなりそうなあたりを抜粋して紹介していきます。

テスティング&自動テスト

まず、自動テストはそもそものテスティング活動があってこそののものである、ということを抑えておく必要があります。
つまり、そもそものテストプロセスや内容がよくないと、いくら効率化しても意味がありません。標準ガイドの中では、以下のように端的に表されています。

「カオスを自動化してもカオスが早くなるだけだ」

自動テスト云々以前にまず、作成しているテストケースやテストプロセスについて確認するべきでしょう。

テストケースの品質

自動か手動か問わず、よいテストケースとはどういったものでしょうか。本の中では、以下の観点にまとめられています。
  • Effective: (欠陥検出の)効率性 = どれくらい欠陥を見つけそうか
  • Exemplary: 典型的 = ひとつで複数のことを確認できるか
  • Economic: 経済性 = 実行、分析、デバッグが低コストで行えるか
  • Evolvable: 発展性 (≒保守性) = 本体側の変更に対して追従する工数がどれほどか
現実的に、すべてのケースや組合せをテストするといったことは不可能であり、そこには経済的な観点が必要(現実的な時間・リソース内で必要十分なテストを実行できるようにする)です。
テストケースの作成にあたっては、上で挙げた属性の間でバランスを取りながらテストを設計するスキルが必要です。これは、テスト自動化とは直接関係ない、そもそものテストする能力といえます。
自動テストの作成を誰(開発者、QA、etc)が行うにせよ、そこで実装するテストケースの内容はそういった能力を備えたメンバーによって作成されるべきです。

テスティング活動

また、一般的なテストの活動は以下のようなプロセスに分解されます。
  • 識別: テスト条件の識別「何」をテストするか
  • 設計: テストケースの設計「何」を「どうやって」テストするか
  • 実装: テストケースの実装
  • 実行: テストケースの実行
  • 比較: 期待結果と実行結果の比較
上流ほど知的作業の割合が多く、下流ほど事務的作業の割合が多いとされます。
一般的には、実行と比較フェーズが自動化しやすいので、テスト自動化といった場合、それらのみを指すことも多いです。ただし、設計フェーズなども自動化の余地がないわけではありません。
同時にまた、(実行や比較の中でも)すべてを自動化する必要もありません。自動化が困難なものを無理やり自動化することは、経済的な観点でいうと必ずしも適切とは限りません。

スクリプティングの技法

さて、上記のように自動化の内容と対象を確認した上で、実際の自動テストを作成していきます。

自動テスト作成のよいとされる技法は、基本的には一般的なプログラミングでよいとされることと同じです。つまり、よく構造化され、理解しやすく、ドキュメント化されており、再利用しやすいといったことに価値があります。
特にメンテナンス性や再利用性が重要であり、そういった面からドキュメンテーションも重要であるとされます。自動テストスクリプトの目的やメンテナンス方法を伝えることで、他メンバーによる再利用を促すことが、その自動テストの持つ価値を最大限に活かすことにもつながります。

自動テストのスクリプティングの技法は以下のように区別されます。
  • リニアスクリプト: 記録したまんまのテスト
  • 構造化スクリプティング: 分岐・ループによる制御が可能
  • 共有スクリプト: 繰り返す処理が共通化されている
  • データ駆動スクリプト: テストケースとテストデータが分離されている
  • キーワード駆動スクリプト: テストケースと機能が分離・抽象化されている
Selenium でたとえれば、 Selenium IDE で録画・再生するだけのものから、WebDriver によるプログラム言語で記述されたもの、その中でテストデータ生成や共通ルーチンの部品化、ひいては Cucumber などで内部処理を隠蔽化した仕組みへと進化する様を想像いただければ、各フェーズのイメージがわくかあと

一般的に、より下のほうが高いメンテナンス性を実現する技法といえます。テストデータや、具体的な操作手順をテストケースから分離し、テストを追加作成するコストや将来のメンテナンスコストをより小さくすることが可能です。ただ、そういった技法を用いれば初期コストは高くなります。当然、プロダクトの寿命やシステムおよび組織の置かれた状況によって、どのレベルまで投資するかを判断するべきでしょう。

メトリクス

ここまででテストの内容、対象、実装方法について検討してきました。それを実践していくことでどれくらい効果があったのかを継続的にチェックしていくことになります。
標準ガイドでは、自動テストではなくテスティング自体のメトリクスについても書かれていますが、ここでは自動テストの評価属性のみ紹介します。
  • 保守性: 変更時の更新のしやすさ
  • 効率性: 自動化にかかるコストの低さ
  • 信頼性: 正確かつ再現可能な結果をもたらすか
  • 柔軟性: 目的に応じた組合せやすさ
  • ユーザビリティ: 自動テストの扱いやすさ
  • 堅牢性: 不測の事態へ対処できるか
  • 移植性: 異なる環境での実行のしやすさ 
これらのうち、どこを強化すべきかというのは、プロダクトや組織の目的によります。自分たちのもつ自動テストが本来これらのどの側面を高くすべきで、現状はどうであるかということを把握することがまず必要でしょう。
また、すべてのメトリクスについて具体的な数値を計測する必要はないとされます。標準ガイドではスターターキットとして、たとえば保守に費やす時間・工数と、自動テストによる利益をはかるものとしてテストサイクルの数や完了したイテレーション数などが挙げられています。

どう改善していくか

さてここまで、一般論としてテストおよびその自動化を点検するための枠組みを標準ガイドからざっくり抜粋してみてみました。上記を踏まえ、たとえばどのように自動テストの改善を考えていくべきでしょうか。
あまり詳細には書けませんが、一例として、私が現在プロダクトの自動テストについて考えていることを紹介してみたいと思います。

現在プロダクトの(システム)自動テストの大部分は QA の管轄にあり、開発者は基本的にユニットテストの作成のみ行っています。したがって自動テストも、 QA のメンバーやアルバイト(=基本的に非プログラマ)が作成・実施するために最適化されてきました。

そのため、標準ガイドに照らすと以下のようなマイナス面が指摘されます。
  • テストケースがデータや操作と分離されておらず、つまりほぼ「リニアスクリプト」の段階にとどまっており、本体機能や画面に変更が生じた場合、多数のテストケースを修正する必要がある (保守性が低い)
  • 上の理由から、新しいテストケースを作成する際にも、既存のものと同じような操作とデータ登録を繰り返し作成しなければならない (効率性)
  • 自動テストの前処理および自動テスト実行スキームが Jenkins と QA テスト環境(≒ステージング環境)にがっちり組み込まれており、任意の環境(たとえば開発環境)で手軽に実行できない (柔軟性、移植性、特に開発者にとってのユーザビリティが低い)
これらの問題点について、たとえば以下のような対応案が挙げられます。
  1. 1. ユーザビリティ・柔軟性を高めるために
    1. 初期状態をセットアップする機能をアプリ本体に組み込み、対象環境を選ばず、前提となる状態を作り出せるように
    2. QA自動テストを開発時のテストと共通の仕組みにのせ、開発段階から既存の自動テスト資産を利用できるように
    3. 自動テストごとのカバー範囲を出しておき、本体の修正箇所から影響ある自動テストをピックアップ
  2. 保守性・効率性を高めるために
    1.   リニアスクリプトからデータ駆動、キーワード駆動のテストスクリプトへ
      1.     (e.g. Selenium WebDriver でいう Page Object Pattern や UI マッピングなど保守性を高めるため手法を利用)
    2.   QA もスクリプト化されたテストケースがメンテナンスできるだけのプログラミング技術を身につける

また、運用面においても、上であげたメトリクスをいくつか計測し、自動テスト自体の質を継続的に評価できるようにしていきたいと思っています。

このあたりはまだ試行錯誤しながら進めている段階なので具体的なレベルではいろいろ変わるかもしれませんが、いずれ、改善の結果などあらためてシェアする機会があればと思います。

このように、自社の組織・プロダクトの目的や置かれた状況を踏まえて、テスティングおよび自動テスト改善を検討するための共通言語として、システムテスト自動化標準ガイドを活用されてみてはいかがでしょうか。

ということで、今回は以上です。
次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...