Cela fait un certain temps que j'ai écrit le dernier article de cette série DevOps. Mais il est temps que je me concentre sur l'un des éléments essentiels les plus cruciaux de DevOps, à savoir la documentation.
Cela peut sembler être une activité très évidente au sein de la communauté DevOps, mais une documentation efficace est souvent négligée dans différentes organisations.
Il y a eu de brèves tentatives pour créer une méthodologie de documentation continue. Il y avait aussi un mouvement pour créer un cadre DocOps qui est sorti de CA (maintenant Broadcom). Malgré sa promesse initiale, DocOps ne s'est jamais imposé comme un mouvement de l'industrie.
Avant de m'y plonger davantage, il est essentiel que je parle brièvement des tests Black Box et des tests White Box.
Test de la boîte noire
Le Black Box Testing correspond à l'aspect non fonctionnel d'un logiciel. Cela n'a rien à voir avec le fonctionnement du logiciel et se concentre sur l'aspect convivialité du logiciel. Pour pouvoir faire un test Black Box, il vous suffit d'être un utilisateur final.
Pourquoi une telle approche est-elle qualifiée de boîte noire ? Le noir indique l'opacité, ce qui indique que vous n'avez accès qu'au niveau utilisateur au logiciel et que vous ne pouvez pas examiner son fonctionnement en interne. Le savoir-faire du code source dans un tel cas n'est pas pertinent.
Par exemple, pour faire un test Black Box de Firefox Nightly, il vous suffit de vous rendre sur la page de téléchargement de Firefox Nightly, de télécharger, d'installer et d'exécuter le navigateur.
Un autre nom pour ce type de test est le test comportemental, car il s'agit de savoir comment le logiciel "se comporte" en temps réel.
Test de la boîte blanche
Le White Box Testing correspond à l'aspect fonctionnel d'un logiciel. Il s'agit de la façon dont le logiciel fonctionne et se concentre sur l'aspect développement du logiciel.
Pour pouvoir faire un test White Box, il faut emprunter le chemin du développeur. Pourquoi une telle approche est-elle qualifiée de boîte blanche ? Le blanc indique la transparence, ce qui indique que vous disposez d'un accès de niveau développeur au logiciel et que vous pouvez examiner son fonctionnement en interne. Le savoir-faire du code source dans un tel cas est essentiel.
Par exemple, pour faire un test White Box de Firefox Nightly, le meilleur endroit pour commencer est la documentation source de Firefox et peut-être aussi la page Firefox ASan Nightly.
Un autre nom pour ce type de test est le test basé sur le code, car il s'agit de la façon dont le logiciel est "codé" et construit en temps réel.
Sur cette note :Réalisez-vous à quel point le logiciel Open Source peut être important en ce qui concerne les tests White Box et Black Box ? Aucune opacité du tout ! Le logiciel propriétaire ne peut être testé qu'en boîte noire car il n'y a pas d'accès au code source. Tout cela a un effet significatif sur la création du manuel complet pour n'importe quel logiciel.Qu'est-ce que le test de documentation ?
Le test de documentation est une procédure de validation de la documentation visant à tester la fonctionnalité, la convivialité et la sécurité de tout processus systémique en cours de développement. Il s'assure qu'un système fonctionne exactement comme documenté.
Qu'est-ce que DocOps ?
Sur le modèle du fonctionnement de DevOps, DocOps est un processus de simplification continu qui accélère les tests de documentation avec une efficacité prudente.
Traditionnellement, le test de documentation a toujours été considéré comme une forme non fonctionnelle de test de boîte noire. Mais à l'ère actuelle, cela ne peut pas s'arrêter là, et DocOps a besoin d'un retour désespéré.
Les tests de documentation peuvent aller au-delà des limites de la Black Box, car connaître la procédure pour développer, construire ou même déployer un logiciel peut également être un facteur essentiel pour atténuer les bogues et résoudre les problèmes.
Cela nécessite également une documentation minutieuse, comme décrit dans la documentation source de Firefox (liée dans la section précédente à titre d'exemple). Par conséquent, les tests de documentation peuvent impliquer à la fois des tests Black Box et White Box. Ainsi, si vous devez entreprendre une telle procédure de validation, vous devez le faire à trois niveaux :
- Test de la documentation des fonctionnalités
- Test de documentation d'utilisabilité
- Test de la documentation de sécurité
Test de documentation de fonctionnalité
Le test de documentation des fonctionnalités est une approche de la boîte blanche du système. Il valide la documentation créée pour le développement, la construction et le déploiement du logiciel.
Test de documentation d'utilisabilité
Le test de documentation d'utilisabilité est une approche de boîte noire vis-à-vis du système. Il valide la documentation créée pour le téléchargement, l'installation et l'utilisation du logiciel.
Test de documentation de sécurité
Le test de documentation de sécurité est à la fois une approche de boîte noire et de boîte blanche vis-à-vis d'un système. Il valide la documentation créée pour effectuer les tests d'intrusion et assurer une sécurité optimale du logiciel et de son système.
Cycle de vie de l'amélioration de la documentation (DILC)
L'efficacité des tests de fonctionnalité, d'utilisabilité et de sécurité dépend de la simplicité de la documentation pour chaque phase du développement d'un système. Si vous considérez le processus de documentation comme un processus systémique, il peut adopter le même cycle de vie du développement du système modèle que j'avais conçu et présenté plus tôt :
Si vous vous concentrez uniquement sur le diagramme ci-dessus en ce qui concerne la documentation de la manière d'effectuer chacune des tâches étiquetées, il deviendrait alors collectivement un Cycle de vie d'amélioration de la documentation qui améliorerait continuellement la qualité du manuel complet. Au début du développement du logiciel, sa documentation subirait également des révisions continues en fonction de ce qui fonctionne et de ce qui ne fonctionne pas, qu'il soit grand ou petit.
Il est regrettable que DocOps ne soit pas beaucoup exploré ces derniers temps. Le logiciel, en soi, peut être excellent, mais il peut être rendu complètement inutilisable sans une documentation appropriée et précise. C'est là que le test de documentation entre en jeu et joue donc un rôle tout aussi important tout au long de la durée de vie du logiciel. Par conséquent, un logiciel seul sera toujours aussi excellent que sa documentation, et c'est la vérité essentielle.
Lorsque vous avez une meilleure documentation, vous vous retrouvez évidemment avec des problèmes moindres/fermés sur GitHub ou tout autre fournisseur de référentiel.
Réflexions finales
Dans la lignée de ce dont je viens de parler, notre objectif principal au Linux Handbook est d'explorer à la fois les tests de fonctionnalité et de documentation de sécurité car l'accent est mis principalement sur la documentation du côté serveur de Linux. C'est FOSS, d'autre part, concerne les Tests de documentation d'utilisabilité en raison de l'accent mis sur l'expérience utilisateur Linux, la facilité d'utilisation et la simplicité.
Cycle de vie de l'amélioration de la documentation peut également être lié à notre tentative continue de maintenir nos articles à jour et de nous assurer que tout ce qui a été couvert précédemment peut toujours être testé et fonctionne tel quel, ce qui est une exigence clé d'Effective DocOps.
J'espère que vous avez trouvé cette lecture utile sur les raisons pour lesquelles la documentation continue peut être un objectif pour toujours. J'explorerai plus loin la série DevOps et j'explorerai HumanOps dans mon prochain article (dans cette série). Si vous avez des suggestions et des réflexions à partager concernant cette série ou cet article en particulier, veuillez m'en faire part dans la section ci-dessous.