6.2 ツールの効果的な使い方：利点とリスク
6.2.1 ツールでテストを支援する利点とリスク（全ツール）
期待できるメリット
反復作業が減る
テスト実行ツール
一貫性や再実効性が増加する
客観的な評価が可能になる
静的解析ツール、カバレッジ計測ツール
テストやテストケースの情報へのアクセスが容易になる
テスト進捗の統計、インシデント率や性能計測結果算出が容易
テストマネジメントツール
ツールを使用することで発生するリスク
テストツールの効果を過大に期待する
テストツールを初めて導入する場合に要する時間、コスト、工数を過小評価する
教育などが必要
大きな効果を継続的に上げるために必要な時間や工数を過小評価する
テストプロセスの変更などが必要
ツールが生成するテスト資産を保守するために必要な工数を過小評価する
ツールに過剰に依存する
手動テストが適しているのに自動テストをする
ツール内にあるテスト資産のバージョン管理を怠る
複数のツールの運用が適切になされない
重要なツール間での関係性と相互運用性の問題が無視されることが
ツールベンダーに潜むリスクを想定しない
ツールベンダーが廃業、撤退、別会社に売却するケース
サポートがされないなど…
ツール自体に潜むリスクを想定しない
オープンソースの場合はプロジェクト停止など
6.2.2 個別ツールの使用上の注意
テスト実行ツール
自動実行のための準備に想定以上のコストが必要になることも
コードの自動生成もあるが、多くの場合そのままスクリプトをテストに使わない
スクリプト作成を効果的にするアプローチ
データ駆動方式
テストデータをスプレッドシートで管理
スクリプトがスプレッドシートからテストデータを呼び出す
テストスクリプトを汎用化できる
キーワード駆動方式
テストデータに加えてキーワード（アクションワード）をスプレッドシートで管理する
言語知識がなくても、キーワードを使用してテストが作成可能
こんな感じの羅列を書く
「対象」「ID」を「アクションワード」「SET」
「対象」「ボタン」を「アクションワード」「CLICK」
RobotFrameworkみたいなことができる？？
メンテナンスコストはかかります
期待結果も格納しておくことが必要です
静的解析ツール
作成ずみのコードに適応すると大量の警告が出ることも
あらかじめ警告に優先順位をつけて、高いものから直していく
警告内容を都度対応し、コンポーネントテスト開始前の実装完了条件にするのも有効
テストマネジメントツール
汎用的なインターフェースを提供している場合や、レポート出力ができるものがある
独自フォーマットのドキュメントの組織の場合
ツールのカスタマイズが必要になることも