MasaoApril's Library.

Software Testingなネタを書いてみた。

システムテスト自動化カンファレンス2014(1)「オープニング：1時間で分かるSTA」

Conference STAC2014 TestAutomation

　2014/12/14(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2014に参加しました。
　本blogでは、聴講したセッションから数回に分け、まとめたものを紹介します。

セッション

　一般講演内容は、下記セッションです。
(※<資料>にリンクを貼りましたので、ご参考下さい。)

1.オープニング：1時間で分かるSTA　/鈴木 一裕　→<資料>
2.テスト自動化のパターンと実践　/.reviewrc　→<資料1>/<資料2>/<資料3>
3.GUI自動テストの保守性を高めるには　/伊藤 望　→<資料>
4.状態遷移テストにおけるテスト設計と実行の自動化　/きょん　→<資料>
5.ビルドプロセスとCI　/長谷川 孝二　→<資料>
6.社内スマホアプリのビルド配信ツールによる自動化事例 /赤根 稔朗(Yahoo! JAPAN)
7.Test Automation Patterns 2014 冬コレ！/松木 晋祐　→<資料>

　今回は、「1.オープニング：1時間で分かるSTA」について紹介します。

1.オープニング：1時間で分かるSTA　/鈴木 一裕

スライド

(1)システムテスト自動化 標準ガイドの原書

・Software Test Automation (Mark Fewster(Authour), Dorothy Graham(Author))

(2)なぜ、翻訳したか？

  • ドメインやツールなどに依存しない書籍が国内にないため。
  • また、原書のPart1は依然として有用であるため。ただし、原書のPart2は一部が陳腐化(ツールやメインフレームなど)しているので、現状に合わせ書き下ろした。

(3)本書について

・邦題：システムテスト自動化 標準ガイド
　著者： Mark Fewster, Dorothy Graham
　訳： テスト自動化研究会
　　リンク：翔泳社のサイト

(4)本書の内容

　以下、ポイントのみ紹介します。

＜第1章：テスト自動化のコンテキスト＞
(a)テストオートメーター

　テスト自動化エンジニアのこと

(b)メリット
  • 実行コストが安価
  • 実行速度が速い！
(c)留意点

  • 技術面 プログラミングスキルが必要 メンテナンス(保守性)も大切

  • 組織面 非現実的な期待を持たせないこと 経営層のサポートが必要

＜第2章：キャプチャーリプレイはテスト自動化ではない＞

　キャプチャリプレイは、テスト自動化ではない！
→理由：比較と検証が無いから。

＜第3章：スクリプティングの技法＞
(a)TABOKによる分類
(b)レベルが高い≠最適
＜第4章：自動比較＞
(a)センシティブな比較

  • 特徴

    • 網羅的で多く比較することが可能
    • 日付判定などでエラーになることが...

  • 用途

(b)ロバストな比較

  • 特徴

    • ピンポイント
    • 予想外の差分を見逃しやすい

  • 用途

    • 機能追加でピンポイントに比較したい場合
＜第5章：テストウェアアーキテクチャ＞
(a)テストウェアアーキテクチャ
  • テスト自動化によりファイル(ログやスクリプト)が増加する
  • ファイル(ログやスクリプト)の構成管理が無いと、破綻することも...
(b)テストウェア
  • アプリがバージョンアップしたら、テストウェアもバージョンアップする必要がある
  • テストウェアのどこをバージョンアップするか検討する必要がある
＜第6章：前処理と後処理の自動化＞
  • 前処理や後処理は、まとまって現れるので共通化しやすい
  • ただし、細かい配慮事項が多い
    • テスト異常終了時はデータのどれを保全するか？
＜第7章：保守性の高いテストの構築＞

  • コストを意識していないのは...

    • 保守のフェーズ。

  • テストケース数が多ければよいわけでない。

    • 「価値があるテストケースは？」という観点で剪定をする必要がある。

  • とりかかりは、短めのテストケースから

    • 長いテストケースの場合、途中で異常完了した時の解析が大変である。
＜第8章：メトリクス＞
  • テストとテスト自動化の測るメトリクスは違う。

  • テスト自動化で測るメトリクス

  • おすすめのメトリクス

    • 自動化に要する時間
    • スクリプト保守時間
    • 実行できるテストケース数や実行回数
＜第9章：その他の課題＞

  • 自動化の優先順位

    • 全部を自動化しないといけないわけではい。まずは、刺身タンポポな作業的なところで「手軽に自動化できるもの」から取り組む。

  • 進捗のモニタリング

    • Pass/Failだけでなく、テストケース数やエラーメッセージなども。

　http://www.juse.jp/sqip/symposium/timetable/day1/ のA1-3 【経験発表】　継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析　荻野 恒太郎(楽天(株)) を参照。

＜第10章：テスト自動化ツールの選択＞ / ＜11章：組織内へのツールの導入＞
  • 購入プロセス
    • チーム作り
    • 要件の把握
    • 制約の把握
    • 投資効果検討書
    • 市場調査
    • デモ
    • 評価・決定

　なお、「プロジェクトがデスマーチだから」という理由でツールを購入しても、プロジェクト自信は破綻する。

  • 導入プロセス
    • 変革の管理
      • 改善することになるので、変えたくない人の抵抗が大きい
    • ロールの割り当て
    • コミットメント確保
    • パイロットプロジェクト
    • 段階的導入
    • 継続的改善

(4)本書で強調していること

  • テスト(設計)が貧弱だと自動化も貧弱になる
  • メンテナンスコストは(思ったより)高い
  • 標準化と規律に手を抜かないこと
  • テスト自動化で浮いた時間を他のテスト活動に工数を投資すべし

所感

　テスト自動化に関する国内の書籍は存在しなかったため、テスト自動化の知見を体系的に学び、テスト自動化に対する改善できる環境が整備できただけでも、ソフトウェアテストにおける歴史が1つ刻まれ、テスト自動化についての議論が盛り上がると思いました。
　私が所属する組織では、テスト自動化の保守(ドキュメント整備など)が課題になっています。本書を読みながら、新たにテスト自動化のシステムを構築する時、どこから取り組むのか考え、チームメンバーの方と議論してみようと思います。