D.Horiyama's output

JSTQB ch6 テスト支援ツール(2/2)

JSTQBテスト技術者

出典: 

6.2 ツールの効果的な使い方

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

組織向けにツールを選択する際の基本原則

組織の成熟度、長所と短所を評価する

評価モデルはいろいろある

組織の成熟度評価モデル

  • CMMI: Capability Maturity Model Integration

テストに特化した成熟度評価モデル

組織の状況を把握することで、ツール導入を推進するスタート地点が明確になる

ツールを活用するためにテストプロセスを改善する機会を識別する

組織やプロセスが程度成熟し、プロセスエリアのゴールを達成するためにプロセスが存在していて、それをツールで自動化するという順番

なにもない状態でツールだけ導入しても作業が増えるだけですぐには効果が出ない

テスト対象で使用する技術を理解して、その技術と互換性のあるツールを選択する

組織内ですでに使用しているビルドツールや継続的インテグレーションツールとの互換性と統合の可否を明らかにする

明確な要件と客観的な基準を背景にツールを評価する

コストを払うからには、さもないとツールを導入した結果が良いのか良くないのか判断できないといけない

  • ツールを導入する目的(要件)が明確であること
  • 合目的性(要件を満たしていること)の客観的な判断基準が握れていること

無料試行期間があるかどうかを確認する

要件を満たしているかどうかの判断

ツールベンダー、もしくは無料ツールのサポートを評価する

組織が自立してツールを使うことができるようなサポートが望ましい

ツールを使用するためのコーチングおよびメンタリングに関する組織内での要件を識別する

組織の成熟度や長所、短所 = スタート地点がわかる

-> ツール導入にあたりどこまでのサポートが必要かの要件がわかる

  • ツールの使い方だけでよいのか
  • 概念の説明から始めないといけないのか

ツールの直接関わる担当者のテストスキルを考慮して、トレーニングの必要性を評価する

さまざまなライセンスモデルの長所と短所を考慮する

  • 無償で全部自分でなんとかするか
  • 有償でサポートを受けるか

具体的なビジネスケースに基づいて、費用対効果を見積もる

PoCやパイロットプロジェクトで評価する

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

PoC: Proof of Concept でツール導入の費用対効果を評価し、導入が決まりました！

-> まずは小規模のパイロットプロジェクトで始めましよう

  • うまく適用できなくても傷が浅い

「本命のプロジェクトではうまく適用できない」というリスクを減らすために、下記のような多角的な視点で評価する:

ツールに関する知識を深め、強みと弱みを理解する

使ってみないとわからないことはある

  • 機能
  • 使い勝手
  • 導入コスト

現状のプロセスや実践しているやり方にツールをどのように適用するかを評価する。そして何を変更する必要があるかを特定する

例:

  • ウォーターフォール型開発だが、コンポーネントテストだけTDDに変更する
  • テスト自動化につき、リグレッションテストの位置づけや実施タイミングを変更する

ツールやテスト資産の標準的な使用方法、管理方法、格納方法、メンテナンス方法を決める

  • 規約を決める
  • 構成管理を導入する

等

期待する効果が妥当なコストで実現可能かを見極める

ツールによって収集およびレポートをさせたいメトリクスを理解し、メトリクスを確実に記録しレポートするようにツールを設定する

例: テストレベル別欠陥検出数を集計・分析したい -> 欠陥情報にテストレベル情報を含める

6.2.3 ツール導入の成功要因

導入当初はむしろコストが増えがち

ツールの効果を持続していくために:

ツール未使用の部署にツールを順々に展開する

  • 導入支援
  • ナレッジの共有

ツールが適用できるよう、プロセスを調整、改善する

プロセスの変更にあたり下記のような人々の理解や協力が必要

  • リーダー
  • マネージャー
  • ステークホルダー

ツールのユーザーに対し、トレーニング、コーチング、メンタリングを行う

利用ガイドを定める

公式マニュアルは情報が多すぎたり分かりづらかったりしがち

組織用のものを独自に作るとよい

ツールを実際に使用する中で得られる情報の集約方法を実装する

ツールの利用状況や効果をモニタリングする

効果が出ていなければ原因を分析し、対策を打つことが重要

  • ツール
  • プロセス
  • 人

ツールのユーザーサポートを提供する

すべてのユーザーから、得られた教訓を集める

うまくいった人のノウハウはもちろん、うまくいかなかった人のアンチパターンも集める

運用やサードパーティも巻き込む

例: 欠陥マネジメントツールが共通だと利用効果が高い