【テスト自動化のプロ】SHIFT社が語る、成功するテスト自動化へのステップと その魅力！ 自動化の導入を迷っている方向けに、自動化のリアルな現場をお伝えします！ 参加メモ - 2014/12/02(火)

2014/12/02(火)19:30-20:45に開催された
『【テスト自動化のプロ】SHIFT社が語る、成功するテスト自動化へのステップと その魅力！ 自動化の導入を迷っている方向けに、自動化のリアルな現場をお伝えします！』
に参加してきました。

以下、イベント中に取ったメモです。

イベントの募集概要（募集サイトより引用）

「テスト自動化」はここ数年非常に盛り上がっているキーワードの１つで、
世の中には数多くの自動化ツールが出回っています。
しかし、実際に着手するとなるといったいどこから手を付ければ良いのか分からない、
チャレンジしてみたけれど続かずに終わってしまった…という方も多いのではないでしょうか。
SHIFTで実施してきた様々な自動化プロジェクトの経験を元に、
自動化の適切なステップや「やってはいけない」パターンについて紹介します。

テスト技術と自動化技術の両方を兼ね備えたテスト自動化エンジニアはそう多くはありません。
外部から採用？社内で発掘？育成？
後半のセッションではSHIFT社内で9ヶ月実施してきたテスト自動化エンジニアの採用、発掘、育成を例に
テスト自動化エンジニアの発掘と育成の方法について検討します。

19:35 - 20:05 玉川紘子氏「テスト自動化・適切なステップとアンチパターン」

• 自動化のアンチパターン
  • Test Automation patterns
    • http://testautomationpatterns.wikispaces.com/Test+Automation+Issues
  • プロセス
    • テストコードの品質が悪い
    • テストデータが整備されていない
  • マネジメント
    • ROIの期待が高すぎる
    • 手動テストチームとのコミュニケーション不足
  • 設計
    • テストが細かすぎて保守できない
    • （メモできず）
  • 実行
    • （メモできず）
• 自動テスト「設計」のアンチパターン
  • 外部変動要素に対する考慮不足
    • 日時依存
      • 成功していたテストが、日が経つと失敗し始める
      • [対策] アプリケーション内で日時をコントロールする機構を用意
        • 設定ファイルで日時を管理
        • テストフィクス茶は設定した日時を元に固定
      • [対策] テストコード側で吸収
        • 現在日時＋X日など計算できるようにしておき、動的にフィクスチャを生成
      • [対策] 運用でカバー
        • 0時を過ぎてから実行することで、途中で日付が変わらないようにする
    • 順序依存／データ依存
      • 実行タイミングや順序によってテストが失敗する
      • [対策] どんな順序で実行されても困らないように、テストケース内で使うデータは各テストケースで独立に準備
      • [対策] 各テストケース内でそれぞれデータを作る
        • 例）【前処理】削除対象のデータを作成　【実施】データを削除
      • [対策] どうしても難しい場合は、各ケースでどのデータに依存しているのかを明示
      • [対策] 前処理・後処理でデータを操作する場合、極力テスト対象の製品コードを使うのを避ける
        • SQLやAPIを使って投入
    • 変更に弱いテスト
      • [対策] PageObjectパターンなどを使ってテストを構造化
        • 画面の要素に依存する部分を、PageObjectとして切り出す
    • 手作業の介在
      • [症状] 自動テストの実行の複数ステップに人手が介在
      • [対策] 手動と自動の領域を切り分け、全自動化できるところにチカラを入れる（＝自動化のためのテスト設計）
        • どうしても手作業が入ってしまう場合は、割り切って「手動テストの効率改善」として実施
      • [対策] ユーザー作成、データクリアなどは、この機会にスクリプトを用意してしまう
        • 一度作ってしまえば、他の工程でも便利に使える
    • 内容・結果がわかりにくい
      • [症状] 自動テスト実行結果の見方が、自動テスト担当者しか理解していない
        • 不具合にきづいても、気づかれない、再現方法がわからない、必要な変更が伝えられていない（テストコードが古いまま）
      • [症状] アプリケーションのテストのうち、どの範囲を自動テストで担保しているかがチームで理解されていない
      • [対策] テストフレームワークで、レポーティングを強化する
        • 失敗時のキャプチャ取得
        • 各操作のログ出力
      • [対策] レポーティングまで含めた運用フローを整備する
        • 自動テストのNGが、不具合なのかテストが古いせいなのかは、自動テスト担当が一次切り分け
      • [対策] 途中のキャプチャも取って、マニュアルの解析との差異を小さくしてあげる
        • 特にCIでまわしているときには、自動チーム内でも有効
      • [対策] 自動化担当以外のメンバー（手動テスト担当、開発者、マネージャー）に対して、定期的に啓蒙活動を行う
        • KPIを取る
          • 自動化で発見されたデグレの数、率
          • 自動テストのカバレッジ
        • 活動当初に範囲に入ってなかった部分でも、後からリクエストしてくれればよい
        • 開発者が自分でも書いてみようと思ったら、儲けもの
        • 開発者との関係が築けてきたら、さらに自動化しやすくするためのリクエストを出す

20:05 - 20:35 太田健一郎氏「テスト自動化エンジニアの発掘と育成」

• 案件に対し、人材枯渇、採用、発掘、育成が急務
  • 自動化アーキテクト
    • 自動化対象・範囲の決定
    • ツールの選定
    • テストコード規約作成
  • スクリプトエンジニア
    • テストスクリプトの実行・修正
    • テストスクリプトの作成
    • ナレッジの蓄積
    • ツール調査
  • テスト設計者
    • 通常のテスト設計
    • 自動化のテスト設計
• 自動化アーキテクト候補
  • SNSと勉強会経由で、採用したいスキルと経験を持った人
    • お誘いするのが難しい
  • スクリプトエンジニア候補（人材紹介会社経由）
    • プログラミングの経験が少ない
    • テストの経験が少ない
  • 社内から探してみた
    • 業務ではテスト設計やテスト実行を担当
      • プライベートでOSSやアプリケーションを公開し、利用されている
        • テスト設計の経験がある
        • プログラミングの経験がある
        • 独自であっても要件定義→運用の経験がある
      • 特に教育もなく、スクリプトエンジニアとして参画可能
    • 学生時代もしくは前職でプログラミング経験がある
      • テスト自動化集中教育でスクリプトエンジニアとして参画可能か見極め
• 結論
  • 今のメンバーで頑張るw
• 資質のある人の育成
  • 完遂力
    • 基本的なAPIを覚えたら、独力でテストスクリプトを作成できる
  • 学習力
    • 習ったこと以外のAPIや派生の操作を、自分で試してみる
  • 清潔力
    • エラー（コンパイル・ランタイム）を放置せずにすぐに修正する
  • 考察力
    • エラーが発生した場合に、エラーの原因を考え抜いた上で自分で対応出来る