Stac2013 opening-koukai

よりよいテスト自動化のためにちょっと考えて見ませんか？

～スコープ、ROI、プロセスを中心に

※公開用

2013.12.01

近江久美子

（STAR）

2013/12/01 Copyright (C) 2013 Kumiko Ohmi All rights reserved 1

講演者について

• 私

– STARコミッター

– ソフトウェアテスト・品質まわりの話題やアジャイルをテーマにした勉強会、コミュニティに出没


目次

1. このセッションは何？

2. 「よいテスト自動化」？

3. よりよいテスト自動化のために

1. スコープを見極める

2. ROIを評価する

3. プロセスを見直す

4. まだまだあるトピック

4. おわりに


このセッションは何？

• 「テスト自動化」どんなイメージですか？

– 楽しい／難しい

– 今やっていて役立っている…／過去に失敗…

– ユニットテスト／負荷テスト／機能テスト

• よりよいテスト自動化を達成するため、どんなことを考えればよいか？

– 万能薬はありません

– 皆さん自身の答えを探すためのポイントを考えて行きましょう



• 主に「ソフトウェアのユーザに価値がある単位で行われるテスト」の自動化を扱います

– 例ホテルの予約管理システムの予約検索機能

• 経験は問いません

– 始めたい人、再開したい人：とっかかりに

– 既にしている人：改善を考えて頂くきっかけに



より具体的な話や事例は、他のセッションをお楽しみに！

– 「事例から見るテスト自動化のポイント」

– モバイルアプリのテスト／テスト設計の自動化／ATDD／Seleniumのハンズオン

– 「Lightning Automated Testing Demo」

– 「テスト自動化のこれまでとこれから」


目次








4. おわりに


「よいテスト自動化」？

テスト自動化

やってみたいですか？

続けたいですか？



テストを

自動化できれば

満足ですか？



• 目の前にあるテストをとにかく、できるだけ自動化すれば、よい自動化になるだろうか？

• “自動化によって，大きな成果が上がる場合もあるが，大半は不満とストレスを募らせるだけである。”（本「ソフトウェアテスト293の鉄則」より）



ちょっと考えてみましょう（30秒間）

1：みなさんのテスト自動化の目的は？ • 例効率化

• 例手動ではできないテストをするため

2：1の目的は、どんな点に注意すればスムーズに達成できそうですか？ • 例ふさわしいツールを使う

• 例テスト対象やテストのことをよく理解する

• 例など



テスト自動化自体が目的ではないし、

目的はそれぞれ異なる

• 例1 効率化したい

– テスト自動化の学習や準備の時間＜テスト自動化しない場合にかかる時間になるようにする • 自動化しないテストもあるかもしれない

• 例2 手動ではできないテストをしたい

– 必要なテストを実行できるツールを選ぶ • 実行できるツールがなければ、複数のツールの連携などを検

討する必要がある




ただ自動化するだけではよい自動化にはならない



• ただ自動化するだけでは、よい自動化にはならない – よいテスト自動化は、それぞれ異なる

– よいテスト自動化の実現手段や、そのポイントも異なる

もうひとつ、考えてみましょう。

• 今までやってきた手動で行われるテストの単なる置き換えだと考えればいい？



手動で行われるテストと、自動化されたテストは、単純に置換えられるか？

→置き換えられない！

– 自動化されてできるようになるテスト

– 自動化で必要なツールの費用

– 自動化のために新しく増える・減る作業




自動化されたテストは、手動で行われるテストを単に置き換えるものではない



• ただ自動化するだけでは、よい自動化にはならない – よいテスト自動化は、それぞれ異なる

– よいテスト自動化の実現手段や、そのポイントも異なる

• 自動化されたテストは、手動で行われるテストを単に置き換えるものではない – 手動のテストのやり方をそのまま使ってもよ

い自動化にならないかもしれない



• 自分たちに合うスコープや、より高いROIを達成できる自動化を考える必要がある

• 自動化により生まれる価値を活かせるプロセスを考える必要がある

→3つのポイントから考えてみましょう


ROI スコーププロセス

目次








4. おわりに


スコープを見極める

• スコープを見極める意味



自動化できる範囲と、自動化しておいしい範囲は必ずしも一致しない


• スコープを見極める意味

– 自動化しておいしいところを明確にして、自動化する範囲を絞り込む

– 思わぬ追加作業が発生しないよう、ステークホルダー間で認識齟齬ない合意を行う


• テスト自動化の「スコープ」？

–「どの」テストか

–テストの「どこ」か



？？


• テストの作業（プロセス）例と「どの」「どこ」


青枠の部分は http://jasst.jp/symposium/jasst13tokyo/pdf/B2.pdf より

機能テスト

負荷テスト

…

「どの」例システムテストの機能テスト

「どこ」例テスト実行


「どの」「どこ」まで明確にする





機能テスト

負荷テスト

…

「どの」例システムテストの機能テスト

• 「どの」テストを自動化するか

– テストレベル

• 例クラスや関数単位で行う単体テストの自動化、システム全体で行うシステムテストの自動化

– テストタイプ

• “コンポーネント又はシステムをテストするためのテスト活動をまとめたものであり、たとえば機能テスト、使用性テスト、回帰テストなどのように特定のテスト目的に焦点を当てている ” （ http://jstqb.jp/dl/JSTQB-glossary.V2.2.J01.pdf より）







機能テスト

負荷テスト

…

「どこ」例テスト実行

• テストの「どこ」を自動化するか

– プロセスやアクティビティ

• テストは仕様書を見た瞬間にできるわけではない。

• 例自動化はテストの実行だけ？ – テスト分析（要件管理など）、テスト設計、テスト結果

管理などの自動化も

• プロセスの例（ http://jstqb.jp/dl/JSTQB-

SyllabusFoundation_Version2011.J02.pdf より）



テストの計画作業とコントロール

テストの分析と設計

テストの実装と実行

終了基準の評価とレポート

終了作業

• テストの「どこ」を自動化するか – 例「テストツールまるわかりガイド（入門編）

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 より）




「どの」「どこ」をどう見極めるか？

→自動化可能かどうかと、自動化必須かどうかの2点から考える

– 自動化しないと実現できないテストか？

– 自動化できるテストか？

– 自動化するとおいしいテストか？



• 自動化しないと、実現できないか？

–例数百人の接続を想定した性能テストの実行

–例数ヶ月間連続稼働させる耐久テストの実行

–そのテストが「必要ならば」自動化は必須。



• 自動化できるか？ ⇒自動化しては意味がないものはNG

– 手動で動かすこと、本番同等に動かすことが必須のテスト

– 例実際に運用可能か本番業務に近い形式で確認するテスト

• ⇒制約があり自動化できない – 乱数や外部情報に影響されて変わる部分をど

こまで自動化するか？ – 採用した自動化ツールができないこと

• 例印刷物の比較を自動化するか？ • 複数のツールを組合せる場合、連携も検討が必要



• 自動化は可能だが必須ではないテストは？

⇒自動化の利点が活かしやすい部分は… – 繰り返し行う部分

• 手動で同じように繰り返し実施することを考えると効果が出やすい

– 仕様が確定している／変わりにくい部分 • 人間と違って曖昧さを許さないので、変更に正確

に追随する必要がある

⇒回帰テスト、スモークテスト、GUIよりAPIのテストから考えてみるのがオススメ



• 「どの」「どこ」を、テスト自動化必須か、テスト自動化しておいしいかで明確にした！

• スコープが見えてきたら、すぐにすべてを自動化すべきか？

→そのテスト自動化、どのくらいの価値がありますか？ ROIを評価しましょう


目次








4. おわりに


ROIを評価する

• ROI＝Return On Investment – 投資収益率

• 投資によってどれだけの利益がうまれたか？


投資

利益

ROIを評価する

• ROIの評価はなぜ大事か？

– ROIの評価で、負担を節約、利益を出せるおいしいところだけ自動化

– 保守・派生プロジェクトでも、時にはROIの観点から見直し、改善につなげる

• でも、ROIの評価は難しい


再実行の回数

スクリプト作成の負荷

ROIを評価する

ツールの購入コスト

導入に必要なスキルのトレーニング

コスト

サポートやライセンスなど保守契約に要する

コスト

自動化により可能になったテストのテスト設計の負荷

スクリプトメンテナンスの負荷

自動化ツールのレポートの分析のた

めの時間

ツールの動作に必要な環境の構築コスト

新技術の導入等による利用技術の変化に対応

する手間

自動テスト可能なつくりにするためのコスト

スクリプトのメンテナンスのための

技術伝承のコスト

ツール起因のトラブルへの

対応負荷

ツールのバージョンアップへの対応負荷

ツールの動作環境の

メンテナンスのコスト

39

… 欠陥修正後の確認テストにかかる時間

2013/12/01 Copyright (C) 2013 Kumiko Ohmi All rights reserved

テスト期間が短いので連続で実行したい

ROIを評価する

• 利益：

– 最終的にはプロジェクトやプロダクトの利益につながらなくてはならない

• 品質向上

• リスク軽減

• コスト削減

• 納期短縮（時間の節約）



テストにもたらされる変化を通して利益を分析する

ROIを評価する

• 利益：

– 最終的にはプロジェクトやプロダクトの利益につながらなくてはならない

• 品質向上

• リスク軽減

• コスト削減

• 納期短縮（時間の節約）

– 直接的に影響を受けるのはテスト。

自動化によりテストの何が変わるのか？


ROIを評価する

自動化はテストの品質・コスト・

時間(効率)・スコープを変える • 品質：再現性、トレーサビリティの向上

自動化準備を通した理解度向上の影響（例テストデータの早期検討でバグ検出）

• コスト：人件費を人間しかできないことへ

同じ作業の繰り返しのコスト減

• 時間：長時間稼働させてテストを短期間に

属人性の低下、知識伝承の効率化

• スコープ：手動では困難なテストが可能に


ROIを評価する

洗い出したら、プロジェクトやプロダクトの利益に結びついているか？を確認

• 例：

– スコープ：手動では困難なテストができるようになる

→性能が出ないことによるリスクを下げるために役立つ

→性能問題によるクレーム対応のコスト☓☓円を削減できる


ROIを評価する

• 投資：

– 4つの軸×時間の軸で考える



時間による変化もお忘れなく

ROIを評価する

• 投資：

– 4つの軸×時間の軸で考える

• ツール、テストプロセス、人、プロダクト（テスト実行の自動化の場合）

• 時間＝導入時点/導入後


ツール／テストプロセス／人／プロダクトについて、時間軸で考える

http://jasst.jp/symposium/jasst13tokyo/pdf/B2.pdf を一部更新

• 投資：ROI評価で考えるべき要素を洗い出す軸と例

時間

導入前～導入プロジェクト導入後～ソフトウェアライフサイクル全体

ツールツールの購入コストサポートやライセンスなど保守契約に要するコスト

テストプロセス

自動テストスクリプト作成の時間

自動テストで検出されたバグの分析に要する時間

人導入に必要なスキルのトレーニングコスト

自動テストスクリプトのメンテナンス技術伝承のコスト

プロダクト自動テスト可能なつくりにするためのコスト

新技術の導入等による利用技術の変化に対応するコスト

48 2013/12/01 Copyright (C) 2013 Kumiko Ohmi All rights reserved

ROIを評価する

ROIを評価する

• 「時間」 – 手動の場合と違い初期コストと運用コストは異なる

• 「ツール」

– 自動化で導入されるツール。外部調達か内部でつくるかによっても違いがうまれる

• 「テストプロセス」「人」「プロダクト」

– 自動化により、プロセス、必要な人材が変わることがある

– プロダクトが自動化により生まれる制約を満たすか考慮する必要がある

– 自動化前との違いは？自動化に適しているか？今後変化したら？


ROIを評価する

注意点

– 目的にあった利益と投資で計算する

• よい自動化が、よく見えなくなってしまうことがある

• 目的を果たしたうえで、ROIを大きくする

– 投資も利益も、時間やコストで計算する場合は更に見積もりが必要

– 厳密に評価するとそれなりにコストがかかる



濃淡をつけて評価する

ROIを評価する

広範囲にわたって利益・投資を見通すのは非常に困難。必要なだけ評価する

– ROI評価それ自体が割高になってしまう恐れ

– 「テスト自動化」という範囲だけではなく、テストやプロジェクトへの要求やリスクを踏まえて重要なポイントの評価に注力する


ROIを評価する

スコープを見極め、ROI評価の結果も上々！

今回のテスト自動化、よりよくそうだ…

→実現のために、適切なプロセスを！


目次








4. おわりに


プロセスを見直す

• スコープの見極めやROI評価で「おいしくなりそうな」ことがわかっている自動化でも、適したプロセスでなくてはおいしくならない

– 何を確認／コントロールすべき？

– プロセスを見直す



• 具体的にどこが、手動テストと異なるのか？

– 自動化された部分は作業がなくなる／減る

• それだけ？



• 導入するツールや導入の仕方に依存するので、あるべき姿／現状を分析する

– 導入前：運用可能なことや変更すべきことを知るため

– 導入後：改善の足がかりにするため

– テスト実行の自動化について、具体的に考えてみましょう



テスト実行の場合 – テスト対象を自動化しやすいつくりにする作業が追加に – 自動テストスクリプトの設計、実装、セットアップが追加

に – 自動テストスクリプトの構成管理が追加に – テスト実行をする、レポートをつくる手間は少なくなる

– テストの事前条件や入出力、合否判定の基準や方法を早期

に決定する – テスト不合格時、エラー時の挙動を早期に決定する – 結果を確認するためのレポートの内容を早期に決定する – 一部のレビューは、テストスクリプトのレビューに代える



テスト実行の場合 • 負荷が変わる

– テスト対象を自動化しやすいつくりにする作業が追加に – 自動テストスクリプトの設計、実装、セットアップが追加

に – 自動テストスクリプトの構成管理が追加に – テスト実行をする、レポートをつくる手間は少なくなる

• タイミングが変わる – テストの事前条件や入出力、合否判定の基準や方法を早期

に決定する – テスト不合格時、エラー時の挙動を早期に決定する – 結果を確認するためのレポートの内容を早期に決定する – 一部のレビューは、テストスクリプトのレビューに代える


スクリプトの構成管理

スクリプトや環境の準備

テストのレビュー

自動化対象（テスト実行）


負荷が変わるタイミングが変わる

• テスト実行の場合 – 負荷が変わる

• テスト対象を自動化しやすいつくりにする作業が追加される • 自動テストスクリプトの設計、実装が追加される • 自動テストスクリプトのレビューが追加される • 自動テストスクリプトの構成管理が追加される • 自動テストスクリプトを動かす環境の準備が追加される • テスト実行をする、レポートをつくる手間は少なくなる

– テスト実行回数が増えるかもしれない

– タイミングが変わる • テストにおける事前条件や入出力、合否判定の基準や方法を

決定する • テストが不合格になったり、エラーになったときの挙動を決

定する • 結果を確認するためのレポートの内容を決定する



テスト以外のプロセスにも影響する

他組織との連携が発生することも

現在のプロセスは？


テスト以外や他組織への影響、現在のプロセスに注意


注意点 – テスト以外、他組織への影響も忘れずに

• 例コードにオブジェクトを特定するための仕組みを仕込んでおく必要がある

– 自動化前からテストプロセスが機能していなかったら、まずはその整備から • 自動化で、すべてが解決することはない • 意味がないテストを自動化しても意味がない

よいテストをつくることが先

– ツールのバージョンアップやプロダクトの規模拡大、人の習熟度等により適宜、見直す

– 自動化により、変えることができる部分も発生する



「よくなりそうな」テスト自動化を、自動化に適したプロセスの整備により「よい」テスト自動化にする

• 負荷・タイミングの検討

• テスト以外のプロセスや組織、現状分析もお忘れなく


目次








4. おわりに


まだまだあるトピック

本セッションで語りきれるほど、テスト自動化の世界は狭くありません。

– スキル、チーム

– 自動化されたテスト実行のバグの分析

– よいテストをつくるには？

– よい自動テストスクリプトをつくるには？

– 自動化されたテストの品質

– ツールの選定

– など

少しだけ考えてみましょう



• スキル、チーム – テスト、自動化、ツール、環境をしらなくてはならない

– “テストの自動化に必要なのは、プログラミング，テスト，プロジェクト管理のスキル”（本「ソフトウェアテスト293の鉄則」p125より）

– 「テスト」だけでも…

• Test.SSF“テスト技術に関するスキルカテゴリ”より

– テスト技法

– モデリング技法など

– （ http://www.aster.or.jp/business/testssf/doc/TestSSF_Skill_V1_20121214.pdf より）

• ステークホルダーやテストへの要求や制約を分析し、内容も網羅度もちょうどよいテストを設計、実装するためのスキル

– スキルを持った人を集めるか、データ駆動型やキーワード駆動型でスキルが違うひと同士の分担を容易にするか？



• 自動化されたテスト実行のバグの分析 – テスト自動化を開始できても、トラブルにあたるか

もしれない – どんなバグ？ ―結果による分類

• テスト対象が誤っている • テストが誤っている →どう予防するか？切り分けるか？

– どんなバグ？ ―原因による分類 • プログラムの問題 • テスト環境の問題 • 自動テストスクリプトの問題 →自動化で追加される • 自動テストツールの問題 →自動化で追加される

→予防と切り分けを容易にするための手当てを検討 • 自動テストスクリプトのテスト実行前のレビュー実施 • 自動テストスクリプトの設計、コーディングのルール定義 • ログやレポートの出力の設定


目次








4. おわりに


このセッションでは、「よりよいテスト自動化を達成するため、どんなことを考えればよいか？」を考えてきました

ところで、テストは…


おわりに

おわりに

テストは、プロジェクトやプロダクトの

見える化を促進する

– バグ、リリースしてよいかどうか、…


おわりに

テストは、プロジェクトやプロダクトの

見える化を促進する

– バグ、リリースしてよいかどうか、…

テスト自動化により、テストは柔軟になる、

幅が広がる

– テスト自動化は、うまく使えば強力な武器

– 見える化が、より柔軟にできるようになったり、幅が広がったりする


テスト自動化を通して、よりよいテスト、

よりよいプロジェクト、プロダクトを！


「よいテスト自動化」？自動化＝よい自動化とは限らないテスト自動化は、単なる手動による

テストの置き換えではないスコープできる範囲と、しておいしい範囲は

必ずしも一致しない「どの」「どこ」まで明確にする ROI

テストにもたらされる変化を通して利益を分析する時間による変化もお忘れなく濃淡をつけて評価する

プロセス負荷が変わるタイミングが変わる

テスト以外の部分、他組織への影響、現在のプロセスに注意

おわりに

みなさんの目的や現状を思い浮かべながら

今日1日、沢山持ち帰って下さい

– 「事例から見るテスト自動化のポイント」

– モバイルアプリのテスト／ATDD／テスト設計の自動化／Seleniumのハンズオンのセッション

– 「Lightning Automated Testing Demo」

– 「テスト自動化のこれまでとこれから」

– 懇親会

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


おわりに

参考文献（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年


参考文献（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年


Stac2013 opening-koukai

Software

Transcript of Stac2013 opening-koukai