Excel2007以降で使用した場合の問題点

PictMasterをExcel2007以降のExcelで使用した場合、制約表の行列をコンテキストメニューで削除・挿入すると、セルの色が変化してしまう問題があります。これは、セルの背景色の扱いに関して、Excel2003以前とExcel2007以降で、VBAに互換性がないために起きている問題です。

近いうちにこの問題を修正したバージョンをリリースする予定です。

テスト仕様書を使わないテストも必要

通常、テストはテスト仕様書をもとにして行ないます。しかし、テストが進んでくるとそれ以上欠陥を見つけ出すことが難しくなります。同じテスト仕様書を使い続けているわけで、欠陥が修正されれば新しい欠陥を見つけることができなくなります。「殺虫剤のパラドックス」といわれる状況です。欠陥が隠れていても同じテスト仕様書を使い続けている限り、見つけ出すことは非常に困難です。

テストを強化するために新しいテスト仕様書を作成する、という対策もありますが、そうした余裕のあるプロジェクトは少ないと思います。テスト仕様書を使わずに、テスト担当者が頭の中でアドリブでテスト設計を行ない、テストを実行する方法を「探索的テスト」といいます。この方法は、システムを熟知しており、経験を積んだテスト担当者が行なえる方法です。

探索的テストと同じようにテスト仕様書を使わないテストの方法に「エラー推測テスト」があります。探索的テストが、前のテスト結果に応じて次のテストの方法を決めていく、系統だったテストという性格であるのに対して、エラー推測テストは、ソフトウェア開発者が「考慮漏れ」を起こしそうな点に的を絞ってテストを実施するものです。

ソフトウェア開発者はすべてを理解しているわけではないので、当然ながら考慮から漏れている対象があることになります。ソフトウェアの欠陥を分類すると、コーディングミスやインターフェースの不一致と並んで考慮漏れという分類となるものがあります。分類結果における考慮漏れの割合は、それほど多くはないのですが、コーディングミスに分類されている欠陥が、元をただせば結局は考慮漏れだった、といった事例が多いのではないかと感じています。個人的な感想に過ぎませんが、ソフトウェアの欠陥の過半数は考慮漏れに起因しているのではないかと思っています。複雑なシステムにおいて、起こる可能性のある事柄をすべて事前に把握することができている、という人はほとんどいないでしょう。エラー推測テストは、そうした人間の弱点に焦点を当て、考慮漏れを起こしそうな条件を見つけ出そうとします。

エラー推測テストはいつ行なえばよいでしょうか。システムテストであれば、テストがある程度進んで、新しい欠陥の発見が少なくなった頃に行なうと効果的です。例えば、一週間のうち、金曜日の午後は、テスト仕様書を使わずに、エラー推測テストを行なうことにするとか、テストの進捗が予定より進み、余裕ができた時間をエラー推測テストの実施に割り当てる、などとすればよいでしょう。

アドリブでテスト設計を行なうというテストの性質上、エラー推測テストの担当者は、システムを熟知しているベテランである必要があります。ソフトウェア開発者の考慮漏れを見つけ出そうとする点からも、充分経験を積んだ人でなければそうした欠陥はなかなか見つけ出せないものです。

エラー推測テストは実施するだけの価値があります。私たちのチームでは、テスト仕様書では発見することが不可能な欠陥をエラー推測テストでいくつも発見することができました。こうして見つかる欠陥は、テスト仕様書のテスト項目としては取り入れづらいものだという明らかな特徴があります。テスト仕様書では、基本的にはテスト対象が要件仕様通りに動作するかを確認するためにテスト項目を決めることになります。本来のテストの目的は、テスト対象に欠陥がないことを確認することですが、結果として、要件仕様通りに動作するかどうかを確認することに収束するという傾向になります。要件仕様に書かれていないことはテストできないことになります。このようにテスト仕様書だけに頼っていると、ソフトウェア開発者の考慮漏れに起因する欠陥を見逃すことにつながります。

探索的テストもテスト仕様書を用いないという点ではエラー推測テストと同じですが、そのテスト方法の性質上、どうしても要件仕様通りに動作するかを確認するテストになる傾向があります。探索的テストが最も向いているのは、欠陥を発見したときにその欠陥が発生する条件を絞り込み、ソフトウェア開発者に有益な情報を提供するために用いる場合です。

システムテストにおけるテスト実行の順番をどう決めるか

システムテストではテストケース数が数万件に達することが珍しくありません。テストの実行においては、膨大なテストケースをどのような順番で実行するのかが極めて重要な意味を持っています。理想を言えば、数万件のテストケースのすべてについて、３回程度繰り返しテストを実行し、検出可能な欠陥をすべて検出するということになるでしょう。しかし、現実においてはそれだけの工数を用意することが不可能である場合がほとんどだと思われます。それでは限られた工数の枠内でどのような順番でテストを実行すればよいでしょうか。

一人のテスト担当者が1日で実行できるテストケース数が20件、テスト担当者が10名、一か月でのテスト実施日数が20日、システムテストの期間が6カ月とした場合、実行できるテストケースの最大件数は以下のように24000件となります。

　20件×10人×20日×6カ月＝24000件

工数に余裕がある場合は、24000件のテストケースを何度か繰り返しテストを行なうことができますが、工数に余裕がなく、各テストケースを1回と＋αしか実行できないものとして説明します。以降の説明では、機能テスを対象としています。

方法Aでは、次の順番でテストを実行します。

テスト担当者ごとにテストを実施する機能を割り当て、一人当たり2400件のテストケースを6ヶ月かけて実行します。この方法では、最初にテストされる機能と最後にテストされる機能との間には6ヶ月近い隔たりが生まれることになります。

方法Bでは、次の順番でテストを実行します。

システムテストの期間をいくつかのサイクルに分け、各サイクルごとに実行するテストケースを割り当てます。ここではテストサイクルを4として説明します。4つのテストサイクルを実行し終えたときにすべてのテストケースの実行が完了することになります。各テストサイクルごとに、どの機能のテストを誰が実行するかを割り当てます。ここで重要なことは、各テストサイクルにおいて、すべての機能についてテストを実行するということです。つまりテストケースを「間引いて」テスト実行するということです。テストサイクルが４つであれば、ごく簡単にいえばある機能のテストケースのうち、4分の1を1つのテストサイクルで実行するということです。

方法Aでは、6ヶ月というシステムテストの期間を通して、テストを実行する機能が順番に変わることになります。この場合、システムテストの終了間近になってテストを実行した機能に多くの欠陥が見つかるということがあり得ます。もしもこうしたことが起きれば、プロジェクトリスクとプロダクトリスクの両方が急上昇してしまいます。

これに対して、方法Bでは、最初のテストサイクルの段階で、他よりも多くの欠陥のある機能を特定可能なことが期待できます。システムテストの早期にそうしたリスクを把握することができれば、余裕をもって対策を検討することが可能となります。方法Bの利点はこれだけではありません。方法Bの利点を箇条書きで次に示します。

①.最初のテストサイクルの段階で、他よりも多くの欠陥のある機能を特定できる。

②.システムテストの全期間に渡ってすべての機能を対象とした様々なメトリクスを、各テストサイクルごとに収集することが可能となり、テストプロセスをコントロールすることが方法Aより容易になる。

③.テストサイクルごとに各人が担当する機能を入れ替えることにより、システムテスト終了の時点でテスト担当者が、システムの機能全体に対する理解を深めることができる。

④.システムテスト開始時点より終了時点でのテスト対象の品質が高くなることに対応して各テストサイクルの期間を決めることができ、テストサイクルに応じてテストの網羅度を変えることができる。

⑤.方法Aでは、最初にテストされる機能と最後にテストされる機能との間に長いブランクがあり、その間に欠陥の修正が行なわれるうちに、最初にテストした機能でデグレードする可能性があり、そのまま見逃される危険があるが、方法Bではそうした危険は少ない。

以上の利点のうち、③はテストサイクルごとに担当する機能が入れ替わるので、最初から担当する機能を固定する方法に比べて、慣れの問題があり、テスト効率の点で不利ですが、テストは一回きりではなく、何度もあるため、長期的にみれば特定の機能のテストが特定のテスト担当者に依存するという問題を回避することができ、機能全体を理解することができる方法Bが有利となります。

上にあげた方法Bの利点で④はこういう意味です。システムテスト開始時点では、ソフトウェアの品質はそれほど高くありません。したがって、この段階でのテストでは、テストを実行するテストケース数をある程度抑え、少なめに設定します。システムテストの中盤では、ある程度の品質が確保されるため、実行するテストケース数は広く深く、多めに設定します。システムテストの最終段階では、徹底したテストは不要ですから、広く浅く、実行するテストケース数は少なめに設定します。

したがってシステムテストの期間が6ヶ月で、テストサイクルが4サイクルであれば、各テストサイクルのテスト期間は例えば次のようになります。

　第1サイクル　1ヶ月
　第2サイクル　2ヶ月
　第3サイクル　2ヶ月
　第4サイクル　1ヶ月

4つのテストサイクルとした場合、どのテストケースをどのテストサイクルで実行するかをテストケース仕様書に明記します。次のテストケース仕様書の例で、左端の「実施TS」の列にある数字が、そのテストケースを実行するテストサイクルを表しています。例えば第2テストサイクルで使用するテストケース仕様書では、実行するテストケースが一目見てわかるように薄い水色などで塗りつぶしておきます。

この例では、各テストサイクルでの実行テストケースの件数には違いはありませんが、実際にはテストサイクルに応じてテスト網羅度を変えることになります。例えば第1と第4のテストサイクルでは実行するテストケース数が少なく、第2と第3のテストサイクルでは多くなります。

膨大なテストケースをどのような順番でテスト実行するかという問題は、テストプロセスにおけるかなり重要な事柄だと思いますが、このことについて説明したものはほとんど存在しないようです。テストプロセスを解説した書籍を何冊か持っていますが、どれにも説明がありません。Web上で検索してみましたが、ここで説明した事柄に近いことが書かれている記事が一つだけ見つかりました。日経BP社のITProというサイトの2006年6月28日の以下の記事です。

　基礎から学ぶソフトウエア・テスト（5）　テストのマネージメントとレポート

ちなみにISTQB テスト技術者資格制度の「ソフトウェアテスト標準用語集」の（日本語版）では、「テストサイクル」の説明として、「特定可能な単一のテスト対象のリリースに対し、テストプロセスを実行すること」とあります。この用語集で扱われている「テストサイクル」は、ここで説明したテストサイクルとは少なくとも同じものではないようです。「ソフトウェア品質知識体系ガイド」でも取り上げられていないようです（見逃しているかもしれませんが）。

PictMaster ユーザーズガイド 第１．０版 をリリースしました。

PictMasterを使用する上で必要最低限知っておく必要のある事柄に的を絞って説明したユーザーズガイドです。

PictMasterに同梱されているユーザーズマニュアルは、100ページ以上の分量があり、状態遷移図や制御パステストについての説明があります。これに対して、このユーザーズガイドでは、Pairwise法（All-Pairs法）による組合せテストについての説明に限定し、ページ数を50ページ程度までに抑えてあります。

PictMasterの使用方法を知るうえでは、このユーザーズガイドが便利に使えると思います。

このユーザーズガイドは、v4.3以降のPictMasterに対応しています。

以下のリンクからダウンロードすることができます。

http://sourceforge.jp/projects/pictmaster/

テスト分析とテストの観点３０選

この記事は古くなっています。新しい記事はこちらをご覧下さい。「テストの観点をどう決めるか」

テスト設計の前には「テスト分析」が必要となります。

テスト分析とは、「テスト対象」について「テストの観点」を抽出することです。
テスト対象とは、テストによってその振る舞いを確認するシステムの機能およびシステムの特性のことです。
テストの観点とは、テスト対象がもたらすシステムの種々の振る舞いを確認するために必要となるテストの着眼点のことです。
個々のテストの観点を分析することで、普遍性を持つ一般化したテストの観点を導き出せます。
テストの観点は、テスト対象によって異なりますが、一般化したテストの観点のいずれかに分類することができます。
テスト対象のテストの観点を決めようとする際に、一般化したテストの観点があるならば、それを参考にして具体的なテストの観点を決めることができるようになります。
一般化したテストの観点にはどのようなものがあるでしょうか。以下に３０の一般化したテストの観点をあげてみます。この中には私が担当するシステムに特有の表現を用いているものも含まれていますが、多くは普遍的に利用できると思われます。また、中にはテスト仕様書を作成して実施する「スクリプトテスト」とは相性が良くないものも含まれています。それらは、「エラー推測テスト」または「探索的テスト」で利用できるでしょう。
【３０の一般化したテストの観点】
(1) 基本
　　 機能の正常ルートを動作させる。
(2) 同時
　　 同時に複数の資源を使用して動作させる。
(3) 競合
　　 使用する資源の競合が起きる動作をさせる。
(4) 併用
　　 他の機能と併用して別機能を動作させる。
(5) 割込み
　　 機能が動作中に別機能を動作させる。
(6) タイマ
　　 各種タイマのタイムアウトを発生させる。仕様上の最小のタイマ値（例えば１秒）で動作させるなど。
(7) 無効
　　 機能が動作しない条件で動作させてみる（例えば未登録状態で登録解除操作など）。
(8) 輻輳
　　 システムを輻輳状態にして機能を動作させる。
(9) 構成変更
　　　ハードウェア構成またはソフトウェア構成を変更して動作させる。
(10) 資源不足
　　　 使用する資源の最大量をオーバーする条件で動作させる。
(11) 例外
　　　 現実にはほとんど起きようがないと思われる例外条件を想定し動作させる。
(12) 失敗
　　　 機能の動作が途中で失敗する条件で動作させる。
(13) 意地悪
　　　 複数の端末からのキーの連打などを行なう。
(14) 中断
　　　 一連の操作を途中で打ち切り、操作前の状態に戻す。
(15) 設定変更
　　　 機能が動作中に、その機能に関係するシステムデータを変更する。
(16) 順序変更
　　　 操作の順序を入れ替えて操作する。
(17) 範囲外入力
　　　 仕様上で範囲外となる入力を行なう。
(18) 最大入力
　　　 仕様上で許容される最大の入力を行なう。
(19) 最大実装
　　　 システム構成上の資源の実装数を最大数まで行なった状態で動作させる。
(20) 例外設定
　　　 システム運用上は初期値のままで問題ないシステムデータを、意図的に初期値以外に設定して動作させる。
(21) 複数方法操作
　　　 同じ機能を動作させる複数の操作方法がある場合、ある方法で動作中に別の方法で操作してみる。
(22) 衝突
　　　 ある資源を使用する機能が動作すると同時にその資源を使用する別機能を動作させる（例えば発着信衝突など）。
(23) 不実行操作
　　　 仕様上では操作可能であるが、通常は行なわない操作（例えば呼出し中の保留操作など）を行なう。
(24) 再立ち上げ
　　　 登録／解除操作後にシステム再立ち上げを行ない、登録／解除操作が反映されていること。
(25) 移行
　　　 ある機能を実行中に別の機能の実行に移行する。
(26) 初期値
　　　 システムデータなどの初期値が仕様書通りであることを確認する。
(27) 集中
　　　 一度に大量の資源を消費するように特定の資源に集中してイベントを発生させる。
(28) 異常データ設定
　　 　意図的に設定ミスを行なってもシステムダウンを招かないこと。
(29) 処理切替
　　　 ある機能が動作中に同時に動作する機能の処理が切り替わる操作を行なう。
(30) 資源切替
　　　 ある機能が動作中に使用する資源の切り替えを行なう。

どのようなテスト技法を適用するかは、テスト対象の性質に応じて一意に決めることができます。