このDevOpsシリーズの最後の記事を書いてからかなり時間が経ちました。しかし、DevOpsで最も重要な要素の1つであるドキュメントに焦点を当てるときが来ました。
DevOpsコミュニティ内での非常に明白な活動のように感じるかもしれませんが、効率的なドキュメントはさまざまな組織で無視されることがよくあります。
継続的なドキュメントの方法論を作成するための簡単な試みがありました。 CA（現在のBroadcom）から生まれたDocOpsフレームワークを作成する動きもありました。当初の約束にもかかわらず、DocOpsは業界の動きとしては決して受け入れられませんでした。
さらに詳しく説明する前に、ブラックボックステストとホワイトボックステストについて簡単に説明することが重要です。
ブラックボックステストは、ソフトウェアの非機能的側面に対応しています。それはソフトウェアがどのように機能するかとは何の関係もなく、ソフトウェアの使いやすさの側面に焦点を合わせています。ブラックボックステストを実行できるようにするには、エンドユーザーである必要があります。
なぜそのようなアプローチはブラックボックスと呼ばれるのですか？黒は不透明度を示します。これは、ソフトウェアへのユーザーレベルのアクセス権しかなく、ソフトウェアが内部でどのように機能するかを調べることができないことを示します。このような場合のソースコードのノウハウは関係ありません。
たとえば、Firefox Nightlyのブラックボックステストを実行するには、Firefox Nightlyダウンロードページにアクセスし、ブラウザをダウンロード、インストール、実行するだけです。
このタイプのテストの別名は、ソフトウェアがリアルタイムで「動作」する方法に関するものであるため、動作テストです。
ホワイトボックステストは、ソフトウェアの機能面に対応しています。それはすべて、ソフトウェアがどのように機能するかについてであり、ソフトウェアの開発の側面に焦点を当てています。
ホワイトボックステストを実行できるようにするには、開発者の道をたどる必要があります。なぜそのようなアプローチはホワイトボックスと呼ばれるのですか？白は透明性を示します。これは、ソフトウェアへの開発者レベルのアクセス権があり、ソフトウェアが内部でどのように機能するかを調べることができることを示します。このような場合のソースコードのノウハウは不可欠です。
たとえば、Firefox Nightlyのホワイトボックステストを実行するには、FirefoxSourceDocsとFirefoxASanNightlyPageを開始するのが最適です。
このタイプのテストの別名は、コードベースのテストです。これは、ソフトウェアがどのように「コード化」され、リアルタイムで構築されるかがすべてであるためです。
そのメモについて：ホワイトボックステストとブラックボックステストの両方に関して、オープンソースソフトウェアがどれほど重要であるかを理解していますか？不透明感はまったくありません！ソースコードにアクセスできないため、プロプライエタリソフトウェアはブラックボックスでのみテストできます。これはすべて、ソフトウェアの完全なマニュアルの作成に大きな影響を及ぼします。ドキュメントテストは、開発中のシステムプロセスの機能、使いやすさ、セキュリティをテストするためのドキュメントの検証手順です。システムが文書化されたとおりに機能することを確認します。
DocOpsとは何ですか？
DevOpsの仕組みに沿って、DocOpsは継続的な簡素化プロセスであり、ドキュメントのテストを慎重に効率的に高速化します。
従来、ドキュメントテストは常にブラックボックステストの非機能形式と見なされてきました。しかし、現在の時代では、それだけで終わらせることはできず、DocOpsには必死のカムバックが必要です。
ソフトウェアの開発、構築、さらには展開の手順を知ることも、バグの軽減と問題の修正に不可欠な要素となる可能性があるため、ドキュメントのテストはブラックボックスの限界を超える可能性があります。
また、Firefox Source Docs（例として前のセクションでリンクされている）で説明されているように、注意深いドキュメントが必要です。したがって、ドキュメントテストには、ブラックボックステストとホワイトボックステストの両方を含めることができます。したがって、このような検証手順を実行する必要がある場合は、次の3つのレベルで実行する必要があります。
- 機能ドキュメントのテスト
- ユーザビリティドキュメントのテスト
- セキュリティドキュメントのテスト
機能ドキュメントテストは、システムに対するホワイトボックスアプローチです。ソフトウェアの開発、構築、展開のために作成されたドキュメントを検証します。
ユーザビリティドキュメントテストは、システムに対するブラックボックスアプローチです。ソフトウェアのダウンロード、インストール、使用のために作成されたドキュメントを検証します。
セキュリティドキュメントのテストは、システムに対するブラックボックスとホワイトボックスの両方のアプローチです。ペネトレーションテストを実施し、ソフトウェアとそのシステムの最適なセキュリティを確保するために作成されたドキュメントを検証します。
ドキュメント改善ライフサイクル（DILC）
機能、使いやすさ、およびセキュリティテストの有効性は、システム開発の各フェーズのドキュメントの単純さに依存します。ドキュメント化のプロセスを体系的なプロセスと見なすと、同じシステム開発ライフサイクルを採用できます。 以前に設計して提示したモデル：
ラベル付けされた各タスクの実行方法の文書化に関して上記の図のみに焦点を当てると、それはまとめて文書化の改善ライフサイクルになります。 これにより、完全なマニュアルの品質が継続的に向上します。ソフトウェア開発が始まると、そのドキュメントは、大小を問わず、機能するものと機能しないものに基づいて継続的に改訂されます。
最近、DocOpsがあまり検討されていないのは残念です。ソフトウェア自体は優れているかもしれませんが、適切で正確なドキュメントがないと完全に使用できなくなる可能性があります。ここでドキュメントテストが機能し、ソフトウェアの存続期間を通じて同様に重要な役割を果たします。したがって、ソフトウェア自体は常にそのドキュメントと同じくらい優れており、それが本質的な真実です。
より優れたドキュメントがあると、GitHubやその他のリポジトリプロバイダーでの問題が少なくなるか、クローズされることになります。
私が今話し合ったことに沿って、Linuxハンドブックの主な目標は機能とセキュリティドキュメントのテストの両方を調査することです。 Linuxのサーバー側の文書化に主に焦点が当てられているためです。一方、FOSSは、ユーザビリティドキュメントのテストに関連しています。 Linuxのユーザーエクスペリエンス、使いやすさ、シンプルさに主眼を置いているためです。
ドキュメントの改善ライフサイクル また、記事を最新の状態に保ち、以前に取り上げたすべてのものをテストしてそのまま機能させるという継続的な試みにも関連している可能性があります。これは、EffectiveDocOpsの重要な要件です。
この読み物が、継続的なドキュメントが永遠の目標になり得る理由についてお役に立てば幸いです。今後、DevOpsシリーズをさらに詳しく調べ、次の記事（このシリーズ）でHumanOpsを調べます。このシリーズまたは特にこの記事に関連して共有する提案や考えがある場合は、以下のセクションでお知らせください。