システムテスト自動化カンファレンス2014に参加しました
概要
ヤフーで開催されたシステムテスト自動化カンファレンス2014に参加しました。
説明では、「テスト自動化は普及のキャズムを超えたようで、
テスト対象のシステムやアーキテクチャパターンについても考えていこう。」
今回のテーマは、「ツールに依存しないテスト自動化技術の知識体系を築き上げる。」でした。
191人の予約が24時間経たない間に埋まってしまった人気の勉強会である。
今回は、この勉強会の内容を簡単に紹介します。資料が公開されているものは、
資料へリンクしているので気になったものは、そちらで。
今年のSTAC2014では現在でも深い知見を与える書籍「Software Test Automation」のSTAR有志による翻訳書「システムテスト自動化 標準ガイド (CodeZine BOOKS) 」( http://www.amazon.co.jp/dp/4798139211/ )を中心に、実践者、Webで集められている各種のアーキテクチャとパターンを紹介し、参加者の皆様と共有します。
http://connpass.com/event/
システムテスト自動化カンファレンス2014 - connpass
システムテスト自動化カンファレンス2014 - connpass
1時間で分かるSTA /鈴木 一裕さん
約450ページのボリュームの『システムテスト自動化 標準ガイド』には一体、どのようなことが書かれているのか。 目次からだけでは読み取れない本の構成と各章のポイントを概説します。 特に、第3章で解説されているテストスクリプトの「レベル」の考え方についてお話しします。
http://connpass.com/event/9618/
1時間で分かるSTA (Software Test Automation) #stac2014
1時間で分かるSTAということで、訳したSTAのPart1について、
各章の位置付けを図解で示しながら、確証の内容について説明していく形式でした。
各章では、どんな説明があったのか簡単に箇条書きにします。
1章 テスト自動化のやるべき場所
- 自動化は実行フェーズが向いている
- ビジネス面よりも技術面の方がやりやすい
2章 キャプチャーリプレイはテスト自動化ではない
準備がすぐにできて、すぐに再生可能
だけど、構造が無いので読み辛いし、ソフトウェアが変わると追随が難しい。
3章 スクリプティングの技法
テストスクリプトの構造は、テスト自動化知識体系で3つに分けられる。
リニアスクリプト+分岐+反復+呼び出し
→構造化スクリプト:柔軟性、冗長性が上がる。
構造化スクリプト+機能ごとに切り離し
→共有スクリプト:再利用性が上がる。
構造化スクリプト+データを変数として切り離し
→データ駆動スクリプト:テストケースが追加しやすくなる。
構造化スクリプト+機能ごとに切り離し+データ切り離し
→キーワード駆動スクリプト:再利用性、テストケースが追加しやすくなる。
4章 自動比較
結果の比較は退屈なプロセスなので、自動化したい。
自動比較では、「対象」と「機会」と「方法」の観点で考える。
「対象」は、できるだけ多く比較するセンシティブ比較と、必要最低限比較するロバスト比較がある。
「機会」は、実行しながら行う動的比較と、実行後に行う実行後比較がある。
「方法」は、そのままを比較する単純な比較と、本質的な部分だけの複雑な比較がある。
6章 前処理と後処理の自動化
前処理と後処理は退屈なプロセスなので、自動化したい。
- ファイルの生成、削除再配置
- テストケースの事前条件を見たしているかチェック
- 入力や比較のための変換
テスト自動化のパターンと実践 /.reviewrc
テスト自動化を適用していくのは、多くのハマりどころがあり中々難しいものです。 しかし、そのハマりどころは多くの人が同様の経験している場合もあり、「パターン」としてまとめることで皆さんの役に立つと考えております。 今回は現場で多く発生するテスト自動化パターンの紹介と、フレームワークを構築することでより開発が加速したというパターン実践事例をあわせて紹介します。
http://connpass.com/event/9618/
テスト自動化パターンの話
テスト自動化では、みんなが共通してハマる罠がある。
それを、パタンランゲージで紹介することで、テスト自動化を定着への道標にする。
具体例をいくつか上げる。
皮をむく
- 自動化を妨げる、動作が不安定なレイヤ・ 変化の激しいレイヤを取り除いてテストを行う
- 安定なテストを行うことができるが、 皮を向くための作業が必要なことも
- 剥いた皮は捨てないように!!
皮もおいしく
- 剥いた「皮」といってもそれも アプリケーションの一部。
- その部分の テストは計画しておく必要がある。
自動家を作る
- テスト自動化を専業とする役割を組織の中に作るパタン
- テスト・実装・予算獲得などの自動化に関するお仕事を引受け、他のエンジニア と協業する
- ゆくゆくはテスト以外も自動化していく!
テクいやつ 「Friendlyで皮をむく」
Windows用アプリの皮剥き器であるFriendlyの設計と使い方を例にして、
皮剥きの実例の紹介であった。他のシステムでも皮剥きができるよう、
抽象的なレベルでの説明もあった。勝手な解釈では、テスト対象は、
GUIで操作する部分をAPIを叩くようにして、皮を分離しやすくという意味だと。
以下、発表時のメモ
システム自動化のボトルネックは、操作技術
自分達が作るときはAPIを使っていたのに、
テスト対象のGUIというプログラムとは別のもの。
だから難しい。
別プロセスのシステムを操作できる。
自在にテスト自動化コードを書くために
普通のプログラムと同じようにテストをしたい。
テストしづらい部分があるときは、それを操作しなくても良いように
元のプログラムを作っておくことができる。
(勝手な理解:たぶん、いろんな処理をAPI化しておけってことだと。)
剥く皮の厚さは対象に応じて。
ボトルネックの所以外はできる限り自動化する。
技術的な部分は隠蔽してシナリオテスト
システムをプログラムとして見る
操作上のボトルネックを取り除くむ
剥いた皮に注意(厚いのか薄いのか)
それぞれの特性を活かせるテスト設計にしよう
エモいやつ 「自動家(オートメータ)をつくる」
「自動家(オートメータ)をつくる」-システムテスト自動化カンファレンス2014 「.reviewrc」枠発表-
「自動家(オートメータ)をつくる」-システムテスト自動化カンファレンス2014 「.reviewrc」枠発表-
現場ごとの自動化を企画・実行する人である「自動家」の話。
自動化のメリットと自動家に必要なものについて紹介している。
自動化のメリット
- 合理性・効率性の向上
- 「本懐」の仕事に近づける
- 楽しい(問題を技術課題に転化できる)
自動家に必要なもの
- 自動化術:テスト、CI/CD、インフラなど自動化に活かせる術
- 自動化脳:自動化できないかと考え続ける思考
- 自動化主義:「自動化マインド」を知り「したい」という意思を伝搬する活動
STA 第2部:GUI自動テストの保守性を高めるには /伊藤 望さん
GUIテストの自動化はスクリプトを作成して終わりではなく、その後も継続的にスクリプトを保守していく必要があります。このセッションでは、オープンソースのテストツール「Selenium」を題材として、「ページオブジェクトデザインパターン」を始めとする、テストスクリプトのメンテナンス性を高める様々な技法や工夫について解説します。
http://connpass.com/event/9618/
Seleniumを使ったテストを例にして、自動テストの保守性を保つ話です。
Seleniumを使ったテスト
キャプリャーリプレイで生成されたコードはそのまま使わない
保守性を高めるために重要なこと
- 失敗要因を減らす
- 失敗調査コストを減らす
- 共通化する
ページオブジェクトデザインパターンを使って共通化しましょう
ページオブジェクトデザインパターンって?
- 画面情報を1つのクラスに集約
- 1ページに対し1つのページオブジェクトクラス
参考:PageObjectデザインパターンを利用して画面変更に強いUIテストを作成する│ソフトウェアテストラボ|アプリテスト|スマートフォンテスト|株式会社シフト
STA 第2部:状態遷移テストにおけるテスト設計と実行の自動化 /きょんさん
状態遷移を活用したJUnitテスティングフレームワークの開発例について解説します。 また本書では削除された内容である、自動テストを前提としたテスト戦略の設計とビルドパイプラインにおける実装についても紹介します。
http://connpass.com/event/9618/
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
はじめに
ボトルネック
自動化っていっても効果のあるところをやらないと意味がない。
まずは現状を見える化する必要がある。
テストを自動化することが正しいのではなくて、開発自体をよいサイクルにすることと
リリースにかける時間を短かくするための有用な選択
テストにかける工数が開発の35パーセントってのは、どこの国でも同じ
でも、フェイルしないようなテストは書いても無駄
デプロイメントパイプライン
なぜ、デプロイメントパイプライン?
テスト自動化するときに俯瞰的に見ないと局所最適してしまうかも。
それに密接にかかわるのがデプロイメントパイプライン。
フィードバックの順序、実行頻度を考えるのに
デプロイメントパイプラインを考えることで効率が良くなる。
各機能を全部通るような状態遷移図を作って巡回セールスマン問題のように、
スモークテストで網羅する。
他には、幅優先探索だったり、ダイクストラ使ったり。
テスト戦略
テスト戦略は、テストケース設計に関する方針を決めたもので、
戦略、段取り、成果物、三位一体である。一度作って終わりではない。
テスト戦略は、アークテクチャ、テストスイートの設計、テストケースの設計について方針を与える。
そして自動化のための自動化戦略は、
「何を自動化するか」「テスト環境」「テスト目的」である。
STA 第2部 : ビルドプロセスとCI /長谷川 孝二さん
『システムテスト自動化 標準ガイド』で言及されている「テストウェアの管理」「テストの前処理・後処理」について、その必要性を再確認するとともに、原書から10年経った今、ビルドツールやCIを活用することで実現できることを事例を交えてお話しします
http://connpass.com/event/9618/
テストウェアを管理するときの問題と対策(STA5章に対応)
- 規模(ファイル数が多い)
- 再利用性(建て増し旅館)
- 複数バージョン(製品のバージョンとの同期)
- プラットフォームと環境からの独立
(動作環境ごとにテストウェアのコピーをつくのか)
→規模とバージョンはツールで解決できるので解決しましょう
前処理と後処理(STA6章に対応)
前処理と後処理とは
前処理・・・生成、チェック、再配置、変換
後処理・・・削除、チェック、再配置、変換
なぜCIなのか
- バグの作り込みを、早期に検出できる
- メトリクスの採取、通知(チャットやメール)などとの連動できる
何を使えばいいのか
ビルドパイプラインを考える
テストレベル(結合度)ごとに順番に実行することで、
フィードバックを素早くする効果がある
社内スマホアプリのビルド配信ツールによる自動化事例 /赤根 稔朗さん
社内のアプリ開発サイクル効率化の一環として取り組んでいる全社のスマホアプリビルド配信ツールを事例にあげその仕組みについて、具体的にどのように自動化を実現しているか紹介します
http://connpass.com/event/9618/
内容は、ヤフー社内で展開されたスマホアプリのビルド配信ツールの事例紹介であった。
下記の問題に関して、社内版のDeploygateを作成して問題を回避した。
コミット漏れでビルドが通らない
→ クリーンな環境でビルドできるか確認通知
PCに繋がないとインストールできない
→ 社内版DeployGateみたいなのでワイヤレスインストール
本番・テスト用、環境が増えれば倍々に
→ 環境毎の設定でビルド
全員がCI勉強するとコスト大
→ 設定はリポジトリの場所だけ
Test Automation Patterns 2014 冬コレ!/松木 晋祐さん
テスト自動化における、プロセス、アーキテクチャ、実行などのパターン集から、2014年現在の国内事情に「似合いそう」なものを厳選。解説とともにお届けいたします。明日から、街の視線を独り占めません!
http://connpass.com/event/9618/
海外と日本で提唱されているテスト自動化のパターンを紹介でした。
※ パターンとは、特定のコンテキストにおいて繰り返し起きる一般的な問題を解決する方法
プロセス:LAZY AUTOMATOR
怠け者は最高のテスト自動化エンジニアになる可能性がある
プロセス:TEST THE TESTS
テスト自体をテストする。
テストは以下の順でバグが発生しやすい。
判定系 作りはじめたころ
駆動系
報告系 マネージャや上司が仕様変更をお願いされる
最初はテスト自体に信頼がないから細かい修正などの依頼はない。
報告系に修正依頼が来れば信頼されてきたってこと。
immutable infrastructureもテストで使えば
デザイン:TEST SELECTOR
テストセレクタを実装しよう。
フォルダ管理だけでなく、タグでテストケースを管理すれば柔軟なテストができる。
例:[機能テスト]だけど負荷がかかるから[負荷テスト]に使える。など
デザイン:AUTOMATE GOOD TESTS
自動化が"効く"テスト
ROIが高くなる優れたテスト
スモーステスト/リグレッションテスト/異なる環境/複雑なテスト/
精度が要求されるテスト/精度が要求されるテスト
システムも80/20の法則になっていて、20%の機能が80%使われる。
なので、20%の良く使われる部分のテストを自動化する
デザイン:SINGLE PAGE SCRIPTS
ページオブジェクト
Webサイトのテストを利用するときに、使うラベル・ボタンごとに1オブジェクトに
テストコードと、対象を認識するコードを分離する
(副作用) IDEテストコードを書くときにサジェストされやすくなる
マネジメント:AUTOMATION ROLES
テスト自動化に関わるひとたち
実践(TABOK)
欧米では、テストエンジニアとテスト自動化は別
テスト自動化エンジニアは、テスト経験よりも開発経験を重視する。
テスト自動化のコストは、
テストコードを書くことは10%、設計がメイン。
実行:VISUALIZE EXECUTION
いまどのテストやってますか。
欲しいFALEが置きたときに、どこが実行されているの??ってなるので
分るようにしておくと良い。
実行:COMPARE WIHTH PREVIOUS VERSION
前の版と比較する
何があっているか、何があってないかっていうのは、過去のバージョンと比較するとよい。
最初に人間が正しいバージョンを決めておく。
テスト自動化が進むと一気に分析すべきものが増えるのは良くない。
ずっと正しい結果か確認しないといけなくなる。
実行できるテストが増えて分析に時間がかかるのは非常によくないですよ。
画像系とか分りづらい。
(同じ処理をする他のソフトと比較してもいいのでは)
実行:VARIABLE DELAYS
可変遅延
スリープはイベントに基づく可変な値を設定しよう
最近だと非同期処理がどんどん増えてきている。
非同期処理のページだと開いた瞬間にはコンテンツが取得されていないことがある。
ツイッターのページは全部非同期取得しているので、
通常期待される見れるまでに時間までに見れるようにしないといけない。
こんなときは、最低何秒待てばいいのか考える。2秒も待てば十分でしょう。
非同期UIの場合はパフォーマンスのテストも同時に行うことになる。
マネジメント(JP):RED MAGICIAN
テスト設計も自動化もできる赤魔道士
日本ではいっしょくただけど、
テストケースを書く人とテスト自動化エンジニアはかなり差がある。
キーワード駆動テスト、モデルベースド・テスト、テスト設計自動化設計生成をできれば活き残りやすいのでは。
まとめ
「テスト」の役割が「保証」から拡大している
「開発インフラとしてのテスト」その実装としてのテスト自動化
自動化エンジニアは品質を背負った「環境エンジニア」
これからの超基盤技術に、みんなでワクワクしていこう!
自分まとめ
ROIを考える
あまり細かくROIを考えてはいなかったまでも、少しの時間でメインの重要な
機能だけにテストを書いていたので方向性に安心しました。
しかし、デプロイパイプライン?という一連の流れを考えての最適化という
視点には欠けていたので別途検討する。
困ったらテスト自動化パタン言語を見るようにする
まだテスト自動化に対する取り組みがあまり行えていないので、
困ったことがあったら随時パタン言語を参照する。
テスト自動化パタン言語 オーバービュー | テスト自動化パターン言語プロジェクト