Weitere ähnliche Inhalte
Ähnlich wie Stac2013 opening-koukai (20)
Stac2013 opening-koukai
- 2. 講演者について
•私
–STARコミッター
–ソフトウェアテスト・品質まわりの話題やア ジャイルをテーマにした勉強会、コミュニ ティに出没
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
2
- 3. 目次
1.このセッションは何?
2.「よいテスト自動化」?
3.よりよいテスト自動化のために
1.スコープを見極める
2.ROIを評価する
3.プロセスを見直す
4.まだまだあるトピック
4.おわりに
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
3
- 4. このセッションは何?
•「テスト自動化」どんなイメージですか?
–楽しい/難しい
–今やっていて役立っている…/過去に失敗…
–ユニットテスト/負荷テスト/機能テスト
•よりよいテスト自動化を達成するため、 どんなことを考えればよいか?
–万能薬はありません
–皆さん自身の答えを探すためのポイントを考 えて行きましょう
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
4
- 6. このセッションは何?
より具体的な話や事例は、他のセッション をお楽しみに!
–「事例から見るテスト自動化のポイント」
–モバイルアプリのテスト/テスト設計の自動 化/ATDD/Seleniumのハンズオン
–「Lightning Automated Testing Demo」
–「テスト自動化のこれまでとこれから」
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
6
- 7. 目次
1.このセッションは何?
2.「よいテスト自動化」?
3.よりよいテスト自動化のために
1.スコープを見極める
2.ROIを評価する
3.プロセスを見直す
4.まだまだあるトピック
4.おわりに
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
7
- 12. 「よいテスト自動化」?
テスト自動化自体が目的ではないし、
目的はそれぞれ異なる
•例1 効率化したい
–テスト自動化の学習や準備の時間<テスト自動化し ない場合にかかる時間 になるようにする
•自動化しないテストもあるかもしれない
•例2 手動ではできないテストをしたい
–必要なテストを実行できるツールを選ぶ
•実行できるツールがなければ、複数のツールの連携などを検 討する必要がある
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
12
- 14. 「よいテスト自動化」?
「よいテスト自動化」?
•ただ自動化するだけでは、よい自動化に はならない
–よいテスト自動化は、それぞれ異なる
–よいテスト自動化の実現手段や、そのポイン トも異なる
もうひとつ、考えてみましょう。
•今までやってきた手動で行われるテスト の単なる置き換えだと考えればいい?
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
14
- 17. 「よいテスト自動化」?
「よいテスト自動化」?
•ただ自動化するだけでは、よい自動化に はならない
–よいテスト自動化は、それぞれ異なる
–よいテスト自動化の実現手段や、そのポイン トも異なる
•自動化されたテストは、手動で行われる テストを単に置き換えるものではない
–手動のテストのやり方をそのまま使ってもよ い自動化にならないかもしれない
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
17
- 19. 目次
1.このセッションは何?
2.「よいテスト自動化」?
3.よりよいテスト自動化のために
1.スコープを見極める
2.ROIを評価する
3.プロセスを見直す
4.まだまだあるトピック
4.おわりに
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
19
- 27. •「どの」テストを自動化するか
–テストレベル
•例 クラスや関数単位で行う単体テストの自動化、 システム全体で行うシステムテストの自動化
–テストタイプ
•“コンポーネント又はシステムをテストするため のテスト活動をまとめたものであり、たとえば機 能テスト、使用性テスト、回帰テストなどのよう に特定のテスト目的に焦点を当てている ” ( http://jstqb.jp/dl/JSTQB-glossary.V2.2.J01.pdf より)
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
27
スコープを見極める
- 29. •テストの「どこ」を自動化するか
–プロセスやアクティビティ
•テストは仕様書を見た瞬間にできるわけではない。
•例 自動化はテストの実行だけ?
–テスト分析(要件管理など)、テスト設計、テスト結果 管理 などの自動化も
•プロセスの例( http://jstqb.jp/dl/JSTQB- SyllabusFoundation_Version2011.J02.pdf より)
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
29
スコープを見極める
テストの 計画作業 とコント ロール
テストの 分析と
設計
テストの 実装と 実行
終了基準 の評価と レポート
終了作業
- 30. •テストの「どこ」を自動化するか
–例 「テストツールまるわかりガイド(入門編) ver.1.0.1」でのツールの紹介
•テスト設計
•テストウェア管理
•テスト結果管理
•など
–例 テスト実行は、3要素に分けられる
•Drive …操作、駆動
•Judge …判定
•Report …報告
•( http://sssslide.com/www.slideshare.net/ussy/android- developertesting 、 http://www.jasst.jp/symposium/jasst13tokyo/pdf/B2.pdf より)
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
30
スコープを見極める
- 32. スコープを見極める
•自動化しないと、実現できないか?
–例 数百人の接続を想定した性能テス トの実行
–例 数ヶ月間連続稼働させる耐久テス トの実行
–そのテストが「必要ならば」自動化は 必須。
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
32
- 33. スコープを見極める
•自動化できるか?
⇒自動化しては意味がないものはNG
–手動で動かすこと、本番同等に動かすことが必須 のテスト
–例 実際に運用可能か本番業務に近い形式で確認 するテスト
•⇒制約があり自動化できない
–乱数や外部情報に影響されて変わる部分をど こまで自動化するか?
–採用した自動化ツールができないこと
•例 印刷物の比較を自動化するか?
•複数のツールを組合せる場合、連携も検討が必要
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
33
- 34. スコープを見極める
•自動化は可能だが必須ではないテスト は?
⇒自動化の利点が活かしやすい部分は…
–繰り返し行う部分
•手動で同じように繰り返し実施することを考える と効果が出やすい
–仕様が確定している/変わりにくい部分
•人間と違って曖昧さを許さないので、変更に正確 に追随する必要がある
⇒回帰テスト、スモークテスト、GUIより APIのテストから考えてみるのがオススメ
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
34
- 36. 目次
1.このセッションは何?
2.「よいテスト自動化」?
3.よりよいテスト自動化のために
1.スコープを見極める
2.ROIを評価する
3.プロセスを見直す
4.まだまだあるトピック
4.おわりに
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
36
- 37. ROIを評価する
•ROI=Return On Investment
–投資収益率
•投資によってどれだけの利益がうまれたか?
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
37
投 資
利 益
- 39. 再実行 の回数
スクリプト作成の 負荷
ROIを評価する
ツールの
購入コスト
導入に必要なスキルの トレーニング コスト
サポートやライセンスな ど保守契約に要する コスト
自動化により可能になった テストのテスト設計の負荷
スクリプトメンテ ナンスの負荷
自動化ツールのレ ポートの分析のた めの時間
ツールの動作に 必要な環境の 構築コスト
新技術の導入等による
利用技術の変化に対応 する
手間
自動テスト可能なつくりに
するためのコスト
スクリプトの メンテナンスのための 技術伝承のコスト
ツール起因の トラブルへの 対応負荷
ツールのバージョン
アップへの対応負荷
ツールの
動作環境の
メンテナンスのコスト
39
…
欠陥修正後の確認テ ストにかかる時間
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
テスト期間が短いの で連続で実行したい
- 42. ROIを評価する
•利益:
–最終的にはプロジェクトやプロダクトの利益 につながらなくてはならない
•品質向上
•リスク軽減
•コスト削減
•納期短縮(時間の節約)
–直接的に影響を受けるのはテスト。
自動化によりテストの何が変わるのか?
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
42
- 43. ROIを評価する
自動化はテストの品質・コスト・
時間(効率)・ スコープを変える
•品質 :再現性、トレーサビリティの向上
自動化準備を通した理解度向上の影響
(例 テストデータの早期検討でバグ検出)
•コスト:人件費を人間しかできないことへ
同じ作業の繰り返しのコスト減
•時間 :長時間稼働させてテストを短期間に
属人性の低下、知識伝承の効率化
•スコープ:手動では困難なテストが可能に
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
43
- 47. ROIを評価する
•投資:
–4つの軸×時間の軸で考える
•ツール、テストプロセス、人、プロダクト(テス ト実行の自動化の場合)
•時間=導入時点/導入後
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
47
- 49. ROIを評価する
•「時間」
–手動の場合と違い初期コストと運用コストは異なる
•「ツール」
–自動化で導入されるツール。外部調達か内部でつく るかによっても違いがうまれる
•「テストプロセス」「人」「プロダクト」
–自動化により、プロセス、必要な人材が変わること がある
–プロダクトが自動化により生まれる制約を満たすか 考慮する必要がある
–自動化前との違いは? 自動化に適しているか? 今後変化したら?
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
49
- 50. ROIを評価する
注意点
–目的にあった利益と投資で計算する
•よい自動化が、よく見えなくなってしまうことが ある
•目的を果たしたうえで、ROIを大きくする
–投資も利益も、時間やコストで計算する場合 は更に見積もりが必要
–厳密に評価するとそれなりにコストがかかる
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
50
- 54. 目次
1.このセッションは何?
2.「よいテスト自動化」?
3.よりよいテスト自動化のために
1.スコープを見極める
2.ROIを評価する
3.プロセスを見直す
4.まだまだあるトピック
4.おわりに
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
54
- 58. プロセスを見直す
テスト実行の場合
–テスト対象を自動化しやすいつくりにする作業が追加に
–自動テストスクリプトの設計、実装、セットアップが追加 に
–自動テストスクリプトの構成管理が追加に
–テスト実行をする、レポートをつくる手間は少なくなる
–テストの事前条件や入出力、合否判定の基準や方法を早期 に決定する
–テスト不合格時、エラー時の挙動を早期に決定する
–結果を確認するためのレポートの内容を早期に決定する
–一部のレビューは、テストスクリプトのレビューに代える
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
58
- 59. プロセスを見直す
テスト実行の場合
•負荷が変わる
–テスト対象を自動化しやすいつくりにする作業が追加に
–自動テストスクリプトの設計、実装、セットアップが追加 に
–自動テストスクリプトの構成管理が追加に
–テスト実行をする、レポートをつくる手間は少なくなる
•タイミングが変わる
–テストの事前条件や入出力、合否判定の基準や方法を早期 に決定する
–テスト不合格時、エラー時の挙動を早期に決定する
–結果を確認するためのレポートの内容を早期に決定する
–一部のレビューは、テストスクリプトのレビューに代える
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
59
スクリプトの構成管理
スクリプトや環境の準備
テストのレビュー
自動化対象(テスト実行)
- 61. •テスト実行の場合
–負荷が変わる
•テスト対象を自動化しやすいつくりにする作業が追加される
•自動テストスクリプトの設計、実装が追加される
•自動テストスクリプトのレビューが追加される
•自動テストスクリプトの構成管理が追加される
•自動テストスクリプトを動かす環境の準備が追加される
•テスト実行をする、レポートをつくる手間は少なくなる
–テスト実行回数が増えるかもしれない
–タイミングが変わる
•テストにおける事前条件や入出力、合否判定の基準や方法を 決定する
•テストが不合格になったり、エラーになったときの挙動を決 定する
•結果を確認するためのレポートの内容を決定する
プロセスを見直す
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
61
テスト以外のプロセ スにも影響する
他組織との連携が 発生することも
現在のプロセスは?
- 63. プロセスを見直す
注意点
–テスト以外、他組織への影響も忘れずに
•例 コードにオブジェクトを特定するための仕組みを 仕込んでおく必要がある
–自動化前からテストプロセスが機能していなかっ たら、まずはその整備から
•自動化で、すべてが解決することはない
•意味がないテストを自動化しても意味がない
よいテストをつくることが先
–ツールのバージョンアップやプロダクトの規模拡 大、人の習熟度等により適宜、見直す
–自動化により、変えることができる部分も発生す る
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
63
- 65. 目次
1.このセッションは何?
2.「よいテスト自動化」?
3.よりよいテスト自動化のために
1.スコープを見極める
2.ROIを評価する
3.プロセスを見直す
4.まだまだあるトピック
4.おわりに
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
65
- 67. まだまだあるトピック
•スキル、チーム
–テスト、自動化、ツール、環境をしらなくてはならない
–“テストの自動化に必要なのは、プログラミング,テスト,プ ロジェクト管理のスキル”(本「ソフトウェアテスト293の鉄則」p125より)
–「テスト」だけでも…
•Test.SSF“テスト技術に関するスキルカテゴリ”より
–テスト技法
–モデリング技法 など
–( http://www.aster.or.jp/business/testssf/doc/TestSSF_Skill_V1_20121214.pdf より)
•ステークホルダーやテストへの要求や制約を分析し、内容も 網羅度もちょうどよいテストを設計、実装するためのスキル
–スキルを持った人を集めるか、データ駆動型やキーワード駆動 型でスキルが違うひと同士の分担を容易にするか?
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
67
- 68. まだまだあるトピック
•自動化されたテスト実行のバグの分析
–テスト自動化を開始できても、トラブルにあたるか もしれない
–どんなバグ? ―結果による分類
•テスト対象が誤っている
•テストが誤っている →どう予防するか? 切り分けるか?
–どんなバグ? ―原因による分類
•プログラムの問題
•テスト環境の問題
•自動テストスクリプトの問題 →自動化で追加される
•自動テストツールの問題 →自動化で追加される
→予防と切り分けを容易にするための手当てを検討
•自動テストスクリプトのテスト実行前のレビュー実施
•自動テストスクリプトの設計、コーディングのルール定義
•ログやレポートの出力の設定
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
68
- 69. 目次
1.このセッションは何?
2.「よいテスト自動化」?
3.よりよいテスト自動化のために
1.スコープを見極める
2.ROIを評価する
3.プロセスを見直す
4.まだまだあるトピック
4.おわりに
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
69
- 72. おわりに
テストは、プロジェクトやプロダクトの
見える化を促進する
–バグ、リリースしてよいかどうか、…
テスト自動化により、テストは柔軟になる、
幅が広がる
–テスト自動化は、うまく使えば強力な武器
–見える化が、より柔軟にできるようになった り、幅が広がったりする
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
72
- 73. テスト自動化を通して、よりよいテスト、
よりよいプロジェクト、プロダクトを!
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
73
「よいテスト自動化」?
自動化=よい自動化とは限らない
テスト自動化は、単なる手動による テストの置き換えではない
スコープ
できる範囲と、しておいしい範囲は 必ずしも一致しない
「どの」「どこ」まで明確にする
ROI
テストにもたらされる変化を通して利益 を分析する
時間による変化もお忘れなく
濃淡をつけて評価する
プロセス
負荷が変わる タイミングが変わる
テスト以外の部分、他組織への影響、 現在のプロセスに注意
おわりに
- 75. 参考文献(1/2)
•「Software Test Automation」, Mark Fewster (著), Dorothy Graham (著), 1999年
•「SSFに基づくテスト技術スキルフレームワーク スキル基準」 , http://aster.or.jp/business/testssf/doc/TestSSF_Skill_V1_20121214.pdf
•「TEST AUTOMATION BODY OF KNOWLEDGE (TABOK)」Automated Testing Institute, 2011年
•「Test.SSF スキル基準及びキャリア基準解説」, http://www.jasst.jp/symposium/jasst13tokyo/pdf/B4-2.pdf
•「アジャイルサムライ-達人開発者への道- 」, Jonathan Rasmusson (著), 西村 直 人 (監訳), 角谷 信太郎 (監訳), 近藤 修平 (翻訳), 角掛 拓未 (翻訳) , 2011年
•「ここからはじめる! Androidアプりのテスト自動化」, http://www.slideshare.net/nowsprinting/ques3-android-testautomation
•「実践Android Developer Testing」, http://sssslide.com/www.slideshare.net/ussy/android-developertesting
•「自動ソフトウェアテスト―導入から、管理・実践まで‐効果的な自動テスト環境の 構築を目指して」, エルフリード ダスティン (著), ジョン ポール (著), ジェフ ラシュ カ (著), Elfriede Dustin (原著), John Paul (原著), Jeff Rashka (原著), 向井 清 (翻訳), 2002年
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
75
- 76. 参考文献(2/2)
•「ソフトウェアテスト293の鉄則」, Cem Kaner (著), James Bach (著), Bret Pettichord (著), テスト技術者交流会 (翻訳) , 2003年
•「ソフトウェアテスト標準用語集(日本語版)Version 2.2.J01 」, http://jstqb.jp/dl/JSTQB-glossary.V2.2.J01.pdf
•「ソフトウエアを改善する50の実践手法」, エルフリード・ダスティン (著), 成田 光 彰 (翻訳), 2008年
•「テスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02」, http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf
•「テスト自動化術概論アルファ版 第3回 Ques」 , 松木 晋祐, 2013年
•「テストツールまるわかりガイド(入門編) Ver.1.0.1」, ASTERテストツールWG, 2012年
•「なれる!Test Automator」, http://www.jasst.jp/symposium/jasst13tokyo/pdf/B2.pdf
•「ビューティフルテスティング ―ソフトウェアテストの美しい実践」, Tim Riley (編 集), Adam Goucher (編集), 大西 建児(監訳) (翻訳), 児島 修 (翻訳), 2010年
2013/12/01
Copyright (C) 2013 Kumiko Ohmi All rights reserved
76