Liderazgo en Pruebas: Ejecutando un Proyecto de Pruebas
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 algunos años de experiencia—especialmente aquellos en equipos ágiles—a sobresalir en sus roles de líder y gestión de pruebas.
En el artículo anterior, hablamos sobre la planificación de un proyecto de pruebas y lo que se debe considerar. Ahora que has afilado tu hacha, por así decirlo, es el momento de ejecutar.
Suscríbete a la newsletter 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 ampliamente para profundizar en este y otros temas. Si lo haces, usa nuestro código exclusivo QALEADOFFER para obtener $60 de descuento en el precio completo del curso.
¿Estás listo?
Gladiadores, ha llegado el momento de hacer el trabajo. El propósito de este artículo es guiarte sobre cómo ejecutar un proyecto de pruebas. Cubriré los siguientes temas:
- La clásica presión sobre las pruebas
- Informe de éxito y fracaso
- Erosión de la cobertura
- Gestión de incidentes
- Gestión de la fase final
Entonces, ¿estás listo? Hay cuatro aspectos críticos:
- Personas – ¿está tu equipo listo?
- Entornos – ¿tienes las tecnologías, datos, dispositivos e interfaces necesarias para implementar pruebas significativas?
- Conocimiento – ¿has preparado tus pruebas con un nivel de detalle adecuado, o tu equipo está listo y en capacidad de explorar y probar el sistema de manera dinámica?
- Sistema bajo prueba – ¿el software o sistema que vas a probar está realmente disponible?
Los tres primeros aspectos están bajo tu control o tienes los medios para monitorear, gestionar y coordinar acciones para proveer personas, entornos y conocimiento. El sistema bajo prueba es otro asunto. Si el sistema bajo prueba se entrega tarde, no puedes empezar de manera significativa con las pruebas. Esta es la clásica presión sobre las pruebas.
¿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
La clásica presión sobre las pruebas
Cualquiera que haya probado sistemas ha experimentado la entrega tardía del sistema a probar. En casi todos los niveles, desde componentes hasta sistemas completos, los desarrolladores se encuentran con problemas y la entrega se retrasa o es incompleta. En la mayoría de circunstancias, cuando se ha asignado un periodo de tiempo para realizar las pruebas, la fecha límite no se mueve y las pruebas se ven comprimidas. Esto obliga a los equipos a elegir entre calidad y rapidez. Para encontrar herramientas que ofrezcan lo mejor de ambos mundos, revisa nuestra lista de mejores plataformas de pruebas de software.
Entrega parcial e incremental
Aunque no se pueda entregar el sistema completo para pruebas, se puede entregar alguna funcionalidad—un sistema parcial—con la promesa de que versiones posteriores contendrán el resto de la funcionalidad. En cualquier momento, el estado de las características en una entrega será:
- Completadas según lo requerido: estas características son comprobables—al menos de forma aislada.
- Incompletas: las características omiten funcionalidad y/o se sabe que tienen errores.
- Faltantes: pospuestas para entregarse en una versión posterior.
Con respecto a las funcionalidades disponibles, puede ser posible probarlas de manera aislada. Sin embargo, pueden depender de datos creados por otras funciones aún no disponibles, lo que podría dificultar su prueba.
Puede que las funcionalidades estén disponibles, pero la salida de esas funcionalidades no puede ser verificada por otras funciones que todavía no existen, por lo que será necesario examinar la base de datos de pruebas antes y después. Es casi seguro que tus pruebas de extremo a extremo que requieren cadenas comprobables de funcionalidades estarán bloqueadas en su mayoría.
En casi todos los aspectos, las pruebas de sistema a nivel de sistemas parciales se ven seriamente dificultadas.
Defendiendo las pruebas
Tu equipo debe avanzar, aunque sea con esfuerzo. Si el sistema no está disponible, o sólo está parcialmente disponible para el equipo, tendrás que gestionar expectativas y defender tu plan.
Tu plan para las pruebas, ya sea a pequeña o gran escala, depende de la disponibilidad del sistema—esto es una suposición—por lo que tu plan debe cambiar. Puede que no documentes criterios formales de entrada, pero el mensaje es el mismo:
Los criterios de entrada son suposiciones de planificación: si estos criterios no se cumplen, tus suposiciones de planificación son incorrectas y el plan debe ajustarse.
Ya sea que estés esperando a que se entregue el sistema o tengas acceso a un sistema parcial, rápidamente te quedarás sin cosas útiles que hacer. Entonces tendrás una conversación difícil con tu product owner o gestor de proyecto. Si la fecha límite de finalización no se mueve, te verás obligado a realizar menos pruebas. Algunas funcionalidades pueden ser menos probadas o incluso quedar fuera del alcance de las pruebas por completo.
El gerente puede creer que podrás recuperar el tiempo más adelante, pero esto casi nunca es posible en la práctica.
El tiempo de pruebas que se pierde debido a entregas tardías o parciales no se puede recuperar simplemente ‘trabajando más duro’.
¿Por qué se retrasa la fase de pruebas? Hay muchas causas posibles, pero tienden a seguir uno de estos patrones:
- No se pueden configurar los entornos a tiempo. Las personas empezaron tarde, estaban demasiado ocupadas o no estaban cualificadas para crear un entorno de pruebas significativo. Lo que está disponible es parcial, está mal configurado o es incompleto.
- La entrega se retrasa porque se subestimó la magnitud del trabajo.
- La entrega se retrasa porque el software contiene demasiados errores, es difícil de probar y arreglar.
- La entrega se retrasa porque al equipo de desarrollo le faltan las habilidades, experiencia o competencia en el dominio empresarial o en las tecnologías que utilizan.
- La entrega se retrasa porque el desarrollo comenzó tarde.
- La entrega se retrasa porque los requisitos continúan cambiando.
Excluidos de la lista anterior están los actos de fuerza mayor y otros factores externos fuera del control del equipo del proyecto. Si el gestor de proyecto insiste en que la fecha límite de pruebas no cambia y el alcance de las pruebas también está fijado, tienes un desafío importante. En todos los casos anteriores, las causas de las entregas tardías son motivos para hacer más pruebas, no menos.
Si el trabajo de desarrollo se subestimó, probablemente el de pruebas también. Si el software tiene muchos fallos, las pruebas tardarán más. Si los desarrolladores carecen de habilidades, el software probablemente será deficiente y llevará más tiempo probarlo. Si los desarrolladores comenzaron tarde (¿por qué?) y el alcance no cambió, ¿por qué deberían reducirse las pruebas? Si los requisitos cambian, probablemente tus planes ya están equivocados: trabajar sobre un mal plan inevitablemente complica las cosas.
¿Cuántas de las causas comunes de retraso en las entregas sugieren que se necesita menos pruebas? Ninguna. Defiende tu plan.
Informe de Éxito y Fracaso
La mayoría de los testers saben que una prueba efectiva requiere curiosidad, persistencia y un olfato para el problema. La principal motivación es provocar fallos y generar suficiente evidencia para que los fallos puedan rastrearse hasta los defectos y, posteriormente, corregirse.
Aunque encontrar (y corregir) defectos es bueno para la calidad del producto, comunicar defectos suele sentirse como si estuvieras dando malas noticias a alguien. Esto podría ser a un desarrollador que cometió un error en algún punto y debe corregirlo, o podrías estar informando a los interesados que alguna funcionalidad crítica no funciona correctamente y el sistema se retrasará.
A nadie le gusta dar malas noticias y es natural sentirse reacio a incomodar a otras personas, especialmente a colegas cercanos. Pero la sensación de que tu noticia es buena o mala no es un sentimiento que le corresponda al mensajero.
Los defectos siempre son malas noticias para alguien, pero el papel de las pruebas no es ser juez de esta manera. En ciertos aspectos, el tester es como un periodista, en busca de la verdad. La historia "El Hijo del Elefante" de Kipling incluye los siguientes versos:
Yo tengo seis honrados sirvientes:
(Ellos me enseñaron todo lo que sé)
Sus nombres son Qué y Dónde y Cuándo
Y Cómo y Por qué y Quién.
De la misma manera que un periodista cuenta una noticia, tú cuentas lo que has descubierto durante las pruebas de un sistema.
La verdad —las noticias— pueden ser buenas o malas, pero tu responsabilidad es simplemente buscar tanto los problemas como los éxitos lo mejor que puedas. Estás tratando de averiguar qué hace un sistema y cómo lo hace.
Al final de un proyecto el objetivo es entregar a producción con la menor cantidad de problemas pendientes posible. Quieres que todas tus pruebas pasen, pero el camino al éxito está obstaculizado por los fallos que se deben investigar y resolver. Tu objetivo táctico es encontrar problemas rápidamente, pero tu objetivo último es no tener ningún problema que reportar.
Para informar con precisión el éxito o fracaso de tu proyecto de pruebas, considera integrar herramientas avanzadas de gestión de pruebas que ofrezcan análisis completos
Debes actuar como un periodista de investigación: buscar la historia con una mente crítica e independiente. Como escribió Kipling:
Si puedes encontrarte con el Triunfo y el Fracaso y tratar a esos dos impostores de la misma manera…
Entonces estarás manteniendo la calma y haciendo un buen trabajo para tu proyecto y las partes interesadas.
Erosión de la Cobertura
Sea cual sea el objetivo de cobertura que se establezca al inicio de las pruebas, varios factores conspiran para reducir la cobertura realmente alcanzada. Erosión es un término apropiado ya que realmente refleja la disminución gradual del alcance de las pruebas planificadas y la inevitable realización de que no todas las pruebas planificadas podrán ejecutarse en el tiempo disponible.
La erosión de la cobertura tiene varias causas antes de la ejecución de la prueba:
- En primer lugar, los planes de prueba identifican los riesgos que deben abordarse y el enfoque que se utilizará para abordarlos. Los planes suelen asumir un presupuesto para las pruebas, que siempre es un compromiso.
- Requisitos, diseños y especificaciones del sistema que son pobres, inestables o están incompletos dificultan la especificación de las pruebas. La cobertura del sistema se ve comprometida por la falta de detalle en las especificaciones.
- La tardía disponibilidad o inadecuación de los entornos de prueba hacen que ciertas pruebas planificadas sean poco prácticas o no tengan sentido. Las pruebas de integración a mayor escala pueden ser imposibles de ejecutar según lo planeado porque no se pueden poner a disposición todas las interfaces o sistemas de integración.
- Las pruebas de rendimiento pueden verse comprometidas porque los entornos carecen de escala o no reflejan la producción.
- La entrega tardía del software bajo prueba significa que, si los plazos permanecen fijos, la cantidad de pruebas dentro del alcance debe reducirse.
Erosión de la cobertura de ejecución de pruebas durante la ejecución de pruebas también tiene varias causas:
- Si la calidad del software a probar es baja al entrar en una fase de pruebas, ejecutar las pruebas puede ser especialmente frustrante. Las pruebas más básicas pueden fallar y los defectos encontrados pueden ser tan fundamentales que los desarrolladores necesitan más tiempo del previsto para solucionarlos. Si las pruebas se suspenden porque la calidad del software es demasiado baja, estarás con retrasos. Si la fecha límite no se mueve, algunas pruebas quedarán fuera del alcance.
- Si aparecen más fallos de los previstos, el ciclo de corrección y re-prueba tomará más tiempo y se acabará el tiempo para completar todas las pruebas.
- Cuando se agota el tiempo y se toma la decisión de liberar, no todas las pruebas estarán completas. O bien algunas pruebas nunca fueron alcanzadas en el plan, o algunos fallos restantes bloquean la finalización de pruebas fallidas. Cuando la fecha de puesta en producción no se mueve, este es el clásico apretón al esfuerzo de pruebas mencionado anteriormente.
Enfrentar la erosión de la cobertura de las pruebas es uno de los desafíos que los testers enfrentan en todos los proyectos. Rara vez todo va sin problemas y reducir el tiempo de pruebas (y la cobertura) suele ser la única opción para mantener el proyecto en marcha.
No es incorrecto reducir la cantidad de pruebas; lo incorrecto es reducir las pruebas arbitrariamente. Por lo tanto, al tomar decisiones sobre qué pruebas recortar, es necesario revisar el impacto sobre los objetivos de prueba y los riesgos por abordar. Puede que debas tener algunas conversaciones incómodas con las partes interesadas.
Cuando el impacto es significativo, puede que necesites facilitar una reunión entre quienes piden los recortes (típicamente la dirección del proyecto) y aquellos cuyos intereses pueden verse afectados por dichos recortes (las partes interesadas). Tu función es exponer la situación respecto a las pruebas completadas, el estado actual conocido del sistema probado, las pruebas que fallan y/o bloquean el progreso, y la cantidad de pruebas que queda por ejecutar.
Tus planes y modelos articulan el alcance original de las pruebas y son críticos para ayudar tanto a las partes interesadas como a la dirección a comprender las brechas y riesgos pendientes y tomar la decisión de continuar o detener las pruebas.
Gestión de Incidentes
Una vez que el proyecto entra en las fases de Pruebas del Sistema y Pruebas de Aceptación, el avance suele estar impulsado en gran medida por los incidentes que ocurren durante la ejecución de las pruebas. Los incidentes desencadenan actividades en el resto del proyecto, y las estadísticas de incidentes a veces pueden proporcionar una buena visión sobre el estado del proyecto. Al categorizar los incidentes, debemos pensar de antemano cómo se usará esa información posteriormente.
Un incidente es un evento no planificado que ocurre durante las pruebas y que puede tener alguna repercusión en la finalización exitosa de las pruebas, en la decisión de aceptación o en la necesidad de tomar otra acción.
Usamos un término neutral para estos eventos no planificados: incidente. No obstante, estos eventos a menudo se denominan con otros términos; algunos más neutrales que otros.
Las pruebas que fallan pueden denominarse observaciones, anomalías o incidencias; términos neutrales que no suponen una causa previa. Pero a veces se usan problemas, errores, defectos o fallos, los cuales presuponen que el sistema contiene un fallo. Sin embargo, esta puede ser una conclusión prematura y estas etiquetas pueden inducir a error.
Te sugerimos que reserves los términos error, defecto o fallo para los resultados del diagnóstico de fallos en la construcción del sistema bajo prueba, que suelen generar reprocesos para el equipo de desarrollo.
Los incidentes se manifiestan de dos maneras:
- Fallo del sistema: el sistema no se comporta como se espera en una prueba, es decir, falla de alguna manera o parece no cumplir algún requisito.
- Interrupción o debilitamiento de las pruebas: algún evento que afecta la capacidad de los evaluadores para completar sus tareas, como la pérdida o falla del entorno de prueba, o de los datos, interfaces, sistemas o servicios de apoyo integrados, o alguna otra influencia externa.
Fallo del sistema
Estos incidentes suelen ser los de mayor preocupación directa porque socavan la confianza en la calidad del sistema.
Interrupciones y pruebas debilitadas
Algunas organizaciones no tratan estos incidentes como incidentes en absoluto: consideran que las interrupciones son parte de los altibajos propios de los proyectos cuando llegan a su fin. Las pruebas debilitadas, aquellas en las que el entorno o la configuración es incorrecta, pueden ser atribuidas al equipo de pruebas (por la configuración o al menos por no comprobarla antes de probar).
En ambos casos, el progreso de las pruebas se ve afectado y, si eres quien gestiona el proceso, eres responsable de explicar los retrasos. Por esta razón, deberías registrar estos eventos como incidentes o pedir al equipo que lleve un registro de pruebas y anote las caídas del entorno, problemas de configuración o la falta de versiones adecuadas del software para probar. Si no lo haces, tendrás dificultades para justificar los retrasos en el progreso y esto podría reflejarse negativamente sobre ti y tu equipo.
¿Registrar incidentes o no?
Con la llegada de los enfoques ágiles y de entrega continua, la visión tradicional de la gestión de incidentes ha sido cuestionada. En los proyectos por etapas, los incidentes se tratan como posibles paquetes de trabajo para los desarrolladores, los cuales se aprueban según su gravedad y/o urgencia.
Existe un proceso formal, a menudo burocrático, que se debe seguir, mediante el cual los incidentes son revisados, priorizados y atendidos por el equipo de desarrollo (u otro equipo). Pueden utilizarse herramientas sofisticadas de gestión de incidentes.
En equipos pequeños y ágiles, la relación entre el evaluador y el desarrollador es cercana. El equipo en su conjunto puede reunirse diariamente para hablar de incidentes importantes pero, con mayor frecuencia, los errores se detectan, diagnostican, corrigen y se vuelven a probar de manera informal sin necesidad de registrar el incidente ni de involucrar a otros miembros del equipo o a personal externo de negocio o IT. Los errores más severos pueden discutirse e integrarse al trabajo de una historia de usuario, o agruparse en iteraciones o sprints dedicados a la corrección de errores.
Hablamos sobre el propósito y la necesidad de la documentación en un artículo anterior. Esa discusión también es pertinente para los incidentes. El equipo debe considerar si requiere una herramienta y proceso para gestionar incidentes y si esto es útil para el equipo y/o necesario para quienes están fuera del equipo.
Los equipos más grandes tienden a depender de procesos y herramientas para gestionar incidentes por tres razones:
- Para asegurarse de que los incidentes no se olviden
- Que los problemas graves sean revisados por las partes interesadas y la dirección del proyecto
- Para capturar métricas que podrían ser valiosas durante y después del proyecto.
Separando urgencia de gravedad
Cualquiera que sea el proceso de gestión de incidentes que adoptes, recomendamos asignar tanto un código de prioridad como de gravedad a todos tus incidentes.
- La prioridad se asigna desde la perspectiva de las pruebas y determina cuándo se resolverá un incidente. El tester debe decidir si un incidente es de alta o baja prioridad (o el grado intermedio que se permita). La prioridad indica la urgencia de este fallo para los propios testers y se basa en el impacto que la falla tiene en el resto de las pruebas.
- La gravedad se asigna desde el punto de vista del usuario y denota la aceptabilidad o no de (habitualmente) un defecto. Los usuarios finales o su dirección deberían asignar la gravedad, o (de manera más eficiente) corregir la valoración inicial de los testers si es necesario. La gravedad refleja el impacto de ese defecto para el negocio si no se corrige antes de la entrega. Generalmente, un defecto grave hace que el sistema no sea aceptable. Si un defecto es de baja gravedad, puede considerarse demasiado trivial para ser corregido antes de la puesta en producción, pero podría solucionarse en una versión posterior.
Si un incidente detiene las pruebas y las pruebas están en la ruta crítica, entonces todo el proyecto se detiene.
Un incidente de alta prioridad detiene todas las pruebas y, generalmente, el proyecto.
Lo importante a tener en cuenta con los esquemas de clasificación de incidentes es que no todo incidente urgente es grave y que no todo incidente grave es urgente.
Gestión de la recta final
Llamamos ‘recta final’ a las etapas finales de nuestro proceso de pruebas porque la gestión de las actividades de prueba durante estos últimos días, posiblemente frenéticos y estresantes, requiere una disciplina distinta a la del periodo anterior mucho más relajado de la planificación de pruebas.
Recuerda, el propósito de las pruebas es entregar información a las partes interesadas para que puedan tomar una decisión: aceptar, corregir, rechazar, ampliar el proyecto o abandonarlo por completo.
Si todos tienen una comprensión compartida de los modelos que se utilizarán para las pruebas, es mucho más fácil explicar qué ‘funciona’ (con respecto al modelo) y también dónde fallan las cosas y cuáles son los riesgos de estos fallos. Son los interesados quienes deben usar esta información para tomar sus decisiones, guiados por ti.
Uno de los valores de adoptar un enfoque de pruebas basadas en riesgos es que, cuando las pruebas se ven limitadas al final de un proyecto, usamos el riesgo residual para argumentar la importancia de seguir probando o incluso de añadir más pruebas.
Cuando la gerencia insiste en reducir las pruebas, los testers simplemente deberían presentar los riesgos que se están ‘intercambiando’. Esto es mucho más sencillo cuando se ha realizado una evaluación temprana de riesgos, utilizada para orientar las actividades de prueba y monitoreada durante todo el proyecto. Cuando la gerencia es consciente de los riesgos residuales de forma continua, es menos probable que decidan reducir las pruebas en primer lugar.
¡Y eso es todo amigos, buena suerte con sus 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 mucho para profundizar en este y otros temas. ¡Si decides hacerlo, usa nuestro cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso!
