プロジェクト管理やテスト工程をクラウド化する

Hudsonの下記記事を読んだ感想をメモ書き。

【元ネタ】
Hudson Selenium PluginでHudsonクラスタをSelenium Gridに - 川口耕介の日記

近年、HadoopやSeleniumなど、複数のサーバ上で動作する事が前提のツールが増えてきており、マルチコア化・クラウド絡みで、このトレンドは今後も続くと予想されます。
ところが、こういったツールはセットアップと運用保守に手間がかかるという欠点があります。
Hudsonで僕がやろうと思っている事の一つは、Hudsonのクラスタ上にこういったツールをインストールするのを簡単にすることです。
Hudsonのクラスタはインストールがとても簡単ですし、プラグインのインストールも容易なので、この環境の上に他のツールをオーバーレイすることで、手間なく様々なツールを利用できるようになります。

「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」本にラストマイル問題という話がある。

※元ネタ
プログラマの思索: Antリファクタリングカタログ

長年、継続的に機能追加されて肥大化したシステムへいかにアジャイルにリリースできるか？という「ラストマイル」問題を提示している。

XPが提示したプラクティス「継続的インテグレーション」「テスト駆動開発」は、高速・高品質な開発を可能にした。
しかし、本番環境へのデプロイ＋リリースのプロセスではその恩恵がない、と。
理由は、3つある。
一つ目は本番環境は大変高価であり、二つ目は検証が複雑で、三つ目は検証の工数が大きすぎるからだ、と。

アジャイル開発の最終目標は「バージョンのないソフトウェア」を提供することにある、と。
つまり、仕様変更の要求が発生したら、それを開発して完成したら、すぐにリリースして本番稼動できることだ、と。

この問題は、アジャイル開発が目指す最終目標につながると思う。
アジャイル開発を実践することで、いわゆる下流工程は高速・高品質な運用が可能になった。
しかしながら、上流工程や上流工程を検証するテスト工程(結合～受入テスト)が大きなボトルネックとして浮き彫りになってきたように思う。

今の僕が考えていることは下記だ。
RedmineやTracを基盤としたチケット駆動開発によって、アジャイル開発のプロジェクト管理はIT化できるし、アジャイル化できる。
テスト駆動開発や継続的インテグレーションの恩恵をあまり受けないユーザテストでは、TestLinkというテスト管理ツールを入れることで、アジャイル開発の弱点を補えると思っている。

上記の3つのラストマイル問題には、僕なら下記のように回答する。

1.本番環境は大変高価で複雑であること

僕なら、VMWareで本番環境を仮想化して、複数の環境を作っておけばいいと思う。
これによって、いつでも仮想化された環境で本番検証できる。
更に、IEやFirefoxなどのWebブラウザのバージョンごとに仮想化されたクライアント環境も作れば、リリースしたWebシステムの動作を色んな観点で検証できるようになる。

普通は、本番環境は世界中に唯一つしかないSWプロジェクトが殆どだろう。
だから、本番リリースを一度失敗すると、非常に危険になる。

仮想化の技術はVMWareの普及と共に、急速に技術革新が起こっている。
上手に使いこなせれば、テスト工程の品質Upができるだろう。

注：下記のVMWareの記事が優れているので参考にしたらいいと思う。
VMwareとっておきの使い方 － ＠IT自分戦略研究所

2.検証が複雑で難しいこと

僕なら、TestLinkでユーザテストのテストケースを一括管理し、TestLinkとSeleniumを組み合わせて、ユーザテストを自動化してしまえばいいと思う。

XPはテスト駆動開発のプラクティスを導入したが、それは単体テスト工程で威力を発揮しても、結合テストや受入テストなどでは、うまく使いこなせなかった。
受入テストでは、テストケースが全ての要件をカバーしているかという要件カバレッジの観点の方がはるかに重要だからだ。

TestLinkを導入することで、テストケースの品質を上げることができるし、上流工程でテスト計画やテストケース作成などの作業も入れるW字モデルの開発も運用できるだろうと思う。

TestLinkの最新バージョンでは、XML-RPCのAPIが提供されているので、今後、TestLinkの操作でテスト自動化も可能になるだろう。

3.検証に手間がかかること

一つのシステムをリリースできる品質までに必要なテストケースを数えたことはあるだろうか？
単体テストから結合テスト、システムテスト、受入テストに必要なテストケース数は最低でも数千～数万の桁が必要だろう。
逆に言うと、それだけのテストをこなさなければ、システムの品質を保証できない。
すると、それだけのテスト工数をどうやって確保するのか、という話になってくる。

今までは、大量のテスターを動員して、Excel上でテストケースや進捗を管理するしかなかった。

僕なら、JUnitやSeleniumをビルドに含めて、複数のHudsonを走らせて、並行ビルドしてしまえばいいと思う。
数千～数万のテストケースを自動テストする時に、数百～数千台のサーバー上でHudsonを並行に走らせられれば、受入テストを大幅に効率化できるだろう。

上記のHudson記事のよれば、複数のハードウェア、複数のプロセスでビルド作業を走らせることができるようにHudsonは改良されているようだ。

この流れは、Googleが提唱したクラウド化と同じ。
安いハードウェアを湯水のように使い、マシンパワーに物を言わせて、システム開発を推し進めて、品質を確保する。

現時点では、Hudsonの機能もまだ不十分だろうが、じきに実現されるだろう。
VMWare、TestLink、Hudsonを使えば、更にプロジェクト管理をIT化できる。

もはやIT産業も、大量のメンバーを動員して開発する労働集約的なビジネススタイルが、そろそろ成り立たなくなりつつあるのではないか？
大量の資金を使って、設備投資で大量のサーバーを準備して、マシンパワーでSW開発を大幅に効率化させる。
その時に必要な技術は、Googleが編み出したMapReduceのように、並列プログラミング、関数型プログラミングなのだろう。

昨今のビジネスがITとは切っても切れないように、SW開発のプロジェクト管理もテスト工程もIT化して、クラウド化していくのではないか。