Webサイトのテストについて，前回に引き続き，もう少し掘り下げてみたいと思います。

　画面キャプチャを中心にした「テスト集計」は，画像ファイルを地道に整理すればよいので取り扱いは比較的ラクです。しかし修正することを考えると，ソースが見えたり，編集できる状態のテスト結果を残せたほうが開発の生産性を高めます。今回，紹介するのは，まだ完成の域には達していない我流の方法ですが，ご参考になれば幸いです。

コンテンツとレイアウトの分離のもたらすもの

　Webサイト開発の方法論では，「コンテンツとレイアウトの分離」が開発生産性を語るうえで避けられないテーマでした。エンジニアとデザイナーが共存する開発現場において，互いのスキルを衝突させずに最高の結果を引き出すためには，この「分離」可能な設計をしておくことが，システム色が強いWebサイトほど必要とされてきました。

テストすべき項目の概念

　その流れは，動的ページ開発という段階に入った時点でさらに複雑になっていきます。ユーザーの入力した情報や表示しようとしている情報に依存して，レイアウトを変更したほうが良いと思われる場面が増えたためです。こうした状況で行われるWebサイトのテストは，同様に複雑にならざるを得なくなっていきます。

　エンジニアリングの世界では，複雑な機能は複数の小さな機能を組み合わせて実装するので，一つひとつの小さな機能を検証（テスト）する「単体テスト（ユニット・テスト）」をまず最初に行います。その単体テストが合格していることを前提に，機能を組み合わせて「結合テスト」を行うのです。

　実は，Webデザインの世界でも同じようなワークフローができつつあります。

　画面を構成する部品（ユニットやパーツ）を切り出して，Cascading Style Sheets（CSS）の設計やブラウザ依存性などを検証する工程は，単体テストに当たります。これは，レイアウトのデザインをする時点で必須といえる作業です。そして，複雑なレイアウトや大規模なWebサイトになるほど，それらのIDやclass設計がわかりやすく，適応しやすく，複数のチームメイトの中で確実に実施できる「体系」となっていることが求められます。

　度重なるWebサイトの仕様変更に耐えられるように設計する，というのも常識化し始めています。従来の“仕様を固めてその通りに作る”というウォータフォール型の開発は，できあがったときに人々に受け入れられるかという観点上，弱点を持つからです。その意味では，Webサイトの規模の大きさや複雑さに関係なく，レイアウトの単機能は美しく体系化されている必要性があるとも言えます。

[Win/Mac]　Firefox＋ScrapBook

　そこで，私が最近試しているのが，Firefoxと，その拡張機能であるScrapBookの組み合わせです。長所はWindowsでもMacintoshでも使えること。そして，HTMLソースの保存や，異種ブラウザでも（やる気になれば）検証可能な点です。

　Firefoxをインストールし，ScrapBookを機能拡張すると，右クリックでWebページの保存ができるようになります。「Alt＋K」で，ブラウザ左側に一覧表が表示されるので，そこで情報を整理することも可能です。保存（スクラップ）したWebページは，内部的にはRDFで管理されていて，自分のPC内（ローカル）に保存されるのと同時に，オリジナルのURLも記録されます。このローカルに保存されたURLを，そのままInternet Explorer（IE）などに入れれば，IEでの表示確認もできるというわけです。

　さて，テスト方法ですが，個人的には二つの方向性で記録を残します。一つは機能ごと，もう一つは時系列での記録です。

　Webサイトは，（仕様の揺れを許容すればするほど）時間とともに変化するので，「時間（いつその状態だったのか）」という概念は非常に大切です。また，開発時には「デグレーション（修正した個所が，他の修正をしている間に元の良くない状態に戻ること）」も起こる可能性があります。したがって，「機能ごとの記録」は設計コンセプトの確認用，「時系列ので記録」は時間とともに成熟していく記録（証拠）として活用しています。

　ScrapBook自体は，仕事関係だけでなく，社内連絡のメモやニュースのスクラップにも使っているので，「プロジェクト（画面上は「Proj」）」フォルダを独立させて作ります。そして，その中にプロジェクト単位で「子フォルダ（画面では「Proj-001」)」を作成し，その中でさらに機能別と時系列別に分けていきます。

　機能別の切り出し方は，そのWebサイトの特徴によって様々です。ECサイトのような決済系であれば，どうしてもお金にかかわる部分のチェックは重くなるので特別に注意が必要でしょうし，トップページのデザインが最重要なキャンペーン系のサイトでは，フロントまわりの1ピクセルのズレにも気がつくように記録すべきでしょう。

　この方法は，ほかにも初期デザイン（まだロジックが組み込まれていない状態のモノなど）や，競合サイトの収集に役に立ちます。気に入ったデザインや試作中のCSSなどを個人辞書的に使ってもいいでしょう。技術動向のニュースのスクラップだけではなく，実装サンプルとして気に入ったレイアウトや色使いなども記録できます。

　さらに，「Alt＋K」の後に「ツール」から「ツリーのHTML出力」を選択すれば，指定したフォルダ単位でHTMLに書き出せます。リンクされたWebページを間違えずに移動させれば，プロジェクト・チームとして，皆で情報を共有することも可能です。

　とはいえ，この方法は万能ではありません。内部でリンクされているswf（Flash）や，動画などで撮れないものもありますし，ユーザーの状態（どんな選択をしてきたかなど）に応じた画面の切り分けなどは記録しようがありません。また，何でも記録していくと，すぐにファイルが溜まるので，多少の掃除は必要でしょう。こうした多少の割り切りと，機能の限界を知る必要はありますが，かなり便利なツールといえます（まだ検証中ですが，同じ機能拡張のInternoteを使えば，画面上のどこを見ればよいかという付箋もつけられそうです）。

ツールに依存することなく，ツールを活用する

　個人的には，あまりツールに依存した開発環境を作りこむのは好きではありません。しかし，最近のオープンソースや標準化の流れを見る限り，そろそろそうしたアプローチもありなのではないかと思えてきています。開発を効率よく行うことと，テスト（検証）を効率よく行うこととはとても近いのです。

　開発作業は，最終的には個人の実装品質の高さに左右されます。大工さんなどの「手に職を持った方々」が，工具の一つひとつに注意をはらっているように，Web職人として「工具」を選びつつ，いいサイト構築を進めていく時代に入っているのかもしれません。


三井 英樹（みつい ひでき）
1963年大阪生まれ。日本DEC，日本総合研究所，野村総合研究所，などを経て，現在ビジネス・アーキテクツ所属。Webサイト構築の現場に必要な技術的人的問題点の解決と，エンジニアとデザイナの共存補完関係がテーマ。開発者の品格がサイトに現れると信じ精進中。 WebサイトをXMLで視覚化する「Ridual」や，RIAコンソーシアム，日刊デジタルクリエイターズ等で活動中。Webサイトとして，深く大きくかかわったのは，Visaモール（Phase1）とJAL（Flash版：簡単窓口モード/クイックモード）など。