ツール依存では高品質なテストプロセス望めない

◆ 少ないテストケースで多くのバグを見つけるには

マーキュリー・インタラクティブ・ジャパン 技術部　ディレクター 小�ｱ 將弘 氏

　ソフトウェアテストの識者は「テストプロセス全体の中で優先度を付け、どこを効率化すべきかを洗い出さなければツールの価値は半減する」と口をそろえる。負荷テストツール「LoadRunner」などを提供するマーキュリー・インタラクティブ・ジャパン 小�ｱ將弘氏もその1人だ。

　小�ｱ氏のスタンスは「ソフトウェアテストも、通常の開発プロジェクトと同様に1つのプロジェクトとして捉え、設計・計画・実施・分析を繰り返す必要がある」というもの。特にテスト計画は実施するテストの種類を洗い出し、判断基準や優先度を決める大切なプロセスだ。「ここで設定した優先度に従い、短期間でいかに多くのバグを見つけるかが、高品質なソフトウェアを実現するキーになる」（小�ｱ氏）という。

　そこで求められるのが、テスト作業だけでなく、テストプロセス全体を効率化する仕組み作りだ。「具体的には、テスト作業の効率化と、プロセス全体を可視化するインフラの整備が重要であり、こうしてテストプロセスそのものが向上してこそ、高品質のソフトウェアが開発できる」（小�ｱ氏）という。

◆ どのようにテスト計画を作成するか

　小�ｱ氏は、テスト計画と開発プロセスの関係について次のように説明する。「開発工程の中では、要件定義の終了後、システム全体の設計に入る。この過程でテストに対する要件を明確にし、実施すべきテストの種類を選択できる。もともと開発工程とテストは一対となっており、例えばプログラミングであれば単体テストの仕様、内部設計であれば統合テストの仕様と、開発の内容をテストの仕様に落としていくことはそれほど難しくない。開発工程の中で、対となるフェイズに合わせてテストを実施していけば、各フェイズを経るうちに対象となるソフトウェアの品質も次第に高まっていくはず」（小�ｱ氏）。

　テスト計画の手段はいくつかある。例えば、優先度の高いものから順にテストケースを作ったり、ビジネスの要因からテスト実施の優先度を決めるといった具合だ。同時に、テストレベルの粒度を決めたり、判断基準をどこに置くかも事前に決定する必要がある。こうしてテスト全体の形が整ってきたら、どこを効率化し、どの分野のカバレッジを広げればいいかが見えるはずだ。その分野こそ、ツールを活用すべきエリアになる。

　ただし、「ここで考えなければならないのは、テスト効率化の手段は複数あるということ。過去に使ったテスト資産を再利用したり、自動化と手動を組み合わせた計画を練り直すことで、テスト作業は効率化できる。その上で、自動化したい分野にツールを当てはめることが重要」（小�ｱ氏）という指摘も。いずれにせよ、開発工程における設計をレビューし、テスト側でも詳細な計画を立て、開発と並行してテストを進めるのが基本スタンスだ。

◆ 自動化ツール適用には入念な準備を

　自動化ツールは、テスト仕様書からスクリプトを作り、テストデータを投入して作業全体を自動化するのが大きな役割だ。現行のテスト仕様書がそのまま自動化スクリプトに落ちれば一気通貫で作業を自動化できるが、現実にはそう簡単に変換できない。というのは、テスト設計段階のテスト仕様書は概要になり過ぎ、逆にテスターが作成したテスト仕様書は細部にこだわっているので計画全体が見えづらい。「ここでは両者のノウハウを集め、テスト仕様書を設計する必要がある」（小�ｱ氏）という。

　実はこのテスト仕様書の設計は、後の「自動化」に際して非常に重要な意味を持つ。というのは、自動化ツールへのスクリプト作成（パラメータ設定）工数は、このテスト仕様書の粒度に依存するからだ。テスト項目と条件のリストだけがあっても、ツールに読み込ませるスクリプトとしては使えない。テスト項目の詳細やテストデータ、条件、実施方法がそろって初めてツールが使えるレベルになる。

　さらに「テスト作業自動化のメリットを享受するには、まず手動のテストプロセスが確立されている必要がある。テスト計画とテストケースの詳細な設計ができて初めて、自動化ツールの効果が期待できる。ただしツールがカバーするのはテストの実行部分だけ。プロセス全体の最適化というレベルには遠い」（小�ｱ氏）と続け、テストプロセスそのものの効率化を目指すには、自動化ツールだけでは足りないことも指摘した。

◆ 管理ツールとの連携でプロセス全体が向上する

　小�ｱ氏が提案するのが、自動化ツールとテスト管理ツールの組み合わせだ。実際のテスト作業は自動化ツールに任せるが、それと共に管理ツールを導入することで、テストプロセス全体の生産性が向上するという。具体的にはテストの進ちょく確認や仕様書の構成管理、不具合（バグ）追跡などのプロセスを容易に把握できるため。特に不具合追跡の情報は、開発サイドと共有することで、品質の向上と不具合予防につなげるという一石二鳥のおまけも付く。小�ｱ氏は「作業を効率化するだけでは、テストそのものの品質は上がらない。テストプロセスを1つのプロジェクトと捉え、適切な管理の仕組みも同時に導入することで、全体の効率化が実現する」と述べる。

　 テストシナリオ作りも、ビジネスプロセスをコンポーネント化することで構築が容易になる。テストスクリプトもコンポーネントやテストデータと関連付けて一元管理することで、再利用可能なテスト資産としてチームにノウハウが共有できる。また不具合情報の共有から、パターン化による予防対策へとプロセス自体を洗練化することも可能。最後に小�ｱ氏は自社製品である「Mercury Quality Center」などを紹介し、テストプロセス全体から作業までをスムーズに管理・改善するソリューションを提示。高品質なソフトウェア開発には、テストプロセスの改善が重要という点を改めてアピールした。

当日行われたプレゼンテーション資料のダウンロード（PDF）が可能です。
ダウンロードボタンをクリックしてください。→