Už je to docela dlouho, co jsem napsal poslední článek z této série DevOps. Ale je čas, abych se zaměřil na jednu z nejdůležitějších věcí v DevOps, kterou je dokumentace.
V rámci komunity DevOps to může vypadat jako velmi zřejmá aktivita, ale efektivní dokumentace je často v různých organizacích zanedbávána.
Proběhly krátké pokusy o vytvoření metodiky průběžné dokumentace. Došlo také k hnutí za vytvoření rámce DocOps, který vyšel z CA (nyní Broadcom). Navzdory původnímu slibu se DocOps nikdy neuchytil jako průmyslové hnutí.
Než se do toho ponořím dále, je nezbytné, abych krátce pohovořil o testování Black Box a White Box Testing.
Testování černé skříňky
Black Box Testing odpovídá nefunkčnímu aspektu softwaru. Nemá to nic společného s tím, jak software funguje, a zaměřuje se na aspekt použitelnosti softwaru. Abyste mohli provést test Black Box, musíte být pouze koncovým uživatelem.
Proč je takový přístup označován jako černá skříňka? Černá označuje neprůhlednost, což znamená, že k softwaru máte přístup pouze na úrovni uživatele a nemůžete se podívat na to, jak interně funguje. Know-how zdrojového kódu je v takovém případě irelevantní.
Chcete-li například provést test Black Box Firefoxu Nightly, stačí navštívit stránku Firefox Nightly Download, stáhnout, nainstalovat a spustit prohlížeč.
Jiný název pro tento typ testování je Behavioral Testing, protože jde o to, jak se software „chová“ v reálném čase.
Testování bílého pole
White Box Testing odpovídá funkčnímu aspektu softwaru. Je to všechno o tom, jak software funguje, a zaměřuje se na vývojový aspekt softwaru.
Abyste mohli provést test White Box, musíte se vydat cestou vývojáře. Proč je takový přístup označován jako White Box? Bílá označuje průhlednost, což znamená, že máte k softwaru přístup na úrovni vývojáře a můžete se podívat, jak interně funguje. Know-how zdrojového kódu je v takovém případě zásadní.
Chcete-li například provést test White Box Firefox Nightly, nejlepším místem, kde začít, je Firefox Source Docs a možná také Firefox ASan Nightly Page.
Jiný název pro tento typ testování je Code-based Testing, protože jde především o to, jak je software „kódován“ a zabudován v reálném čase.
K této poznámce:Uvědomujete si, jak důležitý může být software s otevřeným zdrojovým kódem, pokud jde o testování White Box a Black Box? Žádná neprůhlednost! Proprietární software lze testovat pouze na Black Box, protože neexistuje žádný přístup ke zdrojovému kódu. To vše má významný vliv na vytvoření kompletního manuálu pro jakýkoli software.Co je testování dokumentace?
Testování dokumentace je validační procedura dokumentace k testování funkčnosti, použitelnosti a bezpečnosti jakéhokoli vyvíjeného systémového procesu. Zajišťuje, že systém funguje přesně tak, jak je zdokumentováno.
Co je DocOps?
Na základě toho, jak DevOps funguje, je DocOps nepřetržitý proces zjednodušování, který s pečlivou účinností urychluje testování dokumentace.
Konvenčně bylo testování dokumentace vždy považováno za nefunkční formu testování černé skříňky. Ale v současné době to nemůže jen tak skončit a DocOps potřebuje zoufalý návrat.
Testování dokumentace může jít za hranice černé skříňky, protože znalost postupu pro vývoj, sestavení nebo dokonce nasazení softwaru může být také zásadním faktorem při zmírňování chyb a opravování problémů.
To také vyžaduje pečlivou dokumentaci, jak je popsáno ve zdrojových dokumentech Firefoxu (odkaz na příklad v předchozí části). Testování dokumentace proto může zahrnovat testování černé i bílé skříňky. Pokud tedy musíte provést takový postup ověřování, musíte to provést na třech úrovních:
- Testování dokumentace funkčnosti
- Testování dokumentace použitelnosti
- Testování bezpečnostní dokumentace
Testování dokumentace funkčnosti
Testování dokumentace funkčnosti je přístup White Box k systému. Ověřuje dokumentaci vytvořenou pro vývoj, sestavení a nasazení softwaru.
Testování dokumentace použitelnosti
Testování dokumentace použitelnosti je přístup Black Box k systému. Ověřuje dokumentaci vytvořenou pro stažení, instalaci a používání softwaru.
Testování bezpečnostní dokumentace
Testování bezpečnostní dokumentace je přístup k systému Black Box i White Box. Ověřuje dokumentaci vytvořenou pro provádění penetračních testů a zajištění optimálního zabezpečení softwaru a jeho systému.
Životní cyklus zlepšování dokumentace (DILC)
Efektivita testování funkčnosti, použitelnosti a zabezpečení závisí na jednoduchosti dokumentace pro každou fázi vývoje systému. Pokud se na proces dokumentace podíváte jako na systémový proces, může přijmout stejný životní cyklus vývoje systému model, který jsem navrhl a představil dříve:
Pokud se zaměříte pouze na výše uvedený diagram s ohledem na dokumentaci toho, jak provádět každý z označených úkolů, stane se souhrnně Životním cyklem zlepšování dokumentace což by neustále zkvalitňovalo celý manuál. Jak začíná vývoj softwaru, jeho dokumentace by také procházela průběžnými revizemi na základě toho, co funguje a co ne, ať je velké nebo malé.
Je nešťastné, že DocOps není v poslední době příliš prozkoumán. Software může být sám o sobě vynikající, ale bez řádné a přesné dokumentace může být zcela nepoužitelný. Zde vstupuje do hry testování dokumentace, a proto hraje stejně důležitou roli po celou dobu životnosti softwaru. Proto bude software sám o sobě vždy stejně vynikající jako jeho dokumentace, a to je základní pravda.
Když máte lepší dokumentaci, zjevně skončíte s menšími/uzavřenými problémy na GitHubu nebo jiném poskytovateli úložiště.
Závěrečné myšlenky
V souladu s tím, o čem jsem právě hovořil, je naším primárním cílem v Příručce pro Linux prozkoumat Testování funkčnosti a bezpečnostní dokumentace protože důraz je kladen především na dokumentaci serverové strany Linuxu. Je to FOSS, na druhé straně souvisí s Testováním dokumentace použitelnosti z důvodu primárního zaměření na uživatelskou zkušenost s Linuxem, snadnost použití a jednoduchost.
Životní cyklus zlepšování dokumentace může také souviset s naším neustálým úsilím udržovat naše články aktuální a zajistit, aby vše, co bylo popsáno dříve, bylo možné stále testovat a fungovat tak, jak je, což je klíčový požadavek Effective DocOps.
Doufám, že vám toto čtení bylo užitečné o tom, proč může být průběžná dokumentace navždy cílem. Sérii DevOps budu prozkoumávat dále a prozkoumat HumanOps v mém dalším článku (v této sérii). Máte-li nějaké návrhy a nápady, které byste mohli sdílet s touto sérií nebo konkrétně s tímto článkem, dejte mi prosím vědět v sekci níže.