PictMaster v2.7.1 をリリースしました。
先日リリースした PictMaster v2.7 に、環境設定で「制約表を使用」をチェックしていなくても、制約表に記入された制約が有効となっていたバグのあることが分かりました。
v2.7.1 は、このバグを修正したバージョンです。以下のサイトからダウンロードすることができます。
https://sourceforge.jp/projects/pictmaster/
前バージョンをダウンロードされた方は、お手数ですが最新のv2.7.1 をダウンロードされるようお願い致します。
m(_ _)m
v2.7.1 は、このバグを修正したバージョンです。以下のサイトからダウンロードすることができます。
https://sourceforge.jp/projects/pictmaster/
前バージョンをダウンロードされた方は、お手数ですが最新のv2.7.1 をダウンロードされるようお願い致します。
m(_ _)m
PictMaster v2.7 をリリースしました。
組み合わせテストケースをオールペア法で自動生成するツール PictMaster v2.7 をリリースしました。
以下のサイトsourceforge.jpからダウンロードすることができます。
https://sourceforge.jp/projects/pictmaster/
おもな変更点は、
確認表で、異なる一致条件で同じ確認内容となる指定ができなかったバグを修正しました。これで確認表が使いやすくなったと思います。
その他にデフォルトの外観と機能をシンプルなものにしました。デフォルトの外観は、これ以上シンプルにできないほどシンプルにしました。モデルに制約がなく、確認表を使いたい場合に制約表を表示させないことができるので、使いやすいのではないかと思います。機能も組み合わせを生成するという必要最低限の機能しか働かない設定にしてあります。その他の機能も動作させたい場合は、環境設定で必要な機能を指定してください。
今回のデフォルトのモデルには、値としてエイリアスと無効値が含まれています。環境設定で「確認表を使用」にチェックを入れて確認内容を出力させた場合、出力結果がエイリアスの処理を行なっていることに注意してください（バグではありません）。
詳しい変更点は以下のとおりです。
【機能改善】
・確認表と同じように、制約表の記入内容を無効とし、表示しない設定を可能とした。
・PictMasterでエラーを検出した場合、エラー箇所が自動的に選択状態とされるようにした。
・確認表の確認内容欄を8列の幅から4列の幅に変更した。
【バグ修正】
・確認表で、異なる一致条件で同じ確認内容となる指定ができなかったバグを修正した。
・最少テストケース生成に24時間以上かかった場合、表示される経過時間が正しくないバグを修正した。
・その他、ごく軽微なバグの修正。
【その他】
・ユーザーズマニュアルの「PictMaster使用規定」でのライセンスに関する矛盾した記述を修正した。
以上です。
以下のサイトsourceforge.jpからダウンロードすることができます。
https://sourceforge.jp/projects/pictmaster/
おもな変更点は、
確認表で、異なる一致条件で同じ確認内容となる指定ができなかったバグを修正しました。これで確認表が使いやすくなったと思います。
その他にデフォルトの外観と機能をシンプルなものにしました。デフォルトの外観は、これ以上シンプルにできないほどシンプルにしました。モデルに制約がなく、確認表を使いたい場合に制約表を表示させないことができるので、使いやすいのではないかと思います。機能も組み合わせを生成するという必要最低限の機能しか働かない設定にしてあります。その他の機能も動作させたい場合は、環境設定で必要な機能を指定してください。
今回のデフォルトのモデルには、値としてエイリアスと無効値が含まれています。環境設定で「確認表を使用」にチェックを入れて確認内容を出力させた場合、出力結果がエイリアスの処理を行なっていることに注意してください（バグではありません）。
詳しい変更点は以下のとおりです。
【機能改善】
・確認表と同じように、制約表の記入内容を無効とし、表示しない設定を可能とした。
・PictMasterでエラーを検出した場合、エラー箇所が自動的に選択状態とされるようにした。
・確認表の確認内容欄を8列の幅から4列の幅に変更した。
【バグ修正】
・確認表で、異なる一致条件で同じ確認内容となる指定ができなかったバグを修正した。
・最少テストケース生成に24時間以上かかった場合、表示される経過時間が正しくないバグを修正した。
・その他、ごく軽微なバグの修正。
【その他】
・ユーザーズマニュアルの「PictMaster使用規定」でのライセンスに関する矛盾した記述を修正した。
以上です。
協力会社の人たちへの教育
テスト作業には波があり、繁忙期とそうでないときとで大きな差が出る場合があります。そのため、繁忙期になると協力会社の人たちにテスト担当者になってもらうことがあります。
例えば、携帯電話のテストでは、新製品が出るたびに100～200人位でテスト担当者がテストを行なうと聞いたことがあります。これは私の推測に過ぎませんが、携帯電話のテストは端末の操作が中心で、テスト仕様書に書いてあるとおりに行なえば特別な知識は必要とされないと思われます。
一方、それとは異なる組み込み機器、「システム」が関係する組み込み機器では、特別な用語が多く、テスト担当者にシステムの成り立ちと用語の意味などの特別な知識を理解してもらう必要があります。それと実際の機器との関連はマニュアルの説明だけでは理解が困難です。
協力会社の人たちをテスト担当者として採用した場合、テスト作業に関する「教育」が大きな問題となることがあります。
人数が少ない場合は、マンツーマンで教育できますが、大規模なテストでは多数の協力会社の人たちが、採用時期が異なってテストチームに入ることになります。こうした場合、マンツーマンでは対応しきれません。
このような場合、先に採用した人たちをマンツーマンで教育し、その人たちが、次に採用された人たちをマンツーマンで教育する、というサイクルを繰り返すことにします。こうすることで、多数の協力会社の人たちに、テスト作業に必要な最低限の必要なスキルを身に付けてもらうことができます。また、この方法により、テスト担当者間のチームワークも高めることができます。
例えば、携帯電話のテストでは、新製品が出るたびに100～200人位でテスト担当者がテストを行なうと聞いたことがあります。これは私の推測に過ぎませんが、携帯電話のテストは端末の操作が中心で、テスト仕様書に書いてあるとおりに行なえば特別な知識は必要とされないと思われます。
一方、それとは異なる組み込み機器、「システム」が関係する組み込み機器では、特別な用語が多く、テスト担当者にシステムの成り立ちと用語の意味などの特別な知識を理解してもらう必要があります。それと実際の機器との関連はマニュアルの説明だけでは理解が困難です。
協力会社の人たちをテスト担当者として採用した場合、テスト作業に関する「教育」が大きな問題となることがあります。
人数が少ない場合は、マンツーマンで教育できますが、大規模なテストでは多数の協力会社の人たちが、採用時期が異なってテストチームに入ることになります。こうした場合、マンツーマンでは対応しきれません。
このような場合、先に採用した人たちをマンツーマンで教育し、その人たちが、次に採用された人たちをマンツーマンで教育する、というサイクルを繰り返すことにします。こうすることで、多数の協力会社の人たちに、テスト作業に必要な最低限の必要なスキルを身に付けてもらうことができます。また、この方法により、テスト担当者間のチームワークも高めることができます。
テスト設計のコスト
テスト設計では、テスト仕様書の作成がメインの作業となりますが、テスト仕様書の作成にかけるコストをテスト工程全体のコストに対してどのくらいの割合にするかでいくつかのやり方があると思います。
（１）テスト設計の工数を少なく抑えて、テスト実施に多くの工数を配分するという方法。
（２）テスト設計に十分な工数をかけて、テスト実施の工数は（１）に比較して相対的に低く抑えるという方法。
（１）のテスト設計の工数を抑えるという方法は、テスト実施に専門的な知識を必要としない場合に可能な方法です。テスト仕様書にはテスト実施のための条件を細かく記述する必要がないからです。または、テスト実施が専門的な知識を必要とする場合でも、テスト担当者がその知識を備えている場合は、テスト仕様書は省略した記述で済ますことができます。
（２）のテスト設計に十分な工数をかけるという方法は、テスト実施に専門的な知識を必要とされ、かつテスト担当者に専門的知識が十分でない場合にとられる方法です。
テスト設計にかかるコストは当然ながら（２）が多くなります。しかし、（２）の条件の場合に（１）のようにテスト設計の工数を抑えてしまうと、テスト実施の段階でさまざまな問題が発生し、トータルでのコストが大きくなってしまうでしょう。テスト担当者が誤った方法でテストを実施してしまう、テスト担当者からテスト設計者への問い合わせが頻発し、テストが進まない、などといった問題です。
テスト設計者とテスト担当者が異なる場合、特にテスト担当者が専門的な知識を持っていない場合、テスト設計のコストを抑えると大きな代償を払うことになりかねません。
（１）テスト設計の工数を少なく抑えて、テスト実施に多くの工数を配分するという方法。
（２）テスト設計に十分な工数をかけて、テスト実施の工数は（１）に比較して相対的に低く抑えるという方法。
（１）のテスト設計の工数を抑えるという方法は、テスト実施に専門的な知識を必要としない場合に可能な方法です。テスト仕様書にはテスト実施のための条件を細かく記述する必要がないからです。または、テスト実施が専門的な知識を必要とする場合でも、テスト担当者がその知識を備えている場合は、テスト仕様書は省略した記述で済ますことができます。
（２）のテスト設計に十分な工数をかけるという方法は、テスト実施に専門的な知識を必要とされ、かつテスト担当者に専門的知識が十分でない場合にとられる方法です。
テスト設計にかかるコストは当然ながら（２）が多くなります。しかし、（２）の条件の場合に（１）のようにテスト設計の工数を抑えてしまうと、テスト実施の段階でさまざまな問題が発生し、トータルでのコストが大きくなってしまうでしょう。テスト担当者が誤った方法でテストを実施してしまう、テスト担当者からテスト設計者への問い合わせが頻発し、テストが進まない、などといった問題です。
テスト設計者とテスト担当者が異なる場合、特にテスト担当者が専門的な知識を持っていない場合、テスト設計のコストを抑えると大きな代償を払うことになりかねません。
テスト設計マニュアルありますか
ソフトウェア開発において、指針となるマニュアルはほとんどの企業で作成されていると思いますが、ではテスト設計についてのマニュアルは用意されているでしょうか。ソフトウェア開発マニュアルの中でテスト設計の項目が設けられている例は少ないと思います。
テスト設計をチームで行なう場合、人によってテスト仕様書の書き方が違ったり、テストの観点が異なっていては品質の良いソフトウェアはできません。
チームの全員が同じルールに基づいてテスト設計を行なうことで、一定のレベルに沿ったテスト仕様書を作成することができ、ソフトウェアの品質が確保され、テスト担当者がテストを行ないやすくなることでテストの効率も向上します。それだけにテスト設計マニュアル自体の品質が重要です。
テスト設計マニュアルには、最低でも以下の項目について規定しておかなければなりません。
（１）各種テスト技法の説明
（２）各種テスト対象が持つ性質の説明
（３）テスト対象の性質に応じて適用すべきテスト技法
（４）テスト仕様書のフォーマットと記入方法の説明
（５）テスト仕様書の改版管理の方法
新しくテスト設計チームに入った人は、必ずテスト設計マニュアルを読み、理解することをルール化しましょう。
テスト設計マニュアルは、テスト仕様書作成に際して属人的要因をできるだけ排除して、一定の品質が確保されたテスト仕様書を作成する上で必須のものです。
テスト設計をチームで行なう場合、人によってテスト仕様書の書き方が違ったり、テストの観点が異なっていては品質の良いソフトウェアはできません。
チームの全員が同じルールに基づいてテスト設計を行なうことで、一定のレベルに沿ったテスト仕様書を作成することができ、ソフトウェアの品質が確保され、テスト担当者がテストを行ないやすくなることでテストの効率も向上します。それだけにテスト設計マニュアル自体の品質が重要です。
テスト設計マニュアルには、最低でも以下の項目について規定しておかなければなりません。
（１）各種テスト技法の説明
（２）各種テスト対象が持つ性質の説明
（３）テスト対象の性質に応じて適用すべきテスト技法
（４）テスト仕様書のフォーマットと記入方法の説明
（５）テスト仕様書の改版管理の方法
新しくテスト設計チームに入った人は、必ずテスト設計マニュアルを読み、理解することをルール化しましょう。
テスト設計マニュアルは、テスト仕様書作成に際して属人的要因をできるだけ排除して、一定の品質が確保されたテスト仕様書を作成する上で必須のものです。