Liderazgo en Pruebas: Planificación de Pruebas
Nota del editor: Bienvenidos 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 algunos años de experiencia—especialmente aquellos en equipos ágiles—a sobresalir en sus roles de liderar y gestionar pruebas.
En el artículo anterior, profundizamos en la documentación y algunas mejores prácticas. Esta vez aplicamos gran parte del conocimiento de los artículos anteriores y lo usamos para planificar un proyecto de pruebas.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando salgan nuevas partes de la serie. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul, el cual recomendamos para profundizar en este y otros temas. Si decides hacerlo, ¡usa nuestro cupón exclusivo QALEADOFFER para conseguir $60 de descuento en el precio total del curso!
¿Qué es un plan realmente?
Un plan de proyecto combina las tareas del proyecto, las duraciones estimadas, las dependencias y los entregables en un modelo programado de la realidad.
Si consideras el plan como una predicción del futuro, serías muy cauteloso al confiar en él, pero eso es lo que usualmente hacemos.
Quizás te hayas encontrado con jefes de proyecto que tratan su plan como su propia realidad personal—su propio mundo ilusorio. Pero no deberíamos ser tan duros con los jefes de proyecto—muchas veces están motivados para crear un plan y cumplirlo pase lo que pase.
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 plan no es la realidad; es un modelo de la realidad que requiere cambios constantes.
En este artículo, cubriré cada etapa de la planificación de pruebas, incluyendo:
- Entregables
- Cómo
- Recursos
- Tu red de apoyo
- Estimaciones
- Dependencias, Riesgos y Supuestos
- Comunicación, Compromiso e Informe de Progreso
Pero primero, aclaremos realmente cómo de útil puede ser un plan.
¿Por qué planificar?
La finalidad de la planificación suele ser crear cierto enfoque acordado, definir los compromisos, dependencias, costes y cronograma para ejecutar un proyecto. El plan es un acuerdo entre los participantes, proveedores y partes interesadas del proyecto, que normalmente determina lo siguiente:
- Qué recursos se requieren y cuándo
- Cuándo deben comenzar y finalizar las tareas y quién las ejecutará
- Las habilidades necesarias para completar las tareas
- Las herramientas y tecnologías que respaldan el plan
- Los entregables y cuándo se entregarán
- Los costes de esfuerzos y recursos requeridos
- El proceso para avanzar el proyecto o proceso a lo largo de sus etapas
- Los riesgos que amenazan la entrega.
Algunos de estos aspectos pueden estar especificados en una estrategia o ya estar presentes. Por ejemplo, podría conocerse qué proveedores están involucrados y qué harán para el proyecto. Las herramientas y la tecnología pueden estar ya definidas e implementadas. Las personas, entornos de prueba y datos pueden estar listos. También es posible que exista una estrategia que defina el proceso, el enfoque o las técnicas a aplicar.
Pero, mientras que la estrategia define los principios o la teoría, el plan describe las cuestiones prácticas o logísticas sobre cómo se entregará el proyecto en la realidad.
Una estrategia establece cómo se ejecutará un proyecto en principio, el plan define y confirma cómo se ejecutará en la práctica.
Para muchos jefes de proyecto el plan es lo que está almacenado en Microsoft Project, pero un plan viable depende de que todos los participantes del proyecto comprendan lo que están haciendo y cómo lo harán. Para lograr esto, el plan y el conocimiento sobre cómo se harán las tareas necesitan comunicarse y aceptarse por todas las personas involucradas.
Planificar es un viaje, no una tarea
Para citar al expresidente estadounidense Dwight D. Eisenhower: “La planificación lo es todo. El plan no es nada.” Este sentimiento es tan importante que merece repetirse en casi cualquier contexto del trabajo en proyectos de sistemas. Pero, ¿qué significa decir que el plan no es nada? ¿Cuál es el sentido de planificar si el resultado es un plan sin valor?
El plan con el que termines nunca es inútil, pero el sentimiento de Eisenhower se relaciona con el acto de planificar y su valor en comparación con el plan. Comparemos rápidamente cómo funciona la planificación en proyectos largos y estructurados frente a los ágiles o continuos por separado.
Planificación estructurada vs ágil
En un proyecto a largo plazo, tu negocio, proveedores y personal de TI interno necesitan saber qué compromiso se requiere de ellos para que puedan programar la disponibilidad de personas y recursos físicos.
Se necesita tiempo valioso para reunir la información necesaria para crear un plan. Con todas las dependencias en recursos y personas, y el compromiso y desempeño de los proveedores así como del personal interno, muchas cosas pueden salir mal. Algunas cosas saldrán mal. Por esta razón, el plan, como predicción del futuro, está lleno de dificultades.
El día después de que se publica un plan, y cada día subsiguiente, sale a la luz nueva información y se necesita algún ajuste. Se eliminan requisitos; los proveedores entregan tarde; los entornos, datos de prueba o herramientas no están listos a tiempo. La lista continúa. La planificación nunca es una tarea puntual, es una actividad continua — casi diaria —.
A menudo, los eventos no planificados se tratan como ruido y no reciben mucha atención. Sin embargo, más tarde, algunos de estos pequeños inconvenientes se convierten en grandes problemas. Uno de los desafíos de los proyectos en cascada es que este ajuste continuo puede resultar gravoso porque cualquier cambio se ve como una intervención innecesaria. Los proyectos suelen continuar sin importar, esperando que "todo salga bien al final". Pero esto rara vez ocurre y se ha dicho muchas veces:
¿Cómo llega un proyecto a retrasarse un año? Un día a la vez.
El enfoque ágil es en parte una reacción a la frustración de los planes fijos o inflexibles. La agilidad es la alternativa comprobada a la inercia de los enfoques pesados y por etapas. Pero ¿esto significa que los proyectos ágiles no hacen planes? No.
Incluso en ágil es necesario algo de planificación inicial para estructurar el trabajo, reunir los recursos y programar — al menos a alto nivel — el proceso de lanzamiento en los próximos meses. Pero iteración tras iteración, y muchas veces día a día, el plan general se ajusta de forma continua para tener en cuenta los eventos y la nueva información que sale a la luz.
La planificación es un proceso de aprendizaje continuo, no una tarea con un entregable.
Planificación de pruebas
Hasta ahora, hemos visto la planificación de proyectos en general y hemos sugerido que es, en gran medida, una actividad continua. Ahora nos centraremos específicamente en la planificación de las pruebas en los proyectos.
La planificación de pruebas es muy similar a la de proyectos – en realidad es solo un plan a menor escala. Por supuesto, el plan de pruebas también debe integrarse con el plan general del proyecto porque depende de otras actividades y entregables del proyecto (y otras tareas dependen de la prueba). Con frecuencia, los planes de prueba se ven interrumpidos porque no se cumplen estas dependencias.
Los planes de prueba son relativamente sencillos en su visión general. Puede haber varias actividades que dependan del proyecto principal. Estas suelen aparecer como tareas en el plan del proyecto más grande. Pero estas actividades se distribuyen entre un equipo, con tal vez un gran inventario de elementos de prueba para planificar y ejecutar pruebas.
Este nivel de detalle no es tan relevante para el cronograma del director de proyecto y normalmente se define y gestiona a nivel local dentro del equipo de pruebas.
Veamos algunos de los elementos clave de tu plan de pruebas.
Entregables
¿Cuáles son los entregables de las pruebas?
¡Vaya pregunta! Seguramente son las especificaciones de prueba, las pruebas, los resultados y los informes, ¿no? Los entregables están esencialmente contenidos en la documentación, así que todo lo que debemos preocuparnos es sacar el papeleo y marcar algunas casillas.
Pero este enfoque, aunque común, es en parte responsable de que las pruebas (y los testers) adquieran una reputación de ser costosos, torpes burócratas que aportan poco valor. Al fin y al cabo, ¿quién lee estos voluminosos documentos?
Supongamos que no hay intención de producir documentación de pruebas en un proyecto ágil. Esto es más probable de lo que parece, entonces ¿qué entregan realmente las pruebas en esas situaciones? ¿Qué valor tienen las pruebas en absoluto? Es un poco tarde para hacerse estas preguntas, ¿no?
Cuando se prueba un componente, subsistema o el sistema completo, el resultado es evidencia de cómo se comporta el sistema en alguna situación o contexto. Se recopila y organiza la evidencia del comportamiento del sistema para presentarla a las partes interesadas (desarrolladores, usuarios, gerentes, etc.) para que puedan tomar una decisión: corregir errores, integrar un componente, aceptar o rechazar la funcionalidad, liberar o desplegar un subsistema o el sistema en su conjunto.
El entregable de las pruebas es la evidencia del comportamiento del sistema que usan las partes interesadas para tomar una decisión.
Ahora bien, en algunos proyectos, es esencial proporcionar documentación de las pruebas para registrar cómo se diseñó, implementó y ejecutó una prueba. Pero es la evidencia del comportamiento del sistema lo que constituye el entregable de mayor valor para las partes interesadas.
El valor de las pruebas es el nivel de confianza que tienen los interesados para tomar decisiones basadas en la evidencia de las pruebas.
Esta evidencia puede recopilarse, tabularse y analizarse sistemáticamente en sofisticadas soluciones de gestión de pruebas y presentarse a los interesados en formatos gráficos elegantes. O bien, las notas escritas a mano pueden ser utilizadas por una persona encargada de las pruebas para presentar verbalmente la historia de las pruebas a una persona responsable del producto durante una reunión de pie.
Cualquiera sea la forma de recopilar y presentar, la tarea final de las pruebas es la entrega de la evidencia.
Cómo
Independientemente de la escala o la metodología del proyecto, las pruebas dependen de una serie determinada de actividades. Vamos a observar un proceso genérico desde la perspectiva de la persona que realiza las pruebas (o equipo) y luego veremos algunas de las variaciones que pueden producirse.
Existen las que podrían llamarse ‘actividades de prueba’ y también ‘actividades de soporte a las pruebas’ o ‘logísticas’. Para asegurarte de incluir todas las actividades en el plan, podrías encontrar útiles las listas de verificación en las siguientes tablas.
Una de las actividades en la tabla anterior que quizás no te resulte tan familiar es la actividad de retroalimentación. Seguramente ya te ha tocado trabajar con requerimientos deficientes.
La actividad de retroalimentación, revisión y desafío es aquella en la que quienes prueban, tras analizar y modelar un requerimiento, encuentran problemas y pueden utilizar ejemplos para demostrar en qué partes los requerimientos son incompletos, ambiguos o contradictorios.
Si consideras que los requerimientos son deficientes, definitivamente vale la pena contemplar esta actividad.
Logística de pruebas
La logística de pruebas brinda soporte a las actividades de prueba mencionadas anteriormente. Mientras que la lista de actividades de prueba que he dado es razonablemente completa, la logística de pruebas varía en cada proyecto y organización. Por tanto, la siguiente lista no es exhaustiva. En tu proyecto, tómate el tiempo de pensar cada actividad o dependencia necesaria para llevar a cabo las pruebas.
Recursos (humanos, físicos)
A menudo usamos la palabra recursos para referirnos a las personas en nuestros proyectos y, para algunas personas, esto no resulta cómodo. Las personas no son cosas, son seres humanos, por supuesto. En proyectos pequeños podría ser posible utilizar nombres, pero en organizaciones grandes, cuando se involucran equipos de proyectos que quizás aún no están conformados, la expresión “número de recursos” es simplemente una forma corta de decir “cantidad de personas”.
Más importante aún, no necesariamente es la cantidad de personas la que cuenta, sino sus capacidades, que es lo que realmente importa. Por supuesto, cada persona trabaja de forma diferente y normalmente a distinta velocidad, por lo que deberás tener esto en cuenta en tu planificación.
Más allá de las personas, en diferentes etapas, se necesitarán distintos recursos físicos para poder llevar a cabo las pruebas. Estos pueden ir desde lo más simple hasta lo más específico, y la falta de cualquiera de ellos puede poner en peligro la misión de las pruebas.
Puede que ya tengas la suerte de contar con un laboratorio de pruebas totalmente equipado, gestionado y dedicado. Si no es así, es posible que debas especificar todo, desde el espacio físico y el mobiliario hasta notas adhesivas y borradores, para definir tu entorno de trabajo.
En la tabla de abajo, se muestran algunos recursos típicos requeridos. Tu lista variará considerablemente, sin duda.
Cuando hayas identificado todos los recursos necesarios para llevar a cabo tu plan, considera si necesitas actividades adicionales en tu planificación para adquirirlos.
Tu red de apoyo
¡Si las personas y habilidades que necesitas para hacer las pruebas dependieran de ti, los proyectos serían mucho más sencillos! Pero pocos equipos tienen todas las habilidades que requieren, o la autorización y acceso a los recursos físicos necesarios. Muchos proyectos están dotados y operan bajo un modelo de gestión matricial. Miembros clave del equipo reportan realmente a responsables de otros departamentos especializados, y solo obtendrás de ellos un compromiso limitado.
Es posible que debas especificar una cantidad determinada de horas al día o programar horarios para acceder a las habilidades especializadas mencionadas anteriormente. A veces se te preguntará qué nivel de servicio es aceptable, por ejemplo: “las solicitudes de alta prioridad se responderán en treinta minutos”, y así sucesivamente.
Estimaciones
La estimación en proyectos de software es una tarea compleja. Se ha escrito mucho acerca de la dificultad o incluso la imposibilidad de estimar. Sin embargo, se requieren estimaciones en todos los proyectos y, cuanto más grande es el proyecto, más dependemos de ellas.
Necesitamos estimaciones para crear un cronograma, pero el problema es que la estimación no te da precisión. Lo mejor que podemos hacer es calcular un esfuerzo o tiempo transcurrido con cierto nivel de confianza o probabilidad.
Algunas personas consideran que la estimación es un arte oscuro y existe incluso un movimiento #NoEstimates con una cantidad considerable de seguidores. Hay mucha discusión sobre si la estimación puede ser alguna vez lo suficientemente precisa o si siquiera es una buena práctica en los proyectos de software.
La estimación nunca será una ciencia exacta. Sin embargo, de mis experiencias, me siento cómodo compartiendo estos principios:
- Los requisitos son falibles e imprecisos.
- Las personas son más o menos competentes, conscientes y trabajadoras.
- Cuanto más pequeño sea el elemento de trabajo, más fácil es estimarlo; divide las tareas grandes en unidades más pequeñas siempre que sea posible y suma las estimaciones para la tarea mayor.
- La estimación se basa en la experiencia. Si no tienes ninguna, busca dónde la experiencia de otros es relevante y puede adaptarse.
- Tu elemento de trabajo es único, así que busca patrones de trabajo en otras situaciones conocidas donde tengas experiencia.
- Pide a otros que estimen y compara. Discutir discrepancias expone diferencias en expectativas, confianza y minuciosidad.
- Estima la mejor situación posible y luego la peor. Una buena estimación está en algún lugar entre ambas.
Estima hoy y empieza a trabajar; mañana y cada día subsiguiente, con el conocimiento adquirido, tu estimación de finalización mejorará.
Dependencias, Riesgos y Supuestos
En un artículo anterior, hablamos del riesgo y del papel de las pruebas en la gestión del riesgo. Los riesgos del producto se relacionan con si el producto satisface las necesidades de los usuarios en cuanto a requisitos funcionales o técnicos. Aquí, el enfoque está en los riesgos del plan de entrega real.
Las cosas pueden salir mal en los proyectos. En tu actividad de planificación necesitas dejar claro qué riesgos de fallo has considerado y previsto. Hay tres aspectos en esto: dependencias, riesgos y respuestas.
Dependencias
Las dependencias representan una lista de recursos humanos y físicos requeridos, y actividades predecesoras, que deben completarse para que tus actividades planificadas tengan éxito y se puedan entregar.
Siempre hay dependencias para cualquier actividad de prueba, ya sea una prueba a gran escala de nivel de sistema o una sesión de prueba exploratoria de una característica. Las dependencias cubren tres aspectos principales.
Riesgos
El riesgo es la probabilidad de que tu plan falle durante la ejecución. El riesgo está relacionado con cosas como:
- Tus estimaciones: ¿qué podría causar que tus estimaciones sean erróneas? El sistema siendo más complejo, defectuoso, incompleto o cambiando constantemente podría afectar tus estimaciones.
- Que las personas no estén disponibles, carezcan de experiencia o habilidades, o no estén plenamente comprometidas en tu fase del proyecto. Estos pueden ser miembros del equipo o personas de tu red de apoyo.
- Infraestructura como ambientes de prueba, herramientas (o formación en el uso de herramientas) o espacio de oficina que no estén disponibles, estén mal preparados o defectuosos.
- Actividades predecesoras que no se completen a tiempo (o que se abandonen, entreguen productos parciales o defectuosos o no entreguen nada en absoluto).
Respuestas
Para cada uno de estos riesgos, necesitas evaluar la probabilidad, el impacto y, cuando sean significativos, una respuesta adecuada o consecuencia esperada. Estas respuestas suelen tomar una de estas formas:
- Supuesto: el riesgo se considera lo suficientemente bajo como para ignorarlo o tratarlo como insignificante. Pero está en el radar y registrado como un supuesto (de disponibilidad, integridad, etc.)
- Ajustar: el riesgo es significativo, pero hay alguna acción que puede reducir su impacto en el plan. Por ejemplo, si el sistema bajo prueba se entrega parcialmente, con funciones faltantes, entonces el plan puede ajustarse para probar solo aquellas funciones que están disponibles.
- Consecuencia: algunos riesgos no pueden asimilarse. Si el sistema se entrega tarde, entonces las pruebas no pueden comenzar hasta que se entregue.
Comunicación, Compromiso y Reporte de Progreso
Por último, llegamos a un aspecto crucial pero a menudo pasado por alto de la planificación. Puede que produzcas un plan de proyecto con todas las tareas, participantes, recursos, responsabilidades, dependencias, tiempos, esfuerzo y costos incluidos. O puede ser un acuerdo verbal entre los miembros de un equipo ágil.
De cualquier manera, el plan debe comunicarse de manera efectiva a todos para que todos sepan qué se requiere y cuándo.
Un plan acordado es un contrato entre los participantes. Si un gestor de equipo aprueba un plan, es implícita o explícitamente un compromiso de cumplir con la parte de su equipo en el contrato.
El plan es un contrato entre los participantes.
En proyectos menos formales, puede que no exista un plan escrito ni compromisos en absoluto. En estas circunstancias, el plan es una conversación continua entre los miembros del equipo. El equipo se reúne diariamente y las tareas activas del plan se discuten en tiempo real. ¿En qué están trabajando las personas? ¿El progreso avanza según las expectativas? ¿Qué problemas están experimentando las personas? ¿Qué problemas están bloqueando el avance?
En todos los proyectos, el propósito de los informes de progreso es doble. Obviamente, existe la necesidad de comunicar en qué situación se encuentra cada uno respecto a su actividad actual en el proyecto. Pero el informe de progreso también es una verificación periódica continua de que el avance puede mantenerse y de que se puede confiar en el compromiso de los participantes.
Gracias por leer, acompáñanos la próxima vez para... ¡lo has adivinado, la ejecución!
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando nuevas partes de la serie estén disponibles. Estas publicaciones son extractos del curso de Liderazgo en Pruebas de Paul, que recomendamos ampliamente para profundizar en este y otros temas. Si decides inscribirte, usa nuestro cupón exclusivo QALEADOFFER para obtener $60 de descuento sobre el precio completo del curso.