「システムテスト自動化カンファレンス2014」に行ってきました。
テスト自動化研究会が主催する「システムテスト自動化カンファレンス2014 」に行ってきました。
システムテスト自動化カンファレンス2014 - connpass
開催概要
- 2014/12/14(日)10:00-18:00
- ヤフー株式会社@ミッドタウン・タワー
- 主催
- 参加者数 約200人
- 参加者の50%がエンタープライズ系業種の人。Web系少なかった。
- 資料
- togetter
会場雰囲気
- 机もあるし電源もあるし無線LANもあるし良い環境(*´Д`*)
- 一方で、発表の画面が4つのモニターで構成されていて中心に十文字に線が入っていて邪魔だった(;´Д`)
学んだことと所感
- 自動化というとついツールの話になってしまうが、まずテスト戦略が必要。
- 自動化は、「効率」を重視するのではなくて「効果」を重視すべし。
- 何を重要視するか要検討。
- このことは、「ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解」にも書いてあった。
- 『「効率」が落ちても、「効果」のある施策を。』
- 一方で「つまらない作業も自動化したい」と「その作業必要?」の自問自答。
- 簡単な自動化だけで終わらせない。
- よくある感情起伏:「よっしゃ自動化や!」->「テスト書くの楽しー」->「なんかめんどくさくない?」->「メンテつらい。。。」
- テスト自動化されたものは、メンテナンスコストがかかるもの。(=しっかりメンテナンスしていく意識と覚悟)
セッションメモと雑記
開会+注意事項
- テスト自動化は「普及のキャズム」を超えた。
- キャズム:新製品・新技術を市場に浸透させていく際に見られる、初期市場からメインストリーム市場への移行を阻害する深い溝のこと。
- テスト/テスト自動化について市場の需要がある。
- 事例:米政府があるサイトを作ったが不具合が多かった。そこでSeleniumの開発者が米政府に呼ばれた。
- STARの活動:テスト自動化というとツールの話をになってしまうので、ツールに依らない知識/ノウハウを体系化したい。
- イケテス=イケてるテスト
- 参加者へのアンケート結果の共有
- あとで共有されるはず。
- バグの重要性の定義と共有すべし → テスト戦略へのインプットでありアウトプット。
1時間で分かるSTA
- 使える文言
- 聴講中、頷き推奨!首かしげ禁止!
- 「システムテスト自動化 標準ガイド (CodeZine BOOKS)」の内容の紹介
- 会場で売っていた分が即売した。
- ダメなテストを自動化してもダメ。
- テスト自動化はメンテナンスコストが大きくかかるもの。
- 自動化で浮いたコストは、人ならではのテストを行う。
- あとで調べる/読む
テスト自動化のパターンと実践
- 関西の勉強会グループ(.reviewrc)から発表。
- テストに関する問題/解決をパタンランゲージとして表現したい。
- コンテキスト、背景
- 問題
- フォース(外部からの力)
- 解決
- 結果
- 「皮をむく」の発表
- Friendlyの紹介。
- http://www.codeer.co.jp/AutoTest
- UIは変更が多く壊れやすいので、ユーザロジックをテストすべし。
- ホワイトボックスでテストする。
- 「自動家を作る」の発表
- 問題を解決した人だけでなく、未然に防いだ勇者にも賞賛を。
- 所感
- グループの方針、面白い。「色んな物をみんなで集まってレビューしていきます。文書や発表資料から、実際のソフトウェアまでジャンル様々、色々見ていきます!多分!」
- テスト自動化エンジニアという職種、日本でも今後できそう(必要そう)。
GUI自動テストの保守性を高めるには
- TRIDENTの社長さんの発表
- 主にSeleniumの話
- 保守コストを以下に減らすか。
- 各テスト作成方法にメリット/デメリットがある。IDEで作る。プログラムで作る。エクセルで作るなど。
- メンテする人のことも考えて、選択を。
- まずは、コミット->デプロイの自動化すべし
- 良いテストは、良いデプロイ(準備)から。
- 保守性の高いテストスクリプト作成は、保守性の高いプログラム作成と同じスキルを要する。
- UIのテストのデザインパターン:ページオブジェクトデザインパターン
- ページをオブジェクト化し、それ経由でテストロジックを流す。
状態遷移テストにおけるテスト設計と実行の自動化
- ボトルネックになっているところをテストしないと意味がない。
- テストの4象限の分割を意識すべし
- 良い本
- 実践例:テストする機能については巡回セールスマン問題のようなアルゴリズムで自動生成して、網羅的にテストした。
- デプロイパイプラインを効果的に実現するには、テスト戦略が必要。
- テスト戦略がないと自動化の効果は薄い。
ビルドプロセスとCI
- いろんなCIツールがでてきた。
- 後処理と前処理の自動化、大事。
- Travis CI
- Github連携のCI環境
- リポジトリ(パブリックは無料)に対応している。
- iOSアプリをビルドできる。
- Travis CI - Free Hosted Continuous Integration Platform for the Open Source Community
- walter
- go製のパイプライン実行ツール。
- プラグインが豊富なJenkinsへのアンチテーゼ
- シンプルなビルドパイプラインツールwalterをリリースしました | Advanced Technology Lab
- DeployGate
- DeployGate - 開発中のアプリの配布を、びっくりするぐらい簡単に
- mixi社製デプロイサービス
- スマフォアプリのデプロイ/リリースの仕組み
- パイプラインにこだわらない。意味のあるビルド単位で。
社内スマホアプリのビルド配信ツールによる自動化事例
- ヤフーの中の人
- ヤフーのリリース工程
- レビュー(レビューコメントなど)を見る→意思決定→開発→リリース
- 1サイクル:1ヶ月 or 2週間
- 毎日フィードバックを受けるようにしている。
- 社内で作ったスマフォアプリリリース管理システムの紹介
- バックエンドはJenkins(の動的ジョブ実行)と、Yahoo!ボックス
- 社内で統一的なアプル管理が必要。
- 社内の人からフィードバックし合える。
- テストをお願いするために、チームでステッカーを作った。人参をぶら下げる。
- コミュニティーベースで進めている。
- 他部署のアプリの評価は、非公式でやっている。善意でやっている。
- 所感
- 改善活動として草の根活動を成長させたのがすごい。
- 最初「Jenkinsじゃん」と思ったが、フィードバックし合える環境まで含めると大きな差異あった。またそこが肝。
Test Automation Patterns 2014 冬コレ!
- Test Automation Patternsの抜粋説明。
- TestAutomationPatterns - home
- テストの実践パターン集
- テストにタグをつけるとよい。機能テストでも負荷テストにもなる可能性があるため。
- 工数のほとんどが、テスト自動化の環境作成
- 「実行時間が長くなったら解析時間も長くなりました」はダメ。注力領域を絞るべき。
- 自動テストに必要な要件。
- テストを駆動(実行)していること
- 結果を判定していること
- 結果を報告していること。
- 海外では「テストエンジニア」と「テスト自動化エンジニア」を分けられている
その他
資料のリンクを追って見つけた面白いこと。- テスト自動化のROIを算出できるツール