システムテスト自動化カンファレンス2014(4)「状態遷移テストにおけるテスト設計と実行の自動化」
2014/12/14(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2014で聴講したセッションから数回に分け、まとめたものを紹介しています。
セッション(再掲)
1.オープニング：1時間で分かるSTA /鈴木 一裕 →<資料>
2.テスト自動化のパターンと実践 /.reviewrc →<資料1>/<資料2>/<資料3>
3.GUI自動テストの保守性を高めるには /伊藤 望 →<資料>
4.状態遷移テストにおけるテスト設計と実行の自動化 /きょん →<資料>
5.ビルドプロセスとCI /長谷川 孝二 →<資料>
6.社内スマホアプリのビルド配信ツールによる自動化事例 /赤根 稔朗(Yahoo! JAPAN)
7.Test Automation Patterns 2014 冬コレ！/松木 晋祐 →<資料>
前回は「3.GUI自動テストの保守性を高めるには」でしたが、今回は「4.状態遷移テストにおけるテスト設計と実行の自動化」について紹介します。
4.状態遷移テストにおけるテスト設計と実行の自動化 /きょん
[1]『システムテスト自動化 標準ガイド』(通称：ギア本)の15章を執筆
当初は45ページ分執筆したが、書籍時は18ページに削減された。書籍に掲載されなかった27ページ分を発表する。
→発表資料を15章の前のページに挟み込み、事前に発表資料を読んだ後に15章を読むと内容がより理解できると思います。
[2]デプロイメントパイプライン
(a)ボトルネック
(1)効果のあるテストをやらないと意味がない
(2)まずは現状を把握しよう。
＜ValueStreamMap＞
・リーン開発の本質(P102)：「顧客ではじまり顧客で終わる」
・価値のある時間と無駄に見える時間で見てみる
(3)無駄な時間
承認プロセスが長いなら、その承認プロセスに対し対策を行う。
(4)価値ある時間
テストの時間が減ること。
(b)自動化した結果を繋げる。
(c)継続的デリバリ
S/Wをバージョン管理からユーザに渡るまでを自動化
(d)テスト戦略の一部を具象化したもの
(e)テスト自動化のROIを高めるために重要
(f)ステージを分割
テストレベル/アジャイルの4象限/チーム単位など何でもよいので、ある基準で分割する。
[3]テスト戦略
(a)テスト計画⊃テスト戦略
＜ソフトウェアテスト293の鉄則＞
鉄則278：「テスト計画は、戦略、段取り、成果物の三位一体と心得よ」
(b)ポリシー
体系的ソフトウェアテスト入門によると、リスク/アプリテスト環境/レビュー戦略/テスト目的などが挙げられる。
[4]自動化の戦略
(a)何を自動化するか？
例：デプロイをテスト
(b)テスト環境
・自動化用に準備する。
・手動テスト環境と共用しない
(c)テスト目的
欠陥の予防など
[5]デプロイメントパイプラインの実例
(a)コンテキスト
・システムの状態遷移が大きい
自動テストが半日かかる
・自分の修正したところ以外は把握できない
(b)スモークテスト
デプロイステージ→受入ステージ→コンプリヘンシブステージ/キャパシティステージ/UAT(ユーザ受入テスト)ステージ/本番ステージ
という流れ。
(c)コンプリヘンシブステージ
・網羅的なテスト
横優先探索木のアルゴリズム
(c)キャパシティステージ
性能テスト
(d)UAT(ユーザ受入テスト)ステージ
UATの過程で、.netのhttpクライアントで17000回連続要求で30秒応答ないバグを見つけた。
(e)本番ステージ
エンドユーザ環境でのスモークテスト
所感
Value Stream Mapを初めて聞いたが、後日検索サイトで調べたところ、トヨタ生産方式の手法の1つである「物と情報の流れ図」ということが分かりガッテンした。また、テスト自動化を進める際、開発工程をメンバーで共有できる形にしてから「何がボトルネックか？」「ボトルネックを解消するためにはどのような方法があるか？」を議論してから、自動化を進めることが大切と思いました。
