ドキュメントをテストする

ある意味でハイパーテキストは書物と同様で、校正が必要です。またある意味でそれはプログラムと同じく、テストをしなければなりません。少なくともドキュメントが対象としている読者グループから何人かを選び、それを読んでもらってフィードバックを受けるようにしましょう。ほかのアイデアとしては：

ドキュメントを複数の異なるブラウザで読んでみて、機種依存が無いことを確認する
読者の傾向を観察する。これはサーバーのログファイルを分析することで可能になります。ある部分が読まれていないとすると、読者は間違ったところを探している可能性があります。読者がある一定の道筋を行き来していることが分かるかもしれません。彼らが何を求めているかが推測できれば、リンク周りの手がかりをもっと使いやすく改善できるでしょう。（利用者に関する情報を削除するまでは、ログ情報は秘密扱いにすること）。
読者からの批判や提案を受け入れる用意があるかどうか、またその場合読者はどこに連絡すべきかを明記すること。
人々に、ドキュメントを使って課題を解決し、その成果についてレポートしてくれるように依頼してみる。もしうまく行かなかった場合は、人々な何を探したのか、そもそもそれはドキュメントに記述されていたかどうかを確認すること。

どの程度テストするべきか？

テストには時間がかかります。どの程度テストするかは、ドキュメントに求めるクオリティによります。読者とあなたの時間と労力のバランスを取るということです。もしドキュメントが何かのアイデアを「売る」ものなら、あるいはあなたがドキュメントを売ったりサービスを提供したりする立場なら、できるだけ読者にとって読みやすいものを作ろうとすることでしょう。もし多くの人があなたのドキュメントを読むなら、あなたが少し時間をかけることで多くの人の時間の無駄を防ぐことができるでしょう。

しかし、もしあなたが他の人は関心を持ちそうにないシステムのあまり光の当たらない部分についてドキュメントを作っていたり、あるいはとにかく何かの情報があるだけでも読者はラッキーだと思えば、テストに時間を費やする理由はありません。その情報が必要なら、目指す情報にたどり着くために少々余分な苦労をしてリンクをたどり、あなたの書いたことを理解するべきであるといってもいいでしょう。これがもっとも効率的な方法かもしれないのです。私がこの点を強調するのは、一瞬の間だけ頭に浮かび、急いでファイルに走り書きされ、後の代まで伝える必要はないという情報が非常にたくさんあるからです。このような情報は、洗練されていない形でも利用できるようになっている方が、形が整っていないからといって隠されているよりもずっと有益です。電子技術が発達する前は、出版の労力が大きいためこのような情報は日の目を見ず、クオリティの高くないものを出版するのは無益で読者を侮辱するものとみなされていたのでした。こんにちにおいては、あらゆるレベルの「出版｣が存在し、クオリティの高いものも急ごしらえのドキュメントも、いずれもそれぞれの価値を持っているのです。けれども、読者を失望させないために、こうしたものへの参照を用意するときは、ドキュメントのクオリティを明記しておくことが重要です。

サーバーのログファイルを観察すると、どのドキュメントが実際に読まれているかということが分かります。あなたの時間は、これらのドキュメントのクオリティ向上にあてることで最も有効活用されるというわけです。もちろん、ログファイルの分析自体も時間を食いますけどね。

HTMLをテストする

もしハイパーテキストの編集ソフトを使っているなら、ファイルは常に正しいHTMLで構成されているはずです。現在は、しかしながら、多くの人がHTMLファイルをテキストファイルとして編集し、マークアップを自分で挿入しています。もしあなたがそうしているなら、HTMLの文法チェッカーを通してみるとよいでしょう（W3CのHTMLについてのページからいくつかのリンクがあります）。新しいHTML生成ツールを使うときは、いちどそのアウトプットをテストしてみるのも良い考えです。クライアントリストのページには、いくつかのブラウザ（HTML編集機能をもったものもあります）へのリンクと、別のリストへのリンクがあります。