主な自動化の範囲として、よくあるVモデルにおける受け入れ/システムテストを対象としたカンファレンスに聴講者として参加してきました。
※経験積んで、登壇者側でgiveできたら嬉しいですね。
当日のタイムテーブルなどは以下を参考にしてください。
いきなり話しそれるのですが、ちまたではテストエンジニアはソフトウェアを学んだ人の割合が少ないと言われてると耳に挟むそうです。個人的に、それはテスターの間違いではなかろうかと思います。
Computer Scienceの経験がベースになければ妥当なテストを計画、設計、実装、実施も行えないでしょうし。
ソフトウェアエンジニアと、テストエンジニアはスキルセットに差分はあれど、多くの求められる基礎知識は同等なものであるはず。。。と。
さて、Twitterでは、ハッシュタグ #stac2013 にて検索すれば、ツイートを知ることができます。
以下、比較的だらだらとメモがてら書いたものを書いているのですが、今回の話題の中で一番大事なのは以下ではないでしょうか。
・自動化することを目的としてしまったらだめ（何らかの目的のための手段なのに、それが目的になってしまう・・・）
※後日、他の方がちゃんと纏められましたページを公開しそうですね。その場合、そちらをご参考ください。
※おいおい、発表者の方々が公開可能な形で資料を共有すると思いますが、適宜反映する予定です。
————————
《オープニングセッション》
Title: よりよいテスト自動化のためにちょっと考えてみませんか？ ―スコープ、ROI、プロセスを中心に―
[自分で考えてみましょう]
question 1. テスト自動化の目的は？
question 2. 1の目的は、どんな点に注意すればスムーズに達成できそう？
[自動化を行うにあたってのポイント]
スコープ / ROI / プロセス
[スコープを見極める]
* 「どの」テスト？
* 「どこ」のテスト？
[「どの」テストを自動化？]
* テストレベル
** 単体？システム？など
* テストタイプ
** 負荷/性能/機能など
[「どこ」を自動化？]
* プロセスやアクティビティ
* 「テストツールまるわかりガイド」
* テスト自動化は3要素に分けることも可能
** Drive : 操作、駆動
** Judge : 判定
** Report : 報告
おいしいところを自動化しよう!!
* 自動化は可能？
* 自動化は必須？
[自動化不可能]
* 本番同等に動かすことが必要なテスト（リハーサルなど）
* 制約があり自動化できない
** 乱数や外部情報に影響されて変わる部分をどこまで？
** 採用した自動化ツールができないこと
[自動化は可能だが必須ではないテストは？]
* 自動化の利点が活かしやすい部分
** 繰り返し
** 仕様が確定/変わりにくい部分
* 回帰テスト/スモークテスト/GUIよりはAPIテストから考える方がオススメ
[ROIを評価する]
* ROIの評価は大事
** 負荷の節約/利益を出せる？
* ツール/成熟度/メンテナンス等々、今後、自動化システムを保守するための資源
利益：project/productに繋がる
[自動化はテストの品質・コスト・時間・スコープを変える]
* 品質：再現性、トレーサビリティの向上、自動化準備を通した理解度向上
* コスト：人件費を人間にしかできないところへ
* 時間：長時間かどうさせてテストを短期間に、属人性の低下
* スコープ：主導では困難なテストが可能に
[Point: 時間による変化もお忘れなく]
* 4つの軸x時間の軸で考える
** ツール/テストプロセス/人/プロダクト
* 時間
** 導入前/導入後の違い
[テスト実行の場合]
* 負荷が変わる
** 自動テストスクリプトの構成管理
* タイミングが変わる
additonal notice
* 自動化し易い作りにする等
** テスト以外のプロセスに影響
* 他組織との連会なども
=> テスト以外の組織への影響などもある
* ツールのバージョンアップ/プロダクトの規模拡大、人の習熟度などにより適宜見直す
====
スキル/チーム
* テスト、自動化、ツールなどの知識
* テストの自動化に必要なのは、programming/test/projectmanagementのスキルが必要
* スキル持った人を集める？データ駆動型/キーワード駆動型でスキルを切り離す？
自動化されたテスト実行のバグの分析
* どんなバグ？
** テストが誤っている/テスト対象が誤っている
* それらを予防
————————————————-
[Twitterより抜粋]
* もうC&Rの時代ではなくてKDTの時代なんだから、コストよりスピードが自動化のメリットだと思うんだがね。
* テストの自動化、特にC&Rレベルの自動化を単一プロジェクトのROIで測ろうとするとキツいんだよね。派生全体でのROIだったり、組織能力向上だったり、自動化に伴うテスト設計やテストプロセスの改善が本当の価値なんだよね。それを測れると嬉しいよ。 #stac2013
* ちなみに10年以上前に某SIerさんとC&RのROIを測ったところ、やっぱり繰り返し3.4回が損益分岐点という数字に落ち着いた経験がある。でもそこだけにメリットを囚われるとテスト自動化のエンジニアリング的な嬉しさが見えなくなっちゃうんだよな。 #stac2013
* いえす。なので、さっきのテストタイプ？の一番下にプロダクトメトリクスが入ってたのです。RT @MasaoApril: ソフトウェアメトリクスの収集も自動化できるとメリットが出そう。
* テスト自動化の大きなメリットの一つは、GIGOにならないためにテスト設計を見直すことだと思う。特に、頭の中で無意識に間引いちゃうテスト条件を明示的に考えるようになるから、テスト要求モデリングやテスト設計モデリングが上手になるんだよね。 #stac2013
* テストプロセスに興味がある人は、リファレンスモデルとしてISO/IEC/IEEE29119-2というのが先日出版されました。英語でしかも有料ですが、テストプロセスの整備のテキストとしてはよいものだと思います。ちなみに策定中の29119-5はKDT。ご一読を。 #stac2013
* オラクルさんが会場だから言うわけじゃ無いけど、テストオラクル（＝期待結果）の自動生成の難しさの話ってしてたのかな？遅刻したので話してたらごめん。 #stac2013
————————————————-
————————————————-
《事例から見るテスト自動化のポイント》
* Validation/Verificationに関して、現実・現場の課題や解決を共有する
トイレの歴史に学ぶ自動化パターン
* 過剰な自動化に走り、コスト増に向かっていくと残念な結果になる。
[自動化事例をまとめてみた]
自動化を進めていく。しかし、評価項目がかぶるものが。。。
=> 自動化が目的になり、自動スクリプトが分散し、保守できなくなり・・・
=> メンテできなくなる
ファクトリーオートメーション
* 多くが要求される品質：信頼性
** FA制御用の汎用機機
* 信頼性検証の自動化
* マインドマップ
* 稼働までにかる機関・労力 <= 半端ない
* 効果を実証するつもりが無いなら、やらない方が良い
=> 初期：あまり効果無かった
=> 次
=> テストスイート: 多品種大量生産
* 振り返り
=> もうむり
* 人がやってたことは、実はすごく賢いし、情報の流れとか簡単には見えてこない
* 無意識にしていることは、見えているようにすることをすら
* factory automationは、生産現場レベルで、効果の計測・振り返りをベースとしたたゆまぬ改善が既にある。
* 人の思考・行為を自動化するためには、高度な専門知識・技術獲得・体系化が必要となる。
[現在]
* 無意識の意識化
* テスト自動化に必要な技術を整理
* 獲得技術の適応性を考慮に入れた、テストシステムとしての最適化・構造化（を始めた）
=> テスト工程の自動化を目指している。
自動化の背景にある概念と文化
* オムロン株式会社 創業者 立石一真氏
** 「機械にできることは機械に任せ、人間はより創造的な分野で活動を楽しむべきである」
** 自動化の「その先にあるもの」を考えてみませんか？
————————————————-
* TABOKには触れられていたような気がします。5.4.1ですね RT へぇ。自動テストスクリプトに対するコーディングルールの話があった。そういうのって、存在するのかい？ #stac2013
————————————————
=====================================
=====================================
《スマートフォンアプリの テスト自動化をはじめよう》
http://nowsprinting.hatenablog.com/entry/2013/12/02/113747
[テスト自動化の現状]
* Unit test – iOS
** モデルのユニットテストは比較的容易
** Xcodeに標準的に組み込んでいるため
* Unit test – Android
** JUnit
** モデルのユニットテストは比較的容易
[システムテスト]
* UI変更頻度
* 画面遷移のトランジションアニメーションなどの重要度が高い
** 一方、自動化しにくい
[ROI]
* テスト実行時案の短縮
* 自動化ツールのせん知恵/習得
* 自動化スクリプトの作成（高度なjudgeを求められる）
* 自動化スクリプトの保守
* 等
[現実的な利益にしぼる]
* テスト実行時間の短縮
* “正しい”画面表示のテスト
* 複数のOSバージョン/機種で実行できる
* OS/機種依存バグを検出できる
[テストの目的]
* 欠陥の抽出
* 対象ソフトウェアの品質レベルが十分であることを確認する
* 意思決定
[欲張らないROI]
* 利益
* 投資
=> 頑張らないスクリプト
* ユニットテストでできるものはユニットテストで。
* レイアウト崩れに関しては、スクリーンショットを黙視で確認
* 機種依存関係は、内容次第で主導で確認
[iOS/Androidの事例]
* iOS
** フレームワークまで手を加えたもの
* Android
** left<=right, top<=bottomでないと描画できない仕様など
** 画面遷移のバリエーション網羅を行わないとわからない不具合
[押さえておきたいポイント]
* すべての画面は網羅する（エラーのAlertViewも含める）
* CIなどの繰り返しを行う場合であれば、Imagemagicなどで自動化
* 実行時間も0ではないので、テストケースの絞り込みは意識する <= 重要
[利益を拡大する]
* テスト実行時間の短縮
=> 時間と集中力を高度なテストに割り振る
=> リリース頻度の向上（4~6週間ごとが理想）
* 複数OSバージョン/機種で実行できる
=> さらにテスト実行環境を増やす。端末の回転、ローケル、タイムゾーン、12h/24h表示など
[手動ではできない]
* ロードテスト
* コンカレンシーテスト
* 再現率の低い問題の確認テスト
[フレームワークの紹介]
ツール選定のポイント
* スクリプトスキル
* iOS/Androidで共有する？
* 「何が実行できるか」はあまり重視しない
—-
genymotion
—-
* 実機時、HTTPで通信する
[Tips]
* Target/Configuration
* Gradle+Androidプラグインでプロダクトオートフレーバー可能
[リモートテストサービス]
* AppKit Box Remote TestKit
[まとめ]
* 頑張らないテストスクリプト
* 欲張らないROI
* スクリプトかけない人の場合、monkeytalkはオススメ。
HTML自体も進んでいる。テストの観点/
資料自体、 http://www.slideshare.net/nowsprinting/ques3-android-testautomation にのっているのと同じ。
————————————
* テストコードは実装コードよりも、さらには、ドキュメントなんかよりも、圧倒的に腐るのが早く感じる。一度回転がとまって、メンテが滞ると、もはや腐ってしまって、触るのが実装以上に嫌になる。そういう経験した人もほかにもいるのかな
————————————
《実践で学ぶATDD》
* TDDとは、SmallTalk界隈の方々から始まった
** 広げてきたのが、KentBeck
* TDDとは？
** Kent
*** 自動テストが失敗した場合だけ、新しいコードを書く。重複を取り除く。
** UncleBob
*** 失敗するテストができるまでプロダクトを書いてはいけない
*** グリーンのコードには、追加でモノを書いていはいけない
=> これから追加していくとリファクタリング
** t_wada
*** 健康を健全に保つためのツール
** kyon_mm
=> 共通: Red-green-refactoring
[XP]
* eXtream Programming
[BDD]
* TDDの間違った概念を修正するための概念だと思う by kyon_mm
** TDDは、ユニットテストのみを対象としているわけではない。が、そうなりがち。
=> 概念として、”外から/振る舞いから見た”に注力するために普及させたもの。
[ScinarioBDD]
* より自然言語らしさを目指した結果
* Cucumber系
[SpecBDD]
* テストコードと自然言語をできるだけ1ファイル内におさめる
* RSpec系
[Scrum]
* Readyの定義、Doneの定義
* Doneの定義を先にテストとして書こう
** Story Test Driven Development
[Specification by Example]
* BDDやATDDをうまく包括するような概念
** Live Document: 例示による仕様としてのテストは活きたドキュメント。それが実現できる/できないが重要。
例として実装される内容
=> Historyを追い、どこから対応を始めたか？ということを確認して欲しい。
[ATDD]
* 仕様を顧客とつめていく
* ハッピーパスのみを合意する内容ではない
** “顧客が届けたいもの”を作成することが大事
[ツール]
* FIT
** FitNess
* Senario
** Cucumber
** SpecFlow
* Spec
** RSpec
*** GevenWhenThen, Context, Describe
*** contextによる、setupのネスト
** Spock
*** Groovyによって実装されたもの
[アンチパターン]
* 開発者がacceptance testを書く
** 時間
*** 開発者が行うにはオーバーヘッドが大きい
** 質
*** 開発者が書いていると、テストレベルを意識しづらい
*** 極端に多い/少ないテストになりがち
* 補助する人がいない
** 言うことはわかるが、それは実装できない、というようなテストシナリオもある。そこらへんは話さないといけない。
[ATDD]
* DDD
* Role
** 開発者が行うATDDは、どこまでいってもSTDDどまり。（Story board）
* テストエンジニアが書くATDDはどうなるのか。
[まとめ]
* ATDD
** 誰にとってのAcceptanceTestであるかを意識しなければいけない
** xDDは、ツールではなく態度によってかわる。
* できる所まで、という線を引き、意識して対応を進める
[質問]
* DDDは、ユビキタス言語を合意する等が大事。
—————–
* TDDにへんな影響を受けた人はテストを書くときに実装のテストを書きがち。そうではなく、Given When ThenというAPI群を作り矯正しよう、誤りづらくならないようにしようとした。 #stac2013
* http://www.storklab.com/seleniumhq.org/docs/06_test_design_considerations.html
—————–
——————-
《モデルベースドテスト》
@kjstylepp
http://itpro.nikkeibp.co.jp/article/COLUMN/20120918/423283/
http://www.slideshare.net/kjstylepp/ss-28784815
– テスト自動化研究会
1.1 テストの作業
* 多くの場合、テスト実行がテスト自動化の対象になっている。
* Test.SSF
「方針」や、「仕様」がかっちり決まっていれば、自動でテストケース作れそうですね？
[モデルとは]
* 特定の観点で抽象化して表現したもの
* 状態遷移/論理/組み合わせ/フロー/代数/統計・・・
[状態遷移図]
[論理モデル]
* 構成要素間の論理関係に着目してシステムの複雑な処理を記述する
[組み合わせ]
* 構成要素のバリエーションと制約を列挙し、構成要素間の組み合わせ元をモデリング
[モデルを使う際の注意点]
* 文法/メタモデルをしっかり決めて記述することが望ましい
* 誰かが適当に書いた絵ではモデルとしての価値が低い
* モデルベースドテストを導入する際は必須
[モデルベースドテスト]
* モデルを活用してテスト成果物を作成する
** ブラックボックス技法に分類される
* モデルから、抽象化されたテストが用意される = 詳細化・開発 => 自動テスト
[テストの抽象表現]
テストも抽象化される
* 事前条件
* 入力値
* 実施する操作
* 期待結果
* テストデータ
[テストの抽象化表現]
* テストのモデリングのための規格
** UML Testing Profile
** Testing and Control Notation Version 3
*** DSLとして、欧州の通信業者が使っているようなものが存在する
[遷移状態]
論理パターンによるテストシナリオ
* デシジョンテーブル
[モデルベースドテストの注意点]
* 一般的に、従来よりもテストパターンが多く出る
** 網羅型の技法に沿うため
* 詳細化が必要
[適用プロセス]
* モデルの種類の決定
* モデルの記述
[例]
* astah の有償版
* 遷移図
[デシジョンテーブル]
* SEGTest
** http://softest.cocolog-nifty.com/blog/cegtest.html
*** デシジョンテーブルは、エンジニアリング力という観点でも重要
* All-pair法
* PICTMaster
※テストツール丸わかりガイド
モデリングの能力に依存する。
キーワード駆動テストとの融合
——————-
* UTPのテストアーキテクチャはテストシステムのアーキテクチャで、Test.SSFやテスト設計コンテストのテストアーキテクチャはテストスイートのアーキテクチャですね。混同しやすいですが、違います。
* ちなみにテストモデルの名付け方も2系統ある。状態モデルは、そのモデルで狙っているテスト観点を名前にした系統。論理モデルは、テストケースの構成要素の挙げ方/組み合わせ方の種類を名前にした系統。だから制御フローモデルのように、両系統を併記する方が分かりやすい。
——————-
——————-
《Lightning Automated Testing Demo (各15分)》
《手動テストからの移行大作戦》
* 最初は身の丈にあった自動化をすれば良いのでは？
* スクリプトを読まないとテスト内容がわからない
=>可読性
=> 作った人しかメンテナンスできない
* 自動化の前にすべきこと
《激しいUI変更との戦い》
* GUIベースの自動テストを保守すること
* 人が見てわかるテストケース + 変換ルール =自動変換=> テストケース
* ID指定などにより、変更に対応できる開発を行うことを心がけるようにする。
——–
* 今日のSTACでとてもよいのは、自動化さえすれば完全にハッピー、みたいな話はゼロで、テスト設計やプロセス、開発とのチームワーク、態度など色々全部大事だよ、というメッセージがちゃんと含まれているところ。自動化ハイなんて用語も生まれたしwww #stac2013
——–
《有償ツールの選択ポイント》
HPの製品紹介
———
* Excel で自動テストを駆動することの利点は一つあって、「データに型(数値/文字列/日付…)を持たせられる」こと。これがテキストベースだとツール内のどこかでメタデータとのマッチングが必要になるし、そのメタデータのメンテナンスコストが問題になります。 #stac2013
———
《組み込みクロス開発での継続的な実機テストの実行》
http://www.slideshare.net/goyoki/ss-28809804
———————
《テスト自動化のこれまでとこれから》
* http://www.slideshare.net/Bugler/2013-28786846
———————
以降、懇親会へ・・・
~ my tech diary ~ 