2016. 09. 08 Update !

イマ旬

テストを開発する ~最適なテスト設計プロセスの構築~

ソフトウエア開発におけるテストを網羅的かつ効率的に実施するためには、戦略に基づいた最適なプロセスに従うことが必要です。今回は、効率的にテストを進める手法のひとつとして「テストケースを開発するプロセス」を紹介します。

町田 欣史
株式会社NTTデータ システム技術本部
課長代理 町田 欣史

イマ旬の注目キーワード
テストプロセス改善

テストに必要な視点

NHK朝の連続テレビ小説「とと姉ちゃん」では、主人公が出版する雑誌の看板企画が「商品試験」となっています。石鹸やトースターなど特定の商品に関して、さまざまなメーカーの商品の品質を検証、比較し、その結果を雑誌に掲載します。

この試験では、利用者の立場で気づいたことを洗い出して、商品の使いやすさや耐久性、安全性など多角的な視点に基づいた「試験項目」を設定した上で、実際に商品を使って評価をします。

ソフトウエアのテストは、商品が出荷される前に行うという違いはありますが、この商品試験と相通じる部分もあります。それは、テストの対象を実際に動かしてみる前に、さまざまな視点からどのようなテストをするかを考えるという点です。

ただ思いつくままに動かすのでは適切なテストとは言えません。そのために、「テストケース」と呼ばれるテストの条件や期待結果を記載した成果物を事前に作成して、テストを行うのが一般的です。

テストケースをどうやって作るか、で頭を悩ませている開発現場を多く目にします。ここでは、テストケースの作り方を3つのレベルに分けて紹介します。

レベル1:仕様書・設計書の記述内容を転記する
開発の上流工程で作成する仕様書や設計書には、ソフトウエアが満たすべき要求やその要求を実現する方法が記載されています。その記載通りにソフトウエアが作られているかをテストで確認するために、仕様書や設計書を転記してテストケースを作成します。

これは多くの開発現場で行われている方法です。仕様書や設計書を基にするのは悪いことではありませんが、単に転記するだけでは十分なテストとは言えません。テストに必要な情報が仕様書や設計書に漏れなく書かれていることは現実的にはありえないためです。

また、テストの主たる目的は「仕様通りに動かないこと」、すなわち欠陥を見つけることです。しかし、この手法では「仕様通りに動くこと」の確認に意識が傾く懸念があります。

レベル2:テスト観点、テスト設計技法を使う
仕様書や設計書の内容を基にしつつ、そこにテストならではの視点を取り入れて、テストケースを作成します。これにより、仕様書や設計書の行間や裏の仕様まで行き届いたテストケースを作成でき、欠陥の検出率も向上します。

テスト観点という言葉には厳密な定義はなく、非常に広い意味で使われていますが、「テストで確認すべきこと」というニュアンスで捉えていただければよいと思います。テスト観点は、会社の標準として規定されたものや過去のプロジェクトで使ったもの、あるいは類似システムのバグ情報などを基に作成することが多いです。ISO/IEC 25010で定義された品質特性・品質副特性を参考にすると、利用者と開発者、外部品質と内部品質などさまざまな視点でテスト観点を整理できます。

さらに、具体的なテストケースを作る際にはテスト設計技法を用います。例えば、具体的な入力値を決める場合や、複数の条件の組み合わせを決める場合などに技法を適用することで、適切なテストケースを作成できます。

レベル3:テストケースを開発するプロセスを定義する

レベル2でも、ある程度は十分なテストができますが、さらに効率よくテストを進めるための手法が研究されています。この手法は、テスト設計の成果物であるテストケースを開発するプロセスを定義するものです。

従来はテスト実施前の作業をテストの準備としてまとめていましたが、次の4つの作業に細分化したテスト開発プロセスで行います(図1)。

・テスト要求分析
テスト対象の仕様・構造、要求事項などを整理、分析し、テスト観点を抽出する。
・テストアーキテクチャ設計
テスト対象やテスト観点の依存関係を整理し、テスト工程やテストタイプで整理する。
・テスト詳細設計
テスト設計技法を使ってテストケースを作成する。
・テスト実装
テストケースからテスト手順やテスト自動化用のテストスクリプトを作成する。

図1.旧来のテストプロセスとテスト開発プロセス

図1.旧来のテストプロセスとテスト開発プロセス

この手法では、テストの全体像を俯瞰して整理する「テストアーキテクチャ」を作るのが特徴の一つです。図1では、ある一つのテスト工程におけるテスト開発プロセスを表現していますが、テスト要求分析やテストアーキテクチャ設計は、特定の工程に対してだけではなく、テストの全体を対象にすることもできます。

これまでのテスト計画では、単体テスト、結合テストといった工程の枠組みの中で、どのようなテストをするかを考えていました。一方、このレベル3の手法では、テスト要求分析やテストアーキテクチャ設計をすることで、テスト対象の全体構造をテストの視点で一度組み立て直し、その結果として工程というグルーピングをするという考え方ができます(図2)。

図2.テストアーキテクチャの例

図2.テストアーキテクチャの例(※3)

テスト開発プロセスに関する取り組み

このテスト開発プロセスは日本発のテスト技術で、VSTeP、HAYST法、ゆもつよメソッドなどいくつかの手法が考案されています。そして、テスト開発プロセスの優劣を競うテスト設計コンテストが毎年開催され、ソフトウエア開発会社や第三者検証会社が腕を競っています。

2017年度からOPENクラス(年齢制限なし)とU-30クラス(30歳以下)の2つのクラスに分かれ、若手技術者の方も参加しやすくなりました。日頃の業務で培った実力を試してみたい方は挑戦してみてはいかがでしょうか。2014年度には、私を含むNTTデータの有志が参加し、決勝で3位という成績を残しました

NTTデータでは、このテスト開発プロセスの考え方を取り入れたテスト計画やテスト設計の技術を研究開発し、テストプロセスの標準化に取り組んでいます。

※1 とと姉ちゃん

http://www.nhk.or.jp/totone-chan/

※2 ISO/IEC 25010:2011 Systems and software engineering -Systems and software Quality Requirements and Evaluation (SQuaRE)- System and software quality models (JIS X 25010:2013システム及びソフトウエア製品の品質要求及び評価(SQuaRE) −システム及びソフトウェア品質モデル)

http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733

※3 テスト設計コンテスト’17 – OPENクラスチュートリアル

http://aster.or.jp/business/contest/tutorial.html

※6 ゆもつよメソッド

http://www.slideshare.net/kjstylepp/ss-36095291

※7 テスト設計コンテスト

http://aster.or.jp/business/contest.html

※8 テスト設計コンテスト'14 決勝戦レポート(「らくてす」がNTTデータのチーム)

http://aster.or.jp/business/contest/contest2014.html