オフショアでのUIテストの自動化に向けて

UIテストの自動化に向けて

UI Test Teamの現状の問題と課題

モチベーションの問題
- スキルアップ・成長する楽しみがない
- 同じ画面を何度も見直し、同じ操作を何度も繰り返す作業で非常に退屈
  - -> 品質の低下に
- サポートブラウザの増加＋バージョンによる確認の手間
回帰テストの負担
- バグ修正・仕様変更などによるデグレード確認が頻繁に行われる
コストの問題
- コストとリソースの負担が大きい
- やり甲斐を持てずに辞める人が多い
- 都度教育する手間
- 手動テストの代替手段について調べる時間を確保できない
- ツールやスクリプトの構築/管理方法を学ぶ時間を確保できない
- 案件によっては、テストの自動化に適していない場合がある
- 複雑すぎて自動テストに適していない場合がある
- テスト実施者、QAが、手動テストに慣れていて自動化に不安を感じている
- 日本の場合人件費が大きいので、リターンを得るには膨大な時間が掛かる
- 自動化レベルの人が(人件費が高く)採用できない

自動化って？

何を自動化できる？（例えばSelenium）
- ユーザー操作で出来ることは殆ど実行
- クリックやスクロール・文字入力、ウィンドウサイズの調整、Cookieやセッション情報の書き換えが可能
- スクリーンショットを撮ることもでき、レスポンシブレイアウト等の表示確認やテスト実施時のテストエビデンスとして画面を残しておくことができる

問題の改善策

フローなど、手動で頭を使いながら作業する箇所はテスターがやる
修得・実践レベル次第でインセンティブ or 給与up

自動化のやり方を吸収してもらい、次のステップへ行かせるための架け橋にする

やる気・品質の向上に繫がる

段階を設け、ステップに応じて給与を上げる

  1. 手動によるテスト実施
  2. 手動テストのためのテストケース作成を補助
  3. 手動テストのためのテストケースの構成から作成
  4. 自動テストのためのテストケース作成
  5. 自動テストのためのテストケースの構成から作成
  6. テストコード作成
  7. メンテナンスツールでの担保

難易度と効果の見込み

UIテスト自動化において、テストコードを書かないレベルであれば誰でもできるが、ツールの使い方を覚える&実践するまでに1週間はフルで掛かりそう。(初回はテストケース作成の3倍掛かると言われている。)
きっちり自動化する&できる箇所を見定め、作成~メンテナンスまで1通り運用できれば、効果に時間は掛かるが時間&リソース短縮に繫がる

そもそもオフショア（ベトナム）にするのは何故か

物価、労働コストが日本の4分の1
平均年齢が若い（28才）
人が早く、多く見つけられる可能性が高い
国家レベルでITの育成に取り組んでいる
Selenium技術者が多い
親日
ITは人気がある
面倒みの良い国民性

懸念点

言語
- 英語
  - メリット
    - 人材を取りやすい
    - 1通りのフローが出来れば、他の国でも汎用が利く
  - デメリット
    - 日本とのやり取りの遅延
    - 翻訳の手間
- 日本語
  - メリット
    - コミュニケーションが容易にとれる
  - デメリット
    - 採用し辛い
    - 日本語の修正
人数
- 現状は1PJにつき5~6人程度
- 自動化しても最初は1PJにつき4人程度必要なのではないか
  - 自動化ツール作業: 2人
  - 手動テスト: 2人
スケジュール感（必要な作業）
- 募集サイトの作成
- リソースの確保
- スケジュール作成
- 採用人数の決定 - インターン生
  - エンジニア
  - 言語レベル
- 採用技術レベルのレンジを決定
お客様への提示方法
- 自動、英語、日本語のテスト、どれかを選んでもらう？
- ROI(Return on investment : 投資回収率)での計算

自動化テストの目的

欠陥を摘出する
品質を保証する
欠陥の作り込みを防ぐ

テスト工程

ユニットテスト(開発者) > 総合テスト(開発者) > システムテスト(QA) > 受け入れテスト(顧客)

UIテストの自動化

基礎知識
- grunt
- gulp
- npm

基本的な自動化ツール・フレームワーク

| - DOMツリーを辿り特定の要素・属性を判定 (UI変更に強い、レイアウト崩れは判定できない)
    | - Selenium + Node.js
    | - Calabash-iOS,Calabash-Android
    | - Tuneup JS+Travis CI (iOSのみ)
    | - KIF (iOSのみ)
    | - Robotium (iOSのみ)
    | - Visual Studio
    | - uiautomator (Androidのみ)
    | - × Espresso (不安定)
    | - × Robolectric (不安定)
    | - mocha
    | - CasperJS
    | - Jasmine (easy connect Selenium)
| - 画像認識を利用したGUI操作の自動化 (レイアウト崩れまで評価、ただしUI変更に弱い)
    | - Sikuli
    | - monkeyrunner (androidのみ)

コードを書かないGUI ツール (FireFoxのみ)
- Selenium IDE
メンテナンス向上ツール
- Jenkins
  - Selenium + Jenkins
  - KID + Jenkins

テストの機能で分ける？

テストの種類

単体(ユニット)テスト (モジュール単位)
- 関数やクラスメソッドをテスト
- 自動化ツール (PHPUnit,SimpleTest)
- メリット = テスト実施自動化, テストケースを残すことによる同水準のテストが再実行可能
結合テスト (モジュールを組み合わせた試験)
- Webブラウザからの操作
負荷テスト (高負荷時の耐久性の試験)
受け入れテスト (顧客による試験)
リグレッションテスト(回帰テスト)
- プログラム変更時、予知できない影響範囲を検出するために、関係のなさそうな機能も含め、すべてのテストを実施し直す

テストケースの品質

↑ 知的作業

何をテストするか
どうやってテストするか
- どれくらい欠陥を見つけられる？
- テンプレート化することで複数のことを確認できるか？
- 期間、実行レベル的にコストはどの程度かかるか？
- 仕様変更に対してどの程度汎用性を持っているか？
テストケース作成
実行

↓ 事務的作業

自動テストの評価属性

- 変更時のメンテナンス性
- コストの低さ
- 正確かつ再現可能な結果であるか
- 他ツールやフレームワークとの連携
- ユーザビリティはどうか
- これからも導入を続けられるか
- 検証、本番環境での実行の差異はどの程度か

自動化の仕組み作り構成 (Seleniumの場合)

結合テストのケース手動作成
仕様確定・実装完了
FFアドオンのIDEで単体テストを作成
Firefoxでテスト開始
平行して手動テスト開始
FFでのテスト・確認が終わり次第、テストスイートへ保存
Chrome、その他Driverを用いて自動テスト実行
手動テスト&自動テスト完了、チケット起票
バグ修正
手動による修正確認
一通りのリグレッションテスト

大事なのは仕組みの導入であり、誰でも動かせる構造を作り上げる。

   テストケース作成開始タイミング

IDE（もしくはBuilder）でのモジュール単位でのテストスイートを、HTMLやJS周りの開発が一通り終わり次第（CSSが組み込まれclassやidが指定できるようになり次第）、テストケース作成開始   

手動テストケース作成

自動化と同時に自動化では賄えない部分（表示崩れ、バッチ系統、DB操作が必要な挙動、異常系も？）のテストケースを開発と並行して行う   

マルチブラウザ対応

（Java, python, Ruby）最新のWebDriver / サードパーティの各Driverをインストール＋IDEから出力したものを修正しつつ、各ブラウザで回す（最新のブラウザに合わせ、Driverを常にインストールしなければならない） →最低限簡単なテストコードは書けなければならない。  

監視

Jenkinsなどのメンテナンスツールで、1PJにつき1人を配置し監視 

tail -f /dev/null

If you haven't had any obstacles lately, you're not challenging. be the worst.