新任のFedoraテストリード、仕事に取り掛かる
Woodsは、Red Hatの社内テストツールをFedoraに導入することと、Fedora内における正式なテスト手続きを体系化することで、このような排斥の根を断ちたいと考えている。この目標を達成することで、もっと大規模なテストを徹底的に行うようフリーソフトウェアコミュニティ全体を仕向けることができると期待しているのだ。
Woodsは、品質保証の専門家になるつもりはなかった。最初にCompaqとIBMでテストの手ほどきを受け、そこで十分経験を積んだ彼を2年前に雇ったRed Hatは、テストの自動化ツールを開発する人材を求めていた。「それが、たまたま得意なことだったに過ぎない。まあ、私はこの仕事に突然はまったようなもので、結果的にそれがうまくいったということだ」
Red Hat在職中、Woodsは同社の品質保証の急速な進化を目の当たりにしてきた。「そこに問題があることは誰の目にも明らかだったが、RHEL向けにリリースしてきた製品の品質がどんどん高くなっていることを実感した」
Woodsは、この改善が概ね自動化の進展によるものだと考えている。RHELの各バージョンのサポート期間が7年、更新が年4回、対応アーキテクチャが7種類との数値を挙げながら、「テストすべき製品の分量が信じがたい速度で増大しているが、まだ余裕がある。我々が進めてきた自動化のおかげだと思う」と語る。
しかし、この改善はFedoraにはまだほとんど及んでいない。現在のところ、「Fedoraのテストは、その場しのぎ的だ」と彼は認める。「テストすべき項目の一覧がFedora wikiに掲載され、それを残らずテストする体制にはなっているが、公式のものでない」
新しい地位に就いたWoodsの課題は、この状況を変えることだ。「Red Hatから給料を貰っているが、基本的に私はFedoraプロジェクトのためにだけ働いている」
Red Hatの社内ツールへの一本化
5月に開催されたRed Hat Summit 2006での発表に従い、Red Hatは同社の社内テストツールを108プロジェクトの名の下でフリーソフトウェアコミュニティに公開しようとしている。新しい地位に就いたWoodsの最初の仕事は、これらのツールをFedoraの開発に導入することだ。Woodsによれば、RHELから上流へテストを改善するのはRed Hatの業務の流れから当然のことだが、これはツールをコミュニティに導入する方策の1つでもあるという。「Fedoraプロジェクトに導入すれば、オープンソースコミュニティの一部となり、他のディストリビューションやオープンソースプロジェクトで利用できるようになる」
WoodsがFedoraに導入しようと考えているツールの1つにdogtailがある。Pythonで記述されたGUIテストツールであり、テストを自動化するフレームワークを提供するものである。この基本ソフトウェア自体は先のSummitより以前から無料で提供されていたが、今回Red Hatは社内で使用しているスクリプトの一部をdogtailと共に公開しようとしている。
さらに重要な点は、まもなく「Red Hat Test System」と改名されるものをRed Hatが公開することだ。「これはエンタープライズ版のすべてのLinux製品の開発で使われている自動テストシステムであり、我々が実務で手に入れることができるほぼすべてのものである。ビルドしたツリーで我々が必ず実行する回帰テストと機能性テストで構成される。私に与えられた最初の課題は、この自動テストスイートの穴を塞ぐことだ」とWoodsは言う。彼の説明によれば、これらの社内テストの中にはRed Hatの提携先の資産がふくまれているからだ。この最初の作業が完了した段階でWoodはFedoraに完全に特化したテストラボをRed Hat社内に立ち上げることになっている。
Woodsにとって、これらのテストツールを一般に供することは、Fedoraばかりでなくフリーソフトウェアコミュニティ全体のテスト手続きを改善する極めて重要な一歩である。「フリーの開発ツール全体を俯瞰したとき、これらのツールの意義は単にソフトウェアのテストにとどまらない。フリーソフトウェアコミュニティにおけるテストの現状は、diffのような基本的なツールさえ整備されていない開発現場のようなものだ」と彼は言う。
「余裕のある人は同じ事態を招かないものだ。よりよいツールを提供できれば、事態は変わる。それこそ我々が取り組むべきことなのだ」
Fedoraのテスト手続きの体系化
Woodsによれば、Fedora Testingプロジェクトへの参加に関心を示しているのは、今のところほんの一握りの人々である。彼はそれらの熱心なテスターの参加を歓迎しており、彼らの参加がテスト計画の策定や自動化ツールの改善に役立つものと期待している。しかし、ディストリビューションのリリースに必要なテスト量を考えると、それらのテスターだけで必要な作業はこなせないと思っている。
同時にWoodsは、さらに多くの人々を参加させることが難しいこともわかっている。「ソフトウェアのテストは魅力的な仕事とは到底言い難い」と彼は素直に認める。「テスト好きのLinus Torvaldsなどいないし、それが自覚されることもない」
Woodsは、テストに参加する障壁が開発のそれよりずっと低いことにテスト要員補充の望みをかけている。「ソフトウェアを使用することは同時にそれをテストすることでもある」と彼は言う。彼の目標は、Fedoraコミュニティの多くのメンバが、ほんのわずかな時間でもテスト計画の実施に貢献するよう仕向けることだ。
「私が望むのは、正式のソフトウェアテストに入る障壁を低くすることだ。我々がすべきことは、例えば、適当なWebサイトにテスト計画一式を置き、そこでユーザーが個々のアプリケーションをテストできるような体制を整えることだ。各人に5分だけ貢献してもらうことができれば、その全体をまとめればよい。この方が、ロックスターのテスターが一人でテストするよりも、多くのテストが行われる余地があるだろう」
Woodsは、この種のテストがそれ自体ではフリーソフトウェア開発の場で行われている専門家による評価の役立たないことを認めている。しかし、そのことにそれほど多くの問題があるとも考えていない。「テストを積極的に間違えようとする人がいるとは思えない。たとえ間違えてもプロジェクト全体への影響は小さいので、問題にならない」と彼は言う。
時間があれば、WoodsはFedoraコミュニティのメンバにテストの重要性を教えたいとも考えているが、まだ具体的な計画は固めていない。「いずれそのときが来る」と彼は言う。「ここで我々が述べている原則を適用しようとすると、人々にもっと多くを語ることになると思う」
ロードマップの設定
取材時点でWoodsは、Fedora Boardに正式のプロジェクトと認定してもらうために、Fedora Testingのロードマップを起草しているところだった。彼はRed Hatの社内テストの第一弾がまもなく提供できるものと考えており、この夏の終わりまでには、そのフルセットがFedora Core 6テストリリースに統合されると予想している。「基本的にはRHELと同じテストに通す予定だ」と彼は言う。Fedora Core 6のリリース後、テストラボをRed Hatの外部に移し、Fedoraコミュニティの誰もが利用できるようにするつもりだ。
Woodsは、自分がFedoraのリリースサイクルにできるだけ速やかに組み込まれることを望んでいる。「Fedoraリリースチームにはリリースのための一連のプロセスがあり、私はそのプロセスに関係しなくても最終的には少なくとも通知をもらえると期待している。テストがうまくいく見込みがまるでなければ、私はそのことを知らせるつもりだ。予定を変更したり、それを受け入れたりするのはコミュニティの利益を考えて行うべきだ」
SlashdotでFedoraを排斥する人々とは反対に、WoodsはテストによってFedoraのリリースが遅れても、Red Hatから圧力を受けることはないと予想する。「無論、RHELへの義務はないが、多くのコードが共通するので、Fedoraに問題ありとなればRHELにも問題があることになる。したがって、Fedoraで発見された問題が予定の変更を引き起こすほど重大なものなら、Red Hat側のテストと開発組織の編成に全力を注いで問題に取り組むことになる。それゆえ、私は巨大な問題が生じるとは考えていない」
「私は人々がテストを開発の一部と考えるようになってもらいたい。これはソフトウェア工学の共通のテーマだ。何かがある段階まで成熟すると、厳密な回帰テストやそういった類のものに着手せざるを得ないのである。私はオープンソースコミュニティもそれが必要だと考える。実際、私がこれを人々に伝えるまでもない。人々はテストの重要性をわかっているからだ。私の本当の目標は、テストをもっと簡単にすることだ」とWoodsは言う。Red Hatの社内テストソフトウェアをFedoraに組み込み、Fedoraのテスト手続きを厳密なものにすることで、その効果がFedoraだけでなく、フリーソフトウェア全体に及び、ついでにFedoraを誹謗する人々を、これを限りに黙らせることになればよいとWoodsは期待している。
Bruce Byfieldは講座立案者・講師を務める傍ら、コンピュータ専門誌記者としてNewsForge、Linux.com、IT Manager’s Journalに定期的に寄稿している。
NewsForge.com 原文
