Liderazgo en Pruebas: Documentación
Nota del editor: Bienvenido a la serie Liderazgo en Pruebas del gurú y consultor de pruebas de software Paul Gerrard. La serie está diseñada para ayudar a testers con varios años de experiencia—especialmente aquellos en equipos ágiles—a destacar en sus roles de líder y gestor de pruebas.
En el artículo anterior, expusimos un manifiesto de riesgos para ayudar a los gestores. En este artículo, plantearemos la clásica pregunta “¿Cuántas pruebas son suficientes?”. Spoiler: depende de los interesados.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando se publique una nueva parte de la serie. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul, el cual recomendamos encarecidamente para profundizar en este y otros temas. Si lo haces, ¡usa nuestro código exclusivo de cupón QALEADOFFER para obtener $60 de descuento en el precio total del curso!
No importa el proyecto, la organización o el enfoque, siempre hay lugar para la documentación. Una buena documentación es una bendición, ya que proporciona un registro útil del enfoque, el alcance, los planes, los 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 el copiar/pegar
- Tipos de documentación de pruebas
- Consejos para diseñar documentación
Vamos allá.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
El valor de la documentación
En proyectos estructurados, los documentos normalmente se consideran entregables por sí mismos. En regímenes ágiles o continuos, la documentación puede producirse como un subproducto de mayor o menor valor.
La redacción de documentos puede ser la actividad principal de escritores técnicos profesionales pero, para la mayoría de los profesionales, es una tarea tediosa—por muy útil que pueda ser. Incluso si la redacción de documentos puede resultar aburrida para algunas personas, el verdadero problema con la documentación es que, en muchos contextos, la mayoría es simplemente una pérdida de tiempo. Tiene poco valor, está desactualizada, es inexacta—o todo a la vez.
Todo gestor de pruebas ha redactado estrategias de pruebas que nadie leyó o en las que nadie creyó. Los testers escriben montones de planes de prueba, scripts 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 tanto grandes como pequeños. Por cada documento que redactamos, hay varias preguntas que debemos abordar:
- ¿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 son necesarias para crear el contenido?
- Si el documento debe cambiar con el tiempo, ¿cómo se mantendrá?
- ¿Qué nivel de detalle se requiere?
Los peligros de las plantillas y el copiar/pegar
Si tu proyecto determina que se requiere un determinado documento, como un plan de pruebas del sistema o un registro de riesgos, es tentador buscar una plantilla ya hecha para estos (y muchos otros tipos de documentos) en internet.
Algunas plantillas pueden afirmar que cumplen algún estándar o convención y que han sido descargadas y utilizadas miles de veces. A veces una plantilla puede parecer ajustarse perfectamente a tu propósito. Pero, como veremos, incluso si el índice parece completo puede causarte problemas.
También puede ocurrir que tú u otros en tu empresa hayan preparado un documento similar para proyectos anteriores. Puede que te sientas tentado a copiar y renombrar este documento, cambiar las referencias al proyecto anterior y editar el contenido para que se ajuste.
Advertencia: Por mi experiencia como revisor independiente esto es muy común y a menudo un verdadero problema.
En primer lugar, suele ser bastante evidente cuando un texto ha sido copiado o editado. El lenguaje utilizado en el texto a menudo parece desconectado del proyecto y hay huecos y texto superfluo por todas partes. ¿Por qué ocurre esto?
Utilizar una plantilla predefinida o un documento existente como fuente conlleva varios riesgos:
- Parece exhaustivo, pero puede incluir temas inapropiados y excluir otros que son esenciales.
- Proporciona encabezados para un documento, pero no da ninguna orientación sobre qué contenido es adecuado para cada sección.
- Puede contener texto que parece reutilizable y que se copia sin cambios de un proyecto anterior no relacionado, pero ese texto puede dar una impresión equivocada, o ser inexacto o incompleto.
Utilizar plantillas para obtener encabezados y el formato básico puede ser útil, pero el principal problema con las plantillas es este:
La tentación con las plantillas es confiar demasiado en ellas y luego escribir texto de relleno en las distintas secciones. Al fin y al cabo, podrías pensar que el documento simplemente cumple con un ‘requisito’ y que nadie lo leerá de todos modos. El riesgo de las plantillas es que dejes de pensar y escribas un documento que tiene poco valor.
Tipos de documentación de pruebas
En esta sección, veremos las distintas formas de documentación de pruebas y discutiremos algunas consideraciones en proyectos estructurados o ágiles/continuos frente al enfoque tradicional de cascada.
El conjunto principal de documentos de prueba 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 llamada especificación o planes de prueba, de forma confusa)
- Diseño de pruebas
- Casos de prueba
- Procedimientos o scripts de prueba
- Ejecución de pruebas
- Cronograma
- Registro
- Informe de pruebas
La gama anterior de tipos de documentos cubre la definición del proceso de pruebas, actividades clave de definición y ejecución, y los informes.
Existen varios otros documentos relacionados con pruebas que, en entornos más burocráticos, incluirían definiciones y procesos de gestión del entorno de pruebas, procedimientos de aceptación, procesos de gestión de incidentes, entre otros (trataremos la gestión de incidentes en un próximo artículo).
Otra omisión evidente de lo anterior sería un plan general o cronograma para las actividades de prueba. Un cronograma realmente no es un documento de pruebas, es un subconjunto de un plan general del proyecto para un proyecto estructurado (también trataremos la planificación de cronogramas en un próximo artículo, ¡así que no te lo pierdas!).
Política, Estrategia, Plan Maestro de Pruebas
| Propósito |
|
| Contenido |
|
| Fuentes |
|
| Mantenimiento |
|
Consideraciones Ágiles/Continuas La estrategia de pruebas para proyectos ágiles que utilizan Scrum, por ejemplo, probablemente será bastante breve y constará de solo unas pocas páginas (si es que se documenta). Es posible que el proceso de pruebas no tenga etapas, pero es probable que 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 se diferencia más notablemente de los proyectos estructurados. Es posible que los testers que se focalizan en funcionalidades conforme se entregan no creen documentación alguna. Esto es adecuado si existe una política o carta general para las pruebas de funcionalidades, por ejemplo. Más probablemente, habría una breve carta para probar cada funcionalidad en una sesión de pruebas exploratorias. Una carta es como un plan para un breve período de exploración. La carta normalmente identificará:
| |
Ejecución de Pruebas (Programación, Registro)
| Propósito |
|
| Contenido |
|
| Fuentes |
|
| Mantenimiento |
|
Consideraciones Ágiles/Continuas Si los proyectos ágiles/continuos no se comprometen con documentos de definición de pruebas, en parte compensan esto alentando a los probadores a mantener mejores registros de la ejecución de pruebas. Cuando las pruebas se realizan en sesiones basadas en cartas, se espera que el probador tome buenas notas de las pruebas que ejecuta. Existen pocas herramientas dedicadas al registro de pruebas que sean más que simples cuadernos, por lo que muchos probadores utilizan editores de texto simples, aplicaciones de notas o cuadernos físicos. Los registros tienden a utilizarse para anotar toda la actividad significativa y observaciones durante las sesiones a medida que se llevan a cabo. Un registro típico de pruebas exploratorias contendría aspectos tales como:
| |
Informe de Pruebas
| Propósito |
|
| Contenido |
|
| Fuentes |
|
| Mantenimiento |
|
| Consideraciones Ágiles/Continuas El propósito de un informe de pruebas en un proyecto ágil podría abarcar una sola iteración o sprint, pruebas para una liberación o una fase de pruebas de mayor nivel como integración o aceptación general del sistema. Sea cual sea, el propósito no cambia. Gran parte del contenido del informe de pruebas vendrá de herramientas o notas de los testers. El resumen narrativo de los resultados lo redacta un líder de pruebas o el tester para una fase de prueba de menor escala. Como es habitual, es probable que el informe sea menos formal y haya menos datos en bruto que sirvan de 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, las partes interesadas se mantienen informadas del progreso durante toda la iteración y hay menos necesidad de un informe formal al final del periodo de pruebas. La visibilidad del progreso es una preocupación clave para los equipos ágiles. Con reuniones breves y regulares, quizá diarias, en torno a un tablero Scrum, por ejemplo, los miembros del equipo comparten su comprensión sobre el progreso, se cuestionan entre sí y acuerdan la situación (y próximos pasos) constantemente. De esta forma, es posible que nunca se requiera un informe formal, porque el equipo siempre está informado y actualizado. Si los testers llevan notas escritas de sus actividades de sesión, entonces no habrá datos analizables disponibles para presentar informes automatizados, por lo que los informes de sesión y de progreso pueden presentarse de forma 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 presentar un informe igualmente informativo a las partes interesadas, basado en los 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 de proyecto.
La mayoría de las personas considera la redacción de documentación como una tarea tediosa.
Aquí tienes algunas cosas a tener en cuenta al diseñar tu documentación.
- La documentación debe tener un propósito y una audiencia bien definida. Si tu audiencia no necesita la documentación, no la leerá. Si no se alinea con sus propios objetivos, no la aceptarán.
- Por lo general, es mejor capturar el registro de una actividad antes o durante su realización. Por ejemplo, TDD captura pruebas antes de que se escriba el código. Los registros de las sesiones de pruebas deben capturarse durante la sesión y no escribirse después.
- Los datos esenciales para registrar un aspecto de las pruebas pueden ser mínimos. Por ejemplo, una prueba registrada en una libreta puede ser suficiente para el tester, pero no se puede analizar fácilmente. Tal vez un simple registro de texto con algo de formato podría capturarse igual de rápido, pero también podría ser analizado por una herramienta personalizada.
- Los procedimientos de prueba pueden no ser necesarios si los testers conocen bien el sistema bajo pruebas. Quizás solo es necesario un objetivo de prueba o un mandato. Los casos de prueba preparados se pueden documentar mínimamente en una hoja de cálculo.
Para Terminar
La necesidad es la madre de la documentación.
Si preparas documentación exhaustiva para tus partes interesadas y no la leen, es porque no perciben valor en ella.
Es mejor presentar a un interesado una hoja en blanco y, conjuntamente, añadir los temas que necesita ver en un documento y partir desde ahí. Puede que te pidan toneladas de contenido, pero lo que realmente necesitan es mucho más sencillo. Sigue preguntando '¿por qué quieren esto?'
Gracias por leer. Únete a nosotros la próxima vez mientras nos arremangamos y comenzamos 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 Liderazgo en Pruebas de Paul, que recomendamos encarecidamente para profundizar en este y otros temas. ¡Si lo haces, utiliza nuestro cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio completo del curso!
