Liderazgo en Pruebas: Documentación
Nota del editor: Bienvenidos a la serie Liderazgo en Pruebas del experto y consultor en pruebas de software Paul Gerrard. La serie está diseñada para ayudar a testers con algunos años de experiencia—especialmente a aquellos en equipos ágiles—a sobresalir en sus roles de líderes y directores de pruebas.
En el artículo anterior, presentamos un manifiesto de riesgos para ayudar a los gerentes. En este artículo, plantearemos la clásica pregunta “¿Cuántas pruebas son suficientes?”. Spoiler: depende de los stakeholders.
Suscríbete al boletín de The QA Lead para que te avisemos cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso de Liderazgo en Pruebas de Paul, el cual recomendamos totalmente para profundizar en este y otros temas. Si te animas, usa nuestro cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso.
No importa el proyecto, organización o enfoque, siempre hay lugar para la documentación. Una buena documentación es una bendición, ya que proporciona un registro útil del enfoque, alcance, planes, diseños y los resultados de los análisis, el desarrollo y las actividades de prueba.
En este artículo, cubriré:
- El Valor de la Documentación
- Los Peligros de las Plantillas y del Copiar/Pegar
- Tipos de Documentación de Prueba
- Consejos para Diseñar Documentación
Vamos allá.
¿Quieres más de The CTO Club?
Crea una cuenta gratuita para terminar de leer este contenido y unirte a una comunidad de CTOs y líderes de ingeniería que comparten marcos, herramientas y conocimientos reales para diseñar, desplegar y escalar tecnología impulsada por IA.
Have an account? Log In
El Valor de la Documentación
En proyectos estructurados, normalmente se considera que los documentos son entregables en sí mismos. En regímenes ágiles o continuos, la documentación puede producirse como un subproducto de más o menos valor.
La redacción de documentos puede ser la actividad principal de los redactores técnicos profesionales pero, para la mayoría de los profesionales, es una tarea tediosa — por útil que pueda ser. Aunque escribir documentación puede ser aburrido para algunas personas, el verdadero problema de la documentación es que, en muchos contextos, gran parte de esta simplemente es una pérdida de tiempo. Es de poco valor, está desactualizada, es inexacta — o las tres cosas a la vez.
Todo responsable de pruebas ha escrito estrategias de prueba que la gente no lee ni hace suyas. Los testers redactan montones de planes de prueba, guiones e informes y el único contenido valioso para los interesados son los resúmenes de una página al principio o al final.
Todos hemos escrito documentos que sabemos que tienen poco valor y que nadie leerá.
Esto proviene de problemas comunes con la documentación que encontramos en proyectos grandes y pequeños. Por cada documento que escribimos, hay varias preguntas que debemos plantearnos:
- ¿Qué tipo de documento? ¿Una política o estrategia, un enfoque o plan, un diseño o implementación, o un resultado e interpretación?
- ¿Cuál es el objetivo del documento?
- ¿Qué contenido se requiere para cumplir ese objetivo?
- ¿Qué fuentes de conocimiento se requieren para crear el contenido?
- Si el documento debe actualizarse con el tiempo, ¿cómo se mantendrá?
- ¿Qué nivel de detalle se necesita?
Los Peligros de las Plantillas y del Copiar/Pegar
Si tu proyecto determina que se necesita cierto documento, como un plan de pruebas del sistema o un registro de riesgos, es tentador buscar en internet una plantilla ya preparada para estos (y muchos otros tipos de documentos).
Algunas plantillas pueden afirmar que cumplen con algún estándar o convención y que han sido descargadas y utilizadas miles de veces. A veces, una plantilla puede parecer adecuada exactamente para tu propósito. Pero, como veremos, incluso si el índice parece completo, esto puede traerte problemas.
También puede suceder que tú u otras personas en tu empresa hayan preparado un documento similar para proyectos anteriores. Puede que te tiente copiar y renombrar ese documento, cambiar las referencias al proyecto anterior y editar el contenido para adaptarlo.
Advertencia: Según mi experiencia como revisor independiente esto es muy común y, a menudo, un verdadero problema.
En primer lugar, suele ser bastante obvio cuando se ha hecho un copiar/pegar o edición. El lenguaje utilizado en el texto a menudo parece estar desconectado del proyecto y hay vacíos y texto superfluo por todas partes. ¿Por qué ocurre esto?
Utilizar una plantilla predefinida o un documento existente como fuente conlleva varios riesgos:
- Parece ser exhaustivo, pero puede incluir temas inapropiados y dejar fuera otros que son esenciales.
- Proporciona encabezados para un documento, pero absolutamente ninguna orientación sobre qué contenido es adecuado para cada sección.
- Puede contener texto que parece reutilizable y es copiado sin cambios de un proyecto anterior no relacionado, pero ese texto puede dar una impresión equivocada, o ser inexacto o incompleto.
Usar plantillas para obtener títulos y el formato básico puede ser útil, pero el principal problema de las plantillas es este:
La tentación con las plantillas es confiar demasiado en ellas y luego redactar contenido insustancial para las distintas secciones. Al fin y al cabo, puedes pensar que el documento solo cumple con un ‘requisito administrativo’ y que nadie lo leerá. El riesgo de las plantillas es que dejes de pensar y produzcas un documento de escaso valor.
Tipos de documentación de pruebas
En esta sección, veremos las distintas formas de documentación de pruebas y comentaremos algunas consideraciones en proyectos estructurados o ágiles/continuos frente a enfoques tradicionales tipo cascada.
El conjunto principal de documentos de pruebas suele pertenecer a las siguientes categorías:
- Política y estrategia (a veces conocido como "Plan Maestro de Pruebas")
- Definición de pruebas (también conocido como especificación o planes de pruebas, lo que resulta confuso)
- Diseño de pruebas
- Casos de prueba
- Procedimientos o scripts de pruebas
- Ejecución de pruebas
- Cronograma
- Registro
- Informe de pruebas
La variedad anterior de tipos de documentos abarca la definición del proceso de pruebas, las actividades clave de definición, ejecución y la elaboración de informes.
Existen otros documentos relacionados con pruebas que, en entornos más burocráticos, incluirían definiciones de entorno de pruebas y procesos de gestión, procedimientos de aceptación, procesos de gestión de incidentes, entre otros (la gestión de incidentes la abordaremos en un próximo artículo).
Otra omisión evidente de la lista sería un plan general o cronograma para las actividades de pruebas. En realidad, un cronograma no es propiamente un documento de pruebas, sino un subconjunto del plan general del proyecto para un proyecto estructurado (también trataremos la planificación de cronogramas en un futuro artículo, ¡así que mantente atento!).
Política, estrategia y Plan Maestro de Pruebas
| Propósito |
|
| Contenido |
|
| Fuentes |
|
| Mantenimiento |
|
Consideraciones Ágiles/Continuas La estrategia de pruebas para proyectos ágiles usando Scrum, por ejemplo, probablemente será bastante breve y comprenderá solo unas pocas páginas (si es que se documenta). Es posible que el proceso de pruebas no tenga etapas, pero probablemente haya una definición de pruebas en diferentes niveles. Por ejemplo:
| |
Definición de Pruebas (Diseño, Casos, Procedimientos)
| Propósito |
|
| Contenido |
|
| Fuentes |
|
| Mantenimiento |
|
Consideraciones Ágiles/Continuas El área de definición de pruebas es donde el enfoque ágil es más marcadamente diferente respecto a los proyectos estructurados. Es posible que testers que se centran en las funcionalidades a medida que se entregan no creen ninguna documentación en absoluto. Esto es adecuado si existe una política o carta a nivel de sistema para las pruebas de funcionalidades, por ejemplo. Más probablemente, existiría una breve carta para probar cada funcionalidad en una sesión de pruebas exploratorias. Una carta es como un plan para un corto período de exploración. Generalmente, la carta identificaría:
| |
Ejecución de Pruebas (Programación, Registro)
| Propósito |
|
| Contenido |
|
| Fuentes |
|
| Mantenimiento |
|
Consideraciones Ágiles/Continuas Si los proyectos ágiles/continuos no se comprometen a documentos de definición de pruebas, lo compensan en parte animando a los testers a mantener mejores registros de la ejecución de pruebas. Cuando se hacen pruebas en sesiones guiadas por debates, se espera que el tester lleve buenas notas de las pruebas que realiza. Existen pocas herramientas dedicadas para el registro de pruebas que sean más que cuadernos, así que muchos testers usan editores de texto simples, aplicaciones de notas o cuadernos físicos. Los registros suelen utilizarse para documentar toda actividad significativa y observaciones durante las sesiones mientras se realizan. Un registro típico de pruebas exploratorias incluiría aspectos como:
| |
Informe de Pruebas
| Propósito |
|
| Contenido |
|
| Fuentes |
|
| Mantenimiento |
|
| Consideraciones Ágiles/Continuas El propósito de un informe de pruebas en un proyecto ágil puede abarcar una sola iteración o sprint, pruebas para una liberación, o una fase de pruebas de nivel superior como integración o aceptación general del sistema. Sea cual sea el caso, el propósito no cambia. Gran parte del contenido de un informe de pruebas provendrá de herramientas o notas de los testers. El resumen narrativo de resultados es redactado por un líder de pruebas o el tester para una fase de pruebas de menor escala. Como es habitual, el informe probablemente será menos formal y seguramente habrá menos datos sin procesar que puedan constituir la base para análisis sofisticados. Sin duda, durante la(s) iteración(es), el progreso en términos de funcionalidades o historias entregadas, probadas y aprobadas por los usuarios, podría registrarse en una herramienta o en un tablero KanBan público. De este modo, los interesados están informados sobre el avance durante toda la iteración y hay menos necesidad de un informe formal al final de un periodo de pruebas. La visibilidad del progreso es un aspecto clave para los equipos ágiles. Con reuniones periódicas, quizás diarias, en torno a un tablero Scrum, por ejemplo, los miembros del equipo comparten su visión sobre el avance, se cuestionan entre ellos y acuerdan en todo momento una posición (y los siguientes pasos). De este modo, podría no ser nunca necesario un informe de pruebas formal porque el equipo está siempre informado y actualizado. Si los testers mantienen notas escritas de sus actividades de sesión, entonces no habrá datos analizables disponibles para generar informes automatizados, por lo que el seguimiento de sesiones y el reporte de progreso podría presentarse de manera visual y pública. Esto requiere un alto grado de disciplina y buenas habilidades de comunicación por parte de los testers. El líder o gerente de pruebas tendrá que proporcionar un informe igualmente informativo a los interesados basado en informes verbales. | |
Algunos consejos
El tema de la documentación en los proyectos es delicado tanto para los testers como para otros miembros del equipo.
La mayoría considera que escribir documentación es una tarea pesada.
Esto es lo que debes tener en cuenta al diseñar tu documentación.
- La documentación debe tener un propósito y audiencia bien definidos. Si tu audiencia no la necesita, no la leerá. Si no conecta con sus propios objetivos, no se involucrarán.
- Generalmente es mejor registrar una actividad antes o a medida que la realizas. TDD, por ejemplo, registra pruebas antes de escribir el código. Los registros de sesiones de pruebas deben completarse durante la sesión, no después.
- Los datos esenciales para registrar un aspecto de pruebas pueden ser mínimos. Por ejemplo, un registro de pruebas en un cuaderno podría ser suficiente para el tester, pero no puede analizarse fácilmente. Tal vez un registro de texto simple con algo de marcado sea igual de rápido de captar y podría analizarse con una herramienta personalizada.
- Puede que los procedimientos de prueba no sean necesarios si los testers conocen bien el sistema bajo prueba. Tal vez solo se requiera un objetivo o carta de pruebas. Los casos de prueba preparados pueden documentarse mínimamente en una hoja de cálculo.
Por último
La necesidad es la madre de la documentación.
Si preparas una documentación completa para tus interesados y no la leen, es porque no ven valor en ella.
Es mejor presentar al stakeholder una hoja en blanco y conjuntamente añadir los temas que desean ver en un documento y trabajar desde ahí. Tal vez pidan mucho contenido, pero lo que realmente necesitan es mucho más simple. Sigue preguntando: «¿por qué quieren esto?»
Gracias por leer, acompáñanos la próxima vez cuando nos arremanguemos y comencemos con algo de planificación de pruebas.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Leadership In Test de Paul que recomendamos mucho para profundizar en este y otros temas. Si decides inscribirte, utiliza nuestro código de cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso.
