システムテスト自動化カファレンスへ参戦してきた

1時間で分かるSTA

Software Test Automationとは？

テスト自動化において考慮すべき事項が網羅的に扱っている。
テスト自動化の実例など。
ソフトウェアテストの自動化について一般的な知識を網羅的に扱う書籍がない？
翻訳された書籍がシステムテスト自動化標準ガイド

テスト自動化のコンテキスト

自動化以前にテストはまともなのか？

  • 効果的
  • 経済的
  • 発展的
  • 典型的
キャプチャーリプレイ
  • 準備がほとんどいらない。
  • 操作ログを残せる。
  • しかし、テスト自動化ではない。
スクリプティングの技法
自動比較
  • 何を？どれだけ？比較するか？
  • センシティブな比較。
  • できるだけ多くの情報を比較。
  • ロバストな比較。
  • 費用最低限の情報に絞り比較。
  • 動的比較。
  • 実行後比較。
テストウェアアーキテクチャ
  • テスト自動化によって増殖するファイル（どんどんファイルが増殖）。
  • 共有スクリプトなど、効率的に再利用できる必要がある。
  • 管理なしだと破綻する。
  • 前処理と後処理の自動化。
  • 保守性の高いテストを構築する。
  • テストウェアのメンテナンス。
  • 最初は、短めで、徐々に長くする。
メトリックス

テスト自動化のパターンと実践

テスト自動化パターンについて

そもそも始めるのに勇気と力が必要。
最初は、テンションが高いが、徐々に低下してしまう。
テンションを維持するのが大変。

パタンランゲージ
  • コンテキスト（問題の背景）
  • 問題（実際の問題）
  • フォース（問題を発生させる要因となる外部からの力）
  • 解決（解決策）
  • 結果（レポートなど）

テスト結果を適切に分析し、活用することができていない。
多くの情報を解釈するには担当者のリソースが必要。
目的をもった結果レポートを出力するようにする。
メトリックスを測定する。
全員が理解できる共通言語（ユビキタス言語）で話す。
自分の経験を皆に伝えるツールとして。

パターン解説①
  • システムテスト自動化のボルトネックは、GUI操作。
  • システムテスト自動化って、つまりは、プロダクトプロセスとテストプロセスを協調動作させる。
  • マルチプロセスプログラミング。
  • ホワイトボックスでのテストをする。
  • 一番不安定で、自動化コストがかかる部分（GUI）を抜いて行く。
  • ユーザーロジックのテストだけで十分だったりする（バグのほとんどは、ここにあることが多い）。
  • 単体テストとは違い、結合状態でテストする。
  • 抜いた部分も管理しておく。
  • 自動化でテストしなくとも手動で、確認しておく。
パターン解説②
  • オートーメター
  • 自動家の道具（テストツール、CI&CDツールなど）
  • 自動化の価値
  • 合理性・効率性の向上。
  • 本来作業に近づける（別の仕事（ノイズ）が多い）。
  • 楽しい（問題を技術課題へと転化出来る。

GUI自動テストの保守性を高めるには

Seleniumとその保守性
  • キャプチャーリプレイ。
  • キャプチャーリプレイはテスト自動化ではない。
  • 手動画面操作をSelenium IDE/Selenium Builder（使いづらい）で作る。
  • 画面を操作するだけでスクリプト生成
  • 生成されたものが読みにくいものが出来てしまう。
  • スクリプト修正の作業が大変。
  • スクリプトの共通化ができない。
  • 記録した後、スクリプトの手直しがかなり必要
  • Selenium IDEは、記録機能よりも視覚的に見やすい。
  • 複雑なロジックを書くのは結構大変
  • 処理の共通化がかなり難しいく、だんだんプログラムで書いているのとかわらない。
プログラミング言語（Selenium WebDriver）
  • 共通化の技法を駆使して、メンテナンスコストを減らせる。
  • EclipseなどのIDEのコード保管。
  • コードが書けないと厳しい。
  • テストフレームワークがある。
Excelから自動生成
テストはなぜ失敗するのか
  • テスト対象システムのバグ
  • 仕様変更
  • ツールバグ
  • それ以外

ほぼそれ以外の部分で失敗する。

  • 不安定テスト
  • 環境準備失敗
  • DB定義失敗
  • テストデータ不整合
失敗した原因を突き止める
  • テスト結果に誰でも簡単にアクセスできる。
  • メールやブラウザ上で見れると結果確認が簡単。
  • チーム全体で結果を共有し、テスト失敗への関心を高める。
  • 画面キャップチャ・動画・サーバーログなど、エラー調査に必要なデータを残す。
  • エラーになったテストだけを手元で流して確認できる
  • テストスクリプトはバージョン管理し、誰でも手元に取得できるように
  • 原因が分かったら修正（簡単に修正できる）。
スクリプトを共通化

状態遷移テストにおけるテスト設計と実行の自動化

デプロイメントパイプライン
  • 自動化っていっても、効果のあるものをやらないと意味がない。
  • まずは現状をみえるようにする必要がある。
  • システムテストは、コストと効果を考える。
Value Stream Map

テストを自動化することが正しいのではなく、ソフトフェア開発自体をよいサイクルにすること。
リリースにかかる時間を短くするための有用な選択肢。

Deployment pipeline

テスト自動化をする上で、ある程度は俯瞰しなれば、局所化してしまう。
ソフトウェアをバージョン管理から取り出してユーザーに届けるまで。
ビルドパイプラインを実装するというのは、テストの大まかな分割方針、フィードバック順序、
実行頻度を決め、そして実装後には多様なテストを早期から設計、実装、実行することを意味する。

ビルドプロセスとCI

テストウェア？

自動・手動の区別なく、テストに関わる成果物
テスト資料

テスト結果

  • 実際の出力
  • ログ
  • ステータス
  • 比較レポート
なにが問題なのか？
  • 規模（ファイルの数が多い）
  • 再利用性（建て増し旅館）
  • 複数のバージョン（製品のバージョンとの同期）
  • プラットフォームと環境からの独立（動作環境ごとにテストウェアのコピーを作るのか）
ツールで解決できるもの
  • CIツールで解決（CIの結果、レポート機能など）⇒　規模
  • テスト資料は、バージョン管理システムで管理してしまう　⇒　複数のバージョン
  • テストコード、テストデータ（SQL）、テーブル定義、比較用の出力データ（期待結果）
  • Git-flowなど、ブランチやタグなどの規制しておく。
前処理と後処理の自動化
  • 前処理（生成（DBへのデータ投入）、チェック、再配置、変換）
  • 後処理（削除、チェック、再配置、変換）
  • 後処理の削除、再配置は、前処理でやった方がいい。
  • ビルドツール（Make Rake Ant Gradleなど）