6.3 組織へのツール導入
6.3.1 組織にツールを導入するための原則
ツールを活用するためのテストプロセス改善の機会や組織の成熟度、長所と短所を評価する CMMI = 組織の成熟度を評価するモデル
https://gyazo.com/f8d58b021817d7dd2285d64a8de22ad3
各レベルのゴールにいる組織が、各ツールを使いこなせている状態
既存のテストプロセスにツールを適応するとき
ツールでやろうとしていた作業が手動でもされていなかった可能性
工数が削減されず作業が増えるかも
ツールがあればいいってものではない
ゴールを満たすためのプロセスが組織にないといけない
ツール導入に伴ってプロセス改善がされないといけない
ツールは手段の一つです
（ツールに対する）明確な要件や客観的な基準を背景に評価する
組織としての要件を明確にする
要件を満たしたか客観的な基準を持っている必要がある
もっとわかりやすく言うと「機能検証」
ツールがテスト対象に使用できるのかどうか
使用して効果が出るか
効果が出るように環境を変える必要があるか
ツールベンダー、もしくはサービスサポート提供者の評価
ベンダーのサポート体制などの評価
大きく依存するようであれば、ノウハウ共有化が進まないのでオススメしない
非商用ツールの場合、サービスサポート提供者を評価
オープンソースならコミュニティの活性状況とか
教育や訓練に対する組織内の必要事項の特定
組織の成熟度・長所・短所が明確になる
ツール導入にあたり、どこまでサポートが必要か判断できる
ツールの使い方だけでいいか、概念からの教育が必要か
ツールを習得するためのトレーニングが必要
テスト自動化に関する成熟度、担当者のスキルレベルを把握した上でトレーニングコストを確保する 費用対効果の見積もり
ツール導入すると
テスト作業を効率化し、作業時間を短縮させ、コストを削減させる目的
効果が出ないことも……
様々な準備作業が必要
適応できる対象が限られる
繰り返し行わなくても良い
メンテナンス作業が多くなる
かかる費用と得られる効果を十分に見積もる必要がある
6.3.2 パイロットプロジェクトの目的
「うまく適応できるか」の検証
小規模のパイロットプロジェクトで検証するのが良い
ツール詳細の学習
使ってみないと機能や使い勝手はわからない
パイロットプロジェクトのメンバーが本番ではツールの推進役になる
「思ったような効果が出ない」問題も早めに知ることができる
プロセスや作業手順への適合または変更
プロセスを変更することなくツールを導入できるか、あるいは変更できるか
ツールやテストの関連物の使用、管理、格納、保守方法の決定
やっておくといいことの例
ファイルやテストケース命名方法の決定
役割などが推測できる
ライブラリ作成
期待する効果が妥当なコストで実現可能かどうかの見極め
期待効果がそれまでより低コストで実現できるか
6.3.3 組織内でツール展開を成功させるためには
ツール未使用の部署へのツールの展開
使っていないところでも効果が望めるなら導入を検討する必要がある
同じツールを使えば実施方法が統一化され、ノウハウが蓄積されていく
ツールに合わせたプロセスの適応、改善
ツールに合わせて柔軟に対応する必要がある
慣れたプロセスを変更するリスク
プロセス優先か、ツール優先か十分な判断を
新規ユーザに対するトレーニング、指導、助言
継続して利用するためには組織内にトレーニング用の資料があるべき
利用ガイドの作成
組織内での利用に特化したガイドがあると効率的
ツール活用ノウハウを集める方法の実装
情報共有の仕組み、ルールを作っておく
ツールの利用状況や効果のモニタリング
メリットはあるが、導入支援やプロセス改善をしないと常にリスクがつきまとう
効果が出ているかチェックし、出ていなければ原因を見つけ、対策を打つ
テストチームへの支援の提供
組織としてもテストチームをバックアップする必要がある
購入費用とか……
教訓の収集
ノウハウの共有はもちろんですが……
逆に効果が出なかったこと、効果が出にくいテスト特性
アンチパターン
しくじり先生！！