読者です 読者をやめる 読者になる 読者になる

MasaoApril's Library.

Software Testingなネタを書いてみた。

システムテスト自動化カンファレンス2014(7)「Test Automation Patterns 2014 冬コレ!」

Conference STAC2014 TestAutomation

 半年程前ですが、2014/12/14(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2014で聴講したセッションから数回に分け、まとめたものを紹介しています。

以前書いた記事

セッション(再掲)

1.オープニング:1時間で分かるSTA /鈴木 一裕 →<資料>
2.テスト自動化のパターンと実践 /.reviewrc →<資料1>/<資料2>/<資料3>
3.GUI自動テストの保守性を高めるには /伊藤 望 →<資料>
4.状態遷移テストにおけるテスト設計と実行の自動化 /きょん →<資料>
5.ビルドプロセスとCI /長谷川 孝二 →<資料>
6.社内スマホアプリのビルド配信ツールによる自動化事例 /赤根 稔朗(Yahoo! JAPAN)
7.Test Automation Patterns 2014 冬コレ!/松木 晋祐 →<資料>

 最終回は「7.Test Automation Patterns 2014 冬コレ!」について紹介します。

7.Test Automation Patterns 2014 冬コレ!/松木 晋祐

 本発表では、TestAutomationPatternsのサイト https://testautomationpatterns.wikispaces.com/Test+Automation+Patternsから10パターン、日本から提案したい2パターンを紹介。

[1]パターンとは?

 特定のコンテキスト内で一般的に発生する問題に対し、概ね再利用可能なソリューション。

[2]全体像

  • プロセス
  • デザイン
  • マネジメント
  • 実行

[3]プロセス

(1)Lazy Automator:なまけものは最高のテストエンジニアに

 自分がなまけるために技術的な努力と工夫する。

(2)Test the Tests:テスト実行ツールをテスト

 バグの出現にフェーズがある。

  1. 判定系 初期に出てくる
  2. 駆動系 テストとテストの境目
  3. 報告系 要望が入ると御の字

[4]デザイン

(1)TEST Selector:タグでテストを管理

 フォルダにタグつけるより、テストケースにタグをつける。

  • 機能テスト
  • 性能テスト
  • 最後に実行したテストスイート

(2)Automate Good Tests:自動化に適したテストがある

 性能テストや回帰テストなど

(3)Simple Page Scripts:ページ毎にオブジェクトを作成。

  • Seleniumのコミュニティでは、"Page Object Pattern"として知られている。
  • ページ毎にオブジェクトを作成。

 また、STAR(テスト自動化研究会)のハンズオン資料 https://sites.google.com/site/testautomationresearch/teaching_materials も参考とのこと。

[5]マネジメント

(1)Automation Roles:テスト自動化に関わるひとたち

(a)TABOKの記述が分かりやすいので紹介
  • チームリーダ
  • テストエンジニア
     ※欧州では、テストエンジニアとテストオートメータは職種が異なる。
  • リード 自動化 アーキテクト(テスト自動化アーキテクト)
  • クロスカバレッジコーディネータ  ※組織をカバレッジ。組織を最適化する役割。
  • テスト自動化エンジニア
(b)役割の定義は、過度な期待を抑制する効果がある。
(c)Jen Leger's の経験

 テスト自動化設計やテスト自動化開発が6割。

[6]実行

(1)Visualize Execution:今、どのテストをやってます?

(2)Compare With Previous Version:前の版と比較する

(a)Pass/Failの判定ができない
  • 何が正しいかは、人が定義する必要がある。
  • 画像比較やテキスト比較など
(b)結果を分析するシステムも考慮する必要がある。
(c)競合製品と比較でもよい

(3)Variable Delays:可変遅延

(a)ウェイト時間を定数でやらないこと
(b)イベント発生をpollingして利用すること。

 Web系でよくある。

+2の部分(@日本)

(1)DJR

  • 駆動:Drive
  • 判定:Judge
  • 報告:Report

(2)Red Magician:テスト設計もテスト自動化もできる赤魔道士

  1. テスト設計を学ぶ
  2. よさそうなテストデータを見つける
  3. Driveのネタに

 モデルベーステストは誰が「作る」か

所感

 システムテスト自動化カンファレンス2014開催から半年程経過し、改めて本セッションをふりかえると、テスト自動化を進める上でプロジェクトリーダやチームメンバーと「テスト自動化の目的」「テスト自動化システム構築の進め方」「テスト自動化のスコープ」などの認識合わせが上手くいかないと、テスト自動化プロジェクトjは失敗に終わってしまうことに気付きました。テスト自動化プロジェクトが1つの開発案件の規模だと実感しつつありますので、Test Automation Patterns(https://testautomationpatterns.wikispaces.com/Test+Automation+Patterns)を教訓として、テスト自動化の可能性を検討しようと思います。
 今年度に入り、応援要請があったプロジェクトの任務を遂行していますが、とあるアプリケーションソフトでルーチンワークな操作があり、手打ちで実施するのは時間の無駄と思い、Auto It!で試行錯誤を経て操作の自動化をある程度実現しました。DJRのD(Drive:駆動)のみですが、キー操作による腱鞘炎を予防できると共に、操作時間を6割削減でき、削減できた時間を他のタスクに回すことができました。
 また、前年度まで所属していた第3者課の方から、「ボタン一つで自動化したい」と掴み所の無い相談を受けましたが、「その自動化システムを詳細化して設計する必要がある。DJR(Drive/Judge/Report)の切り口で、最初はDriveから取り組んでみては如何?」と助言してみました。
 パターンを上手く利用すると自他共に知恵が廻り、賢い開発へ一歩進めることができるなと実感しています。