だいぶ出遅れ感がありますが、
12/1(日)に行ってきたシステムテスト自動化カンファレンスの感想です。
イベント内容はこちら
https://sites.google.com/site/testautomationresearch/event
当日の様子やスライドは、こちらのTogetterにまとめられています。
システムテスト自動化カンファレンス2013ツイートまとめ
http://togetter.com/li/597476
スタッフ、登壇者の方々、参加者まで
自動化に対する色々な思いが感じられて、非常にアツいイベントでした！
リリースに求められるスピードが上がってきて、自動化の注目度も上がる中、
アツいセッションの数々で楽しかったです。
自動化スキルあげねば！とモチベーションアップしました。
【印象に残った言葉】
「機械にできることは機械に任せ、
人間はより創造的な分野で活動を楽しむべきである」
という言葉ですね。
オムロンの創業者・立石一真さんの言葉だそうです。
まさに自動化の目的ってこれですよね。
【印象に残ったキーワード】
(1)自動化ハイ
(2)頑張らない自動化
(1)自動化ハイとは
※私的定義です
自動化を推進するとき、
自動化そのものが楽しくなって自動化の目的を忘れ
結果として無駄になってしまう成果物が量産される状態のこと。
目的や期限、コスト感って重要ですね。
身に覚えのある方がけっこういるのでは(^^;
(2)頑張らない自動化
自動化には、できることできないことがあるし、
なかには自動化できるけど、してもあまり意味ないものなどもあり得ると思います。
なので、自動化しておいしい部分だけを自動化する「頑張らない自動化」が必要です。
欲張らないって重要ですね。
初めてプロジェクトでSeleniumを使ったとき、
「自動化で全部できるわけじゃない」
と当時の上司からいわれました。
たぶん、このことを指してたんだろうなと思います。
【各セッションのメモ】
※資料は、公開されてるものは上に張ったtogetterにリンクがあります。
システムテスト自動化カンファレンス
12/1(日)9:45-18:00
(1)よりよいテスト自動化のためにちょっと考えて見ませんか 近江久美子
よりよい自動化を達成するためどんなことを考えれば良いか
→自分の答えを探すためのポイントを見つけましょう！
・テスト目的の例
効率化→準備や学習時間<自動化で短縮できた時間
手動ではしづらいテスト→必要なツールを選ぶ
・手動のテストと自動のテストは単純には置き換えられない
→自分たちに合うスコープや、より高いROIを達成できる自動化を考える
自分たちに会うプロセスを考える
・どの、どこのテストを自動化するか明確にする
テストレベル 単体？ 性能？
テストタイプ
・どこを自動化するか？
仕様書見た瞬間にテストできるわけではない
設計、実行、分析のどこを自動化するか明確にする
・テスト実行はDrive Judge Reportの3要素に分けられる
美味しいとこだけ自動化
どこ、どのテストを自動化するか明確に。
・自動化しないと実現できないテストか？
数百人での接続を想定とか、48時間回し続ける性能テスト
→必要なテストなら自動化
・自動化しても意味ないものもある
マニュアルテストとか、印刷されたものが正しいかとか
・複数のツールを連携する場合、ツール同士の連携や制約はOK？
・自動化の利点
リグレッションテスト
仕様が変わりにくいもの #曖昧さを許さないため変更が多いものには向かない
APIとかから考えると良い
・ROIを考える
負担を節約、利益を考える
保守、派生でも時にはROIから考えて改善につなげる
→でもROIから考えるって難しいよね
★利益
最終的にプロジェクトやプロダクトの利益につなげる必要あり
品質向上
リスク軽減 など
→テストにもたらされる変化を通して利益を考える
自動化はテストの品質、コスト、時間、利益変える
品質 再現性、トレーサビリティ向上
自動化理解度の向上
コスト 人件費は人しかできないところへ
時間 長時間稼働させて短期間に 夜間テスト
属人性の低下、知識伝承の効率化
#スクリプトやデータが残ってる→書き方統一される
→これらを洗い出して、利益に繋がってるか確認
★投資
時間:自動化は初期コストと保守コストが異なるため分けて考える
自動化でプロセス、必要な人材が変わることもある
・目的にあった利益と投資で計算する
投資も利益も直にゃコストに置き換えて計算する場合はさらに見積もりが必要
厳密に評価すると大変
※必要な分だけ評価する。評価するだけで結構大変。
・プロセスをみなおす
手動テストと異なるのは？
時間短縮
導入ツールや仕方に依存するのであるべき姿などを考える
増える手間、減る手間を考える、どのタイミングで増減するかも考える
結果の決定方法、IOは決めておく
注意点
他のチームと連携するひつようがある場合もある # 設計ちょっと変えてもらうとか
テストプロセスが機能してない場合は、まずその整備から
ツールのバージョンアップや人の習熟度アップにより、適宜見直す
■終わりに
テストは、プロジェクト、プロダクトの見える化を促進
テスト自動化により、テストは柔軟に、幅が広がる
→うまく使えば強力な武器になる
感想：
自動化の際に考える必要のあるポイントがまとまっていて、分かりやすかったです。
私はROIを考えるのが苦手なので、そこ注意しないとな。
(2)事例から見るテスト自動化のポイント（検これ（検証コレクション）の方々）
<1>トイレの歴史に学ぶ自動化パターン
「拭く」という行為を自動化しようと思い立つ
→色々やりすぎた結果、お値段200万の無駄に豪華なトイレ完成
→もう俺、手で拭くわ
<2>自動化のたどるサイクル
自動化お導入時、技術的なハードルで踏み出せないことが多い
→自分でこっそり作っておいて一気に紹介＆導入 #3分間クッキング
ただし勝手に各自がやりすぎ複雑になる # 自動化ハイ
運用が超大変！ 主管エンジニアが移動 自動化めんどい #原住民蜂起
自動化は放棄される→ある日やってきたエンジニアがテスト発見 #インディージョーンズ
<3>ファクトリーオートメーションにおけるシステムテスト自動化事例
■ファクトリーオートメーションとは
製造工程の自動化 運んで、管理して、検査して、品質も管理
要求され理品質 信頼性 いろんな環境で動くから
■システムテスト自動化の歩み
・フェーズ1
自動化システム初号機 信頼性検証機
何をされても止まらない
稼働までの時間、労力半端なし
デバッグ超めんどい
→効果を振り返ると、、、思ったほど楽しくない、マイナス、投資回収だいぶ先
★自動化の傾向
自動化ハイ、建て増し
自動化の前に、テストとして健全な認識を持つことから始める
■ファクトリーオートメーション
自動化の難しさ
従来人がやってたことは実は難しい、簡単に流れが見えない
人に知恵の集合→テストも一緒
・パラダイムシフト
人の役割の自動化の難しさ
無意識の意識化が第一歩
思考とかを自動化するのは大変
・テストプロセス全体を通して
無意識の意識化(振り返り)
テスト自動化に必要な知識を整理
全体をバランス良く考える
『機械にできることは機械に任せ、
人間はより創造的な分野で活動を楽しむべきである』
自動化の先にあるものを考えてみる
感想：
従来人がやってきたことは、実は難しいってのが心に残りました。
ちょっとした違和感に気づく、とかって自動化にはできないんですよね。
どこまで機械にできるのか、という見極めが大事ですね。そこが難しいんですけど。
(3)スマートフォンアプリのテスト自動化を始めよう 長谷川 孝二
■テスト自動化の現状
システムテスト
→自動化テストツール/フレームワークは多数
UI変更頻度が高いため、自動化しづらい
■システムテスト自動化のROI
・求められるもの
自動化スクリプト作成 高度なジャッジを求められる
スクリプトの保守
・現実的に得られるリターン
時間の短縮
複数のOS、バージョンで実行できる
・現実的必要な投資
自動化ツール選定
スクリプト作成
・現実的に実現できるスクリプトにするには
日付とかはユニットテストで頑張る
レイアウトは目視確認
機種依存問題は自動化諦める 内容次第で手動確認
・注意点
すべての画面、遷移は表示する
アラートも含むことが望ましい
繰り返し行う段階であれば、スクリーンショットの比較は自動化する
実行時間は0ではないのでテストケースの絞りこみは検討する必要がある
・利益を拡大する
時間の短縮
→時間路集中力をより高度なテストに振り向ける
リリース頻度の向上
複数OS機種で実行できる
→さらにテスト実行環境を増やす 端末の回転など
手動ではできないことができる
ロードテスト、メモリリーク、コンカレンシーテスト
■ツール
Appium
UIAutomation
Robotium
Espresso
UIautomatore
<両方>
Calabash
MonkeyTalk
・選定のポイント
スクリプト書けるか
テスト共有したいか iOSとAndroidで
※何が実行できるかはあまり重視しない
■まとめ
頑張らないROI
欲張らないテストスクリプト
(4)ATDD実践入門
■ATDDとは
受け入れテスト駆動開発（Acceptance Test Driven Development）
■歴史
受け入れテスト自体は昔から存在する。
TDDはSmallTalk界隈の習慣、KentBackが大々的に始める
Red green refacoringを回す
FIT
統合テストのためのフレームワーク
Fit/Fitness
Wikiで記述する
■BDD
TDDの中で、ユーザとしてテストを書きなさいとoKentBeckは言ってる
だが、UnitTestから入るのが簡単だが本来はそうでない
BehaviorDrivenDevelopment誕生
シナリオBDD フィーチャーとテストコード
スペックBDD テストコードと自然言語を同一ファイルに書く
■Scrum
Readyの定義 Doneの定義
→STDD
Specification by Example
重要なのはLiveドキュメントだ
■プロセス
仕様を顧客と話し合う
仕様について文書や付随する条件について表で書く
■目的
ユーザと共通の一枚絵を書くこと
仕様を把握できてること
■ツール
Fit/Fitness
Cucumber
RSpec
Spock
■アンチパターン
開発者が受け入れテストを書く
→時間のオーバーヘッドが大きい、テストレベルを意識しづらい、極端に多い、少ないが起きる
補助する人がいない
■理想と現実
DDD ドメイン駆動設計
Role ユーザが理解できる言葉で、協力しながら書く
テストエンジニアが書くATDDはどうなるのか？
■まとめ
誰にとっての受け入れテストか？
現状のツールはXPできるチーム成果である
勘違いすると生産性下がるので、自分たちにできる範囲でATDDやりましょう
(5)モデルベースドテスト入門〜テスト詳細設計を自動化しよう〜
朱峰 錦司
テスト自動化ってつまりはテスト実行自動化でしょ？
どこからテストケース湧いてくるの
本当にそんなことできるの？
1.テスト詳細設計とは
JSTQB
分析、設計、実装、実行、終了基準の評価とレポート
TestSSF
要求分析、アーキテクチャ設定、詳細設計実装、実行
決まったテストの方針に基づいて、テスト対象の仕様からテストケースを作る作業
→方針と仕様決まってれば自動でテスト作れんじゃね？
2.モデル
開発対象のシステムの振る舞いや性質を特定の観点で抽象化し表現したもの
一つのモデルで全ての仕様を表現するのは無理
様々な観点によるモデリング手法が存在
状態遷移
論理
組み合わせ
・注意点
システム特性に応じて、適切なモデリング手法を選ぶ必要がある
文法、メタモデルをしっかり決めて記述することが望ましい
3.モデルベースドテスト
モデルを活用してテスト成果物を作成する
主にテストベースはソースコードではなくモデルのため、ブラックボックステストに分類される
モデル→抽象化したテストケース
テストのモデリングのための規格
UMLTestingProfile
Testing and control Nation v3
論理パターンによるテストシナリオ
ディシジョンテーブル
・注意点
従来よりもテストパターンが多くなる
実行可能なテストにするためには詳細設計必要
4.モデルベースドテストの適用
モデル種類の決定
モデルの記述
テストモデルの種類の決定
モデルの変換方針の決定
修正
(2)状態遷移テストの適用例
デシジョンテーブルの適用例
CEGTest
組み合わせテストの適用例
PICTMaster
テストツール丸わかりガイドライン参照
5.導入のポイント
設計モデル記述によるメリット
テスト対象の仕様理解促進
仕様漏れの発見
必要なスキル
モデルリング
■まとめ
モデルベースドテスト
まずはモデリングしよう
(6)
LT
(1)手動テストからの移行大作戦 うらやま さつき
問題1 よく落ちる
身の丈にあった範囲で自動化しよう
問題2 作った人にしかわからない
誰にでもわかる自動化システムを作ろう
→誰にでもわかるテストを作ろう
Drive
Judge
Report から考えると
入力値があいまい→規定値のシートを作成、テストケースのフォーマット作成
判定方法があいまい→
自動化の前にするべきことはないか今一度ご確認ください
(3)激しいUI変更との戦い 玉川 紘子
GUIベースの自動テストを保守すること
・なぜ保守が大変か
UI、文言の仕様変更
可読性の問題
テストしづらい製品コードは指摘する
テストケースの元をメンテナンスする
クリックする、テキストを入力する→削除する、検索するなど
ユーザの動作自体は変わらない
アプリと対話する
基本動作、対象の組み合わせで各機能の操作を作成
個別のテストシナリオを作る
(4)有償ツールの選択ポイント 藤井
投資したら取り返す、倍返しだ！
事例
月数百人規模
毎日不具合、毎日クレーム、、、なプロジェクト
・使用ツール
QTP
ALM
・ポイント
QTPスクリプトの設計、作成
ALM、QTPの連携
→バージョン管理やレポーティングが楽々
なぜ高い効果をげられたか
→目的が明確
頑張るところを間違えないテスト自動化
有償ツールの機能だけでなく、ツール連携、サービスも確認する
ちなみに半沢直樹の食堂シーンの撮影はHP社の食堂だった
(2)組み込みクロス開発での継続的な実機テストの実行 井芹 洋輝
テスト自動化は重要です
テストレベルにとどまらず、責務や負荷の分散を行う
本来の目的に立ち戻り
テスト自動化のこれまでとこれから 辰己 敬三
(1)テスト自動化のこれまで
(2)テスト自動化の今
(3)テスト自動化のこれから
自動化研究の現状
TestAutomatorへの招待
(1)
たぶん最初の論文 1962 Automatic Progrm Testing
1990年代
2000年代オープンソース
Selenium 水銀の毒性を中和する 水銀 Murqury Poison
→テストツール大手だったマーキュリー社への皮肉
(3)
ワークショップ
AST
毎年特別テーマを設けて開催
2013 Test as a Service クラウドサービス 最近ホットな話題
STA
Cloid Testing
Test as a service
・�Test Automatorの位置づけ
TestLead
TestEninner
LeadAutomationArchicture
カバレッジ
狭い意味でのオートメーター
・Capgemini社
テストオートメーターの求人出てる
・・謄好肇・璽肇瓠璽拭爾寮嫐�
テスト内容の品質特性
テスト実行資材の品質特性←ここがオートメーターの責務
テスト結果利用時の特性
・・謄好肇・璽肇瓠璽拭爾凌与瑤� Linkedinで調べた
テストエンジニアは14万
テストオートメーター 58人
テストオートメーションは結構いる
・・泙箸�
専門家は10-15人
自動化は必須知識、ツール使いこなしたり、開発に関わることで、開発の一端に触れるのはよい経験
(7)懇親会
今までの自動化経験とかをお近くの方と話しました。
聞いてみると、やはりある程度融通が効く、かつ少人数のチームでないと
自動化導入するの難しいみたいですね。
LTも色々面白かったんですが、
自分が気になったのは、SikuliとDevNomiの話。
Sikuli
http://www.sikuli.org
これはちょっと調べてみよう。
なんだか長くなりましたが、以上です。
