Es ist schon einige Zeit her, dass ich den letzten Artikel dieser DevOps-Serie geschrieben habe. Aber es ist an der Zeit, dass ich mich auf eines der wichtigsten Dinge in DevOps konzentriere, nämlich die Dokumentation.
Es mag wie eine sehr offensichtliche Aktivität innerhalb der DevOps-Community erscheinen, aber eine effiziente Dokumentation wird in verschiedenen Organisationen oft vernachlässigt.
Es gab kurze Versuche, eine kontinuierliche Dokumentationsmethodik zu schaffen. Es gab auch eine Bewegung zur Schaffung eines DocOps-Frameworks, das aus CA (jetzt Broadcom) hervorging. Trotz seines ursprünglichen Versprechens hat sich DocOps nie als Branchenbewegung durchgesetzt.
Bevor ich weiter darauf eingehe, ist es wichtig, dass ich kurz über Black-Box-Tests und White-Box-Tests spreche.
Black-Box-Tests
Black Box Testing entspricht dem nicht-funktionalen Aspekt einer Software. Es hat nichts damit zu tun, wie die Software funktioniert, und konzentriert sich auf den Aspekt der Benutzerfreundlichkeit der Software. Um einen Black-Box-Test durchführen zu können, müssen Sie nur Endbenutzer sein.
Warum wird ein solcher Ansatz als Black Box bezeichnet? Schwarz steht für Undurchsichtigkeit, was darauf hinweist, dass Sie nur auf Benutzerebene Zugriff auf die Software haben und nicht nachsehen können, wie sie intern funktioniert. Know-how des Quellcodes ist in einem solchen Fall irrelevant.
Um beispielsweise einen Black Box-Test von Firefox Nightly durchzuführen, müssen Sie lediglich die Download-Seite von Firefox Nightly besuchen, den Browser herunterladen, installieren und ausführen.
Ein anderer Name für diese Art des Testens ist Verhaltenstest, da es darum geht, wie sich die Software in Echtzeit „verhält“.
White-Box-Tests
White Box Testing entspricht dem funktionalen Aspekt einer Software. Es dreht sich alles um die Funktionsweise der Software und konzentriert sich auf den Entwicklungsaspekt der Software.
Um einen White-Box-Test durchführen zu können, müssen Sie den Weg des Entwicklers einschlagen. Warum wird ein solcher Ansatz als White Box bezeichnet? Weiß steht für Transparenz, was darauf hinweist, dass Sie Zugriff auf Entwicklerebene auf die Software haben und sich ansehen können, wie sie intern funktioniert. Know-how des Quellcodes ist in einem solchen Fall unerlässlich.
Um zum Beispiel einen White-Box-Test von Firefox Nightly durchzuführen, ist der beste Ausgangspunkt die Firefox Source Docs und vielleicht auch die Firefox ASan Nightly Page.
Ein anderer Name für diese Art des Testens ist Code-basiertes Testen, da es darum geht, wie die Software „codiert“ und in Echtzeit erstellt wird.
In diesem Sinne:Ist Ihnen bewusst, wie wichtig Open-Source-Software sein kann, wenn es um White-Box- und Black-Box-Tests geht? Überhaupt keine Undurchsichtigkeit! Proprietäre Software kann nur von Black Box getestet werden, da kein Zugriff auf den Quellcode besteht. All dies hat erhebliche Auswirkungen auf die Erstellung des vollständigen Handbuchs für jede Software.Was ist Dokumentationstest?
Das Testen der Dokumentation ist ein Validierungsverfahren der Dokumentation zum Testen der Funktionalität, Benutzerfreundlichkeit und Sicherheit eines beliebigen systemischen Prozesses, der sich in der Entwicklung befindet. Es stellt sicher, dass ein System genau wie dokumentiert funktioniert.
Was ist DocOps?
In Anlehnung an die Funktionsweise von DevOps ist DocOps ein kontinuierlicher Vereinfachungsprozess, der das Testen der Dokumentation mit sorgfältiger Effizienz beschleunigt.
Herkömmlicherweise wurde Dokumentationstest immer als eine nicht funktionale Form des Black-Box-Tests angesehen. Aber in der aktuellen Ära kann das nicht einfach so enden, und DocOps braucht ein verzweifeltes Comeback.
Dokumentationstests können über die Grenzen der Black Box hinausgehen, da die Kenntnis des Verfahrens zum Entwickeln, Erstellen oder sogar Bereitstellen einer Software auch ein wesentlicher Faktor bei der Minderung von Fehlern und der Behebung von Problemen sein kann.
Auch das erfordert eine sorgfältige Dokumentation, wie sie in den Firefox Source Docs beschrieben ist (als Beispiel im vorherigen Abschnitt verlinkt). Daher kann das Testen der Dokumentation sowohl Black-Box- als auch White-Box-Tests insgesamt umfassen. Wenn Sie also ein solches Validierungsverfahren durchführen müssen, müssen Sie es auf drei Ebenen tun:
- Prüfung der Funktionsdokumentation
- Usability-Dokumentationstest
- Prüfung der Sicherheitsdokumentation
Test der Funktionsdokumentation
Das Testen der Funktionalitätsdokumentation ist ein White-Box-Ansatz für das System. Es validiert die Dokumentation, die zum Entwickeln, Erstellen und Bereitstellen der Software erstellt wurde.
Usability-Dokumentationstest
Das Testen der Usability-Dokumentation ist ein Black-Box-Ansatz für das System. Es validiert die zum Herunterladen, Installieren und Verwenden der Software erstellte Dokumentation.
Prüfung der Sicherheitsdokumentation
Das Testen der Sicherheitsdokumentation ist sowohl ein Black-Box- als auch ein White-Box-Ansatz für ein System. Es validiert die erstellte Dokumentation zur Durchführung von Penetrationstests und zur Gewährleistung einer optimalen Sicherheit der Software und ihres Systems.
Lebenszyklus zur Verbesserung der Dokumentation (DILC)
Die Effektivität von Funktionalitäts-, Benutzerfreundlichkeits- und Sicherheitstests hängt von der Einfachheit der Dokumentation für jede Phase der Systementwicklung ab. Betrachtet man den Prozess der Dokumentation als einen systemischen Prozess, kann dieser denselben Lebenszyklus der Systementwicklung annehmen Modell, das ich zuvor entworfen und vorgestellt hatte:
Wenn Sie sich nur auf das obige Diagramm in Bezug auf die Dokumentation konzentrieren, wie jede der gekennzeichneten Aufgaben durchgeführt wird, würde dies insgesamt zu einem Lebenszyklus zur Verbesserung der Dokumentation werden das würde die Qualität des gesamten Handbuchs kontinuierlich steigern. Zu Beginn der Softwareentwicklung wird auch die Dokumentation ständig überarbeitet, je nachdem, was funktioniert und was nicht, wie groß oder klein es auch sein mag.
Es ist bedauerlich, dass DocOps in letzter Zeit nicht viel erforscht wird. Software an sich mag ausgezeichnet sein, aber sie kann ohne ordnungsgemäße und genaue Dokumentation vollständig unbrauchbar gemacht werden. Hier kommt der Dokumentationstest ins Spiel und spielt daher während der gesamten Lebensdauer der Software eine ebenso wichtige Rolle. Daher ist Software an sich immer so exzellent wie ihre Dokumentation, und das ist die grundlegende Wahrheit.
Wenn Sie eine bessere Dokumentation haben, haben Sie offensichtlich weniger/geschlossene Probleme auf GitHub oder einem anderen Repository-Anbieter.
Abschließende Gedanken
In Anlehnung an das, was ich gerade besprochen habe, ist unser Hauptziel bei Linux Handbook, sowohl Funktionalitäts- als auch Sicherheitsdokumentationstests zu untersuchen weil der Fokus hauptsächlich auf der Dokumentation der Serverseite von Linux liegt. FOSS dagegen bezieht sich auf Usability Documentation Testing aufgrund des primären Fokus auf Linux-Benutzererfahrung, Benutzerfreundlichkeit und Einfachheit.
Lebenszyklus der Dokumentationsverbesserung kann auch mit unserem kontinuierlichen Versuch zusammenhängen, unsere Artikel auf dem neuesten Stand zu halten und sicherzustellen, dass alles, was früher behandelt wurde, immer noch getestet werden kann und unverändert funktioniert, was eine Schlüsselanforderung von Effective DocOps ist.
Ich hoffe, Sie fanden diese Lektüre hilfreich darüber, warum kontinuierliche Dokumentation ein ewiges Ziel sein kann. Ich werde die DevOps-Reihe weiter untersuchen und HumanOps in meinem nächsten Artikel (in dieser Reihe) untersuchen. Wenn Sie Vorschläge und Gedanken zu dieser Serie oder insbesondere zu diesem Artikel haben, teilen Sie mir dies bitte im Abschnitt unten mit.