システムテスト自動化カンファレンス2013(2)
1ヶ月のブランクがありますが、
システムテスト自動化カンファレンス2013(1)の続きです。
前回は、3つのポイント「スコープ」「ROI」「プロセス」のうち、「スコープ」まででしたので、今回は残りの「ROI」「プロセス」とその他トピックスから私が解釈したことをまとめてみます。
よりよいテスト自動化のためにちょっと考えてみませんか? ―スコープ、ROI、プロセスを中心に―
3つのポイント
ROI
- ROIの評価
- プロジェクトやプロダクトの利益につながらなくてはならない
- 品質向上
- リスク軽減
- コスト削減
- 納期短縮
- プロジェクトやプロダクトの利益につながらなくてはならない
私の開発ドメインでは、上記4点について議論が無いばかりでなく、経営層からは「(手動テストから自動テストに置き換えた)自動化率」の面でしか評価されていませんでした。当時の私は、「手動テストを自動テストに置き換えるのが良いと判断しているのは何故なのか?」と疑問に思いました。
このままでは不味いと思いますので来年度以降、経営層や業務依頼元にテスト自動化について上記4点を押さえた上で、テスト工数や予算確保のため、下記をベースに説明することを考えています。
- 品質向上:「テスト実行の質」「性能テストの測定精度の改善」「テスト結果報告の質」
- リスク軽減:スモークテストによる基本機能のバグ検出感度の改善
- コスト削減:スモークテストや性能テストの継続的実行によるランニングコストの低減、
- 納期短縮:夜間のロングランテストの継続的実行によるテスト稼働率の改善
- 自動化によるテストの品質
- 再現性やトレーサビリティの向上
- 自動化準備を通じた理解度向上の影響
- 再現性やトレーサビリティの向上
時々ですが、不具合を発見したものの、不具合が再現できない事が発生しています。
テスト実行手順や条件を明確にしていないことが原因の1つですので、
ロジックを押さえた思考の訓練として1つのきっかけになると思います。
- 自動化によるテストのコスト
- 人件費を人間しかできないことに
- 同じ作業の繰り返しによるコスト減
「刺身タンポポ」で例えられるルーチンワークを手動で繰り返すのは時間効率の面から非効率とおもいますので、定型作業に該当する部分は自動化を進めるべきです。
私は、直近1~2年前からテストリーダとしての業務を担当していますが、出社してからパソコンの電源を入れた後、テスト結果報告用のファイルを開いたり、社内システムやBTS(Bug Tracking System)にアクセスすることが日常茶飯事なので、UWSCを利用して作業の自動化を試験的に実施しています。まずは、定型業務の半自動化で進め、思考を要求される業務に集中できるように進めようと思います。
- 自動化によるテストの時間(効率)
- 夜間に実行して機材使用率の改善
私の開発ドメインの品質特性で必須事項の1つとして「連続稼働」があります。
連続稼働を夜9時から翌朝9時とすると、我々が寝ている間に12時間分テスト実施したことになりますので、1人日強相当のテストを実施したことになります。
- 属人性の低下
通信機能の伝送遅延時間を計測することがありますが、以前はオシロスコープなどのアナライザで1条件毎に測定していました。現在は、電気信号を取り出し電気入力されたら、あるシステム上で自動的に伝送遅延時間を測定できるようにしています。
- 知識伝承の効率化
自動化で考えたことをスクリプトの形で記録し、第3者が記録物を見ることで考えの足跡を辿ることができるので、培った知識をベースに改善した考えることができると解釈しました。設計技法や設計ドキュメントなど、考えの足跡と自分の知見を化学変化させること、知識移転を進める必要があると思います。
- 自動化によるテストのスコープ
- 手動ではできない/困難なテスト
脳を使って判断することや反応することは、自動化が困難ではないかと思います。例えば、アプリケーション使用時の快適さやヒトのミスがあります。
- 投資
- 時間
- 手動の場合と違って、初期コストと運用コストは違う
- 時間
初期コストは、テスト自動化のための土台(インフラ)が必要になります。例えば、自動化用パソコンやサーバー、自動化スクリプトの実装でかかるコストが挙げられると思います。
運用コストは、仕様変更時の自動スクリプトの変更や技術の進化による自動化システムの更新など、変化に対応するためのコストがあると思います。
- ツール
- 外部調達か内製かで違いが生まれる
ツールの選定は、特定非営利活動法人(NPO法人)ソフトウェアテスト技術振興協会(ASTER:Association of Software Test EngineeRing)のテストツールWGの成果物である「テストツールまるわかりガイド(入門編)」を参考するとよいでしょう。
- テストプロセス、人、プロダクト
- 自動化によりプロセスや必要な人材が変わってくる
- 自動化によって発生するコスト
開発マネージャからテスト自動化の依頼を受けますが、片手間で実施することが多く、思うように進まないことがあります。また、テスト自動化システムが数年で使い物にならないことが多々あります。そのような現状を打破するため、テスト自動化部隊を創設するべきでないかと開発マネージャに提言していますが、予算の壁があり実現に至っていません。開発部隊&テスト部隊の体制について、議論する必要があると痛感しています。
- 注意
- 目的に合った利益と投資で計算する。
- 時間やコストで計算するときは、さらに見積が必要。
- 厳密に評価するとそれなりにコストがかかるので、濃淡をつけて評価するとよい。また、評価するときのコストも考える。
テスト自動化に関するメトリクスを検討する必要があるようです。まずは、GQM法から何のメトリクスからROIを評価するか、議論してみようと思います。
プロセス
- テスト実行の自動化
- プロダクトを自動化
- 実行やレポートを自動化
- 負荷が変わる
- タイミングが変わる
- テスト以外や組織への影響、現在のプロセスに影響がある
- 自動化前からテストプロセスが機能していなかったら、その整備から始めること
- ツールのバージョンアップやプロダクト規模の見直しを適宜実施
- 自動化によって変える部分
- 自動化に適したプロセスの整備
- 「よい」テストを自動化する
これからのロードマップとして、上記の要素も検討する必要があるようですので、適宜ふりかえりながら自分たちのためのプロセスを構築しようと思います。
その他トピックス
- スキル、チーム
- ISO/IEC/IEEE 29119 Software Testing Standard
最近、話題になっていますが、原典を入手して、自組織でどのように進めるのか議論してみようと思います。
特に、下記のPart2:Test Processesをベースにするとよさそうです。
http://softwaretestingstandard.org/part2.php
- テストスキル標準:Test.SSF
特定非営利活動法人(NPO法人)ソフトウェアテスト技術振興協会(ASTER:Association of Software Test EngineeRing)のテストスキル標準:Test.SSFや一般社団法人 IT検証産業協会(IVIA)のテスト技術スキルFWを参照して、自組織で議論してみようと思います。
- 自動化したテスト実行のバグ分析
- テスト自動化してもトラブルにあたることがある。
- 分かりやすい自動化の設計
- ログの取り方
特に、「分かりやすい自動化の設計」については、これからの議論になるのではと思います。
- プロジェクトやプロダクトの見える化を促進
- バグ
- リリース判定
ステークホルダに有用な情報を提供するために、自組織でも議論すべきと思います。
次回は、『事例から見るテスト自動化のポイント』について書く予定です。