ソフトウェアテストは知的創造行為そのもの
今でもテストは新人が最初に担当する「易しい」作業と見られる風潮が強いようですが、実際には奥の深い難しい作業です。ソフトウェア開発のVモデルにあるように、テストはソフトウェア開発の半分の工程を占める重要な作業です。
ソフトウェア開発者の生産性には数倍の個人差があるといわれていますが、テスト担当者の生産性についても数倍の個人差があると私は感じています。かつて「ソフトウェア工場」という言葉が使われ、ソフトウェア開発から属人性をできるだけ排除し、「工場」の作業員と同様に同じレベルのプログラムをプログラマーに生産させようとする考え方が現れた時代がありました。今、そういう考え方をする人はほとんどいないでしょう。ソフトウェアシステムはそれほど単純ではないからです。
巨大なソフトウェアシステムは、人類が創造するものの中で最も複雑なものだといわれています。このことに異論をはさむ人は少ないと思います。そのようなシステムを構築するには、人並み外れて優れた少数のエンジニアの存在が欠かせません。そして担当する部分の難しさに応じたレベルのエンジニアが必要となります。「工場」で同じ製品を毎日作り続けるような作業とソフトウェアの開発は大きく異なる性質を持っています。
ソフトウェア開発プロセスの標準化は必要ですが、標準化の枠外にエンジニアの「創造性」が存在します。創造性自体は標準化できないものです。ソフトウェアは創造性の産物でもあります。このことはソフトウェアのテストについてもいえます。
ソフトウェアをテストする方法には無限ともいえる方法があります。その中から最も適切な方法を見つけ出し、テストを設計することは知的創造行為そのものといえます。そうして作られたテスト設計仕様書、テストケース仕様書をもとに実際にテストを実施することも知的創造行為といえます。仕様書にすべてを記述することは不可能です。テスト担当者は仕様書をもとにテストを行なう中で仕様書にはかかれていない事項で不具合を見つけだすことが多いものです。
テスト担当者は、自身のレベルに応じた複雑さのテスト対象をテストすることになります。テスト担当者が仕様書には書かれていない不具合を１つ見つけ出すとき、１つの創造行為を行なったといえるのです。
今後、ますますテストの重要性は増してくるでしょう。それとともにテスト技術者の社会的地位向上がもたらされることを願ってやみません。
強い制約、弱い制約
制約がないモデルで生成した組み合わせの件数に対して、制約を加えると組み合わせの件数が少なくなる制約が「強い制約」です。一方、制約を加えると組み合わせの件数が多くなる制約が「弱い制約」です。ほとんどの制約は「弱い制約」に属します。「強い制約」は非常にまれな制約です。
ほとんどの制約は「弱い制約」なので、制約の数が増えるに従って、生成される組み合わせの件数が緩やかに増加していきます。これは可能なすべてのペアを網羅するというAll-Pair法の原理に基づくものです。制約の数が増えるに従って、生成される組み合わせの件数が増加する理由については、「制約があるとテストケース数が増えるのはなぜ？ 」を参照してください。
数少ない「強い制約」のいくつかの例を示します。
下図のモデルは制約がない場合、組み合わせの件数は32です（最少テストケース生成を100回行った場合。以降も同様）。下図の制約を有効にすると生成される組み合わせの件数は25となります。この制約ではパラメータＡのみが制約条件となっていますが、もう１つの任意のパラメータも制約条件にすると、「弱い制約」になります。これとは逆に、パラメータＥも制約対象にすると、最も「強い制約」となり、生成される組み合わせ件数は5となります。
別の「強い制約」の例を２つ示します。生成される組み合わせの件数は、最初の例では24件、次の例では21件となります。
まだこれ以外にも「強い制約」のパターンがあるでしょう。探してみるのも面白いかもしれません。パラメータと値の数が多いと、制約の指定方法によっては組み合わせ生成に長時間かかる場合がありますので注意してください。
「強い制約」、「弱い制約」はわたしが作った造語です。
それでは、また。
無効値テストの最適化
組み合わせテストでは多くの場合、機能が動作する組み合わせをテストしますが、機能が動作しない場合の振る舞いを確認するために、機能が動作しない無効値を含む無効値テストも行なう必要があります。
無効値テストでは、１つのテストケースに複数の無効値を含むと、実際にはどれか１つの無効値のテストとなり、残りの無効値のテストが行なわれない、という問題があります。
PICTには、この無効値テストをサポートする機能があり、値の前に( ~ )を付加すると、その値が無効値とされます。こうして生成されたテストケースには１つのテストケースには無効値が２つ以上含まれないようになります。
PICTの無効値テストの機能は有意義なものですが、生成されたテストケースには無効値を１つも含まないテストケースも含まれています。無効値を含む場合だけのテストをしたい場合には、余計なテストケースとなります。ここで無効値を含まないテストケースを単純に削除し、無効値を含むテストケースだけにしたいと思うかもしれません。
もし、テスト担当者が無効値とその他の無効値以外の値のすべてのペアをテストしたいと思っているなら、その意図に反した結果となるでしょう。無効値を含まないテストケースを単純に削除すると、残ったテストケースはすべての可能なペアの組み合わせを網羅したものにはなりません。ペアの欠落が発生します。
次の図と表は、PICTの無効値テストの機能( ~ )を用いたモデルと、それから生成した組み合わせです。このモデルでは、５つのパラメータと５つの値で各パラメータに１つの無効値を含んでいます。
表１で、グレーに網掛けした値が無効値です。黄色に網掛けしたテストケースは無効値を含まないテストケースです。
表２は、無効値を含まないテストケースを削除したものです。
表２をよく見てもらうと、組み合わせに現れていないペアのあることが分かります。例えば、a2とb3のペアが欠落しています。このペアは削除したテストケースに含まれていたものです。
従って単純に不要なテストケースを削除するという方法は使えません。
欲しいのは、無効値を１つだけ含むテストケースですべてのペアを網羅した組み合わせです。そこでPICTの無効値テストの機能( ~ )を用いてその組み合わせを生成しようとしたのですが、PICTがエラーメッセージを出力し、うまくいきません。
PICTの無効値テストの機能はあきらめて( ~ )を使わずにそれと等価な制約指定をPictMasterの制約表を使って実現したのが図２の制約表です。この図では一部しか表示されていませんが残りの部分も同様のパターンですので容易に類推できると思います。
図２で、制約１、制約６、制約１１、・・・ がPICTの無効値( ~ )に相当する制約指定の部分です。残りの制約指定は、値が無効値でない場合にペアの組み合わせが可能な無効値をOR条件で指定しています。この制約指定は、すべての無効値が他の無効値以外の値とのペアを網羅するために必要な指定です。この制約指定がないと、無効値と他の値とで欠落するペアが出てしまいます。
図２の制約表で生成した組み合わせを表３に示します。
表３ではすべてのテストケースに１つの無効値が含まれています。テストケース数は表１の47件に対して34件と少なくなっています。そして各無効値は他の無効値以外のすべての値とのペアを網羅しています。
この例では、すべてのパラメータに無効値が含まれていますが、一部のパラメータだけに無効値を含む場合も同様の方法で最適化することができます。
それでは、また。
再び間接制約について
「間接制約」については以前にAllPairIIの機能として「Jennyの間接制約を検出する機能について」と題して9月8日に取り上げています。今回は、間接制約を検出する機能を持たないPictMasterを使用する上で、間接制約に対してどういった考え方をすれば良いのかを話題にしたいと思います。
間接制約は、制約を明示的に指定した結果、副次的に現れる制約のことを言います。最も分かりやすい例を２つ示します。この例はAllPairIIで行なったものですが、PictMasterでも全く同様に間接制約は現れます。
間接制約の例その１
図１．モデルその１
表１．モデル１の組み合わせ
リスト１．間接制約のリストその１
間接制約により組み合わせに現れない値のペア
B：b2 + C：c3
B：b3 + C：c3
間接制約の例その２
表２．モデル２の組み合わせ
リスト２．間接制約のリストその２
間接制約により組み合わせに現れない値のペア
A：a1 + C：c2
A：a1 + C：c3
以上の２つの例で、それぞれの制約表をよく見ていただくと、言葉で説明するよりも間接制約が現れる理由がよく理解できると思います。モデル１よりモデル２が分かりやすいでしょう。
間接制約で問題となるのが、間接制約によって組み合わせに現れないペアも網羅する必要があるのではないか、ということです。モデル１の場合、パラメータBとCの間には制約表の上では制約が記述されていないため、b2、b3とc3との組み合わせを網羅しなければならない、というものです。
このことを実現するには、パラメータAにダミーの値「－」を追加しなければなりません。追加されたダミーの値とb2、b3の組み合わせが追加され、c3との組み合わせが網羅されます。
ここで問題となるのが、パラメータAにダミーの値を追加できるものなのか、ということです。もし、パラメータAがダミーの値を含ませることができる性質のものであるならば、要因分析（組み合わせるパラメータと値を洗い出すこと）の段階で既にパラメータAの値の１つとしてダミーの値が含まれるだろうということです。言い換えるなら、最初からダミーの値を含まないパラメータに後からダミーの値を追加することはできないはずだということです。もし、追加できるとするならば、要因分析の段階で間違った分析を行なっていたことになります。
ここで実例をあげてみます。これはビジネスホンシステムでの保留・保留応答の組み合わせテストの例です。
これをAllPairIIのJennyで生成し、出力された間接制約を以下に示します。
リスト３．間接制約の実例
間接制約により組み合わせに現れない値のペア
保留操作：CLRキー押下 + 応答操作：プリセレクション→オフフック
保留LK：IK + 応答操作：オンフック→呼び返し着信
保留LK：SK + 応答操作：オンフック→呼び返し着信
保留LK：PK + 保留操作：フッキング
保留LK：EKG + 保留操作：CLRキー押下
保留LK：IK + 保留操作：フッキング
保留LK：SK + 保留操作：フッキング
保留LK：EK + 保留操作：CLRキー押下
保留LK：SK + 保留操作：CLRキー押下
保留LK：IK + 保留操作：CLRキー押下
被保留端末：DCL-PSM + 保留LK：IK
被保留端末：DCL-PSM + 保留LK：SK
保留LK：EKG + 応答操作：オンフック→呼び返し着信
保留LK：EK + 保留操作：フッキング
被保留端末：KT + 保留LK：SK
被保留端末：SLT + 保留LK：SK
被保留端末：IP-SLT + 保留LK：IK
被保留端末：ITE + 保留LK：SK
保留LK：DK + 応答操作：オンフック→呼び返し着信
保留LK：EKG + 保留操作：フッキング
被保留回線：NGN + 保留LK：PK
被保留端末：SLT + 保留LK：IK
保留LK：EK + 応答操作：オンフック→呼び返し着信
被保留端末：－ + 保留LK：DK
保留LK：外線 + 保留操作：機能＋保留
被保留端末：ITE + 保留LK：IK
保留LK：DK + 保留操作：フッキング
保留LK：PK + 応答操作：オンフック→呼び返し着信
保留操作：CLRキー押下 + 応答操作：オフフック→LK押下
被保留端末：KT + 保留LK：IK
被保留端末：IP-SLT + 保留LK：SK
保留LK：内線 + 応答操作：プリセレクション→オフフック
保留操作：フッキング + 応答操作：オフフック→LK押下
被保留回線：内線 + 保留LK：IK
被保留端末：IPKT + 保留LK：IK
被保留端末：IPKT + 保留LK：SK
保留LK：DK + 保留操作：CLRキー押下
保留LK：PK + 保留操作：CLRキー押下
保留LK：外線 + 応答操作：プリセレクション→オフフック
保留LK：内線 + 応答操作：オフフック→LK押下
保留LK：内線 + 保留操作：機能＋保留
被保留回線：NGN + 保留LK：DK
被保留回線：内線 + 保留LK：SK
被保留端末：－ + 保留LK：PK
保留LK：外線 + 応答操作：オフフック→LK押下
保留操作：機能＋保留 + 応答操作：オンフック→呼び返し着信
保留操作：フッキング + 応答操作：プリセレクション→オフフック
この例では、47件の間接制約が出力されましたが、内容を調べてみたところ、実際に問題となる間接制約は１件もありませんでした。つまり、これらの組み合わせが現れていないのは正しかったのです。他のいくつかの例でも調べてみましたが問題となる間接制約はありませんでした。
なぜ、これだけ多くの間接制約が指摘されながら、実際に問題となる間接制約がなかったのでしょうか。これらの間接制約はすべて組み合わせ不可能な組み合わせでした。制約表による直接制約により、組み合わせ可能な組み合わせがすべて網羅されており、間接制約には組み合わせ可能な組み合わせが残されていなかったと見るべきでしょう。
間接制約は、PICTだけで発生するものではなく、組み合わせできない組み合わせを除外する、という機能をもつすべてのツールで発生します。All-Pair法だけでなく、直交表ベースのツールでも同様です。
間接制約の問題は、要因分析さえしっかりできていればそれほど問題とするものではないと考えます。
それでは、また。
PictMaster 2.7.3 をリリースしました。
このバージョンでは、値の大小比較を行なうと未定義エラーとなるバグの修正のほか、細かいバグ修正を行ないました。
その他に、ユーザーズマニュアルの内容更新（訂正）を行ないました。
以下のサイトsourceforge.jpからダウンロードすることができます。
https://sourceforge.jp/projects/pictmaster/
詳しい変更点は以下のとおりです。
【機能改善】
・サブモデル欄の記入フォーマットを簡略化した。
・結果表を使用した場合の生成結果の表示タイミングを改善した。
【バグ修正】
・演算子に <、> を用いた値の大小比較を行なうと、値が未定義というエラーメッセージが表示されるバグを修正した。
・あるパラメータの値が30個あり、確認表を使用すると、値が未定義というエラーメッセージが表示されるバグを修正した。
・パラメータが30個あり、確認表を使用した場合、「整形」ボタンと自動整形の機能が正しく動作しなかったバグを修正した。
・パラメータが30個あり、「整形」ボタンを使用した値の並び替えで行番号が付加された生成結果の30個目のパラメータを最優先するキーに指定して整形を実行すると、VBAのエラーとなるバグを修正した。
【その他】
・制約表での「セット」という記述を「制約」に変更した。
・確認表の名称を「結果表」に変更した。
・ユーザーズマニュアルでの「デシジョンテーブルと組み合わせテストの統合」の章を全面修正した。
以上です。