È passato un po' di tempo da quando ho scritto l'ultimo articolo di questa serie DevOps. Ma è ora che mi concentri su uno degli elementi essenziali più cruciali in DevOps, che è la documentazione.
Potrebbe sembrare un'attività molto ovvia all'interno della community DevOps, ma la documentazione efficiente viene spesso trascurata in diverse organizzazioni.
Ci sono stati brevi tentativi di creare una metodologia di Documentazione Continua. C'era anche un movimento per creare un DocOps Framework uscito da CA (ora Broadcom). Nonostante la sua promessa iniziale, DocOps non ha mai preso piede come movimento del settore.
Prima di approfondire ulteriormente, è essenziale che parli brevemente di Black Box Testing e White Box Testing.
Test della scatola nera
Black Box Testing corrisponde all'aspetto non funzionale di un software. Non ha nulla a che fare con il funzionamento del software e si concentra sull'aspetto dell'usabilità del software. Per poter fare un test Black Box, devi solo essere un utente finale.
Perché un tale approccio viene definito Black Box? Il nero indica opacità, che indica che hai solo accesso a livello di utente al software e non puoi esaminare come funziona internamente. La conoscenza del codice sorgente in questo caso è irrilevante.
Ad esempio, per eseguire un test Black Box di Firefox Nightly, tutto ciò che devi fare è visitare la pagina di download di Firefox Nightly, scaricare, installare ed eseguire il browser.
Un altro nome per questo tipo di test è Behavioral Testing, perché si tratta di come il software "si comporta" in tempo reale.
Test della scatola bianca
White Box Testing corrisponde all'aspetto funzionale di un software. Riguarda il funzionamento del software e si concentra sull'aspetto di sviluppo del software.
Per poter fare un test White Box, devi seguire il percorso dello sviluppatore. Perché un tale approccio viene definito White Box? Il bianco indica la trasparenza, che indica che hai accesso al software a livello di sviluppatore e puoi esaminare come funziona internamente. La conoscenza del codice sorgente in questo caso è essenziale.
Ad esempio, per eseguire un test White Box di Firefox Nightly, il miglior punto di partenza è Firefox Source Docs e forse anche la pagina ASan Nightly di Firefox.
Un altro nome per questo tipo di test è Code-based Testing, perché riguarda il modo in cui il software viene "codificato" e costruito in tempo reale.
A proposito:ti rendi conto di quanto possa essere importante il software open source quando si tratta di test sia su White Box che su Black Box? Nessuna opacità! Il software proprietario può essere testato solo su Black Box perché non è possibile accedere al codice sorgente. Tutto ciò ha un effetto significativo sulla creazione del manuale completo per qualsiasi software.Che cos'è il test della documentazione?
Il test della documentazione è una procedura di convalida della documentazione per testare la funzionalità, l'usabilità e la sicurezza di qualsiasi processo sistemico in fase di sviluppo. Si assicura che un sistema funzioni esattamente come documentato.
Cos'è DocOps?
Sulla falsariga di come funziona DevOps, DocOps è un processo di semplificazione continua che accelera i test della documentazione con un'attenta efficienza.
Convenzionalmente, il test della documentazione è sempre stato considerato una forma non funzionale di test della scatola nera. Ma nell'era attuale, questo non può finire qui e DocOps ha bisogno di un ritorno disperato.
Documentazione I test possono andare oltre i limiti della Black Box perché conoscere la procedura per sviluppare, costruire o persino distribuire un software può anche essere un fattore essenziale per mitigare i bug e risolvere i problemi.
Ciò, inoltre, richiede un'attenta documentazione come descritto in Firefox Source Docs (collegato nella sezione precedente come esempio). Pertanto, il test della documentazione può coinvolgere del tutto sia il test della scatola nera che quello della scatola bianca. Quindi, se devi intraprendere tale procedura di convalida, devi farlo a tre livelli:
- Test della documentazione di funzionalità
- Test della documentazione di usabilità
- Test della documentazione di sicurezza
Test della documentazione delle funzionalità
Funzionalità Documentazione Il test è un approccio White Box al sistema. Convalida la documentazione creata per lo sviluppo, la creazione e la distribuzione del software.
Test della documentazione di usabilità
Il test della documentazione di usabilità è un approccio Black Box al sistema. Convalida la documentazione creata per il download, l'installazione e l'utilizzo del software.
Test della documentazione di sicurezza
Il test della documentazione di sicurezza è sia un approccio Black Box che White Box verso un sistema. Convalida la documentazione creata per condurre test di penetrazione e garantire la sicurezza ottimale del software e del suo sistema.
Ciclo di vita del miglioramento della documentazione (DILC)
L'efficacia dei test di funzionalità, usabilità e sicurezza dipende dalla semplicità della documentazione per ciascuna fase dello sviluppo di un sistema. Se consideri il processo di documentazione come un processo sistemico, può adottare lo stesso Ciclo di vita dello sviluppo del sistema modello che avevo progettato e presentato in precedenza:
Se ti concentri solo sul diagramma precedente per quanto riguarda la documentazione su come eseguire ciascuna delle attività etichettate, diventerebbe collettivamente un Ciclo di vita del miglioramento della documentazione che migliorerebbe continuamente la qualità del manuale completo. All'inizio dello sviluppo del software, anche la sua documentazione sarebbe sottoposta a continue revisioni in base a ciò che funziona e cosa no, grande o piccolo che sia.
È un peccato che DocOps non sia stato molto esplorato negli ultimi tempi. Il software, da solo, potrebbe essere eccellente, ma può essere reso completamente inutilizzabile senza una documentazione adeguata e precisa. È qui che entra in gioco il test della documentazione, che svolge un ruolo altrettanto importante per tutta la durata del software. Pertanto, il software da solo sarà sempre eccellente come la sua documentazione, e questa è la verità essenziale.
Quando hai una documentazione migliore, ovviamente finisci con problemi minori/chiusi su GitHub o qualsiasi altro provider di repository.
Pensieri finali
Sulla falsariga di quanto ho appena discusso, il nostro obiettivo principale in Linux Handbook è esplorare sia Test della documentazione di funzionalità e sicurezza perché l'obiettivo è principalmente documentare il lato server di Linux. È FOSS, d'altra parte, si riferisce a Test della documentazione di usabilità a causa dell'attenzione primaria all'esperienza utente, alla facilità d'uso e alla semplicità di Linux.
Ciclo di vita del miglioramento della documentazione può anche essere correlato al nostro continuo tentativo di mantenere aggiornati i nostri articoli e garantire che tutto ciò che è stato trattato in precedenza possa ancora essere testato e funzionare così com'è, il che è un requisito chiave di DocOps efficaci.
Spero che tu abbia trovato utile questa lettura sul perché la documentazione continua può essere un obiettivo per sempre. Esplorerò la serie DevOps più avanti ed esplorerò HumanOps nel mio prossimo articolo (in questa serie). Se hai suggerimenti e pensieri da condividere relativi a questa serie o a questo articolo in particolare, faccelo sapere nella sezione seguente.