言葉の定義が曖昧で申し訳ないですが、V字モデルを考えた時に右上のほうにあるテストのことを想定しています。ですが、あまり厳密にシステムテストとの違いとか、パフォーマンスや負荷はとかを区別していません。「右上のほう」くらいを考えます。
要求分析 -------> 受け入れテスト
基本設計 -----> システムテスト
機能設計 ---> 結合テスト
詳細設計 -> 単体テスト
コーディング
反復的に、スパイラルになど、とにかく少しずつソフトウェアを開発していくのが、バグ発生のリスクが少ない印象があります。仕様変更にも耐えやすい。そうすると、受け入れテストが自動化されていると、容易にテストでき、要求とことなる状態になったことがすぐわかります。あるいは、要求との差異の大きさが分かります。なので、受け入れテストは自動化したほうがよいわけです。
が！ ほとんどできていません。システムテストでさえ、網羅率が非常に低いのが現状です。これだけ頭でわかっているのに、やっていないのは、なぜなんだろうと考えました。おそらく、レイヤが高いところでのテストは、投資の規模が大きくないと、便益が得られないからだ、という仮説です。
1. 実装に時間がかかる
単体テストなんかは、ほんの数行のコードを書けば、とりあえず何がしかのテストを始められます。自分だけではじめることもできます。一方で、受け入れテストはそもそも手順が多いし、前提条件を作り出すために作業やコーディングが発生します。なのでめんどくさいなぁ、と思ってしまいます。2. 実装に費用がかかる
単体テストなら開発マシンで実行するところから始められます。受け入れテストは、特にサーバで動かすときには、テスト用の環境を用意する必要です。テスト自体が副作用を生むので、他の作業から隔離する必要があるからです。3. コミュニケーションに時間がかかる
要求なるものが、要求する側とされる側で、そのまま共有できることは稀です。すくなくとも、私の職場では。何らかの形で文書の変換が必要になります。PowerPoint で「友達がつぶやいたら盛り上がっている絵」みたいなのが書かれていたとして、それを、「N秒以内に友達関係にあるユーザが、システムに対して操作Aをしたことが、画面に表示される」と翻訳しないといけません。逆に、後者だけあっても、受け入れOKを確認する人には通じません。これはけっこう難しくて、いまだに効率良く要件を記述する方法が分かりません。4. 変更の追跡に時間がかかる
関連して、変更があったときの追跡に時間がかかります。いつのまにか PowerPoint のファイルに「なんとかボタン」がひとつ追加されていたりして、そのボタンを機能させるためには、かなりの影響範囲があったりするわけです。それを追跡して仕様に反映するのだけでも大変なのに、テストとかもうああ、という。書きだしてみて、ネガティブスパイラルっぷりにびびります。解決策や結論的なものは、残念ながらまだありません。ただ、仕事の大きさに圧倒されて、手を付けられないのであるなぁ、というのが分かったというところです。
