システムテスト自動化カンファレンス2014(2)「テスト自動化のパターンと実践」
2014/12/14(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2014で聴講したセッションから数回に分け、まとめたものを紹介しています。
セッション(再掲)
1.オープニング：1時間で分かるSTA /鈴木 一裕 →<資料>
2.テスト自動化のパターンと実践 /.reviewrc →<資料1>/<資料2>/<資料3>
3.GUI自動テストの保守性を高めるには /伊藤 望 →<資料>
4.状態遷移テストにおけるテスト設計と実行の自動化 /きょん →<資料>
5.ビルドプロセスとCI /長谷川 孝二 →<資料>
6.社内スマホアプリのビルド配信ツールによる自動化事例 /赤根 稔朗(Yahoo! JAPAN)
7.Test Automation Patterns 2014 冬コレ！/松木 晋祐 →<資料>
前回は「1.オープニング：1時間で分かるSTA」でしたが、今回は「2.テスト自動化のパターンと実践」について紹介します。
2.テスト自動化のパターンと実践 /.reviewrc
[1]テスト自動化のパターンと実践
(1)テスト自動化パターン
- 本発表は、関西独自の内容。
- ちなみに、松木さんの仰るテスト自動化パターンは http://testautomationpatterns.wikispaces.com/の内容。
(2)テスト自動化に関する問題/課題
- テスト自動化は難しい(ありがち)
始めるのに勇気と力がいるし、みんなが嵌まる罠がある。
- 最初：楽しい→後々：辛い
保守が大変。
(3)どうする？
- 経験をアクセスしやすい形で公開しよう！
関連する問題に気付きを与えることを考慮し、パターンランゲージが最適と判断した。
(4)パタンランゲージ構成
- コンテキスト
問題の背景の事情 - 問題
- フォース
問題発生の要因となる外部の力 - 解決
- 結果
例：「ダッシュボード」
- 結果
「記録したメトリクスをテスト仕分けなど自動化システムの改良に用いることができるようになる。」
(5)パターンランゲージの活用方法
- 自動化ユビキタス言語として活用
自動化における問題。
→言語化しにくい
例えば、下記のように言葉を与える。
メリットは、下記3点。
- 共通の会話ができる。
- 問題があっても、解決方法を検討できる。
- 経験を伝えるツール
(6)GitHubに公開中！
URL
https://github.com/KenColle/AutomationPatternLanguage
「是非、Pull Requestして下さい。」とのこと。
[2]皮を剥く
テスト自動化を妨げる不安定なところを取り除いて、テスト自動化を安定させる。
(1)もっと自由に自動化したい！
「自動化のボトルネック」
- 操作技術で引っかかる人が多い(経験上)
GUI画面はコードの中を見るような感じで捉える。もしかしたら、API化できるところもあるかも。
- 対象をホワイトボックス的に見る
(2)皮のむき方
- GUIだけのように見えるけど、その奥にはシステムがある。 GUIだけでなく、テスト対象のシステムも着目すること。
- キーマウスエミュレーション なかなか難しい(操作が上手くできないなど)
- テストしやすいものを自動化 単体テストでない操作開始トリガーを変えているだけ。
- 神関数
- 取り組みのポイント
(3)新たな皮をかぶせる
アプリケーションドライバ
操作層とテストシナリオの層を分離
- テストシナリオを外部仕様の言葉(言語)で書けるようにする。
- 取り組んでみると、トレーニングしたらテスターが自分で自動化スクリプトを書けるようになる。
(4)まとめ
- システム＝プログラム
- 操作上のボトルネックを取り除く
- むいた皮に注意
[3]「自動家をつくる！」
(1)自動家
テスト自動化×CI→プロジェクト全体の自動化。
- 自動化術(知識)
- テスト自動化の道具
- 環境構築構成管理の道具
- ビルドデプロイの道具
- 自動化脳(思考)
- 自動化主義(マインド)
(2)重要性
未然に防いだ勇者が重要。
(3)自動化の価値
- 合理性・効率性の向上 仕事が早くなる！
- 本懐の仕事に近づける 本来やるべき仕事：経験的にプログラムできる時間は全体の半分くらい
- 楽しい！ 問題を技術課題へ転化できる
(4)まとめ
- 自動化は、仕事を変えていく。
- 創造的な仕事。
(5)自動化パターン
「自動家に成る」
所感
「テスト自動化のパターン」は、現場の知見や経験を結晶化した形式知なので、これからテスト自動化に取り組むときや挫折しそうになったときに参照し、解決の糸口として活用していこうと思う。また、「皮を剥く」でもありましたが、テスト自動化のボトルネックが操作技術なので、別のアプローチを考えることも必要だと痛感しました。最後に「テスト自動家」を組織で貢献するため、マインドや方向性をステークホルダと根気よく議論することも課題だなと思いました。
