ドキュメントをテストするときに焦点を当てることができる品質のリスト：
1.スクリプトパフォーマンス
ドキュメントが持つべき最も重要な品質。 シナリオは正確に記述する必要があり、その実装は製品が作成された目標の達成につながるはずです。 代替シナリオがある場合は、それらに言及する必要があります。
2.説明の完全性
機能の各要素は、ボタン、チェックボックス、ツールチップなどのインターフェイス要素であることを意味する明らかなポイント 入力コマンド、またはアクションに対する反応を記述する必要があります。 特に、特定のメッセージが表示されたときに、ユーザーがドキュメント内でアクションのアルゴリズムを見つける必要がある場合があることに留意してください。
3.必須項目に注意を払う
必須で重要なユーザーのアクションが記載されているようなものであってはなりません。すべての必要なアクションの説明に注意を払う必要があります。 ドキュメントは、すべての追加条件が小さな活字で説明されているローン契約に似てはなりません。 たとえば、構成ファイルにピリオドの代わりにカンマがある場合、アプリケーションが起動しないという情報を明示的に書き留める価値があります。 ローン契約で、支払いが期限内に支払われない場合、金利は20％ではなく、年率300％になることが明確に述べられているように。
4.説明の関連性
多くのバージョンがあるソフトウェア製品のドキュメントをテストする場合、説明の関連性に注意する必要があります。 現在のバージョンでは機能が変更されていることが判明する場合がありますが、これはドキュメントには含まれていません。 または、最後の時点で、この機能を現在のリリースに含めないことが決定され、ドキュメントにすでに説明されています。 また、年、連絡先の詳細、システム要件、ライセンス契約、スクリーンショットの関連性にも注意を払う価値があります。
5.ユーザーが急いでいるという事実への適応
重要な品質。 ドキュメントが余暇にゆっくり読まれるということはまれです。 ほとんどの場合、人々は何かがうまくいかないときはドキュメントに目を向けます。ユーザーはドキュメントを数時間後に読む可能性があります。 ここでは、依存関係を持つアクションのチェーンの数を最小限に抑えることをお勧めします。 スクリプトの実行は、クエストの通過に似てはなりません。 スクリプトの実行に必要なすべての条件がスクリプトの前に記述されていればよいでしょう。 この類似性をもたらすことができます：レンガの壁に棚を釘付けする必要がある場合、棚に加えて、穴あけ機、ドリル、ダボ釘が必要です。
6.ユーザーがいらいらするという事実への適応
ソフトウェア製品とやり取りするときの感情的な反応は、他の人とやり取りするときの反応と非常によく似ています。 ユーザーが問題を抱えているという事実のためにドキュメントを読んだ場合、彼はおそらく腹立たしい状態にあるでしょう。 ここでは、アトミックな文と段落の作成を推奨できます。 たとえば、使用に問題がある場合は<<の代わりにアプリケーションを再インストールします。 オペレーティングシステムのコンポーネント1がインストールされ、オペレーティングシステムの設定で条件2が指定されている場合に問題が発生します。>>登録することをお勧めしますこれは再インストールによってのみ解決できます>>
7.構造性、クイック検索への適応性
ドキュメントには明確な構造が必要であり、ユーザーはその中の目次に関する情報をすばやく見つけることができなければなりません。 カメラの品質と類似点を描くことができます。単純なカメラには、このような構造的特徴が必要です。そうすれば、瞬間を逃さずにすばやく使用できます。 カメラが長時間ケースから外れて長時間オンになった場合、適切なタイミングで役に立たない可能性があります。 ドキュメントとヘルプに関して、情報の検索に時間がかかる場合、ユーザーは検索を中止できます。 彼は行動を起こす忍耐を持っていません。
8.アクションの不可逆性の兆候
ユーザーの操作が元に戻せない場合は、明示的に指定する必要があります。 たとえば、プログラム内の何かを削除した場合、それを復元することは常に不可能です。 特定のアクションを元に戻す方法に関する情報を追加することも価値があります。 たとえば、多くのデータをプログラムに取り込みたいが、それらが正しいかどうかはわかりません。設定を復元するなど、アクションを元に戻す方法を明確に示すことは価値があります）。
9.予想の確認
いくつかのアクションのシーケンスを説明した後、期待される結果を示す価値があります。 塩とスパイスをそこに加えた後、あなたがスープを試すべきであるように。
10.ユーザーアクションの欠如の結果の説明
ユーザーが必要なアクションを実行しなかった場合に起こることに関する情報をドキュメントに追加する価値があります。 たとえば、ユーザーがネットワークインターフェイスのIPアドレスを指定しない場合、このインターフェイスを介してパケットを送信できません。
11.情報の提示の明瞭さ
テストオブジェクトに最も適した用語を使用する必要があります。 特定の用語を使用する場合は、個別に説明する価値があります。 用語の二重解釈が可能な場合は、どちらを使用するかを明確にする必要があります。
12.ロジックと一貫性
シナリオは、どのアクションがどのような目的で実行されているかを示す必要があります。 実行するアクションの意味を理解する必要があります。
13.プレゼンテーションの順序
いくつかのシナリオでは、アクションのシーケンスが重要です。 たとえば、スープを調理するときは、まず水を注ぎ、次にジャガイモなどの他の材料を追加します。 最初にポテトを入れて、ずっと後に水を注ぐと、スープの代わりに食べられないものができます。
14.スペル、構文、句読点
もちろん、テキストは正しく説明する必要があります。 スペルは、MS Wordまたはその他の方法で確認できます。 構文と句読点を確認するには、テキストを読み、その意味を理解し、使用されている各用語の意味を理解する必要があります。
15.デフォルト設定の説明の可用性
設定があり、デフォルト値がある場合は、これを説明しておくといいでしょう。 ユーザーは、設定を変更したがデフォルトの設定に関する情報を見つけたいが、変更を覚えていなかったため、プログラムが正常に動作しなくなった場合があります。
16.聴衆への適応
製品が一般ユーザー向けに設計されている場合、そのマニュアルでは、ユーザーのアクションをわかりやすい用語で説明する必要があります。 製品がAppleユーザーまたはLinux管理者向けに設計されている場合、これらのユーザーの機能を検討する価値があります。 サーバーおよび管理ソフトウェアのガイドは、多くの場合、システム管理者を対象としています。
17.アトミックシナリオ
ヘルプの方が適切ですが、多くの場合、ユーザーが必要とする機能要素は1つだけです。 そして、ドキュメンテーションを完全に研究する欲求と機会はありません。 これを行わない可能性がある場合は、ユーザーに製品ニュースを強制的に学習させないでください。 たとえば、テキストエディターでフォントを変更する必要がある場合、ドキュメントでテキストエディターの履歴を調べたり、テキストエディターの機能のリストを調べたり、フォントとは何かを調べたりする必要があることをドキュメントで示すべきではありません。
18.ユーザーの最低限の資格への適応
人々は常にプログラムがどのように機能するかを尋ねるわけではありません;結果は彼らにとって重要です。 また、さまざまなユーザーが製品を使用できることを考慮する価値があります。 たとえば、高度な資格を持つシステム管理者は、製品を使用して作業の結果を指で監督に示す必要がある場合があります。 そして、監督は、示された結果が彼の活動の枠組みにおいて非常に重要であるならば、文書を調べることができます。 インターネットを開く必要があるものを理解するために、複雑な技術用語を使用するためのコストは可能な限り少なくしています。 主婦は電子レンジがどのように機能するかを知る必要はありませんが、調理することができ、金属物を中に入れてはならないことを知ることが重要です。 また、科学者とは異なり、主婦は、電子レンジに卵を入れてはならないことを知っている必要があります。
質の高いドキュメントが必要なのは誰ですか
ドキュメンテーションの品質に注意を払う人が少ないことにしばしば気づきます。 確かに、誰に利益をもたらしますか？ ソフトウェア製品の開発中に多くのチームがドキュメントを作成するのは、ドキュメントを作成するタスクが上級役員によって設定されたためだと思われます。 そして、文書の品質を保証する優先度の低下は、それが与える利益を数字で計算する方法がないという事実によるものです。 残念ながら、そのような統計を数字で提供することはできません。
文書化の利点は、住宅用の追加インフラストラクチャを作成する利点と比較できます。 一方では、住宅の面積が販売の主な役割を果たします。価格は平方あたりに設定されます。 しかしよく見ると、いくつかの家の価格は他の家の価格よりもはるかに高いです。 そして、これは主に周囲のインフラストラクチャ（駐車、エレベーター、芝生など）によるものです。
高品質のドキュメントが利用できることには利点があります：ユーザーは製品を放棄しようとせず、技術サポートの負荷が軽減され、開発チーム内で製品の機能に関する質問が少なくなり、販売が容易になります。