作成したマクロが正しく動作するかの前に、ExcelのVBE上で構文チェックが行なえます。

「構文エラー」とは書き込んだソースプログラムの記述誤りのことです。いろいろありますが、以下のようなケースがほとんどです。

• 宣言していない変数を使った。あるいは参照範囲外で使おうとした。
• 呼び出すプロシージャの名前違いや引数の個数、データ型違い。
• メソッドやプロパティ、関数の「スペル」を間違えた。
• そのオブジェクトには存在しないプロパティを使おうとした。
• 判断やループと「End」句との不整合。

簡単なマクロであれば「目視」でチェックできてしまいますが、数百行、数千行ものマクロを作成するようなこともあるかも知れません。
私が作ったものではいろいろな機能をツールバーで使い分けて、2万行を超えているものもありますが、それほどのものを作ってもExcel上できちんと動作するものです。

これらのほとんどは、動作させる事前にチェックすることができます。

構文チェックは、表示中のプロジェクト全体に対して行なわれます。VBE内のツールバーより「デバッグ」メニューの「...Projectのコンパイル」をクリックするだけです。



このチェックは、「お勧めの初期設定」で説明している「Option Explicit」がモジュ－ルの先頭にあることが前提となります。
既に作成済みのマクロでモジュールの先頭に「Option Explicit」の行がない場合は書き加えて下さい。複数のモジュールやクラスがある場合は各モジュールに必要です。



エラーがある場合は、最初に見つかったエラーでメッセージが表示されます。修正したら再度「...Projectのコンパイル」をクリックすることを繰り返します。何もメッセージが表示されなくなったら構文チェックは完了です。
構文チェックは記述上の誤りをチェックしてくれますが、「正しく動く」ことへの確認ではありません。一応動きはするようになったということです。後は、テストとして実際に動作させて実行結果が正しいことを確認します。
正しい操作で正しい実行結果が出ることの確認はもちろん、誤った操作でどのようになるかなどを確認して下さい。また、大量なデータや繰り返し動かした時どうなるか、桁数が大きいとどうなるかなどの確認も必要です。

あまりに多くの機能を持たせたり、機能が単純でも処理結果のバリエーションが複雑な処理では場合によって100％確証のあるテストがし切れないことがあります。このような時は、どのバリエーションは動作確認できたか、確認できていない部分がどれだけあるかを明確にしておき、実行に移した時のリスクを考えておく必要があります。
例えば、不具合の事象が見つかった時点で正しい状態に戻せるようにしておくことが1つです。これには運用に渡ったワ－クブックからVBAモジュールだけを差し替えるとか、ワークシート上の不正処理結果を正しく計算し直すなどができるように仕組んでおくことを考えます。
別の方法としては、一部のユーザーに「ベータ版」として断わりを入れて配布して仮運用してもらう方法があります。Windows自体もこの方法を採っています。但し、これはいろいろな組み合わせによって予測外の影響が出ることを配慮しての動作確認であって、1つ1つの単体機能の動作検証を省略してしまうことの助けにはなりません。