システム開発のハイライトと言えばテストです。シナリオをこなすのも大変ですし、見つかったバグの管理であったり、どうにもならない場合のお客様との調整などを考えると非常に苦しい時間であり、また複雑さをコントロールする中で醍醐味を感じる部分でもあります。

そのテストを考えるのは設計や開発と同じくらいクリエイティブな活動であると思います。テストの役割はその時に問題がなかったことを確認するだけにとどまるものではありません。テストの時点で、システムの挙動を把握できるようなテストデータを積み重ねて置くことにより、リリース後の障害の切り分けでテストデータが生きてくることがあります。

例えば負荷テストで想定以上の負荷をかけた場合にどのようなダウンをするかを観測しておくことができます。そこまでやっておいた場合、実際の運用で障害が発生した際に性能オーバーなのか、それとも別の要因なのかというところを切り分けやすくなります。

テストというものをそのように捉えれば、運用の場面で欲しいテストデータはどのようなものであり、それはどういったシナリオで得ることができるだろう、ということが定まります。

また、特に負荷テストでは自分が設計したシステムが自分の想定通りの負荷がかかっているか、という点も見逃せない点です。負荷をかける場合、動いていればOKとか、レスポンスが何秒以内というところがどうしても注意を惹きます。しかしながらテスト用のデータが適切でないなどの理由によっては、負荷分散やキャッシュの効果により実際に使われる場面では起こりえないような状況が表面化することがあります。

例えばコストダウンの一環として検証環境に仮想サーバを用いることがあります。本来ならば検証環境には本番と全く同等の構成が欲しいところですが、なかなかそういう訳にもいきません。仮想サーバの中には物理ディスクへのアクセスを減らすために仮想ディスクに強力なキャッシュを備えた製品がありますが、それが良い仕事をしすぎると問題です。キャッシュの効果が出やすいアプリケーションの場合、本番の物理のサーバよりも高いパフォーマンスを出してしまうというようなことが考えられます。どうしても本番データよりもテストデータのほうが単純でバラツキが小さいものになりがちですので、本番では思ったよりもキャッシュが活用されずパフォーマンスが出ないという現象につながりかねません。

そういった場合ではまず検証環境で小さな負荷テストをやっておき、どれくらい負荷がかかったかを認識します。本番環境でそれと矛盾しないような結果が確認されれば問題ないですが、それが大きく異なるような場合は現象を突き止めていく必要があると言えるでしょう。

同じように、開発環境に強い負荷をかけようとしても機器に負荷がかからないということもあります。例えばテストツールの設定が悪くて実際の負荷が発生していない、ですとか、シナリオのデータのバラツキが悪くてキャッシュだけが忙しく働き、メモリやCPUに仕事がいっていない、ですとか、そういったことが考えられます。

このような想定外を乗り越えると、開発をしながら「このアプリは1秒につき完全にユニークなリクエストを100個投げたときに、Webサーバの負荷はこれくらい、DBサーバの負荷はこれくらい」という「普通」を把握していくことができます。最終的な負荷テストの値はお客様に報告するとしても、開発の段階から積み重ねたこの「普通」の経験値はなかなか明文化することが難しいものです。『何が普通で何が普通でないか』これを把握するためにはやはりシステムに対する意地悪が必要になります。私の経験としては、そのような意地悪が得意な人には優秀な技術者の方が多いように思います。

私がシステム開発に携わっていたとき、自分の開発力にはあまり自信がありませんでした。しかし障害の切り分けと原因特定ではそこそこ良い仕事ができたというように思っています。それは論理的思考力であったり知識であったりというよりは、システムの「普段の姿」をよく観察していたことに尽きるのではないかと思っています。テストデータというと「異常が無いこと」に意識が向きがちですが、「普通」を把握するためのデータという観点もまた重要であるように思います。