ギアと開発とわたし_AAA2015

Copyright 2015 Kazuhiro SUZUKI
ギアと開発とわたし
～愛するあなたのため毎日磨いていたい自動テスト～
2015年6月27日(土)
Asiyan Automation Alliance 2015
@芦屋市民センター
鈴木一裕 @kz_suzuki

Copyright 2015 Kazuhiro SUZUKI 2 / 75
お話の前に、いつもの免責
 プレゼンターは、繊細な心の持ち主です。
 「うなずき」が推奨されます。
 「首かしげ」「眉ひそめ」は推奨されません。
 プレゼンターは、有識者ではありません。
 ギア本で知識を得ただけの初級実践者です。
 みなさんに何かを「教える」ものではありません。
 初級者disは、若い可能性の芽を摘むことになります！
 このプレゼンは、ステマではありません。
 印税は受領済みです。

自己紹介: 関西の人との思い出
関西におったら
いじめられてるで。

自己紹介: 基本情報
 鈴木一裕 @kz_suzuki
 以前: いわゆるSIerにて、業務システムのテスト・品質管理
 最近: インフラ機器の組込みソフトの評価、テスト自動化
 コミュニティ末端系人財
 ブログ・『ソフトウェアの品質を学びまくる』
- 最近、帰宅後力の低下のため、投稿率が悪化
 テスト自動化研究会、探索的テスト研究会
- 最近、週末力の低下のため、出席率が悪化
 ギア本関係者
 全体まとめと翻訳パートの監修を担当
 CodeZineに補足記事を寄稿

自己紹介: 翻訳にチャレンジしてみて
 翻訳と自動化の共通点
片手間で取り組むのは
死亡フラグ

自己紹介: 翻訳にチャレンジしてみて
 全国の技術書翻訳者に感謝
 自分が翻訳素人であることを差し引いても・・・
 出版されたものは直接修正できないという恐怖
 情熱か強迫観念のいずれかが必要
 質問に答えてくれた原著者に感謝
 “test automation regime”という謎の表現
- 戦後レジームからの脱却、アンシャンレジーム、・・・
 “exemplary”という謎のダジャレ
 floppy disk, word processorという謎のガジェット
- Win10ではUSBフロッピードライブがデフォルトではサポートされない

これまでかじった自動化。

 UWSCで操作をキャプチャ・リプレイ！
自己紹介: 俺の自動化 (黎明編)
テスト対象
ポイント❷
複数端末から同一対象への操作を
ランダムに繰り返し実行させたら、
排他についてのバグ見つかるかも！
ポイント❸
うおお何か出たー！！
ポイント❶
記録したスクリプトをそのまま使うん
じゃなく、変数化したり構造化した
りしたんだ！

自己紹介: 俺の自動化 (羽衣編)
 DOSプロンプトベースドアプローチ！
ポイント❶
呼び出す機能とパラメタをExcelで管理！
Excelなのでパラメタの追加が容易！
Excelマクロでコマンドプロンプトをキック！
ポイント❷
コマンドプロンプトがTeraterm
マクロを起動！
ポイント❸
Teratermでテスト自動実行！
マクロ同士は特に連携せず！
テスト端末
テスト対象テスト対象

自己紹介: 俺の自動化 (復活編)
 キーワード駆動の世界に入門
 新しい職場、キーワード駆動フレームワーク完備！
 自分のプロジェクトに導入するにあたり、ギア本を超参照！
 このセッションの中で、少しお話しします。

おはなしすること
 なぜテストを自動化したいのか
 ギア本を使ってみた
 ギア本にあまり書かれていないこと
 まとめ

なぜ、テストを自動化したいのか。
製品の品質を手軽に確認したい・・・
手動テストのコストを下げたい・・・
テストをもっと増やしたい・・・
テスト工程を短くしたい・・・
テストをサボりたい・・・

テストの期間を短くするには
どうすればいい？

テスト実行時間を支配する式
 テスト期間をスケジュール内におさめねば！
𝑻 𝒑𝒍𝒂𝒏𝒏𝒆𝒅 : 納期までのテスト期間
𝑻 𝒂𝒄𝒕𝒖𝒂𝒍 : 実際のテスト期間
𝑷 𝒏 : テスト担当者の人数
𝑺 : テストの消化速度
𝑪 𝒏 : テストケース数
𝑻 𝒑𝒍𝒂𝒏𝒏𝒆𝒅 > 𝑻 𝒂𝒄𝒕𝒖𝒂𝒍 ∝
𝑪 𝒏
𝑷 𝒏 ∗ 𝑺

 Tplanned（納期までの期間）を長くするには？
 納期変更
- 政治力や土下座などを駆使
 この世の時間を消し去る
- テストの「過程」は消し飛び、納期遅延という「結果」だけが残る
 相対論的効果による「時間の遅れ」の利用
 精神と時の部y
𝑪 𝒏
𝑷 𝒏 ∗ 𝑺

 満たすべき不等号の向きを変えるには？
 なにジョジョ？
テストが期日までに終わらない？
 ジョジョそれは無理やりテストを終わらせようとするからだよ
 逆に考えるんだ
「納期遅延してもいいさ」と
考えるんだ
𝑻 𝒑𝒍𝒂𝒏𝒏𝒆𝒅 < 𝑻 𝒂𝒄𝒕𝒖𝒂𝒍 ∝
𝑪 𝒏
𝑷 𝒏 ∗ 𝑺

 Cn（テストケース数）を小さくするには？
 テスト設計の見直しによるテストケース合理化
 リスクに基づいたテストケースの優先順位づけ
 テストケースを無作為に間引く！
 間引かない、でも実際には実行しない！
𝑪 𝒏
𝑷 𝒏 ∗ 𝑺

 Pn（テスト担当者の人数）を大きくするには？
 人数を倍にすれば、半分の時間で終わるじゃない！
- 対象プロダクトを知っている人なら有効
- 何も知らない人が来ると、Brooksの法則が発動
「要員追加が、遅れているソフトウェアプロジェクトはさらに遅らせる」
𝑪 𝒏
𝑷 𝒏 ∗ 𝑺

 S（テストの実行速度）を大きくするには？
 テストしやすいプロダクト設計
 効率のよい実行順序
 労働環境の向上
- ハイスペックマシン、広い画面、青い空、白い雲、さわやかな風・・・
 テスト担当者の熟練
 手抜き文化の醸成
 自動化
𝑪 𝒏
𝑷 𝒏 ∗ 𝑺

納期変更
優先順位づけ
いい増員
実行順序改善
テスト再設計
プロダクト設計
労働環境
熟練
自動化
間引き
サボり
悪い増員
手抜き文化長
期
短
期
光闇

自動化、そこでギア本です。
※「詳しい要約」はコチラにも。

 原著『Software Test Automation』のスコープ
ギア本に書かれていること
QA
テスト
デベロッパ
テスト
機能
テスト
非機能
テスト
テスト
実行
テスト設
計・実装
ツール・
言語非依
存
ツール・
言語依存
ユニットテストより後の、主に画面系のテストが
対象
いわゆる非機能テストは対象外。
ただし、大量ユーザの模擬など、性能テストに
力を発揮することに言及
テスト実行（検証を含む）を対象とする。
テスト設計・実装については、第2部第15章で
補足
Chapter 1は、ツールや言語に依存しない、一
般的な解説。なおギア本では第2部で、具体
的なツールや言語を使っての実例を紹介

 第1部: テストの実行を自動化する技法
 テスト自動化において考慮すべき事項を網羅的に扱う
- 第1～2章: 概論
- 第3～9章: 技術的な側面
- 第10～11章: ビジネス・組織的な側面
 ドメイン・言語・ツールへの依存性が低い
 第2部: システムテスト自動化のケーススタディ
 テスト自動化研究会有識者による書下ろし
 原著Part2のケーススタディを、現代的な内容でリプレース
- 第12章: 第3章の「共有スクリプト」（Selenium）
- 第13章: 第3章の「キーワード駆動スクリプト」（Silk Test）
- 第14章: 第5章のテストウェアアーキ、第6章の前・後処理（Travis CI）
- 第15章: 第1章のテストケース自動生成・選択・実行（Groovy、JUnit4）

 全体イメージはこんな感じ
テストケース
実行
❺物理
アーキテクチャ
❻前処理
❻後処理
❹比較
❼メンテナンス
❾テストケース選択、
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
❶❷全体の俯瞰
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

各章を実践してみて感じたこと。

第1章テスト自動化のコンテキスト
 全体イメージ
テストケース
実行
❺物理
❻前処理
❻後処理
❹比較
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

 自動テストの限界 (ギア本1.9)
 手動テストの方が、多くの結果が見つかる
 テスト自体の品質に依存する
 ツールは臨機応変にがんばらない
 テスト自動化の問題 (ギア本1.6)
 品質向上についての過剰な期待
- 安定したリグレッションテストを自動化する場合、欠陥は少ない傾向
 自動テストで欠陥ゼロ→品質OKという誤解
- テストの7原則其の1: テストは欠陥があることしか示せない
 テスト自動化のGIGO
 コスト削減についての過剰な期待
- 金がかかるのは、ツールのコストや自動化の初期コストだけではない
 組織サポート不足

 「カオスを自動化しても、カオスが速くなるだけ」
 「何もしないテストを自動化しても、何もしないテストを効率化
するだけである」
 テストの品質と、テスト自動化の品質は別物
 既存のテストをそのまま自動化する前に考えよう
 そのテストケースは必要なのか？
- 紙の帳票をネ申Excel (pdf) にして「デジタル化」するのに近い
 そのテストケースの手順は明確か？
- 実行手順が不明だと自動化が難しい
- 「ユーザ登録機能が妥当な時間内で正しく動作すること」
 そのテストケースの実行結果の検証方法は明確か？
- 検証内容が不明だと（実行しか）自動化できない
- そもそも手動でも実行できていたのか・・・？

 自動化が難しいテストもあるよね
 自動化が無為に終わりかねないもの
- 品質が安定していないソフトウェアでのテスト
- 仕様が安定していないソフトウェアでのテスト
- 長いシナリオを通してのテスト
 ハードウェア的な関与が必要なもの
- 物理的な障害を発生させるようなテスト
- システム構成のバリエーションがキーとなるテスト
 人が判断しながらテストすべきもの
- ユーザビリティに関するテスト
- 探索的テスト
 膨大なリグレッションテストの犠牲になってできて
いなかった、人ならではのテストを強化しよう！

拡充
自動化
削減
削減
自
動
化
可
自
動
化
不
可
意味ある意味ない

第2章キャプチャーリプレイはテスト自動化ではない
テストケース
実行
❺物理
❻前処理
❻後処理
❹比較
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

第2章キャプチャーリプレイはテスト自動化ではない
 自動化にはどんな課題があるのかを知る
 自動化の対象は、「実行」部分だけではない
 単純なアプリの自動化でさえ多くの検討事項がある
 画像は懐かしい感じのWin9xアプリケーションだけどな！

第3章スクリプティングの技法
テストケース
実行
❺物理
❻前処理
❻後処理
❹比較
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

 リニアスクリプト
 一つのテストケースが一つのスクリプトに対応
 構造化スクリプト
 分岐・反復・呼び出しを導入する
 スクリプトの柔軟性向上、冗長性低減
 共有スクリプト
 スクリプトを機能ごとに切り離し、再利用する
 スクリプトの組み合わせによるテストケースの追加が容易
 変数はスクリプトに含まれたまま

 データ駆動スクリプト
 スクリプトで使う値を、変数として切り離す
 データセットを増やすことで、テストケースを容易に追加可能
- テストケースを適切に増やすためにはテスト設計技法が必要！
 自動化のご利益が得られるアプローチとしてギア本が推奨
A: ログイン
B: 登録
C: 変更
Z: ログアウト
a1
b1
c1
元のテストケース
A: ログイン
B: 登録
C: 変更
Z: ログアウト
a1
b1
c1
a2
b2
c2
データが分離された
テストケース
追加されたデータセット

 キーワード駆動スクリプト
 スクリプトの機能を分割し、データも切り離す
 各機能を「キーワード」として抽象化し、実装を隠蔽する
 キーワードとデータの組み合わせで、テストケースを柔軟に
追加できる
ログインする
登録する
変更する
ログアウトする
a1
b1
c1
ログインする
登録する
a2
b2
元のテストケース機能とデータを分割
されたテストケース
追加されたテストケース
A: ログイン
B: 登録
C: 変更
Z: ログアウト
a1
b1
c1

テストファイル
 キーワード駆動スクリプト (ちょっと補足)
ログインする
登録する
変更する
a1
b1
c1
補助
スクリプト
制御
スクリプト
制御スクリプト
 テスト実行の全体をつかさどる
 テストファイルを1行ずつ読み、補
助スクリプトを呼び出す
テストファイル
 テストケースに相当する
 キーワードとパラメタの組み合わせ
補助スクリプト
 キーワードに対応するスクリプト
 具体的な操作が実装される
※あくまでギア本での呼び方です。
組織全体のテスト
自動化エンジニア
プロジェクトのテスト
自動化エンジニア
テストエンジニア/
ドメインエキスパート
必ずしも役割を分ける必要はないが、
キーワード駆動だと分けやすい。

 ギア本勉強会ではこんな声が。
 データ駆動スクリプト
- コストと効果のバランスがちょうどいい
- ツールが標準的にサポートしているので取り組みやすい
- ドメインによっては、データの種類を増やすことの嬉しさは少な目
 キーワード駆動スクリプト
- 学習コストは低い ※テスト実装部分のみ
- 複数の環境でテストケースが使いまわせる
- フレームワーク構築から安定までに時間がかかる
 後で少しキーワード駆動の話をします。

第4章自動比較
テストケース
実行
❺物理
❻前処理
❻後処理
❹比較
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

第4章自動比較
 実行結果と期待結果の単純な比較こそ自動化！
何を
どれだけ
どのように
 画面の表示結果だけ確認すればいい？
 データベースのレコードは？
 ユーザに見えないログは？
 画面全体を比較する？一部だけ比較する？
 値だけ比較する？体裁まで比較する？
 実行中に比較？実行後に比較？
 毎回変わるようなID・日付けはどう扱う？

第4章自動比較
 比較は、しょせん比較でしかない
 「事前に定義した期待値と一致したかどうか」だけ
- 期待値が間違っていれば、比較の判定も間違う
- 定義されていない期待値は、そもそも比較されない
- 人間の持つ「違和感」は、自動比較では得られない
 本当に機械に任せていいのか・・？
- 今取り組んでいるプロダクトだと、情報がコマンドラインから取れるので、
楽な部分もある
- テストケースに明示されている検証内容で十分かは要確認
- 検証内容は継続的にブラッシュアップしていくのがよさそう

第5章テストウェアアーキテクチャ
テストケース
実行
❺物理
❻前処理
❻後処理
❹比較
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

第5章テストウェアアーキテクチャ
 管理しなければならない山のようなテストウェア
 とにかく種類と数が多くなる
- テストケースが増えてもそれほど増えないもの
> テスト仕様書、共有スクリプト、・・・
- テストケースが倍になると、一緒に倍になるもの
> テストケース中に操作するファイル、固有のスクリプト、・・・
- テストケースの実行回数が倍になると、一緒に倍になるもの
> テストケース中に操作したファイル、差分レポート、ログ、・・・
> エビデンスとして、あるいは資料として残しておく必要がある
 テストの本質ではないが、きちんと考えないと破綻
- ソフトウェアのバージョンに対する、テストウェアのバージョン管理
- 環境ごとのテストウェア

第6章前処理と後処理の自動化
テストケース
実行
❺物理
❻前処理
❻後処理
❹比較
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

第6章前処理と後処理の自動化
 テストケース実行前後の作業こそ退屈です
 ギア本にあるざっくり分類
- ファイルの生成・削除・再配置
- テストケースの事前条件を満たしているかのチェック
- 入力や比較のための変換
 実際に取り組んでみると・・・
- テストケースを実行するまでの条件を整えるのが大変
- 自動化しないテストケースでも、準備部分を自動化できれば福音
- テストケースに「前提条件」が明記されていないと、自動化で詰む
しかし前提条件ってどこまで書いておくものなんだろう・・・
- 物理的な「装置」が制約になることも。

第7章保守性の高いテストを構築する
テストケース
実行
❺物理
❻前処理
❻後処理
❹比較
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

第7章保守性の高いテストを構築する
 第7章はテストウェア全体の保守性
 アンチパターン
- テストケースはガンガン増やしていいのか？
- 前処理後処理を省くために、テストケースを結合しまくっていいのか？
 規約とドキュメンテーション
- どんなスクリプトが、どんな仕様で、どんな名前で、どこにあるか、の
認識が組織内で合っていないといけない
- スクリプトを修正した際の影響範囲が特定できないといけない
 第12章はテストスクリプトの保守性
 Selenium WebDriverでのスクリプト
- メソッドとして切り出す粒度はどう考える？
- その他実装における注意点やノウハウ・・・
 キーワード駆動は保守コストが低い？

第8章メトリクス
テストケース
実行
❺物理
❻前処理
❻後処理
❹比較
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

 はい、いつもの「測れなければ、改善できない」
 テストと自動テストは、分けて考える
 ダメなテストを自動化してもダメ。テストをまず測る
 ギア本推奨キット・・・「時間」の観点は？
テスト
自動
テスト
 重大な欠陥のDDP
※その工程までの発見された全欠陥のうち、
その工程で発見された欠陥の割合
 自動化に要する時間
 スクリプトの保守に要する時間
 実行できるテストケース数、回数
＞

 組織・立場によって自動化に求める効能は異なる
 自動化の目的に沿ったメトリクスを取ろう！
- テスト期間短縮が目的なのに、テストケース自動化率？
- 品質確認が目的なのに、実行時間短縮率？
 目的の不明確なメトリクス収集は、現場が疲弊するだけ
- 自動化に限らず、必要十分なデータを簡単に取れるように工夫
- 数字だけじゃなく中身も見ようね・・・

第9章その他の課題
テストケース
実行
❺物理
❻前処理
❻後処理
❹比較
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

 「その他」に詰め込まれた重要な事柄
手動テスト
ケース1
自動化の
優先順位
実行する
テストの選択
テストの実行
順序の決定
テストステータス、
結果のレポート
❶
❸
❹
❷
手動テスト
ケース2
手動テスト
ケース3
手動テスト
ケース4
手動テスト
ケース5
自動テスト
ケース1
自動テスト
ケース2
自動テスト
ケース3
自動テスト
ケース4
自動テスト
ケース3
自動テスト
ケース1
自動テスト
ケース4
前処理
後処理
自動テスト
ケース2
前処理
後処理

 テスト自動化の優先順位
 どんな基準がある？
- 重要な機能に対するテスト
- 単純で自動化の容易なテスト
- 人間にとっては手間でストレスだが、機械には楽なテスト
- 実行と検証の手順が明確に定義されているテスト
 何を目的に自動化しているのか振り返る
- テスト工程を短くすることが目的なら・・・
→ 待ち時間ばかり長いテストケースを自動化して夜流すとか
- つまらんテストからテストエンジニアを解放したいなら・・・
→ 細かくて数の多いテストケースを優先するとか
- パラメタの組み合わせで起こる欠陥を攻めたいなら・・・
→ データ駆動で、既存のテストセットにはないケースを追加するとか
 手っ取り早く成果が見えることも、組織としては大事

 テストケースを完全に自動化する？
 テスト実行部分だけの自動化
- 検証部分の判定条件が定量的に表現できないもの
- 「問題ないこと」をこれから精緻にしていきたい場合
- 特に新しいテストケースは、人の目が重要になることも
 前提条件を揃える自動化
- 毎回の同じ作業を省けるだけでも嬉しさはある
- 一方、その準備段階で見つけられたかも知れない欠陥は隠れる

第10章テスト自動化ツールの選択
テストケース
実行
❺物理
❻前処理
❻後処理
❹比較
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

 ツールの購入、そして導入は、一大プロジェクト
購入
プロセス
導入
プロセス
ロールの
割当
変革の
管理
コミット
メント確
保
パイロッ
トプロ
ジェクト
段階的
導入
継続的
改善
要件の
把握
チーム作
り
制約の
把握
市場の
調査
デモ
評価・決
定

 そもそも、ツールで解決できる問題なのか？
購入
プロセス
要件の
把握
チーム作
り
制約の
把握
市場の
調査
デモ
評価・決
定
 ツールと自動化の限界を把握
- テスト自動化より先に（あるいは同
時に）進めるべきテーマはないか？
- ソフトウェア設計段階での品質確保
が必要でないか・・・？
- 手動テストをそのまま自動化すれ
ば問題が解決するのか・・・？
 自動化への幻想の芽を撲滅
- ソフトウェアの品質を高めるための
施策を同時に進める
- 自動化への過剰な期待を抑える

第11章組織内へのツールの導入
テストケース
実行
❺物理
❻前処理
❻後処理
❹比較
順番付け、etc
❿ツール
選定
⑪ツール
導入
❽メトリクス
前処理
後処理
自動テスト
手動テスト
スクリ
プト
ドキュ
メント
テスト
データ
テスト
結果
❸スクリプ
ティング技法

 購入よりも、実は導入こそがハードル
第11章組織内へのツールの導入
導入
プロセス
ロールの
割当
変革の
管理
コミット
メント確
保
パイロッ
トプロ
ジェクト
段階的
導入
継続的
改善
 ロールをしっかり定義する
- キーワード駆動で三つのロールに分
けると取り組みやすかった
- ロールを分けると、開発のルールと
ドキュメンテーションがより重要に
 できる限り、専任に
- 自動化は中期的に成果が出る
- 工数を減らしたいからこその自動化
- 「1日のうち、テストに5時間、自動化
に2時間」という目論見は・・・
 上層部からのコミットメント
- 継続的に声を出してもらおう

というギア本だが、実際の作業
手順はあまり書いていない。

キーワード駆動の実装を例に、
自動化の手順を考えてみる。
（試行中です、no more dis）

テスト自動化の手順 (あくまでも例)
1. テストケースを作成する
2. テストケースごとに自動化の可否を分ける
3. 自動化の優先順位を決める
4. テストケースの手順を標準化する
5. 必要なキーワードを抽出する
6. テストケースとキーワードの関係を整理する
7. キーワード実装の優先順位を決める
8. キーワードの仕様を決める
9. キーワードを実装する
10. テストケースをキーワードで記述する
11. 自動テストを実行する
12. キーワードとテストケースを保守する

 前準備
1. テストケースを作成する
- 既存のテストケースがあれば、それが対象になる
ただし自動化の作業は、テストケース自体の見直しの機会
- 手動での実行時間や、自動化作業の工数も測定しておくといい
- 自動化の目的に合わせてメトリクスも決めよう！
2. テストケースごとに自動化の可否を分ける
- 組込み系だと、操作・検証両面で、ハードウェア的な制約が多い
- 可否の割合は、自動化のプロジェクトのメトリクスにも
3. 自動化の優先順位を決める
- あまり細かく分けてもしょうがないので、高・中・低くらいで
- 優先順位の基準を決めておくといい。詳しくは第9章

 キーワードの抽出 (この三つは同時並行)
4. テストケースの手順を標準化
- 記述の粒度や、表現方法をそろえる
- テストケースの記述流儀が人依存だと苦労する
- 手順に具体的な「操作」が書かれ過ぎると凶
5. 必要なキーワードを抽出する
- テストケースがきれいになると、必要なキーワードが見えてくる
逆に、見えたキーワードでテストケースを書き直すことも
- 手順のみでなく、検証もキーワード化する
- 前提条件をそろえるためのキーワードも
6. テストケースとキーワードの関係を整理する
- どのテストケースでどのキーワードが使われている？
- キーワード実装の優先度と、実装後の保守に必要な情報
- 自動化しておくのが吉

 キーワードの実装
7. キーワード実装の優先順位を決める
- テストケースの優先度や、キーワードの使用頻度から
8. キーワードの仕様を決める
- テストケースに記述された手順がベース
- 前提条件が満たされていないケース、エラーとなるケースの考慮
- 最初から作りこむか、まずは動くものを作るか
- パラメタ追加にどこまで柔軟に対応させるか
9. キーワードを実装する
- 仕様に基づいてキーワードを実装
- スクリプティングの規約に従う

 運用・保守
10. テストケースをキーワードで記述する
- 既存のテストケースとのトレーサビリティはどうする？
- ハイパーExcelに比べて、一覧性が低くなることも
11. 自動テストを実行する
- コケたところからの復帰はできているか？
- 手動と自動をシームレスに進捗管理できるか？
- 偽陰性・偽陽性の経過観察・・・
12. キーワードとテストケースを保守する
- キーワードの仕様変更に伴うテストケース全修正
- フレームワークの仕様変更に伴うテストケース全修正
- バージョン管理
このように、手順を整理し、知見を重ねていきたい。

ところで、こんなことが心配になる。

自動化で心配されること
 実行時間はそれほど改善されないのでは？
 ネガティブ派: よくわからんが手でやった方が速いだろ！
 ポジティブ派: 操作を自動化しても、待ち時間部分はそう変
わらないことや、検証部分に人の関与が残るケースを理解し
ている
→同時実行数や、検証部分の精緻化を進める

 検証部分は本当に自動化してよいのか？
 ネガティブ派: よくわからんが人間が関与しないと不安だろ！
 ポジティブ派: ベテランが、テストケースに明示されない部分
まで気にしてテストを実行したり、探索的にテストしていること
を理解している
→検証部分が安定しているものを自動化対象とする

 自動化しても、品質の劇的な改善はないのでは？
 ネガティブ派: よくわからんが、欠陥が出ないなら自動化する
必要ないだろ！
 ポジティブ派: おかしな影響を受けていないことを確認するリ
グレッションテストでは、「欠陥があまり出ないこと」が前提で
あることを理解している
→正しい理解だと思われる
自動化に対する正当な不安感は、
ちゃんと吸収して進めましょう。

まとめに入ります。

実践してみて感じたこと
 テスト設計大事だよね
 人間ならではのテストをしたいよね
 そんなにサクサク自動化って進まないよね

実践してみて感じたこと
 ギア本のご利益は、人による
 すごく役に立つ章もあれば、とりあえずスルーな章も
 読み直すと含蓄のある言葉が埋もれている
 ギア本は完璧じゃない
 足りない部分、情報が古いところもあるので、一般論の把握
に使ってほしい
 Webで補足しているから合わせて読んでほしい

いいテストと、いい自動化で、
きっと幸せになれる。

ご清聴ありがとうございました。

ギアと開発とわたし_AAA2015

More Related Content

What's hot

Viewers also liked

Similar to ギアと開発とわたし_AAA2015

ギアと開発とわたし_AAA2015