はじめに : JSTQB FLの学習内容・解釈・気づきを共有

JSTQB Foundation Level(シラバスVersion2018J03)について学習した内容と自分の解釈・気づきをまとめてブログで公開しています。JSTQB FLをシラバスや教科書で学習されている方は、不明点があるときに、本ブログの内容と照らし合わせて頂いて、理解の助けになればいいなと考えています。
(※このブログを全部を読むというよりは、学習中に分からないことがあったときに、覗いていただくという使い方が良いと思います。)

今回の内容 : 第6章.テスト支援ツール

目次

テストツールの考慮事項

テストツールの分類
 テスト自動化の利点とリスク
 テスト実行ツールとテストマネジメントツールの特別な考慮事項

ツールの効果的な使い方

ツールを選択する際の基本原則
 ツールを組織に導入するためのパイロットプロジェクト
 ツール導入の成功要因

テストツールの考慮事項

テストツールの分類

テストツールを使用する目的は、テストマネジメントやテスト実行などに適応することで効果や恩恵を受けることである。その際に、テストツールの目的やターゲットとなるテストの作業を理解したうえで、テストツールを選定する必要がある。

テストツールを使用する目的

テスト活動の効率化
- テスト実行(反復作業)の自動化
- テスト実績集計や欠陥情報の記録・分析作業の効率化
テスト活動の品質向上
- テスト活動の一貫性向上
- 欠陥の再現性向上
手動では実現不可な活動の実現
- ツールにより人では実行できないテストの自動化
テストの信頼性向上
- 脱人手によりテストの精度向上
- 大量データによるテストを効率よく実現

ツールで支援したいテストの作業

テストのマネジメント
- テスト要件マネジメント
- テスト実績・欠陥のマネジメント
- プロジェクトリスクの把握
- 要件とテストウェアのトレーサビリティ確保
- テストウェアの構成管理
- 欠陥のマネジメントとトラッキング
- 継続的インテグレーション
静的テスト
- レビュー(レビュー記録、共有、オンライン)
- 静的解析 (プログラム中の問題を検出)
テスト設計とテスト実装
- テストデータ生成
- テストケース作成 (保守性と生産性、網羅性)
- TDD、ATDD、BDDのためのテストコード作成
テスト実行と結果記録
- リグレッションテスト
- 要件に対するカバレッジの評価
- コードカバレッジの評価
- スタブやドライバの準備
性能計測と動的解析
- 処理能力の計測
- 使用しているライブラリがシステムリソースを使っていないかの確認
- メモリの割り当てや解放、並列処理に問題がないかの確認

テスト支援ツールの種類

テストとテストウェアのマネジメントの支援ツール
- テストマネジメントツールとアプリケーションライフサイクルマネジメントツール
- 要件マネジメントツール
- 欠陥マネジメントツール
- 構成管理ツール
- 継続的インテグレーションツール
静的テストの支援ツール
- レビューツール
- 静的解析ツール
テスト設計とテスト実装の支援ツール
- テスト設計ツール
- モデルベースドテストツール
- テストデータ準備ツール
- テスト駆動開発ツール
- 受け入れテスト駆動開発ツールやふるまい駆動開発ツール
テスト実行と結果記録の支援ツール
性能計測と動的解析の支援ツール
- 性能テストツール
- モニタリングツール
- 動的解析ツール
特定のテストに対する支援ツール
- データ品質の評価
- データのコンバージョンとマイグレーション
- 仕様性テスト
- アクセシビリティテスト
- ローカライゼーションテスト
- セキュリティテスト
- 移植性テスト

目次へ戻る

テスト自動化の利点とリスク

テストを自動化することで得られる効果・利点がある。一方で、自動化することにおける潜在的なリスクがあることを注意しておく必要がある。

利点

手動作業の削減と時間の節約
- 手動作業(テスト実行やテストレポートの作成など)で発生していた時間の削減
- 静的解析ツールによるソースコード中の問題の検出により、レビュー時間の削減
一貫性や再実行性の向上
- 同じ頻度で同じ順序のテスト実行が可能となる
評価の客観性が向上
- ツールによる定量的なデータ計測が可能となり客観的な評価ができる
テストに関する情報へのアクセスの容易性が向上
- テスト進捗の統計やグラフ描画、欠陥率や性能計測結果の集計が容易になる

ツールを使う潜在的なリスク

ツールへの過大な期待
- 削減時間やコストの過大評価
- ツールの使いやすさへの過大な期待
- ツールですべて賄おうとする(部分的に考えると従来方法のほうが良い場合もある)
ツールの初期コスト(時間、コスト、工数)の過小評価
ツールの運用コストの(時間、コスト、工数)の過小評価
- ツール自体の運用
- ツールに関わるテスト資産のメンテナンス
ツールを適切運用しない
- ツール内にあるテスト資産の構成管理を怠る
ツールベンダに潜むリスクの想定漏れ
- ビジネスを廃業、ツール販売の撤退
- ツールのサポート、アップグレード、欠陥修正への対応の良し悪し
ツール自体に潜むリスクの想定漏れ
- ツール自体が停止するリスク
- プラットフォームへの不適合
組織内でツールへの当事者意識が不明確
- ツール自体の更新作業が滞る
- 適切な知識、スキルを持った担当者の設置がなされない

目次へ戻る

テスト実行ツールとテストマネジメントツールの特別な考慮事項

テスト実行ツールの考慮事項

スクリプト作成に関して
- テストスクリプトやテストデータの作成のコストが大きくなる可能性がある
- テストケースやテストデータのメンテナンスコストや構成管理が必要となる
  - 対策
    - データ駆動方式
      - テストデータとテストスクリプトを切り分ける
    - テストデータはスプレッドシートで準備し、テストスクリプトは汎用化する
    - キーワード駆動方式
      - テストスクリプトをキーワード化し関連図けておくことで、キーワードによるテストスクリプトの作成を可能にする
    - モデルベースドテストツールによる、テストケースの生成

テストマネジメントツールの考慮事項

テストウェアやテストレポートのフォーマットに関して
- 組織の独自フォーマットがある場合に、ツールに適合させる必要がある
  - 対策
    - ツールのカスタマイズ
    - 他ツールなどとの連携

目次へ戻る

ツールの効果的な使い方

ツールを選択する際の基本原則

ツール選定時は、下記の原則に沿って機能検証を行う。そして、テスト対象に使用できるのか、使用して効果が出るのかを立証する。(「コンセプトの証明 PoC (Proof of concept)」)

組織の成熟度、長所と短所を評価する
- 評価モデルの例：CMMI、TPI NEXT、TMMi
ツールを活用するためにテストプロセスを改善する機会を識別する
- ツールで支援しようと思っていた作業をそもそも実施していなければ、逆に作業が増えてしまう。本来やるべきことを見直し、テストプロセスを改善する必要がある
テスト対象で使用する技術と互換性のあるツールを選択する
- 例えば、組み込み系なのか、汎用OS系なのかにより、適切なツールは変わる
組織内で既に使用しているビルドツールやCIツールとの互換性と統合の可否を明らかにする
- ツール間のデータの互換性があるのか、また必要におじてツール間でデータをやり取りするインターフェースを準備する
明確な要件と客観的な基準を背景にツール評価を行う
- ツールを導入することで「なにをどうしたいのか」といった目的とそれを達成できたかの評価方法を明確にしておく。(改善効果を客観的に評価するため)
無料試行期間があるかを確認する
ツールベンダーのサポートを評価する
- ツールを運用していく中で、ツールベンダーのサポートは必須となる。
- ツールの研修・トレーニングの有無
- スケールメリット
- レスポンス
- 欠陥修正の対応
- など
組織内でツールを使用するためのコーチングおよびメンタリングに関する要件を識別する
- 組織内でツールを導入する際に、どこまでサポートが必要なのかを明らかにしておく必要がある
ツールに直接携わる担当者のテストスキルの評価とトレーニング
ライセンスモデルの長所と短所を比較する
ビジネスケースに基づいて費用対効果を見積もる
- 費用
  - ツールを適用できる範囲の制約
  - 準備作業
  - メンテナンス作業
- 効果
  - 効率化
  - 品質向上

目次へ戻る

ツールを組織に導入するためのパイロットプロジェクト

ツール選定完了後、まずは小規模パイロットプロジェクトで試行を行うとよい。

パイロットプロジェクトで重点的に確認すること

ツールに関する強み・弱みを理解
- カタログに載っていない機能や使い勝手
- ツール運用開始までにかかるコスト
現状のプロセスや実践しているやり方にツールをどのように適用するかを評価する。そして何を変更する必要があるのかを特定する
- プロセスを変更する必要があるのか、あるいは変更する必要があるのか
- 作業の追加がないか
ツールやテスト資産の標準的な使用方法、管理方法、格納方法、メンテナンス方法を決める
- ツールから出力されるファイルの管理方法を決める
- 命名方法や管理場所
期待する効果が妥当なコストで実現可能かどうかを見極める
- 初期コスト、保守費用、発生する作業、学習コストの検討
ツールによって収集・レポートさせたいメトリクスを理解し、メトリクスを確実に記録しレポートするようにツールを設定する
- 開発プロジェクトで収集したいメトリクスを検討し、ツールで実際に収集するための設定をする

目次へ戻る

ツール導入の成功要因

ツールを導入し、効果を持続的に得るために必要な取り組みについて

ツール未使用の部署にツールを順々に展開する
- 組織内でテストの実施方法が統一される
- ノウハウの蓄積ができるようになる
ツールが適用できるよう、プロセスを調整、改善する
- プロセスを優先するかツールを優先するかを十分に検討し、総合的に効果的な改善を行う
ツールのユーザーに対してトレーニング、コーチング、メンタリングを行う
- 新規ユーザーへのトレーニング
- ベンダトレーニングのアサイン
- 組織内でトレーニング用資料を整備
利用ガイドを定める
- 組織内でガイドを作成 (マニュアルでは複雑すぎるため、自社用にテーラリングが必要)
- 組織内のプロセスとの関連や実際に使用しているツールとの関連などもガイドに示すとよい
ツールを実際に使用する中で得られる情報の集約方法を実装する
- 社内ユーザーのノウハウを蓄積する仕組みを作る
- ツールの展開や改善につなげる
ツールの利用状況や効果をモニタリングする
- ツールが利用されているか、効果が得られているかを継続的に確認する
- 効果が出ていなければ、原因を分析し、対策を打つ
  - 要因分析としては、ツール・プロセス・人の観点でとらえるとよい
ツールのユーザーサポートを提供する
- 組織としてのツール導入戦略を計画する
- 例えば、組織で複数ライセンスを一括契約することで値引きができないか検討するなど
すべてのユーザーから得られた教訓を集める
- ノウハウの共有
- 効果が出ない誤った使い方や効果が出にくいテストの特性などを共有し、失敗を繰り返さない

目次へ戻る

目次へ戻る

以上　第6章.テスト支援ツール

参考になれば幸いです。