システムテスト自動化カンファレンス2014(7)「Test Automation Patterns 2014 冬コレ！」
半年程前ですが、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：テスト実行ツールをテスト
バグの出現にフェーズがある。
- 判定系 初期に出てくる
- 駆動系 テストとテストの境目
- 報告系 要望が入ると御の字
[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：テスト設計もテスト自動化もできる赤魔道士
- テスト設計を学ぶ
- よさそうなテストデータを見つける
- 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から取り組んでみては如何？」と助言してみました。
パターンを上手く利用すると自他共に知恵が廻り、賢い開発へ一歩進めることができるなと実感しています。
