2013/12/1(日) 「システムテスト自動化カンファレンス2013」に参加してきました。
公式サイト
https://sites.google.com/site/testautomationresearch/event
Togetter
http://togetter.com/li/597476
場所は日本オラクルさんです。
参加者は200人くらいでしょうか。申し込み開始から早々と満員御礼になるほどの人気ぶり！
最近弊社でもDevOpsやら継続的デリバリーやら、ちらほら耳にするようになり。。。
そんな私も、それらをテーマにした社内ワーキングに放り込まれました。
ということで、テスト自動化は私の業務にも直結しており、このイベントは前々から大変楽しみでした。
開催から10日ほど経ってしまったが、復習のためメモをダラダラを書き起こしてみる～
■開会の挨拶と注意事項
10時開始の15分くらい前から、本カンファレンスの趣旨とかの説明がありました。
意外だったのは、単体テストレベルではなくシステムテストレベルを自動化のターゲットにしている、とのことでした。
タイトルにもあるように「システムテスト」自動化のカンファレンス。興味深い。
■よりよいテスト自動化のためにちょっと考えてみませんか？
― スコープ、ROI、プロセスを中心に ―
近江 久美子 氏
■１．このセッションは何？
・よりよい自動化を達成するために、万能薬はない。
・ソフトウェアのユーザに価値がある単位で行われるテストの自動化を扱う。
・単体テストレベルはスコープ外。
■２．「よいテスト自動化」？
■テスト自動化の目的
・例：効率化したい
「テスト自動化の学習の時間や準備の時間 ＜ テスト自動化しない場合の再実行にかかる時間」になるようにする。
・手動で行われるテストは単純に置き換えられない。
■３つのスコープから考えてみる
１．スコープ
２．ROI
３．プロセス
■３．よりよりテスト自動化のために
★３－１．スコープを見極める
・自動化できる範囲と、自動化しておいしい範囲は必ずしも一致しない
・自動化しておいしいところを明確にして、自動化する範囲を絞り込む
・思わぬ追加作業が発生しないよう、ステークホルダー間で認識齟齬がない合意を行う
■スコープを明らかにする
①どの （工程とか）
②どこ （プロセスとか）
■「どの」テストを自動化するか
①テストレベル
単体テストなのかシステムテストなのか
②テストタイプ
機能テスト、使用性テストなのか、etc
■テストの「どこ」を自動化するか
①プロセスやアクティビティ
・疑問１：テストって、こんなにアクティビティってあったかな・・・？
（例： テスト計画、テストの分析と設計、テスト実装と実行、評価、レポート、終了）
・疑問２：テスト実行じゃないの？
■テスト実行は、3要素に分けられる
1. DRIVE ・・・ 操作、駆動
2．JUDGE ・・・ 判定
3. REPORT ・・・ 報告
■「自動化可能かどうか」と「自動化必須かどうか」の2点から見極める
①自動化しないと実現できないテストか？
②自動化できるテストか？
③自動化するとおいしいテストか？
■自動化しないと実現できないか？
- 例１： 数百人の接続想定の性能テスト
- 例２： 数ヶ月間連続稼動させる耐久テスト
- そのテストが「必要ならば」自動化は必須
■自動化できるか？
① 自動化しては意味が無いものはNG
（例：リハーサルに近いもの。それは本番同等に動かす必要がある）
② 制約があり自動化できない
(a)
乱数や外部情報に影響されて変わる部分。
シミュレートでできないことはないが、そこまでやるかどうかを考えること。
(b)
採用した自動化ツールができないこと
例１：印刷物の比較
例２：複数のツールを組み合わせる場合の連携（連携したほうが嬉しいのか）
■自動化は可能だが必須でないテストは？
・自動化の利点が活かしやすい部分は・・・
１．繰り返し行う部分
２．仕様が変わりにくい部分
（仕様変更にすぐに追随できないとすぐに使えないテストになる）
・回帰テスト、スモークテスト、GUIよりAPIのテストから考えてみるのがおススメ
（画面はけっこー変わるので）
★３－２．ROIを評価する
■その自動化、どのくらい価値があるか？
・ROIの評価で、おいしいとこだけ自動化する。
・保守・派生プロジェクトでも、時にはROIの観点から見直し、改善につなげる
・利益と投資に分けて考える
■利益
・最終的にはプロジェクトやプロダクトの利益につながらなくてはいけない
・テストにもたらされる変化を通して利益を分析する
・自動化はテストの品質・コスト・時間（効率）・スコープを変える
①品質
- 再現性、トレーサビリティの向上
- 自動化準備を通した理解度向上の影響
（自動化はあいまいをゆるさないので、事前に考えるきっかけになる → 結果的に品質向上に寄与）
②コスト
- 人件費を人間しかできない作業へ振れる
- 同じ作業の繰り返しのコスト減
③時間
- 案外、準備に時間がとられる。
- 人間とあまりにも違うスピードでテストやってもダメなことがある。
- でも、イイ点がある。それは夜間にできちゃう点。
- 属人性の低下、知識伝承の効率化（テスト実行の自動化ならば、手順やデータを確認すれば全部載ってる）
④スコープ
- 手動では困難なテストが可能に
この４つで考える。洗い出したら利益に結びついているかを確認する。
■投資
・４つの軸×時間で考える （時間による変化もお忘れなく）
・４つ ＝ ツール、テストプロセス、人、プロダクト
・時間： 初期コストと運用テストは異なる
・ツール： 外部調達か内部でつくるかで違いがある
・自動化により、プロセスや必要な人材が変わることがある
・プロダクトが自動化により生まれる制約を満たすか考慮する必要がある
（HTMLのボタンに適切なIDを振りましょう、という制約とか）
■注意点
・目的にあった利益と投資で計算する
・投資も利益も、時間やコストで計算する場合は更に見積りが必要
・厳密に評価するとそれなりにコストと時間がかかる
・おススメは、濃淡をつけてROIの評価をすること。
・全部見通すのは困難。ROI評価それ自体が割高になる恐れがある。
★３－３．プロセスを見直す
・適したプロセスでなくてはおいしくならない
・どこが手動テストと異なるか？ → 自動化するとそこのテストがなくなる
・ほんとうにそれだけ？
■テスト実行の場合
・テスト対象を自動化しやすいつくりにする作業が追加に
・自動テストスクリプトの設計、実装、セットアップが追加に
・自動テストスクリプトの構成管理が追加に
・レポート作成の時間は減る
→ 負荷が変わるものと、タイミングが変わるものがある
・テストを書きやすいようテストチームが実装チームに依頼したり
→ テスト以外の組織とかにも注意する必要がある
・自動化しても、テストプロセスが機能していなければ意味が無い
→ テストプロセスの整備からやりましょう
・自動化で変わっちゃう部分もあるが、変えることができる部分も発生する
★３－４．まだまだあるトピック
■スキル、チーム
・いろいろ知らなければいけないことが出てくる
・スキルを持った人を集めるか、やり方を工夫することでスキルが違う人同が士分担するアプローチも考えられる
・人材の話はこの後の辰巳さんの話でも登場する
■自動化されたテスト実行のバグの分析
・手でテストしている時と違う観点が出てくる。例えば、テスト自体が誤っているとか
・自動テストスクリプトのテスト実行前のレビュー実施
・自動テストスクリプトの設計、コーディングのルール定義
・ログやレポートの出力の設定（ちゃんとわかるように）
■４．おわりに
・テストは、プロジェクトやプロダクトの見える化を促進する
（バグ、リリースしてよいかどうか）
・テスト自動化により、テストは柔軟になる、幅が広がる
・テスト自動化を通して、よりよりテスト、よりよいプロジェクト、プロダクトを！
■事例から見るテスト自動化のポイント
TABOK関西
■１．検これについて by 前川さん
・活動は、レビューとテストの自動化が主な対象
・レビューについては、テスト設計コンテストのレビューとかをやってる
・テスト自動化については、自動テストのパターンを集めている。テスト自動化の事例をコレクション中。
■２．自動化事例をまとめてみた by 森田さん
・自動化の事例を２軸にマッピングした「テスト自動化マップ」を作ってみた
・アンチパターン
①自動化ハイ ・・・ 自動化自体が目的になる
②建て増し旅館 ・・・ わけがわからなくなる
■３．事例紹介 by 川口さん
・タイトル「事例からみるテスト自動化のポイント」
１．ファクトリーオートメーションとは
製造工程を自動化したもの。
・作業ミス軽減
・効率向上
・安全性の向上
２．システムテスト「自動化」の歩み
・２つのフェーズがある。
(1) フェーズ１：初めての自動化
・何をされてもとまらない用にできた。でもやりすぎた。
・稼動までの期間や保守が半端ない
・自動化の効果を実証しないくらいならやらないほうがいい。
・仕事が楽しくなったかどうかで検証した。
(2) フェーズ２：自動化の加速
・フェーズ１：一撃必殺
・フェース２：波状攻撃
・フェーズ１：建て増し旅館、ビッグバン自動化
（自動化の前に、テストとして健全な認識を持つことから始めましょう）
・フェーズ２：自動化ハイ
（もっと上手くできないもんか？）
自動化の難しさの根っこに気づく
・人がやってた仕事ってすごく賢い
・無意識にやっている。そこは自動化しにくい
・目に見えることだけ自動化すると様々なものが隠蔽される
自動化の成功の秘訣に気づく
・効果の計測、振り返りをベースとしたたゆまぬ改善
パラダイムシフトが起こった
・人間の役割を自動化することの難しさを理解する
・無意識を意識化する。人のやってることの表面化・形式化させることが第一歩
・人の思考や行為を自動化するには、高度な専門知識とかが必要
テストプロセス全体を通して
・無意識の意識化
・テスト自動化に必要な技術を整理
・テストシステムとしての最適化・構造化
テストに必要なアクティビティが最適に自動化されたシステムを目指す。
オムロン創業者・立石一真氏の言葉
「機械にできることは機械に任せ、人間はより創造的な分野で活動を楽しむべきである」
■ハンズオンセッション
実践で学ぶ、効率的な自動テストスクリプトのメンテナンス
伊藤 望
午後はSeleniumのハンズオンセッションに参加しました。
あと、環境構築やサンプルプロジェクトはこちらから。
https://sites.google.com/site/testautomationresearch/event/conference2013_handson
私、Seleniumはこれまで、横浜のJUnit写経会で触った程度でした。
そんとき書いたブログはこちら。
『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) に参加しました
http://makopi23.blog.fc2.com/blog-entry-74.html
今回のハンズオンイベント、とても勉強になりました～
教材もサンプルも充実しているし、補助のTAさんも人数いたし。
Seleniumを初めて触る人にとっては非常にわかりやすい教材だと思います。
makopi23のハンズオン成果物をGithubにアップしておきました。
https://github.com/makopi23/STARHandsOn-release
招待講演/クロージングセッション
テスト自動化のこれまでとこれから
辰巳 敬三 氏
ハンズオンが終わった後、これが最後のセッションだったので聴講しました。
これまでのテスト自動化の歴史について纏められていました。
よくこれだけ調べたもんです。興味深い内容ですね～
★感想：
非常に勉強になりました。
特にオープニングセッションの近江さんの講演は、テスト自動化について非常によく纏まっていました。
この資料、あとで見返すだけでもとても復習になりました。
あとSeleniumのハンズオン、これも素晴らしい。
実際、このハンズオンで学んだことを早速業務に使ってみました。
こーゆう、ハンズオンで実際に手を動かして自動化を体験するのはすごくいい取り組みですね。
資料もサンプル題材も、今後もずっと使えるものに纏まっていたと思います。
ハンズオンの平行して実施されていたセッションが聴講できなかったのが悔やまれます。
が、大変充実した１日で、勉強になったし楽しかった。
関係者のみなさま、ありがとうございました～
