システムテスト自動化カンファレンス2014
システムテスト自動化カンファレンスに参加してきました。参加して良かったです。
日時：2014/12/14 10:00～18:30
会場：ヤフー株式会社
http://connpass.com/event/9618/
概要
システムテスト自動化は普及のキャズムを超え、実践段階となっています。 一方で適切なテスト自動化アーキテクチャを欠いた闇雲な自動化による 失敗例も国内外で複数聞かれます。 システムテスト自動化の普及と実践を目的とするSTARとしても、自動テストの対象であるソフトウェアやサービスが成功のためのアーキテク チャやソフトウェアパターンを作り、広めてきたようにシステムテスト自動化もアーキテクチャとパターンを共有すべき時期が来ていると考えてい ます。 今年のSTAC2014では現在でも深い知見を与える書籍「Software Test Automation」のSTAR有志による翻訳書「システムテスト自動化 標準ガイド (CodeZine BOOKS) 」( http://www.amazon.co.jp/dp/4798139211 )を中心に、実践者、Webで集められている各種のアーキテクチャとパターンを紹介し、参加者の皆様と共有します。 また、単に知識として共有するだけでなく、自分たち自身でテスト戦略、テスト設計、アーキテクチャ、パターンを考えていくというハンズオンも 用意しています。 是非、お誘いの上、ご参加検討頂けると幸いです。
感想
定員は200人ですが満員でした。また、年齢も20代後半から50代まで幅広くいたように思います。 今回のセミナーのコンセプトは
「日本にテスト自動化エンジニアを普及したい」
にあると感じました。 セミナーで紹介する内容もテスト自動化エンジニアに興味をもってもらう事に重きを置いているように思いました。現在のシステム開発の流れとして、テスト＝品質は勿論だが、テストの役割が拡大しているのではないか？と感じるものがある。
テストを沢山やることが本当に品質向上に不可欠？（あてずっぽうのテストを沢山やることは非効率）
現在の主流がアジャイルの様なCIが主となるのでは？（テストの回数が増えるので効率良くテストする必要性）
今までの様なテスト方法で、これから求められるような品質は担保できるのか？（求められる品質が上がっているし、技術も進化している）
注意として「テスト自動化は銀の弾丸ではない」です。全てを自動化することは不可能だし手作業でのテストも十分必要ですと謳っている。 実務に落とし込むと
「最もテストの重要性が高い所は自動化してリスクを軽減し、空いた時間を手作業のテストに回しましょう」
となります。ここまで来るとコンサル的な視点を持っているエンジニアしかできない職務に感じます。 （他のテスト自動化勉強会でも「今後のテストエンジニアはコンサル的な能力がないと生き残れない」と言っていたな）
ただ、このような職務能力（テスト自動化エンジニア）は第一世代が色々とやってくれた現在、今、能力を身に付ければ第二世代として社内や社会に重宝される時代が来るかも知れない。
実際にやってみるとしたら・・・
製品サイクルの長い製品に適用すれば費用対効果は高そうで逆に失敗したら赤字 →開発初期からテスト自動化エンジニアの参加が必要
→何か最もボトルネックになるか？を判断できるセンスが必要
→なんとなくなってみて時間ばかり掛かるなら専門家に依頼した方が良い
→開発初期からテスト自動化専門家が必要になる
→当然ながら、失敗できないものは専門家に依頼する
製品サイクルの長い製品は専門家に依頼し、短いものは自前でまかなうのが落とし所でしょうか？ また、xUnitでの単体テスト程度なら導入は容易だが、システムテストの自動化までする場合は専門化に依頼した方がトータルの費用対効果は高くなると考えられる。テスト自動化に求める内容と目標値をシッカリと数値化して取り組む必要があると思います。 システムテスト自動化と開発者の心をくすぐる題目だったが、話を聴くと、やはりテストの本質を見極める能力を身に付けなければと痛感させられた。
メモ
10:30～オープニング：1時間で分かるSTA
基本的に販売した書籍の紹介内容でした。会場で用意した書籍は完売しました！ （パワーポイントにX/Xとページ数を表示するアイデアは良かったな）
テスト自動化エンジニア（Test Autometer)
自動化での注意点は手動テスト実行より技術力が必要になる。
手動テストの方が有利な面もある ⇒自動化した分だけ手動テストを充実しよう
ポイント
自動化ではメンテナンスコストこそ重い 初期は大変だけど、やってしまえばやれてしまう。メンテナンスが本当に大変。
偉い人のサポートが継続的に必要
11:30～テスト自動化のパターンと実践 /.reviewrc
話が実践的で凄く面白かったです。自動化するとは何か？その本質を考えさせられました。弊社の開発はC#が主流なので、今回紹介された Friendly は使ってみたいライブラリです。別プロセスにアクセスできるようで、米Microsoftでも好評だったとのこと。
ポイント
テストの重要性を知る人間の管理が必要（自動化と手動の重要さを分かっている人）
アプリケーションドライバって何？（技術的な部分は隠蔽）
システムをプログラムとして見る（開発者の開発センスが問われそうだ…）
13:15～STA GUI自動テストの保守性を高めるには
Seleniumでの説明でした。
環境の準備 →コンパイル・デプロイから手作業を排除して不安定な作業は自動化する。
コンパイル・デプロイの自動化は費用対効果が高い。 環境の保存 ⇒環境はスナップショットで冷凍して、そこから呼び出すのが一番簡単ですよ。
ポイント
ページオブジェクトデザインパターンが有効
保守コストをできるだけ低くするにはどうしたら良いか？のアイデアを事前に考えておく必要がある。 （そう言えば、VisualStudioでクラス構成図だしてみようとして忘れていた）
14:20～STA 状態遷移テストにおけるテスト設計と実行の自動化
テストの本質を考えさせられました。自分がテスト自動化を検証した時は、簡単な箇所だけの自動化で満足して複雑になってしまった重要な機能が自動化できなかった。テスト自動化が表現し難い仕様って…？その仕様、システムの品質に影響をおよぼすのではないか？
ボトルネックの箇所を自動化しよう
？バリューストリームマップって何？リーン開発の本質に載っているそうだが？
？デプロイメントパイプラインって何？ →全体を俯瞰して局所化しないことが重要。普通は局所化してしまうが、それでは費用対効果が低い。 何が最も自動化によって費用対効果が高いか？を考えよう。 費用対効果はテストだけでなく開発・設計・保守・政治？・コミュニケーションの全てを母数として取ることが本質を見落とさない。
？スモークテストって何？
スモークテストを考える事は”本当は”難しい。
？状態遷移グラフって何？状態遷移グラフで状態を網羅するってどういうことでしょう？
効率良くテストをする。 1つの例として、コードを変更した箇所がバグるのでコードを変更した箇所に関係するテストケースを自動生成するような事もした経験があるとのこと。
15:15～ビルドプロセスとCI
CIについての勘所についての説明です。現在Jenkinsを使っているので何となく理解できます。
16:00～社内スマホアプリのビルド配信ツールによる自動化事例
Yahoo!さんの自動化の実例でした。 私のお手軽に始めた構成（クリーンな環境でビルドする事やリリースやコードカバレッジ）が似ていました。また、やってみた感想も同じでした。お手軽な割には費用対効果が高いです。費用対効果と言うより、開発エンジニアが面倒な事から解放されて嬉しそうです。
- JenkinsにBuildxmlを渡して動的にビルドを行う。
17:15～Test Automation Patterns 2014 冬コレ！
やっぱり「テスト自動化だが、テストの本質が最も先に考えなければならない問題である」と考えさせられます。個人的にはテストエンジニアとテスト自動化エンジニアは一緒になると思います。理由としてはテストエンジニアの役割は海外の人件費でとかなりそうで、国内のエンジニアはテスト自動化エンジニアとしてのスキルを身に付けなければならない状況になるのでは？と思います。結果、国内にはテストエンジニアもテスト自動化エンジニアも両方できる人になるのでは。
テスト自動化を実践して、報告レポートに対して要望が出てくるようになれば成功！
テスト自動化エンジニアに必要な技術は開発経験でテスト設計経験は重要視されないようだ？
アメリカの様にテストエンジニアとテスト自動化エンジニアを別けるか？
テストの役割が拡大している。
自動化をすると開発インフラとしてのテストになる。 当然、品質保証の役割もあるが、もっと広域の意味を成すと思われる。
テストエンジニアは今後重宝される存在になれるのでは？
