Ha pasado bastante tiempo desde que escribí el último artículo de esta serie DevOps. Pero es hora de que me concentre en uno de los elementos esenciales más cruciales en DevOps, que es la documentación.
Puede parecer una actividad muy obvia dentro de la comunidad DevOps, pero la documentación eficiente a menudo se descuida en diferentes organizaciones.
Hubo breves intentos de crear una metodología de documentación continua. También hubo un movimiento para crear un DocOps Framework que salió de CA (ahora Broadcom). A pesar de su promesa inicial, DocOps nunca se convirtió en un movimiento de la industria.
Antes de profundizar más, es esencial que hable brevemente sobre las pruebas de caja negra y las pruebas de caja blanca.
Prueba de caja negra
Black Box Testing corresponde al aspecto no funcional de un software. No tiene nada que ver con el funcionamiento del software y se centra en el aspecto de usabilidad del software. Para poder hacer una prueba de Black Box, solo necesita ser un usuario final.
¿Por qué se hace referencia a este enfoque como una caja negra? El negro denota opacidad, lo que indica que solo tiene acceso a nivel de usuario al software y no puede ver cómo funciona internamente. El conocimiento del código fuente en tal caso es irrelevante.
Por ejemplo, para hacer una prueba de caja negra de Firefox Nightly, todo lo que tiene que hacer es visitar la página de descarga de Firefox Nightly, descargar, instalar y ejecutar el navegador.
Otro nombre para este tipo de prueba es Prueba de comportamiento, porque se trata de cómo se “comporta” el software en tiempo real.
Prueba de caja blanca
White Box Testing corresponde al aspecto funcional de un software. Se trata de cómo funciona el software y se centra en el aspecto de desarrollo del software.
Para poder hacer una prueba de caja blanca, debe seguir el camino del desarrollador. ¿Por qué se hace referencia a este enfoque como Caja Blanca? El blanco denota transparencia, lo que indica que tiene acceso de nivel de desarrollador al software y puede ver cómo funciona internamente. El conocimiento del código fuente en tal caso es esencial.
Por ejemplo, para hacer una prueba de caja blanca de Firefox Nightly, el mejor lugar para comenzar es Firefox Source Docs y quizás también la página Firefox ASan Nightly.
Otro nombre para este tipo de prueba es Prueba basada en código, porque se trata de cómo el software se "codifica" y construye en tiempo real.
En ese sentido:¿Se da cuenta de lo importante que puede ser el software de código abierto cuando se trata de pruebas de caja blanca y caja negra? ¡Sin opacidad en absoluto! El software propietario solo se puede probar con Black Box porque no hay acceso al código fuente. Todo esto tiene un efecto significativo en la creación del manual completo para cualquier software.¿Qué es la prueba de documentación?
La prueba de documentación es un procedimiento de validación de la documentación para probar la funcionalidad, usabilidad y seguridad de cualquier proceso sistémico en desarrollo. Se asegura de que un sistema funcione exactamente como está documentado.
¿Qué es DocOps?
En la línea de cómo funciona DevOps, DocOps es un proceso de simplificación continua que acelera las pruebas de documentación con una cuidadosa eficiencia.
Convencionalmente, las pruebas de documentación siempre se han considerado como una forma no funcional de pruebas de caja negra. Pero en la era actual, eso no puede terminar ahí, y DocOps necesita un regreso desesperado.
Las pruebas de documentación pueden ir más allá de los límites de Black Box porque conocer el procedimiento para desarrollar, construir o incluso implementar un software también puede ser un factor esencial para mitigar errores y solucionar problemas.
Eso, también, requiere una documentación cuidadosa como se describe en Firefox Source Docs (vinculado en la sección anterior como ejemplo). Por lo tanto, las Pruebas de Documentación pueden involucrar tanto Pruebas de Caja Negra como de Caja Blanca juntas. Entonces, si debe realizar un procedimiento de validación de este tipo, debe hacerlo en tres niveles:
- Pruebas de documentación de funcionalidad
- Pruebas de documentación de usabilidad
- Pruebas de documentación de seguridad
Pruebas de Documentación de Funcionalidad
La prueba de documentación de funcionalidad es un enfoque de caja blanca hacia el sistema. Valida la documentación creada para desarrollar, construir e implementar el software.
Pruebas de documentación de usabilidad
La prueba de documentación de usabilidad es un enfoque de caja negra hacia el sistema. Valida la documentación creada para la descarga, instalación y uso del software.
Pruebas de documentación de seguridad
La prueba de documentación de seguridad es tanto un enfoque de caja negra como de caja blanca hacia un sistema. Valida la documentación creada para realizar pruebas de penetración y garantizar la seguridad óptima del software y su sistema.
Ciclo de vida de mejora de la documentación (DILC)
La efectividad de las pruebas de funcionalidad, usabilidad y seguridad depende de la simplicidad de la documentación para cada fase del desarrollo de un sistema. Si considera el proceso de documentación como un proceso sistémico, puede adoptar el mismo ciclo de vida de desarrollo del sistema modelo que había diseñado y presentado anteriormente:
Si solo se enfoca en el diagrama anterior con respecto a la documentación de cómo realizar cada una de las tareas etiquetadas, se convertiría colectivamente en un Ciclo de vida de mejora de la documentación. que mejoraría continuamente la calidad del manual completo. A medida que comienza el desarrollo de software, su documentación también pasa por revisiones continuas basadas en lo que funciona y lo que no, sin importar si es grande o pequeño.
Es lamentable que DocOps no se esté explorando mucho en los últimos tiempos. El software, por sí solo, puede ser excelente, pero puede volverse completamente inutilizable sin la documentación adecuada y precisa. Aquí es donde entran en juego las pruebas de documentación y, por lo tanto, desempeñan un papel igualmente importante a lo largo de la vida útil del software. Por lo tanto, el software por sí solo siempre será tan excelente como su documentación, y esa es la verdad esencial.
Cuando tiene mejor documentación, obviamente termina con problemas menores/cerrados en GitHub o cualquier otro proveedor de repositorio.
Pensamientos finales
En la línea de lo que acabo de discutir, nuestro objetivo principal en el Manual de Linux es explorar las pruebas de documentación de funcionalidad y seguridad porque la atención se centra principalmente en documentar el lado del servidor de Linux. Su FOSS, por otro lado, se relaciona con Pruebas de documentación de usabilidad debido al enfoque principal en la experiencia del usuario de Linux, la facilidad de uso y la simplicidad.
Ciclo de vida de mejora de la documentación también puede estar relacionado con nuestro intento continuo de mantener nuestros artículos actualizados y garantizar que todo lo que se cubrió anteriormente se pueda probar y funcione tal como está, lo cual es un requisito clave de DocOps eficaz.
Espero que haya encontrado útil esta lectura sobre por qué la documentación continua puede ser un objetivo permanente. Exploraré la serie DevOps más adelante y exploraré HumanOps en mi próximo artículo (en esta serie). Si tiene sugerencias e ideas para compartir relacionadas con esta serie o este artículo en particular, hágamelo saber en la sección a continuación.