トップ回答者
.NET3.5@VS2008から、.NET3.5@VS2010 へ移行した際にどれくらいのテストが必要なのでしょうか

質問
回答
-
少しでも、開発環境変更というリスクの影響を抑えたいのであれば、何らかのテストは実施するべきでしょう。
それが全パステストなのか、軽いさわり込みにとどめるのかは、リスクをどの程度大きく見るかではないでしょうか。VB.NET であれ、C# であれ、Visual Studio 2010 のタイミングで言語仕様が拡張されています。
それに伴って、構文解析・意味解釈・コード生成の処理に多少なりの変化があること予想されます。この情報を以て、すべての人に通じる判断をすることはできません。
対象のシステムの規模、リスクが現実化したときの影響、かけられる費用などによって判断は分かれていくでしょう。
質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。- 回答としてマーク koty 2010年8月16日 4:15
-
開発・保守してるものによってはService Packどころか、セキュリティ更新プログラムでもテストプロセスは実行します。
kotyさんが開発・保守しているシステムが、どの程度テストの必要性があるかで判断するしかないと思います。
#技術というよりかは、コストを見合いながら、より政治的な判断をするしかないと思います。・重要なアプリ:お金と時間をかけて徹底的にテスト
・それほどでもないもの:各画面や機能をひと通り動かしてみる
・あまり重要でないもの:とりあえずコンパイルが通って動けばOK,あとはツールを信じる^^;質問にある全パステストがどれくらいのテストをさしているのか(条件分岐網羅?、全ての画面で各機能を動かしてみる?)定かではありませんが、何がしかのテストは必要だと思います。
#動くと思いますが、もし保守でお金を取っているのなら、テストしてなくて何かあったときの言い訳にすごく困ります。しないという選択肢は普通ないと思います。(条件分岐網羅テストまでするかと聞かれたら、よっぽどのことがない限りしませんが^^;)- 回答としてマーク koty 2010年8月16日 4:16
すべての返信
-
少しでも、開発環境変更というリスクの影響を抑えたいのであれば、何らかのテストは実施するべきでしょう。
それが全パステストなのか、軽いさわり込みにとどめるのかは、リスクをどの程度大きく見るかではないでしょうか。VB.NET であれ、C# であれ、Visual Studio 2010 のタイミングで言語仕様が拡張されています。
それに伴って、構文解析・意味解釈・コード生成の処理に多少なりの変化があること予想されます。この情報を以て、すべての人に通じる判断をすることはできません。
対象のシステムの規模、リスクが現実化したときの影響、かけられる費用などによって判断は分かれていくでしょう。
質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。- 回答としてマーク koty 2010年8月16日 4:15
-
開発・保守してるものによってはService Packどころか、セキュリティ更新プログラムでもテストプロセスは実行します。
kotyさんが開発・保守しているシステムが、どの程度テストの必要性があるかで判断するしかないと思います。
#技術というよりかは、コストを見合いながら、より政治的な判断をするしかないと思います。・重要なアプリ:お金と時間をかけて徹底的にテスト
・それほどでもないもの:各画面や機能をひと通り動かしてみる
・あまり重要でないもの:とりあえずコンパイルが通って動けばOK,あとはツールを信じる^^;質問にある全パステストがどれくらいのテストをさしているのか(条件分岐網羅?、全ての画面で各機能を動かしてみる?)定かではありませんが、何がしかのテストは必要だと思います。
#動くと思いますが、もし保守でお金を取っているのなら、テストしてなくて何かあったときの言い訳にすごく困ります。しないという選択肢は普通ないと思います。(条件分岐網羅テストまでするかと聞かれたら、よっぽどのことがない限りしませんが^^;)- 回答としてマーク koty 2010年8月16日 4:16
-
以下は、あくまで個人的な感想です。
これは作るアプリケーションにも依るとは思うのですが、開発ツールに更新があった場合、すごく怖いのは細かいロジックの動きが少しづつ変わってたりすることです。これは、大方コンパイルの時警告が出たり、エラーが出るので把握可能です。今回はライブラリは同じなので、問題ないと予想されますが、意外にユニットテストを再度行わないと見つからなかったりします。一般的に、四捨五入が銀行方式に変わるとかそんな大きな変更は、リリースノートにデカデカと書いてありますが、それでも運用してから初めて気づくなんてことも……(いちいちリリースノートを上から下まで読んでいる人がどれだけいるか^^;)
あと、これも頭を痛めるのは、便利なコントロールやサードパーティ社製のツールが新バージョンをサポートしてなかったり動きが変わってしまうこともあります。
これらは、単体テストでは発覚せず、使ってみて初めてわかる部類の違いが多かったりします以上から、私は、単体テストのみなならず、一通りの画面や機能はチェックすべきだ、という立場です。
これは、会社やアプリのポリシーなので何とも言えません。
個人的な感想としては、開発側が動くことをテストやツール会社のサポート条項などでエビデンスを出さない限り、受け入れ印は押しません。私もAzuleanさんと同じで、開発ツールなどの更新は、アプリ自身のライフサイクルに合わせることをお勧めします。
アプリ改修時なら、テストも一緒に行うでしょうから、別途テストを行うコストが削減できます。#正直、自分が個人で作って公開しているようなアプリであれば、コンパイルが通って動けばそれ以上のことはしないと思います^^;
#TDDなどで、テストクラスを作っておくと、このような時の回帰テストのときチェックがかなり楽です。
#あと、WPFにすると、アクセシビリティクラスを使って画面や機能全体のUI動作が必要なチェックも自動化のためのクラスをかけるのでとても楽。
##(たぶん、自動的なテストはエビデンスの一つにはなっても、それだけで受け入れ印押してくれるところは少ないと思いますが^^;) -