納期を守るためにはバグはあってもいいか？

タイトルの質問、みなさんはどう考えるでしょうか。

まず考え方として、バグがないことを証明することはできない、という事実を認めることにしましょう。そうするとこの質問は、既知のバグがあっても納期を守るために出荷していいか、という質問に言い換えることができます。

ここでバグの内容が問題となります。

ケース１

　汎用システムの納入で、ユーザ側の動作仕様ではそのバグが絶対起きないケース。この場合はそもそもバグの個所が実行されることがないのでバグのあることが分かっていてもユーザ側ではバグが発生することはありません。修正を行なうと納期に間に合いません。

ケース２

　バグの内容がごく軽微で、ユーザにとってバグとは分からないケース。設計仕様書上は仕様とは異なる動作をするが、ユーザに提出した仕様書にはその点の動作には触れておらず、それがユーザにとって何ら不利益をもたらさない場合です。修正を行なうと納期に間に合いません。仕様が複雑になるとこうしたケースの生じる場合があります。

ケース３

　バグの内容は軽微だがユーザ側はバグと認識できる。バグ修正にはソフトウェア変更のリスクが大きく修正に多大な工数がかかるケース。ユーザには軽微な不利益が生じますが、バグをなくそうとすると納期が大幅に後ずれせざるを得ないケースです。

建前で考えると、納期を守るためにはバグはあってもいいとはもちろん言えませんね。でも実際のケースで考えると、そうとも言い切れない場合が往々にしてあるものです。

最初のケース１では、ユーザ側ではバグが発生することはないということがあらかじめ分かっているので、バグがあっても問題ないと言えるでしょう。

次のケース２では、ユーザ側でもバグは発生するが、ユーザ側でそれがバグと認識できないケースです。この場合、ユーザ側にとってその動作はバグとは認識されず、不利益も被らないわけですから、そのまま納入するほうが双方とも幸せになれます。

最後のケースでは問題が面倒です。ユーザ側からこれ位なら問題ないから納期通りに納入をしてほしいと言ってもらえれば一番簡単です。もし、ユーザ側が納得できない場合はバグを修正することになり、ではバグ修正版がいつまでなら納入できるか納期を巡ってユーザ側との折衝になります。折衝の結果、ユーザ側にとって納期の遅れによるデメリットが、軽微なバグ修正のメリットに比べて大きければそのまま納入し、後日バグ修正版と入れ替えるということになるかもしれません。

このように、納期を守るためにはバグはあってもいい、とは必ずしも正しいとは言えませんが、実際の場面ではそれが正しいこともよくあります。

PictMasterをExcel 2013で使用時の画面表示の挙動について

これは最新バージョンに限ったことではないですが、PictMasterをExcel 2013で使用した場合、画面表示の動きがExcel 2010以前とは異なる場合があります。これはOfiice 2013でウィンドウのユーザインタフェースがそれまでの multi Document Interface（MDI）から Single Document Interface（SDI）に変更されたことが原因です。

MDIは１つのウィンドウの中にさらにいくつかのウィンドウが表示されます。Excelとしてはおおきなウィンドウが１つあるだけでその中にいくつかのウィンドウが閉じ込められているひと時代前の古いユーザインタフェースでした。それがExcel 2013のSDIでは晴れて各ウィンドウがそれぞれ独立して表示されるようになった訳です。これは非常に大きな仕様変更で、ユーザにとっては格段に操作性がよくなりました。

ただし、いいことばかりではありません。VBAで処理しようとしたとき問題が起きる場合があります。それはVBAのなかで複数のファイルにアクセスする部分です。これまでのMDIでは複数のファイルは同じ１つのおおきなウィンドウの中に閉じ込められていたので、画面の表示を一時停止するApplication.ScreenUpdating = Falseさえ掛けていれば画面表示に問題が起きることはありませんでした。しかしSDIでは各ファイルが独立したウィンドウを持つようになったため、Application.ScreenUpdating = Falseを掛けても、どうもそれが確実に実行されない場面が出てきました。

問題が起きるのはPictMasterで「希望するカバレッジで生成」を行なった場合、一瞬灰色のウィンドウが表示されます。その他には結果表を使用して生成を行なった場合、一時的に画面にちらつきが出ます。これらの動作はOffice 2013での仕様変更に起因するものでPictMaster側では回避することができません。

これらは特に障害という訳ではありませんのでOffice 2013のユーザはそのままでご使用ください。

PictMaster 6.2J をリリースしました

PictMaster 6.2J をリリースしました

変更点は次の通りです。

【機能改善】
・制約表で扱える制約指定の数を50件から100件に拡張した。
・結果表で扱える結果指定の数を50件から100件に拡張した。　

【バグ修正】
・生成エンジンがCIT-BACHの場合にサブモデルの使用でPictMasterのエラーとなる場合があるバグを修正した。
・エイリアスでかつ無効値の値を結果表で指定すると生成結果と一致しないバグを修正した。

【その他】
・ファイル形式をExcel2007以降のExcelマクロ有効ブック（*.xlsm）に変更した。
・本バージョンからExcelバージョンのサポート対象がExcel2007以降となった。Excel2003以前では使用できない。

サポート対象がExcel2007以降となった理由は、機能改善で制約指定を100件まで扱えるようにしたためです。Excel2003以前では大きな表が扱えないため、サポート対象外となります。

PictMasterバージョン6.2Jは次のサイトからダウンロードすることができます。

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

PictMaster 6.1J をリリースしました

今回のバージョンの変更点は次の通りです。

【機能改善】
・拡張サブモデルをサブモデルに統合した(*1)。

【バグ修正】
・生成エンジンにPICTを使用して最小テストケース生成を行なった場合、制約指定に矛盾した制約があるなど、PICTが検出するエラーが発生するとVBAのエラーとなる問題を修正した。

*1: サブモデルはPICTオリジナルの機能であり、環境設定の「組み合わせるパラメータ数」が１の場合に有効に使用できる機能です。その反面、環境設定の「組み合わせるパラメータ数」が２以上では、生成されるテストケース数が膨大となってしまうので実用になりません。一方、拡張サブモデルはPictMaster独自の機能であり、環境設定の「組み合わせるパラメータ数」が２以上の場合に有効に使用できる機能です。
　6.1Jでは、環境設定で「拡張サブモデル」の指定チェックボックスを削除し、環境設定の「組み合わせるパラメータ数」が１の場合はPICTオリジナルのサブモデルを使用し、２以上の場合はPictMasterの拡張サブモデルの機能を内部で使用するようにしました。

生成エンジンにPICTを使用して最小テストケース生成を行なうと発生する場合のある問題について

現行のPictMaster v6.0に以下の問題のあることが分かりました。

・生成エンジンにPICTを使用して最小テストケース生成を行なった場合、制約指定に矛盾した制約があるなど、PICTが検出するエラーが発生するとVBAのエラーとなる。

この問題を修正した v6.0.1をまもなくリリースする予定です。