1時間で分かるSTA (Software Test Automation) #stac2014

Copyright 2014 Kazuhiro SUZUKI

60 minutes STA

1時間でわか(った気になれ)るSTA

2014年12月14日

stac2014@ヤフー株式会社様

鈴木一裕@kz_suzuki

http://connpass.com/event/9618/

Copyright 2014 Kazuhiro SUZUKI 2 / 78

自己紹介

鈴木一裕 @kz_suzuki いわゆるSIerにて、業務システム・インフラ機器用ソフトウェアの

テスト・品質管理など

『ソフトウェアの品質を学びまくる』

- もっともバズったのは、「積ん読」という言葉が国際的に普及している件

- 2015年からがんばる

コミュニティ末端系人財

テスト自動化研究会

探索的テスト読書会など

今回、全体まとめと翻訳パートの監修を担当

家庭と仕事を犠牲にした

https://twitter.com/kz_suzuki

http://blog.livedoor.jp/prjmng/

http://blog.livedoor.jp/prjmng/archives/52359281.html

https://sites.google.com/site/testautomationresearch/


自己紹介

俺の自動化!!

ポイント❶呼び出す機能とパラメタをExcelで管理！Excelなのでパラメタの追加が容易！Excelマクロでコマンドプロンプトをキック！

ポイント❷コマンドプロンプトがTeraterm

マクロを起動！

ポイント❸Teratermでテスト自動実行！マクロ同士は特に連携せず！

テスト端末

テスト対象テスト対象

・・・全然かっこよくない。Selenium？おいしいの？


お話しすること

『Software Test Automation』とは？

なぜ翻訳するの？

『システムテスト自動化標準ガイド』とは？


お話の前に

プレゼンターは心が弱いです。

積極的な「うなずき」が推奨されます。

積極的な「首かしげ」は推奨されません。

「何言ってるのかわからない」ランプが5回点滅したら、

それは「ホ・ン・ヲ・カ・エ」のサインです。

翔泳社様の特設ブースがあります。

ちょっと安いはずです。


『Software Test Automation』とは

著者: Mark Fewster, Dorothy Graham

- 英国の著名なソフトウェアテストコンサルタント

- Graham氏はJaSST’13 Tokyoで基調講演

発売日: 1999/8/25

- 決して新しい本ではないが、テスト自動化に関する

2014年の調査で、「最も有名で、最も読まれ、最

もおすすめできる本」として多くの票を獲得

物理的なスペック: 600ページ、926g

- 同著者による『Experiences of Test Automation』

(672ページ)との併せ持ちで筋力アップにも効果あり

STARで輪読していたTABOK(テスト自動化

知識体系) は、本書を大いに参考にしている

ようである！

http://gihyo.jp/news/report/2013/01/3101

http://www.dorothygraham.co.uk/downloads/generalPdfs/surveyResults.pdf

http://www.amazon.co.jp/gp/product/0321754069/ref=as_li_qf_sp_asin_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=0321754069&linkCode=as2&tag=syakaijinngak-22

http://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCEQFjAA&url=http://www.tabok.automatedtestinginstitute.com/&ei=gs6LVO3TAaG2mQXM7oHICA&usg=AFQjCNE9vrkq4PQhtvx9Xi8w0K0RsnchPw&sig2=g6SHZreOgHnuZ5CYagxrqg&bvm=bv.81828268,d.dGY


Part 1: Techniques for Automating Test Execution

テスト自動化において考慮すべき事項を網羅的に扱う

- Chapter 1～2: 概論

- Chapter 3～9: 技術的な側面

- Chapter 10～11: ビジネス・組織的な側面

ドメイン・言語・ツールへの依存性が低い

Part 2: Test Automation Case Studies

テスト自動化の実例をたんまり

扱っている対象が一部、古い

実例については、原著らが新しく別の書籍を出している



全体イメージはこんな感じ

❸実行

❺物理アーキテクチャ❻前処理

❻後処理

❹比較

❼メンテナンス

自動テストケース ❾実行するテストケースの選択、順番付け、・・・❿ツールの

選択

⑪ツールの導入

❽メトリクス


ビジネス・組織的技術的

手動テストケース

❶❷全体の俯瞰

・・・


なぜSTAを翻訳するの？

日本では類書が見当たらない

- ソフトウェアテストの自動化について一般的な知識を

網羅的に扱った書籍はなさそうだ（多分）

- TABOKは概論の概論といったものであり、不十分

→ STARのアウトプットとして最適だ！

Part 1は依然として有用な内容

- 特定の言語やツールに依存せず、一般的な解説書

として平易に読める

- テスト自動化の全体像を知りたい技術者・管理者

にとって価値がある！

→ ここを翻訳対象にしよう！

Part 2はさすがに一部、陳腐化が・・・

- ていうか、第2部まで訳したらあと2年かかる

- 思い切ってSTARで書き下ろしては？（翔泳社様）

→ それだ！（安易な判断）


STAの中身をご紹介します。


❸実行


❻後処理

❹比較



選択


❽メトリクス

第1章テスト自動化のコンテキスト




・・・



テストオートメーター！

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

英語では、test automator

- 各種Windowsアプリケーションで必ず校正されそうになる

- automaterもよく候補に挙がる

- 「もしかして: udometer」

（「降水量を計る器具からなる計器」・・・）

テスト自動化研究会の趣旨

本会では、ソフトウェアテスティングにおける重要な実践技術である「テスト自

動化」（特に上層、システムテスト／受け入れテスト）について、技術領域の

定義と啓蒙、およびそれを主たる価値とする「テスト自動化エンジニア」

（Automator）という職業の国内における創造を推進しています。

テスト自動化研究会 Webサイトより




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

ダメなテストを自動化してもダメなまま

テストケースの4つの特性

- 効果的 (Effective): 欠陥をどのくらい見つけられる？

- 経済的 (Economic): 実行・分析・デバッグのコストはどのくらい？

- 発展的 (Evolvable): テスト対象の変更に、どのくらい追随しやすい？

- 典型的 (Exemplary): ？？？

exemplaryって何？

「見せしめのテストケース」、意味がわからねえ・・・

【形容詞】

1 模範的な; 模範となる.

2 見せしめの，戒めのための

3 典型的な，代表的な Weblioより



Dorothyさんに聞いてみた。


な、なんだってーーー ΩΩΩ representativeの方が、実態に近い言葉

- positiveなテストを一気に済ませるイメージ

- negativeなテストは一つずつってドリル本に書いてあった

4つの言葉をすべて「e」から始まるようにすれば、

頭いい感じになると思った。

翻訳する場合は、この言葉はおかしい。(笑)NO

IMAGE(Dorothy近影)

http://www.amazon.co.jp/gp/product/4817193603/ref=as_li_qf_sp_asin_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=4817193603&linkCode=as2&tag=syakaijinngak-22



自動化で、これらは特性は改善される？

効果と典型性は変わらない。

- この2つは、テストケース自体の特性

発展性は、場合によっては下がる

- 手動だと、人間が判断してちょろっとテストケースを修正したり・・・

経済性は、初期はまず間違いなく下がる

→ そもそも、まずはテストを良くするべし

テストの品質と、テスト自動化の品質は別物



何を自動化する？

テストのアクティビティ、I/JSTQB的には。

自動化に向いているのは、実行、比較、前後処理- 共通点: おおむね退屈

テストケース実装の自動化は？

- 第15章で、状態遷移モデルに基づくテストケース生成をカバー

- パスの重み付けなどを利用した優先度も提案

コントロール

計画

分析

設計

実装

実行

評価

レポート

終了

実行

比較

後処理

前処理



実行の自動化の長所

量の面

- 実行コストが安いので、高頻度に実行できる

- テスト実行の速度が（割と）速い

- テストケース追加コストが安いので、多数のテストを実行できる

- リグレッションテストを気軽に実行できる

- よって品質に確信が持てる自信につながる #ただしイケテスに限る

質の面

- テストの実行手順の再現性が高い

- 再利用しやすい

- 人ができないテストをできることがある。

> たとえば多人数のシミュレーションなど



自動化での留意点

技術面

- 手動のテスト実行よりも技術力が必要

- コストも時間もメンテナンスにこそかかる

- フレームワークや規準の確立と遵守が重要

- テストでバグゼロ = 品質OKではない

> テストの7原則其の1: テストは欠陥があることしか示せない

- 自動化にとって欠陥がたくさん見つかるわけではない

- テスタビリティを考慮することが、開発の制約になることも

組織面

- 非現実的な期待を抱きがち

- 常に組織（特に上層部）のサポートが必要

テスト工程のコストを

90%削減！

摘出バグ5割増！


手動の方が有利な局面も

ツールは工夫も、臨機応変な対応も、探索もしてくれない

自動化で工数が浮いたなら、人ならではのテストを増強しよう！


機能テスト・ストーリーテスト・プロトタイプ・シミュレーション

単体テストコンポーネントテスト

探索的テストシナリオ

ユーザビリティテストアルファ/ベータ

パフォーマンス/負荷テスト

セキュリティテスト「～性テスト」

1

2

4

3

自動と手動手動

自動ツール

チームを支援する

製品を批評する

ビジネス面

技術面『実践アジャイルテスト』より


❸実行


❻後処理

❹比較



選択


❽メトリクス

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




・・・



第2章の目的

記録しただけのスクリプトじゃダメだと理解する

- タイトルは言い過ぎ感ある

- キャプチャーリプレイだって無能ではない。第3章参照

単純なアプリの自動化でさえ、多くの課題があると理解する

- Scribbleという架空のアプリを対象に、擬似的なスクリプト言語を用いて、

自動化のイメージを概観

- そして、自動化におけるハードルを把握

> キャプチャーリプレイがダメなら、どんなアプローチを取る？ → 第3章

> 検証において、何をどのくらい比較する？ → 第4章

> どんなツールを使う？ → 第10章・第11章


iTunesで「john lennon」を検索、をUWSCで記録


MMV(1107,22,47) ※マウスの移動を記録ACW(GETID(“iTunes”,“iTunes”),-8,-8,1382,722,0) ※要素は座標指定BTN(LEFT,CLICK,1107,22,78) ※マウスのクリックを記録KBD(VK_J,CLICK,1360) ※キー入力を1字ずつ指定KBD(VK_O,CLICK,1312)KBD(VK_H,CLICK,234)KBD(VK_N,CLICK,250)

id = GETID("", "Shell_TrayWnd", -1)id = GETID("iTunes", "iTunes", -1)SENDSTR(id, "john lennon love", 1, True)

●UWSC: 低レベル記録

● UWSC: 高レベル記録

操作は明確だが、目的はわかりづらい。

いらない情報だらけ。※もちろん役に立つこともあるよ

http://www.uwsc.info/



長所もあれば短所もある

この後の.reviewrcのセッションでも言及ありとのこと！

準備がほとんどいらない。すぐに記録・再生可能

操作ログを残すことができる

テストの前提条件としてのデータ準備に使える

他にもたとえば・・・

構造がないので、そのままじゃ読みづらい

入力の自動化に過ぎない。検証は手動

ソフトウェアが変わると、それに追随して再記録が必要

テストケースの数に比例して増加する・・・



❻後処理

❹比較



選択


❽メトリクス

第3章スクリプティングの技法




・・・

❸実行



キャプチャーリプレイがダメなら、どうするんだ？

テストスクリプトの構造は、いくつかのレベルに分けられる

TABOK(テスト自動化知識体系)による分類

リニアスクリプト

レベル1構造化スクリプト

※TABOKでは明示的な扱いなし

レベル2

共有スクリプト※TABOKでは「機能分割フレームワーク」

データ駆動スクリプト

レベル2キーワード駆動スクリプト

モデルベース※STAではスクリプティングの技法に含めない

第12章

第13章

第15章

http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&id=1352&Itemid=95


リニアスクリプトから構造化スクリプトへ

分岐により、スクリプトに判定という柔軟性をもたせる

反復により、スクリプトの冗長性を減らす

呼び出しにより、スクリプトを小さい単位に分ける



構造化スクリプトから共有スクリプトへ

スクリプトを機能ごとに切り離し、再利用する

共有スクリプトの組み合わせによるテストケースの追加が容易

変数はスクリプトに含まれたまま


A: ログイン

B: 登録

C: 変更

Z: ログアウト

a1

b1

c1

A: ログイン

B: 登録

Z: ログアウト

a1

b1

元のテストスクリプト機能分割されたスクリプト

追加されたスクリプト

A: ログイン

B: 登録

C: 変更

Z: ログアウト

a1

b1

c1


構造化スクリプトからデータ駆動スクリプトへ

スクリプトのデータを変数として切り離す

データを変えることで、テストケースの追加が容易

テストケースのシナリオは変えられない

A: ログイン

B: 登録

C: 変更

Z: ログアウト


a1

b1

c1

元のテストスクリプト

A: ログイン

B: 登録

C: 変更

Z: ログアウト

a1

b1

c1

a2

b2

c2

データ分割されたスクリプト



さらに、キーワード駆動スクリプトへ

スクリプトの機能を分割し、データも切り離す

各機能を「キーワード」として抽象化し、実装を隠蔽する

キーワードとデータの組み合わせで、スクリプトを柔軟に追加

ドメインエキスパート・テストエンジニアと、オートメーターを分離


A: ログイン

B: 登録

C: 変更

Z: ログアウト

a1

b1

c1

A: ログイン

B: 登録

Z: ログアウト

a2

b2

元のテストスクリプト機能とデータを分割されたスクリプト


A: ログイン

B: 登録

C: 変更

Z: ログアウト

a1

b1

c1


ただし、レベルが高い＝最適、ではない

プロジェクトの規模や期間に応じた選択が肝要

どのアプローチでも、ドキュメンテーションは必須

レベルの高いアプローチほど、規律の徹底が必要になる



❸実行


❻後処理

❹比較



選択


❽メトリクス

第4章自動比較




・・・


第4章自動比較

結果の比較こそ、退屈で、自動化したいプロセス！

でも、「何を」「どれだけ」「どのように」比較する？

たとえば、「新規ユーザの登録」をした場合、・・・

画面の表示結果だけ確認すればいい？データベースのレコードは？

画面全体を比較する？値だけ比較する？実行しながら比較？実行後に比較？

毎回変わるようなID・日付けはどう扱う？

何を

どれだけ

どのように


第4章自動比較

比較の感度: 差分をどのくらい意識するのか

センシティブな比較

- できるだけ多くの情報を比較する

- 小さな差分でも検出しやすい i.e. 興味のない差分まで検出しがち

- 動的比較 * センシティブだと、テスト実行の時間やメンテコスト大

- 同じ差分で何度もコケるはめに・・・

ロバストな比較

- 必要最低限の情報に絞って比較する

- 余計な差分に惑わされずに済む i.e. 予想外の差分を見逃しがち

- 情報が少ないと、テストがコケた時の分析が大変・・・

使い分け方の例

- 回帰テストなど、安定を確かめるテストはセンシティブに。

- 機能追加などでの詳細な確認では、狙った部分のみでロバストに。

擬陽性

擬陰性


第4章自動比較

比較のタイミング: いつ比較するのか

動的比較

- テストケースを実行しながら比較する

- 途中段階にしか現れないものも比較できる

- スクリプト中に比較処理が追加するので、複雑になることも

実行後比較

- テストケースを実行した後に比較する

- テスト実行とは分けて処理することもできる

- 実装の候補として、シェルスクリプトなども考えられる

※その場合は、テスト実行自動化ツールとの連携が難しい

STAでは、自動化ツールへの依存が小さい実行後比較の

方が手厚い。


第4章自動比較

単純な比較と複雑な比較: どう比較するのか

単純な比較

- ありのままの姿で比較する

複雑な比較

- 本質的でない部分、比較する必要のない部分に対処する

- grep、sed、awkを使った置換・比較のtips

「フィルタ」へ

- 比較に使う置換は「フィルタ」として再利用。ツール化も可能

- 非プログラマから実装を隠蔽


第4章自動比較

なお、比較は、しょせん比較です。

「事前に定義した期待値と一致したかどうか」だけ。

間違った期待値に一致するかもしれないし・・・

比較の対象になっていないところがおかしいかもしれないし・・・

人間みたいに気を利かせてくれないし・・・


第4章自動比較

いろいろな種類の出力

テキスト万歳

データベースのレコード、バイナリデータ

- ダンプしたり、テキスト変換したりできないか

- なるべくツールに依存しないように！

CUI系の画面

- 文字列が正しい、だけでいいのか？

- 太字・イタリック・色といった属性が大事なことも

GUI系の画面

- たとえばメッセージを考えてみても、メッセージの内容なのか、表示属性なの

か、画面に適切に表示されているかなのか

画像、音声、動画、・・・


❸実行


❻後処理

❹比較



選択


❽メトリクス

第5章テストウェアアーキテクチャ




・・・



テスト自動化によって増殖するファイルたち・・・

「正しくドキュメントが編集されたことを確認」するには？

ドキュメント（編集前）

差分レポート

ログ

テスト仕様書

共有スクリプト

ドキュメント（編集後）

固有のスクリプト


ドキュメント（比較用）

比較ツール

テストケースの数が増えるとn倍テストの回数が増えるとn倍



管理なしだと破綻は必定。

第5章は、使用・生成される作成物の論理的な関係と、

維持するための物理的なアーキテクチャについて言及

- テストスクリプトの、プログラムとしてのアーキではない

アーキテクチャは、自動化の初期から意識して適用する！

自動か手動か、どのテストレベルか、によらないアーキテクチャ



テストウェア

テストに使用・生成されるすべての作成物（artifact）

テストウェアの課題

とにかく種類と数が多くなる

共有スクリプトなど、効率的に再利用できないといけない

- 既存スクリプト探索時間は最大2分説

対象ソフトウェアに追随してテストウェアも変わる

- どうやってバージョン管理する？

- 旧バージョンのソフトウェアのためのテストウェアを取り出せるか？

環境ごとにテストウェアも変わる

- 同じ機能を持った別のスクリプトをどう管理する？



テストウェアの区別

テスト資料（Test materials）

- テストが実行可能になる前に必要なテストウェア作成物

テスト結果（Test results）

- テストの出力


差分レポート

ログ

テスト仕様書


ドキュメント（編集後）



比較ツール

テスト資料テスト結果

生成物 2次生成物


テストケース


さらに分類し、テストウェアライブラリで管理

テストセットスクリプトセット

データセット

ユーティリティセット


テスト仕様書




ツール類

共有データ

1つ以上のテストケースの集まり

テストレベル、目的などに応じて分割

テストセット内のテストウェアは、そのテストセットでのみ使用される

目的に応じて束ね、テストスイートに・・・

複数のテストケースで使用するスクリプトと、そのドキュメントなど

2つ以上のテストセットから参照されデータ。たとえばデータベースの基本的なデータエントリ

スタブ、コンバータ、比較ツール、・・・

関連ドキュメント

関連ドキュメント



これでやっと、「テスト資料」は整理できたが？

テスト実行のたびに出力される生成物は・・・

バージョン管理は・・・

環境ごとのテストウェアは・・・

長谷川さんのセッションでも言及あります！


❸実行


❹比較



選択


❽メトリクス

第6章前処理と後処理の自動化




・・・

❻後処理



テストケース実行前後の作業こそ退屈です。

大まかな分類してみると・・・

- ファイルの生成・削除・再配置

- テストケースの事前条件を満たしているかのチェック

- 入力や比較のための変換

まとまって現れるので、共通化しやすい

手動の特徴である想像力などもあまりいらない範囲

- 本当かな？

実行が手動であっても、前処理と後処理の自動化は有効



それでも細かい配慮事項は多い。

テストが異常終了した際に、データをどう保全するか

テストケースごとに処理を行うか、テストセット単位で行うか

- たとえばデータベースの生成とデータの復元

前後処理をどんなツールで実装するのか

たとえばシェルスクリプトで実装した場合、テスト自動化ツールとど

のように統合するのか

長谷川さんのセッションでも言及あります！


❸実行


❻後処理

❹比較



選択


❽メトリクス

第7章保守性の高いテストを構築する




・・・



テストウェアのメンテナンスは忘れられがち！

メンテコストは実は、手動より自動で効いてくる

手動は実行しながら修正できる。自動だと失敗に終わる

顧客情報で「電話番号」が増えたら？電話番号とは何？

第7章はアンチパターン集



テストデータや期待結果も必要

同様に、メンテナンスコストがかかる

実行時間が長時間化する

価値があるテストケースなのか？という観点での

「草刈り」が必要

テストケース数は、多ければ多いほどイイ!!?

高度なアプローチであれば、ケースの追加は簡単だけど・・・



長いテストでコケると、その地点以降の欠陥は

隠れたまま

長いとそれだけ、失敗の際の解析も大変

複雑になるほど、メンテナンスもつらくなる

短いテストケースから始めよう。

長いテストケースは、手動でやるのがいいのかも。

機械がやるテストながら、長くて複雑なテストケースがイイ!!?

確かにややこしいテストは機械におまかせしたいが・・・



特殊な形式では、直接の編集が難しい

アプリケーション側で形式が変更になった場合、作ってしまったデータセットの作り直しで泣く

ニュートラルな形式なら、変換プロセスのみの更新で済む

できるだけテキスト形式で保持しよう。

（ただし、わたしはExcelが大好きです）

データセットは、アプリケーション固有の形式で持つのが一番!!?

確かにテストごとの変換の手間はないが・・・



テスト結果は、OK / NGさえわかれば十分だ!!?

テストウェアの名前は、個々人の自由な発想で命名しよう!!?

などなど、保守性を損なうアンチパターンを事前に知っておきましょう。→ 詳しくは .reviewrcや午後の伊藤さんのセッションでも！


❸実行


❻後処理

❹比較



選択


❽メトリクス

第8章メトリクス




・・・



“ Measure what is measurable and

make measureable what is not so.- Galileo Galilei (1564-1642) ”

“ If you can not measure it, you

cannot improve it.- Lord Kelvin (1824-1907) ”

聞き飽きた引用ですね。


「測る」対象として、テストと自動テストは別物

どちらか一方となれば、まずはテストを測るべし

そもそもテストがダメなら、自動化してもダメ

測る目的を、明確に！


テスト自動テスト＞


DDP (Defect Detection Percentage)

その工程までの発見された全欠陥のうち、その

工程で発見された欠陥の割合

機能ごとの分類、深刻度による重み付け、・・・

DDPの低下 = テストの欠陥検出能力の低下

DFP (Defect Fix Percentage)

既知の欠陥のうち、修正された欠陥の割合

徹底性

コードカバレッジとか、画面上の部品全部とか

自動的に計測できるものも多い

ROI (Return On Investment）

@ITの太田さんの記事に詳しい


テスト

自動テスト

http://www.atmarkit.co.jp/ait/articles/1406/03/news152.html


保守性: ソフトウェアの更新に追随できるか？

更新の発生頻度、更新にかかる時間、・・・

ユーザビリティ: フレームワークは使いやすい？

テストの追加の容易さ、トレーニングの時間、・・・

堅牢性: テストを安定して進められる？

テストがつまづく頻度、原因調査の時間、・・・

移植性: 他のプラットフォームでも使える？

効率性: テストの効率は上がっている？

テスティングのアクティビティに要する時間の比率

全体工数

テスト失敗時の分析に時間がかかり始める


テスト

自動テスト


信頼性: 判定結果は信頼できる？

擬陽性と擬陰性

いわゆるソフトウェアのreliabilityとちょっと違う

柔軟性: 素早くテストに着手できる？

サブセットを取り出すことの簡単さとか

過去のバージョンのとりだしやすさとか。

井芹さんの『テスト自動化の品質モデルの扱

い』では、「テスト環境の品質」として整理

自動テストの品質モデルとして、さらに、「テスタ

ビリティの品質」と「テスト設計の品質モデル」を

定義


テスト

自動テスト

http://www.slideshare.net/goyoki/tq-mfor-sts

http://www.slideshare.net/goyoki/ss-36405244

http://www.slideshare.net/goyoki/tq-mfor-sts



おすすめのスターターキット

テスト自動テスト

重大な欠陥のDDP 自動化に要する時間

自動スクリプトの保守に要する時間

実行できるテストケース数、回数など


❸実行


❻後処理

❹比較


自動テストケース❾実行するテストケースの選択、順番付け、・・・❿ツールの

選択


❽メトリクス

第9章その他の課題




・・・


まだまだ検討すべきことが！


自動化の優先順位

実行するテストの選択

テストの実行順序の決定

テストステータス、結果のレポート

手動テストケース1













❶

❸

❹

❷

❸

❶

❷



自動化の優先順位

すべてのテストケースを自動化しないといけないわけではない

優先順位づけする基準はいくつもある。

- 手軽に自動化できるものから？

- 重要な機能から？

- 担当者のストレスになっている項目から？

手っ取り早く成果が見えることも、組織としては大事

実行するテストの選択

目的に応じて、適切なテストセットを素早く選べなくては

- たとえばテストタイプごと、前回実行時に「失敗」だったもののみ、・・・



テスト実行順序

テストケースをグルーピングし、論理的に階層化する

- たとえば、スモークテスト的な上層と、機能を細かく検証する下層。

上層でこけたら、下層のテストは実行しない

- 実行環境ごとにグルーピングすることも

テストステータス

「成功」と「失敗」だけでは必ずしもうまくいかない

既知の未修正欠陥による「期待された失敗」

- 複数の欠陥のうち、一部だけを修正して再テストを行う場合

- 自動テストで忘れられがちな、「失敗」に対する調査時間

- 最初からテスト対象にしない？逆にすべて「失敗」に倒す



進捗のモニタリング

さまざまなメトリクスを盛り込んだレポート- テストケース数（指定、実行、成功、失敗、・・・）

- エラーメッセージ、差分ファイル

- テスト失敗の原因のサマリ

- 経過時間

SQiP2014でBest Report Future Awardを受賞された、楽天の荻野恒太郎さんの発表がすごく面白いです。

このデータの取得も

自動化しよう！

http://www.juse.jp/sqip/symposium/report/

http://www.slideshare.net/kotaroogino/ngauto-s-qip2014presentation20140906


❸実行


❻後処理

❹比較



選択


❽メトリクス

第10章テスト自動化ツールの選択




・・・


ツールの購入、そして導入は、一大プロジェクト


購入プロセス

導入プロセス

ロールの割当

変革の管理

コミットメント確保

パイロットプロジェクト

段階的導入

継続的改善

要件の把握

チーム作り

制約の把握

市場の調査

デモ評価・決定


ある程度の規模であれば、選定のチームが必要


購入プロセス

要件の把握

チーム作り

制約の把握

市場の調査


選択と評価の責任をもつ、各部

門の代表者を集める

多様なスキルが必要

将来のオートメーターもメンバーに


そもそも、ツールで解決できる問題なのか？


購入プロセス

要件の把握

チーム作り

制約の把握

市場の調査


自動化しても、テスト自体がよく

なるわけではない

- リグレッションテストの時間がない？

- 静的解析やインスペクションでは？

- 解決策はツールじゃない、場合も

投資効果検討書

- テスティングに要する工数、欠陥の

見逃しによるコスト、ツールのイニシャ

ルコスト、ラニングコスト、・・・

- 定量化できない要素もあり

制約を的確に把握

- ハードウェア、既存の開発ツール

- コスト、社内政治、・・・


ここでやっと、ツールの調査開始


購入プロセス

要件の把握

チーム作り

制約の把握

市場の調査


候補となるツールのリスト作成

- 『テストツールまるわかりガイド』

- 選定のための点数付け

- 絞り込み

自作か購入か

- 市場にいいものがなければ、自作

- 自作は見た目がしょぼく、使いづらい

かもしれないが、ニーズに対応しやす

い

ツール自体の情報の収集

- 評価レポート

- MLやユーザグループ

http://www.aster.or.jp/business/testtool_wg.html


ここでやっと、ツールの調査開始


購入プロセス

要件の把握

チーム作り

制約の把握

市場の調査


ベンダーがいる前提だけど・・・

自動化のデモのために

- 基本ルートのテストケースと、「悪

夢」のようなケースを事前に

- さらに、中間的なケースを当日に

- 対象となるアプリケーションでよく起こ

る種類の変更に基づくメンテナンス

定量評価

- テストケースの記録のための時間

- 比較で検出できた差分の数、・・・

- 購入までのプロセスを明確に、・・・


❸実行


❻後処理

❹比較



選択


❽メトリクス

第11章組織内へのツールの導入




・・・


購入よりも、実は導入こそがハードル


導入プロセス

ロールの割当

変革の管理



段階的導入

継続的改善

人は変革に対抗する・・・！

- 今のままでいい、変えたくないという

人の抵抗は大きい

- ツールがもたらすメリットを地道に広

めていく広報活動が重要

さまざまなロールが必要

- 自動化のエヴァンジェリスト

- 文化を変革してく人

- ツールの責任者

- 上層にいる支援者

上層部からのコミットメント

- 購入時点で途切れてはダメ

- 金・人といったリソースと、「変革を進

めるんだ」という態度の両方


一気に進めると危険


導入プロセス

ロールの割当

変革の管理



段階的導入

継続的改善

問題は小さいうちに摘む

- 「成功」の基準を決めたうえで試行。

楽観的な基準を立て過ぎない

- 小さいパイロットだからこその失敗も

段階的に導入する

- パイロットの欠陥を、ダメな面も含め

て広める。生産性は、当初は下がる

- 教育やトレーニングの準備

- 変化の公式 f(a, b, c) > z

a: 現状に対する不満

b: 共有された将来のビジョン

c: aからbに至る工程に関する知識

z:変革に必要となる心理的なコスト

ひたすら改善！


超かいつまむと、こんな感じです。


テストがしょぼければ、自動化してもしょぼい

自動化で欠陥をたくさん見つけられるわけではない

問題がないと教えてくれるわけでもない

自動化では、メンテナンスコストこそ重い

だからこそドキュメントの整備を忘れるな

標準と規律なしには長続きしない

えらい人のサポートが継続的に重要

自動化で浮いた時間で、人間ならではのテストを！

STAで繰り返し強調されること


翻訳について

英語から入力

技術的な理解

日本語で出力

レビュー

全体的な整合性用語・用字の統一訳注などの補強・・・

レビュー

テスト実装設計(済)

ビッグバンテストによるデスマ・・!!

ユーザ受け入れテストお願いします！

ユーザ受け入れテスト


質問は後のセッションの

方々へどうぞ！