Webサイトのテストについて，前回に引き続き，もう少し掘り下げてみたいと思います。今回は，開発が進み，実装工程からテスト工程に移った後，効率よく品質をチェックする方法を考えてみます。

　「問題」を発見してからその修正を完了するという流れを，個別の中身に立ち入らずに，「件数の増加ペース」に注目して品質の概要を捉えるという方法です。実装の現場にいる人にとっては，自分の担当部分が全体から見てどのような位置づけになるのかを認識できる場であり，マネジメントする側にとっては，全体像を数値的に把握できる場にもなります。

「ステイタス」の分類

　「問題」を発見した場合，“誰が担当して修正し，修正を報告するか”という流れを作るべきです。

　問題にはそれぞれ個別の「事情（原因）」があるので，それらに意識がいってしまうと，「木を見て森を見ず」の状態になりかねません。できる限り客観視できるように，そうした「ステイタス」の集計報告が，チーム内での品質向上を実感できる数字となります。そのステイタスは，基本的には下記の三種類だと思います。

「ステイタス」の流れ

▼起票（＝問題発見＝問題分類）
問題が発見されたという意味です。それがどういった問題であるのか，つまりどうなれば「正しい」のかがわかっている――という状態です。一人のプロジェクトでない限り，問題を適切に表現することが必須で，後でどんな問題であるのかを第三者（チーム内の誰か）が理解できる必要があります。
▼着手済み
「起票（＝問題認識）」に対して，誰かが担当を受け持ったという状態です。放置されていないことを示します。開発者が自分の領域を正しく意識しているなら，自然と着手済みに移行しますが，そうでない体制では，「交通整理役」となる問題の割り振り役が必要になります。
▼完了
問題の修正が完了したことを意味します。意味としては二つあり，一つは「修正して不具合がなくなった状態」，もう一つは「今期は実装しない」というものです。開発には無限にリソース（予算や時間）が与えられるわけではないので，このような割り切りも必要になります。

　「起票」されたすべての問題が「完了」となることが，基本的な流れです。そして，起票された「数」がそのプロジェクトで認識された「問題の数」であり，プロジェクトの開発規模によってある程度の数に達していないと，テストが不十分かもしれないと思われるものです。

「起票」の例（バグ管理システムで行う場合）

「問題」の分類

　起票の時点で，問題が分類できることが理想的だと思いますが，分類は少なくとも下記の七つになると思われます。

▼文言修正
「てにをは」の問題から，適切な用語の統一性までを含む問題です。単純なものは，開発者がその場で修正可能ですが，法的な用語や業界標準的な表現も含むこともあるので，クライアントへの確認（あるいはクライアントが作文）する必要が生じる場合もあります（ただし，その場合は時間がかかる）。
▼表示修正
コンテンツ的にも動作（挙動）的にも問題はないのに，表示の崩れや位置的に違和感を感じるような問題です。最近では，CSS（Cascading Style Sheets）の修正の問題に絞れる場合が多くなってきています。設計段階ではOKが出ていても，実データを適応させた後に，文書の長短などによってクライアントが難色を示す場合もあります。複雑なデータを組み合わせる場合には，可能な限り実データに近い状況での試作することの大切さを思い知らされる問題でもあります。
▼コンテンツ不足／説明不足
ページ構成や画面設計上は問題がなくても，実際のユーザーの立場に立ってみると，説明が不足している，あるいは不親切に感じるレベルの問題です。一般的には，コンテンツ（ページ）を増やしたり，リンクを増やしたりして対応します。ナビゲーションや，サイト全体の「深度」が変わる場合もあるので，当初のコンテンツ整理（情報デザイン）の重要性を思い知らされる問題です。
▼バグ／不具合／挙動不適切
意図した挙動をしない問題です。バグ混入（発見）の時期によって分類するなら，下記の三種が考えられます。
  1. 仕様策定時：
    仕様ロジックに問題がある場合。仕様策定時点での想定の甘さや，稼動時の状況を見誤っている場合。根本的な問題だと，全体スケジュールや，ユーザー・インターフェースの修正にまで発展する可能性がある。
  2. 実装時：
    実装に問題がある場合。単純なミスタイプや変数やその有効範囲（スコープ）の見誤りなど。設計仕様上の問題ではなく，実装段階で混入したバグ。担当開発者のスキル不足や注意力散漫，過労状況が続くプロジェクト管理の場合に多発する。
  3. 運用時：
    データに問題がある場合/そのようなデータを想定していない場合。運用上想定外のデータが混入しやすい状況であったり，当初考えなくて良かった状況も考慮しなければならなくなった場合などに発見される。基本的には，設計段階を運用現場の意見を聞かないで終了してしまった場合が多く，誰がそのシステムを日常的に管理するのか，という視点の欠如が原因となる。
　分類方法としては，開発領域単位で捉えて，「フロント」と「サーバー」等という整理の仕方をとる場合も多いと思われます。いずれにしても，Webサイト開発をソフトウエア工学の目線で見る限り，この部分の問題に関する情報が「テスト工程」の中では最重要の分野となります。
▼未実装
仕様上実装する予定になっている機能のうち，テスト開始時点で実装されていない機能です。全体を通してのテストができないという，工程管理上の問題も生む問題です。一般的には，最も利用頻度の高い「シナリオ」にこの種の問題がある状態では，「テスト工程」には入らないので，この件数の多さによってプロジェクトの進ちょく状況の遅れを読み取れます。ただし，メイン機能でありながら，実装技術の検証のために，実装を意図的に遅らせる場合もあるので，プロジェクト毎に扱いは変わります。
▼要調査
「問題」の整理がまだついていない状態です。ブラウザ依存によるものなのか，何かしらのタイミングのせいか，あるいはデータベースなどの根幹的な「製品」の問題（バグ）である可能性もあるような場合です。誰が修正できるのかを判断しかねる場合，一時的にこの項目として扱います。ただし，あくまで「一時的なもの」として認識する必要があります。そうでなければ，この項目の件数が自然と増加するからです。
▼ボツ／実装しない／次期課題／先送り
仕様策定後に出された要求など，今回の開発対象としない項目です。次回の開発の優先事項として扱うべきものとして，記録に残しますが，今期のバグ件数にはカウントしないものです。

　以上，七つの問題とステイタスの関係は，下図のようになります。問題が発見された後，担当者が「着手済み」にステイタスを変え，修正が済めば「完了」とします。完了とできないものは，基本的には「ボツ」以外はない状態で，テスト工程が終了するはずです。

「問題」と「ステイタス」の関係

バグ曲線の捉え方

　こうした問題を，時間を横軸にしてプロットしていったものが，いわゆる「バグ曲線」と呼ばれるものです。テスト工程に入ったばかりの段階（開始期）は，テスト要員がその機能を熟知していなかったり，まずは簡単なテストを行うので，発見される問題が少ないのが通常です。そのうち，込み入ったテストを行うようになると，ある程度の数の問題が発見されます。発見をできるだけ早めることができれば，修正を行う時間を稼ぐことができるということにもなります。そして，収束をできるだけ早められることが，その開発チームの「品質」や「スキル」と呼ばれるものになります。しかし，Webサイト開発においては，一つ注意しなければいけないことがあります。

バグ曲線

　それは，前述の七つの「問題」を一緒くたにして語ることの危険性です。Webサイトは，従来型のアプリケーションと違って，「表現」や「見栄え」そのものも「機能」なのです。それは，対象ユーザーが不特定多数に近くなるほど（イントラネットとは反対の方向性を持つほど），その傾向は強まります。文言修正や表示修正も，立派な問題として認識すべきです。

　しかし，修正にかかる時間（コスト）やその困難さには「差」があります。文言修正は，クライアントとのネゴさえ済めば，数秒で片付けられる問題ですが，バグ（ロジック）修正はもう少しエンジニア的な検証ステップを経る必要があります。文言修正もバグ（ロジック）修正も，同じ一件としてカウントしては，このバグ曲線から読み取れる，「品質」を見誤る可能性が高くなってしまいます。

バグ曲線(2)

　したがって，「問題」を種類別に集計する必要があるように思います。文言修正や表示修正ごとに集計を取ると，おそらくは担当する人間も違っているので，それぞれのスキルや品質が見えてきます。

　もし文言修正の件数が突出しているとしたら，仕様策定時などでのクライアントとの折衝に緻密（ちみつ）さが欠けていることを暗示しているかもしれません。表示修正が突出しているなら，ブラウザ依存性の検証が不十分だったり，CSSのスキル不足である可能性があるでしょう。バグ修正が突出しているなら，そもそものアプリケーション開発スキルの問題が見えてきます。

結論

　バグ曲線は，一回だけの開発のために作成するものではありません。類似の開発における，品質の「めど」を認識するためのツールです。曲線を適切に作成することによって，その開発チームの長所短所が見えてきます。どの程度の開発工数をかけていれば，バグの累積数がどの程度にいくのかも推測できます。そこから逆算して，テスト要員をどのように育ててテストに投入すべきかも類推できます。

　しかし，テストの効率を良くするには，やはり適切なデータ集計が必要です。適切な問題の切り分け方法と，自動的な集計手段（集計のために時間をかけるのは本末転倒です），そしてその蓄積から得られるスキルや知恵。こうしたものの集積知が，複雑化するWebサイト開発には，ますます必要になってくるように思います。


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