Liderazgo en pruebas: planificación de pruebas
Nota del editor: Te damos la bienvenida a la serie Liderazgo en pruebas, del gurú y consultor de pruebas de software Paul Gerrard. La serie está diseñada para ayudar a los testers con algunos años de experiencia —especialmente a quienes forman parte de equipos ágiles— a sobresalir en sus funciones de liderazgo y gestión de pruebas.
En el artículo anterior, profundizamos en los detalles de la documentación y algunas prácticas recomendadas. Esta vez aplicamos gran parte de los conocimientos de los artículos anteriores y los utilizamos para planificar un proyecto de pruebas.
Suscríbete al boletín de The QA Lead para recibir una notificación 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 código de cupón exclusivo QALEADOFFER para obtener un descuento de 60 $ en el precio total del curso!
¿Qué es un plan, después de todo?
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 consideraras el plan como una predicción del futuro, serías muy cauteloso a la hora de confiar en él, pero eso es lo que solemos hacer.
Es posible que hayas conocido a gestores de proyectos que tratan su plan como su realidad personal: su propio mundo ilusorio. Pero no debemos ser tan duros con los gestores de proyectos: a menudo están motivados para crear un plan y cumplirlo sin importar qué ocurra.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
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é todas las etapas de la planificación de pruebas, incluidas:
- Entregables
- Cómo
- Recursos
- Tu red de apoyo
- Estimaciones
- Dependencias, riesgos y supuestos
- Comunicación, compromiso e informes de progreso
Pero primero, tengamos una idea clara de la utilidad de un plan.
¿Por qué planificar?
El propósito de la planificación suele ser crear un enfoque acordado, un conjunto de compromisos, dependencias, costes y un calendario para entregar un proyecto. El plan es un entendimiento entre las partes interesadas del proyecto, los proveedores y los participantes que normalmente establece lo siguiente:
- Qué recursos se requieren y cuándo
- Cuándo deben comenzar y terminar las tareas y quién las realizará
- 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 del esfuerzo y de los recursos necesarios
- El proceso para hacer avanzar el proyecto o proceso a través de sus etapas
- Los riesgos que amenazan la entrega.
Algunos de estos aspectos pueden estar especificados en una estrategia o ya estar implementados. Por ejemplo, es posible que ya se sepa qué proveedores participan y qué harán para el proyecto. Las herramientas y la tecnología que se utilizarán también pueden ser conocidas y estar ya disponibles. Las personas, los entornos de pruebas y los datos pueden estar preparados. También puede existir una estrategia que defina el proceso, el enfoque o las técnicas que se utilizarán.
Sin embargo, mientras que la estrategia establece los principios o la teoría, el plan describe los aspectos prácticos o la logística de 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á el proyecto en la práctica.
Para muchos gestores de proyectos, el plan se encuentra en software como Microsoft Project, pero un plan viable depende de que todos los participantes del proyecto sepan qué están haciendo y cómo hacerlo. Para lograrlo, el plan y el conocimiento de cómo se harán las cosas deben comunicarse y contar con el compromiso de todos los involucrados.
Planificar es un viaje, no una tarea
Para citar al ex presidente de Estados Unidos Dwight D. Eisenhower: «planificar lo es todo. El plan no es nada». Este sentimiento es tan importante que merece repetirse en casi todos los contextos 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 inútil?
El plan que se obtiene nunca es inútil, pero el sentimiento de Eisenhower se refiere al acto de planificar y a su valor en comparación con el plan. Comparemos rápidamente cómo funciona la planificación por separado en proyectos estructurados de mayor duración y en proyectos ágiles/continuos.
Planificación estructurada frente a ágil
En un proyecto de mayor duración, tu empresa, los proveedores y el personal interno de TI necesitan saber qué compromiso se requiere de ellos para poder programar la disponibilidad de las personas y de los recursos físicos.
Recopilar la información necesaria para crear un plan requiere un tiempo valioso. Con todas las dependencias de recursos y personas, así como del compromiso y el rendimiento de los proveedores y del personal interno, muchas cosas pueden salir mal. Algunas cosas saldrán mal. Por ello, el plan, como predicción del futuro, está plagado de dificultades.
Al día siguiente de publicar un plan, y cada día posterior, sale a la luz nueva información y es necesario realizar algunos ajustes. Se descartan requisitos; los proveedores entregan tarde; los entornos, los datos de prueba o las herramientas no están listos a tiempo. La lista continúa. Planificar nunca es una tarea puntual, sino una actividad continua —casi diaria—.
A menudo, los acontecimientos no planificados se tratan como ruido y no reciben mucha atención. Pero, más adelante, algunos de estos pequeños fallos se convierten en problemas importantes. Uno de los desafíos de los proyectos en cascada es que este ajuste continuo puede resultar gravoso, porque cualquier cambio se considera una manipulación innecesaria. Los proyectos suelen continuar su marcha de todos modos, con la esperanza de que las cosas «salgan bien al final». Pero rara vez es así, y se ha dicho muchas veces:
¿Cómo llega un proyecto a retrasarse un año? Un día cada vez.
El enfoque ágil es, en parte, una reacción ante la frustración que provocan los planes fijos o inflexibles. La agilidad es la alternativa demostrada a la inercia de los enfoques engorrosos y por etapas. Pero ¿significa esto que los proyectos ágiles no planifican? No.
Incluso en los proyectos ágiles es necesaria cierta planificación inicial para estructurar el trabajo, movilizar los recursos y programar —al menos a alto nivel— el proceso de lanzamiento durante los próximos meses. Pero, iteración tras iteración y, a menudo, día tras día, el plan general se ajusta continuamente para tener en cuenta los acontecimientos y la nueva información que sale a la luz.
La planificación es un proceso continuo de aprendizaje, no una tarea con un entregable.
Planificación de pruebas
Hasta ahora, hemos examinado la planificación de proyectos en términos generales 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 planificación de proyectos: en realidad, es simplemente 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 las pruebas). Con frecuencia, los planes de pruebas se ven alterados porque no se cumplen estas dependencias.
Los planes de pruebas son relativamente sencillos en términos generales. Puede haber varias actividades que dependan del proyecto principal. Estas son las que suelen aparecer como tareas en el plan general del proyecto. Sin embargo, estas actividades se distribuyen entre un equipo que quizá tenga un inventario amplio de elementos de prueba para los que planificar y ejecutar pruebas.
Este nivel de detalle no es tan relevante para el cronograma del director del proyecto y normalmente se define y gestiona a nivel local dentro del equipo de pruebas.
Veamos algunos de los elementos fundamentales de tu plan de pruebas.
Entregables
¿Cuáles son los entregables de las pruebas?
¡Qué pregunta! Seguramente son las especificaciones de las pruebas, las pruebas, los resultados y los informes. Los entregables están esencialmente contenidos en la documentación, así que lo único que debemos hacer es preocuparnos por sacar el papeleo y marcar algunas casillas.
Pero este enfoque, aunque es común, es en parte culpable de que las pruebas (y los profesionales de pruebas) hayan adquirido la reputación de ser burócratas caros y torpes que aportan poco valor. Al fin y al cabo, ¿quién lee estos documentos voluminosos?
Supongamos que en un proyecto ágil no existe la intención de producir documentación de pruebas. Esto es bastante probable, así que ¿qué entregan realmente las pruebas en esas situaciones? ¿Qué valor aportan las pruebas? Es un poco tarde para hacerse estas preguntas, ¿no?
Cuando se prueba un componente, un subsistema o el sistema completo, el resultado es evidencia de cómo se comporta el sistema en una situación o contexto determinado. La evidencia del comportamiento del sistema se recopila y organiza para presentarla a las partes interesadas (desarrolladores, usuarios, directivos, etc.) con el fin de que tomen una decisión: corregir errores, integrar un componente, aceptar o rechazar una funcionalidad, lanzar o implementar un subsistema o el sistema en su conjunto.
El entregable de las pruebas es la evidencia del comportamiento del sistema que las partes interesadas utilizan para tomar una decisión.
Ahora bien, en algunos proyectos es esencial proporcionar documentación de pruebas para registrar cómo se definió el alcance, se diseñó, se implementó y se ejecutó una prueba. Pero la evidencia del comportamiento del sistema es el entregable final que aporta valor a las partes interesadas.
El valor de las pruebas es el nivel de confianza que tienen las partes interesadas 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 las partes interesadas en elegantes formatos gráficos. O un evaluador puede utilizar notas escritas a mano para presentar verbalmente la historia de las pruebas a un propietario del producto en una reunión diaria.
Independientemente de cómo se recopile y presente, 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 determinada serie de actividades. Examinaremos un proceso genérico desde la perspectiva del evaluador (o del equipo) y después analizaremos algunas de las variaciones que se producen.
Existen las que podrían denominarse «actividades de prueba» y también actividades «de apoyo a las pruebas» o «logísticas». Para asegurarte de incluir todas las actividades en el plan, las tablas siguientes pueden resultarte útiles como listas de comprobación.
Una actividad de la tabla anterior que quizá no reconozcas tanto es la actividad de retroalimentación. Seguramente ya habrás tenido que trabajar con requisitos deficientes.
La actividad de retroalimentación, revisión y cuestionamiento es aquella en la que los evaluadores, después de analizar y modelar un requisito, descubren problemas y pueden utilizar ejemplos para demostrar dónde faltan requisitos, son ambiguos o se contradicen.
Si consideras que los requisitos son deficientes, definitivamente vale la pena reservar tiempo para esta actividad.
Logística de las pruebas
La logística de las pruebas respalda las actividades de prueba anteriores. Mientras que la lista de actividades de prueba que he presentado es bastante completa, la logística de las pruebas varía con cada proyecto y organización. Por lo tanto, la lista siguiente no es exhaustiva. En tu proyecto, tómate el tiempo necesario para analizar cada actividad o dependencia requerida para llevar a cabo las pruebas.
Recursos (humanos y físicos)
A menudo utilizamos la palabra recursos para referirnos a las personas de nuestros proyectos y, para algunos, eso no resulta cómodo. Las personas no son cosas; son seres humanos, por supuesto. En proyectos pequeños, puede ser posible utilizar nombres, pero en organizaciones más grandes, cuando participan equipos de proyecto que quizá todavía no estén formados, un número de recursos es simplemente una forma abreviada de decir un número de personas.
Y lo que es más importante, no es necesariamente el número de personas lo que cuenta, sino que lo que realmente importa son sus capacidades. Por supuesto, las personas trabajan de maneras diferentes y normalmente a velocidades distintas, por lo que deberás tener esto en cuenta en tu planificación.
Además de las personas, necesitarás diferentes recursos físicos en distintas etapas para que las pruebas puedan avanzar. Estos van desde los más comunes hasta los altamente específicos, y la falta de cualquiera de ellos puede poner en peligro la misión de las pruebas.
Quizá ya tengas la suerte de contar con acceso a un laboratorio de pruebas exclusivo, gestionado y totalmente equipado. Si no es así, puede que tengas que especificarlo todo, desde el espacio físico y el mobiliario hasta las notas adhesivas y las gomas de borrar, para definir tu entorno de trabajo.
En la tabla siguiente se muestran algunos recursos habituales necesarios. Sin duda, tu lista será considerablemente diferente.
Cuando hayas identificado todos los recursos necesarios para ejecutar tu plan, considera si necesitas añadir actividades adicionales a tu plan para adquirirlos.
Tu red de apoyo
Si las personas y las habilidades que necesitas para realizar las pruebas estuvieran bajo tu control, ¡los proyectos podrían ser mucho más sencillos! Pero pocos equipos cuentan con todas las habilidades que necesitan o con la autorización y el acceso a los recursos físicos necesarios. Muchos proyectos se dotan de personal y se gestionan siguiendo un modelo de administración matricial. Los miembros clave del equipo dependen directamente de los responsables de otros departamentos especializados y obtendrás de ellos un compromiso limitado.
Es posible que debas especificar un número determinado de horas al día o programar horarios para acceder a las competencias especializadas mencionadas anteriormente. A veces, te preguntarán qué nivel de servicio es aceptable, por ejemplo: «las solicitudes de alta prioridad recibirán respuesta en treinta minutos», y así sucesivamente.
Estimaciones
La estimación en los proyectos de software es un asunto complicado. Se ha escrito mucho sobre cómo la estimación es difícil o incluso imposible. Pero las estimaciones son necesarias 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 proporciona exactitud. Lo mejor que podemos hacer es calcular el esfuerzo o el tiempo transcurrido con cierto nivel de confianza o probabilidad.
Algunas personas consideran la estimación un arte oscuro e incluso existe un movimiento #NoEstimates con un número considerable de seguidores. Existe mucho debate sobre si la estimación puede llegar a ser 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, a partir de mis experiencias, me siento cómodo compartiendo algunos de estos principios:
- Los requisitos son falibles e imprecisos.
- Las personas son más o menos competentes, concienzudas y trabajadoras.
- Cuanto menor sea el elemento de trabajo, más fácil será estimarlo; divide las tareas grandes en unidades más pequeñas siempre que sea posible y consolida las estimaciones en la tarea de mayor tamaño.
- La estimación se basa en la experiencia. Si no tienes ninguna, busca dónde es pertinente la experiencia de otras personas y puede adaptarse.
- Tu elemento de trabajo es único, así que busca patrones de trabajo en otras situaciones conocidas en las que tengas experiencia.
- Pide a otras personas que hagan una estimación y compárala. Analizar las discrepancias pone de manifiesto diferencias en las expectativas, la confianza y el nivel de exhaustividad.
- Estima la situación más favorable y después la situación más desfavorable. Una buena estimación se encuentra en algún punto intermedio.
Haz una estimación hoy y comienza a trabajar; mañana y cada día posterior, con los conocimientos adquiridos, tu estimación del tiempo necesario para completar el trabajo mejorará.
Dependencias, riesgos y supuestos
En un artículo anterior, analizamos el riesgo y el papel de las pruebas en la gestión de riesgos. Los riesgos del producto están relacionados con si el producto satisface las necesidades de los usuarios en lo que respecta a los requisitos funcionales o técnicos. Aquí, el foco está en los riesgos para el plan de entrega real.
Las cosas salen mal en los proyectos. En tu actividad de planificación, debes dejar claro qué riesgos de fallo has considerado y previsto. Hay tres aspectos: dependencias, riesgos y respuestas.
Dependencias
Las dependencias representan una lista de los recursos humanos y físicos necesarios, así como de las actividades predecesoras que deben completarse para que tus actividades planificadas tengan éxito y se entreguen.
Siempre existen dependencias para cualquier actividad de pruebas, ya sea una prueba de sistemas a gran escala o una sesión de pruebas exploratorias de una funcionalidad. Las dependencias abarcan tres aspectos principales.
Riesgos
El riesgo es la probabilidad de que tu plan fracase durante la ejecución. El riesgo está relacionado con aspectos como los siguientes:
- Tus estimaciones: ¿qué podría hacer que tus estimaciones fueran incorrectas? Que el sistema sea más complejo, defectuoso, incompleto o cambie constantemente podría afectar a tus estimaciones.
- Que las personas no estén disponibles, carezcan de experiencia o competencias, o no estén plenamente comprometidas con tu fase del proyecto. Pueden ser miembros del equipo o personas de tu red de apoyo.
- Que la infraestructura, como los entornos de pruebas, las herramientas (o la formación en su uso) o el espacio de oficina, no esté disponible, se haya preparado de forma inadecuada o presente defectos.
- Que las actividades predecesoras no se completen a tiempo (o se abandonen, entreguen productos parciales o defectuosos, o no entreguen nada).
Respuestas
Para cada uno de estos riesgos, debes evaluar la probabilidad, el impacto y, cuando sea significativo, una respuesta adecuada o la consecuencia prevista. Estas respuestas suelen adoptar una de las siguientes formas:
- Supuesto: se considera que el riesgo es lo suficientemente bajo como para ignorarlo o considerarlo irrelevante. Sin embargo, se mantiene bajo vigilancia y se registra como un supuesto (de disponibilidad, integridad, etc.).
- Ajuste: el riesgo es significativo, pero existe alguna acción que puede reducir su impacto en el plan. Por ejemplo, si el sistema sometido a pruebas se entrega parcialmente y faltan funcionalidades, el plan puede ajustarse para probar únicamente las funcionalidades disponibles.
- Consecuencia: algunos riesgos no pueden asimilarse. Si el sistema se entrega tarde, las pruebas no pueden comenzar hasta que se haya entregado.
Comunicación, compromiso e informes de progreso
Por último, llegamos a un aspecto crucial, pero a menudo pasado por alto, de la planificación. Puede que elabores un plan de proyecto que incluya todas las tareas, participantes, recursos, responsabilidades, dependencias, plazos, esfuerzo y costes. O puede que se trate de un acuerdo verbal entre los miembros de un equipo ágil.
En cualquier caso, el plan debe comunicarse eficazmente a todos para que sepan qué se requiere y cuándo.
Un plan acordado es un contrato entre los participantes. Si el responsable de un equipo aprueba un plan, se compromete implícita o explícitamente a cumplir con la parte del contrato correspondiente a su equipo.
El plan es un contrato entre los participantes.
En los proyectos menos formales puede no existir ningún plan escrito ni compromiso. En estas circunstancias, el plan es una conversación continua entre los miembros del equipo. El equipo se reúne a diario y las tareas activas del plan se analizan en tiempo real. ¿En qué están trabajando las personas? ¿El progreso va según lo esperado? ¿Qué problemas están experimentando? ¿Qué problemas están bloqueando el progreso?
En todos los proyectos, el propósito de informar sobre el progreso es doble. Obviamente, es necesario comunicar en qué punto se encuentra cada persona en relación con su actividad actual en el proyecto. Pero el informe de progreso también es una comprobación periódica continua de que el progreso 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 una notificación cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso de Liderazgo en pruebas de Paul, que recomendamos encarecidamente para profundizar en este y otros temas. Si lo haces, utiliza nuestro código de cupón exclusivo QALEADOFFER para obtener un descuento de 60 $ sobre el precio completo del curso.
