Liderazgo en Pruebas: Ejecución de un Proyecto de Pruebas
Nota del editor: Bienvenido a la serie Liderazgo en Pruebas del gurú y consultor en 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 gestor 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 el hacha, por así decirlo, es momento de ejecutar.
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 para una exploración más profunda de este y otros temas. Si decides hacerlo, ¡usa nuestro cupón exclusivo QALEADOFFER y obtén $60 de descuento en el precio total del curso!
¿Estás listo?
Gladiadores, ha llegado el momento de hacer el trabajo. El objetivo de este artículo es guiarte en cómo ejecutar un proyecto de pruebas. Voy a cubrir:
- La clásica presión sobre las pruebas
- Informe de éxitos y fallos
- Erosión de la cobertura
- Gestión de incidentes
- Gestión de la fase final
¿Y bien, estás listo? Hay cuatro aspectos críticos:
- Personas – ¿tu equipo está listo?
- Entornos – ¿tienes las tecnologías, datos, dispositivos e interfaces para implementar pruebas significativas?
- Conocimiento – ¿has preparado tus pruebas con el nivel de detalle adecuado, o tu equipo está preparado y es capaz 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 cuentas con 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 hacer ningún avance significativo en las pruebas. Esta es la clásica presión sobre las pruebas.
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
La clásica presión sobre las pruebas
Cualquiera que haya probado sistemas ha experimentado la entrega tardía del sistema a probar. Prácticamente en 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 los casos, cuando se asigna un periodo de tiempo para realizar las pruebas, el plazo no se mueve y las pruebas se ven comprimidas. Esto obliga a los equipos a elegir entre calidad y velocidad. Si quieres herramientas que ofrecen lo mejor de ambos mundos, revisa nuestra lista de las principales plataformas de pruebas de software.
Entrega parcial e incremental
Aunque el sistema completo no pueda ser entregado para pruebas, algunas funcionalidades—un sistema parcial—pueden entregarse con la promesa de que lanzamientos posteriores contendrán las funcionalidades restantes. En cualquier momento, el estado de las características en una entrega será:
- Completadas según lo requerido: estas funcionalidades son comprobables—al menos de manera aislada.
- Incompletas: las funcionalidades omiten partes o se sabe que tienen fallos.
- Ausentes: pospuestas para un lanzamiento posterior.
Respecto a las funcionalidades disponibles, puede que sea posible probarlas de forma aislada. Sin embargo, pueden depender de datos generados por otras funcionalidades aún no disponibles, lo que podría dificultar la prueba.
Puede que tengas funcionalidades disponibles, pero la salida de esas funcionalidades no puede ser verificada por otras funcionalidades aún no implementadas, por lo que será necesario examinar la base de datos de pruebas antes y después. Es casi seguro que las pruebas de extremo a extremo que requieran cadenas comprobables de funcionalidades estarán en gran medida bloqueadas.
En casi todos los aspectos, las pruebas a nivel de sistema de sistemas parciales se ven gravemente afectadas.
Defendiendo las pruebas
Tu equipo debe avanzar, aunque sea a paso lento. Si el sistema no está disponible, o solo está parcialmente disponible para el equipo, tendrás que gestionar las expectativas y defender tu plan.
Tu plan de pruebas, ya sea a pequeña o gran escala, depende de que el sistema esté disponible—eso es un supuesto—por lo que tu plan debe cambiar. Puede que no documentes criterios de entrada formales, pero el mensaje es el mismo:
Los criterios de entrada son supuestos de planificación—si estos criterios no se cumplen, tus suposiciones de planificación son erróneas y se debe ajustar el plan.
Tanto si estás esperando a que se entregue el sistema como si tienes acceso a un sistema parcial, pronto te quedarás sin cosas útiles que hacer. Entonces tendrás una conversación difícil con tu responsable de producto o director de proyecto. Si no se mueve la fecha límite de finalización, te verás obligado a realizar menos pruebas. Algunas funcionalidades pueden recibir menos pruebas o incluso quedar fuera del alcance del testeo por completo.
El responsable puede creer que podrás recuperar el tiempo más adelante, pero esto rara vez es factible en la práctica.
El tiempo de pruebas perdido por entregas tardías o parciales no se puede recuperar simplemente ‘trabajando más duro’.
¿Por qué se retrasan las pruebas? Hay muchas causas posibles, pero suelen responder a uno de estos patrones:
- Los entornos no se pueden configurar a tiempo. Las personas empezaron tarde, estaban demasiado ocupadas o no tenían la cualificación para crear un entorno de pruebas significativo. Lo disponible es parcial, está mal configurado o incompleto.
- La entrega se retrasa porque se subestimó el tamaño del trabajo.
- La entrega se retrasa porque el software tiene errores, es difícil de probar y de corregir.
- La entrega se retrasa porque el equipo de desarrollo carece de habilidades, experiencia o competencia en el dominio del negocio o en las tecnologías que utilizan.
- La entrega se retrasa porque el desarrollo empezó tarde.
- La entrega se retrasa porque los requisitos cambian constantemente.
Excluidos de la lista anterior quedan los desastres naturales y otros factores externos fuera del control del equipo de proyecto. Si el director de proyecto insiste en que la fecha límite para las pruebas no cambia y el alcance de las pruebas también está fijado, tienes un reto importante. En todos los casos anteriores, las causas de entrega tardía son argumentos para hacer más pruebas, no menos.
Si se subestima el trabajo de desarrollo, probablemente también se subestiman las pruebas. Si el software tiene errores, las pruebas llevarán más tiempo. Si los desarrolladores carecen de habilidades, es probable que el software sea deficiente y tarde más en ser probado. Si los desarrolladores empezaron tarde (¿por qué?) y el alcance no ha cambiado, ¿por qué deberían reducirse las pruebas? Si los requisitos cambian, es probable que tus planes estén equivocados de todos modos —seguir un mal plan inevitablemente complica las cosas.
¿Cuántas de las causas habituales de entrega tardía sugieren que se necesitan menos pruebas? Ninguna. Defiende tu plan.
Informar de Éxitos y Fracasos
La mayoría de testers saben que una prueba eficaz requiere curiosidad, persistencia y olfato para el problema. La motivación principal es provocar fallos y reunir suficientes evidencias para que esos fallos se puedan rastrear hasta defectos que luego puedan corregirse.
Aunque encontrar (y corregir) defectos mejora la calidad del producto, comunicar los defectos a menudo se siente como si estuvieses dando malas noticias a alguien. Puede ser a un desarrollador que ha cometido un error en algún sitio y debe arreglarlo, o podrías estar informando a los interesados de que alguna funcionalidad crítica no funciona correctamente y que el sistema será retrasado.
A nadie le gusta dar malas noticias y es natural sentir cierta reticencia a molestar a los demás, especialmente a colegas cercanos. Pero la sensación de que tu noticia es buena o mala no es algo que deba preocupar al mensajero.
Los defectos siempre son malas noticias para alguien, pero la función de las pruebas no es juzgar de ese modo. En algunos aspectos, el tester es como un periodista, en busca de la verdad. La historia de “El Hijo del Elefante” de Kipling incluye los versos:
Tengo seis honrados servidores:
(Me enseñaron todo cuanto sé)
Sus nombres son Qué y Dónde y Cuándo
Y Cómo y Por qué y Quién.
Del mismo modo que un periodista narra una noticia, tú estás contando la historia de lo que descubriste al probar un sistema.
La verdad —la noticia— puede ser buena o mala, pero tu responsabilidad es simplemente detectar tanto los problemas como los éxitos lo mejor posible. Estás intentando descubrir lo que hace un sistema y cómo lo hace.
Al final de un proyecto, el objetivo es entregar en producción con el mínimo de problemas pendientes posible. Deseas que todas tus pruebas pasen, pero el camino al éxito está plagado de fallos de prueba que deben investigarse y resolverse. Tu objetivo táctico es encontrar problemas rápidamente, pero tu objetivo final es no tener problemas que reportar.
Para informar con precisión sobre el éxito o fracaso de tu proyecto de testeo, considera integrar herramientas avanzadas de gestión de pruebas que ofrezcan análisis completos.
Debes comportarte como un periodista de investigación: buscando la historia con una mentalidad crítica e independiente. Como escribió Kipling:
Si puedes enfrentarte con el Triunfo y el Desastre, y tratar por igual a esos dos impostores …
Entonces mantendrás la cabeza fría y harás un buen trabajo para tu proyecto y los interesados.
Erosión de la Cobertura
Cualesquiera que sean los objetivos de cobertura existentes al inicio de las pruebas, varios factores conspiran para reducir la cobertura realmente alcanzada. Erosión es un término apropiado a utilizar ya que realmente refleja la reducción paulatina 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 las pruebas:
- En primer lugar, los planes de prueba identifican los riesgos a tratar y el enfoque que se usará para abordarlos. Los planes suelen suponer un presupuesto para las pruebas, que siempre es un compromiso.
- Requisitos del sistema, diseños y especificaciones pobres, inestables o inacabados dificultan la especificación de las pruebas. La cobertura del sistema se ve comprometida por la falta de detalle en las especificaciones.
- La disponibilidad tardía o insuficiencia de los entornos de prueba hace que ciertas pruebas planificadas sean poco prácticas o carentes de sentido. Las pruebas de integración a gran escala pueden ser imposibles de ejecutar como se había planificado porque no se pueden disponer de todas las interfaces o sistemas con los que interactúa el software.
- Las pruebas de rendimiento pueden verse comprometidas porque los entornos carecen de escala o no reflejan el entorno de producción.
- La entrega tardía del software bajo prueba implica que, cuando los plazos permanecen fijos, debe reducirse la cantidad de pruebas dentro del alcance.
La erosión de la cobertura durante la ejecución de las pruebas también tiene varias causas:
- Si la calidad del software a probar es mala al entrar en una fase de pruebas, ejecutar las pruebas puede resultar especialmente frustrante. Las pruebas más básicas pueden fallar, y los defectos encontrados pueden ser tan fundamentales que los desarrolladores necesiten más tiempo del previsto para corregirlos. Si se suspende la prueba porque la calidad del software es demasiado baja, se retrasará el proyecto. Si el plazo no se mueve, se reducirá el alcance de algunas pruebas.
- Cuando surgen más defectos de los previstos, el propio ciclo de corrección y re-prueba lleva más tiempo y se puede agotar el tiempo disponible antes de completar todas las pruebas.
- Cuando el tiempo se agota, y se toma la decisión de liberar el producto, no todas sus pruebas estarán completas. Puede que algunas pruebas nunca se hayan ejecutado en el plan o que algunos defectos restantes bloqueen 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 que se refiere en el apartado anterior.
Enfrentar la erosión de la cobertura de pruebas es uno de los retos a los que se enfrentan los testers en todos los proyectos. Rara vez las cosas salen según lo previsto y reducir el tiempo dedicado a las pruebas (y la cobertura) suele ser la única opción para que el proyecto siga adelante.
No está mal reducir la cantidad de pruebas; sólo está mal reducirlas de manera arbitraria. En consecuencia, al elegir qué pruebas descartar, el impacto sobre los objetivos de las pruebas y los riesgos a tratar debe ser revisado. Puede que tengas que sostener algunas conversaciones difíciles con las partes interesadas para superarlo.
Cuando el impacto es significativo, puede que sea necesario facilitar una reunión entre quienes piden los recortes (normalmente la dirección del proyecto) y quienes pueden verse afectados por los recortes (las partes interesadas). Tu papel es exponer la situación en cuanto a las pruebas completadas, el estado actual conocido del sistema probado, las pruebas que fallan o bloquean el progreso, y la cantidad de pruebas que aún quedan por realizar.
Tus planes y modelos articulan el alcance original de las pruebas y son fundamentales para ayudar a las partes interesadas y a la dirección a comprender las carencias y riesgos pendientes, y decidir si se continúa probando o se detiene el proceso.
Gestión de Incidentes
Una vez que el proyecto avanza a las fases de Pruebas del Sistema y Pruebas de Aceptación, está fundamentalmente dirigido por los incidentes que se presentan 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 aportar una buena visión sobre el estado del proyecto. Al categorizar los incidentes, debemos pensar de antemano cómo se usará más tarde esa información.
Un incidente es un evento no planificado que ocurre durante la realización de pruebas que puede tener alguna repercusión sobre la finalización exitosa de las pruebas, sobre la decisión de aceptación, o sobre la necesidad de tomar alguna otra medida.
Utilizamos un término neutro para estos eventos imprevistos – incidente. Sin embargo, estos eventos suelen denominarse con otros términos; algunos más neutros que otros.
Las pruebas que fallan pueden denominarse observaciones, anomalías o incidencias — términos neutros que no presuponen una causa. Pero a veces se utilizan palabras como problemas, errores, defectos o fallos — lo que presumiblemente implica que el sistema está defectuoso. Sin embargo, esto puede ser una conclusión prematura y esas etiquetas pueden inducir a error.
Sugerimos reservar los términos error, defecto o fallo para los resultados del diagnóstico de fallos en la construcción del sistema bajo prueba que, normalmente, generan reproceso para el equipo de desarrollo.
Los incidentes se manifiestan de dos maneras:
- Fallo del sistema: el sistema no se comporta como se esperaba durante una prueba, es decir, falla de algún modo o parece no cumplir algún requisito.
- Interrupción o menoscabo de las pruebas: algún evento afecta la capacidad de los testers de completar sus tareas, como pérdida o fallo del entorno de pruebas, de los datos o de las interfaces o de los sistemas o servicios integrados de soporte, o alguna otra influencia externa.
Fallo del Sistema
Estos incidentes suelen ser motivo de mayor preocupación porque minan la confianza en la calidad del sistema.
Interrupciones y pruebas socavadas
Algunas organizaciones ni siquiera consideran estos incidentes como tales: las interrupciones son vistas como parte natural de los proyectos al llegar a su fin. Por otro lado, las pruebas socavadas, aquellas en las que el entorno o la configuración de prueba es incorrecta, pueden ser achacadas al equipo de pruebas (por la configuración o, al menos, por no verificarla antes de realizar la prueba).
En ambos casos, el avance en las pruebas se ve afectado y, si estás gestionando el proceso, eres responsable de explicar los retrasos. Por este motivo, deberías registrar estos eventos como incidentes o pedir al equipo que lleve un registro de pruebas, anotando caídas del entorno, problemas de configuración o falta de versiones adecuadas de software para probar. Si no lo haces, te será difícil justificar los retrasos y podría repercutir negativamente sobre ti y el equipo.
¿Registrar incidentes o no?
Con la llegada de enfoques ágiles y de entrega continua, la visión tradicional de la gestión de incidentes se ha visto desafiada. En los proyectos secuenciales, los incidentes se consideran paquetes de trabajo potenciales 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 para revisar, priorizar y actuar sobre los incidentes, por parte del equipo de desarrollo (u otro equipo). Pueden estar involucradas herramientas sofisticadas de gestión de incidentes.
En equipos ágiles más pequeños, la relación entre probador y desarrollador es muy cercana. El equipo puede reunirse a diario para tratar incidentes mayores pero, con más frecuencia, los errores se detectan, diagnostican, corrigen y se vuelven a probar de forma informal, sin necesidad de registrar el incidente ni involucrar a otros miembros del equipo, ni al personal externo de negocio o IT. Los errores más graves pueden discutirse e integrarse en el trabajo relativo a una historia de usuario, o agruparse en iteraciones o sprints dedicados a la corrección de fallos.
Hemos hablado sobre el propósito y la necesidad de la documentación en un artículo anterior. Esa discusión también es pertinente en el caso de los incidentes. El equipo debe considerar si es necesario disponer de una herramienta y un proceso de gestión de incidentes, y si resulta útil para el equipo o exigido por personas ajenas a él.
Los equipos grandes tienden a depender de procesos y herramientas para gestionar los incidentes por tres razones:
- Para asegurar que los incidentes no sean olvidados
- Para que los problemas graves sean revisados por los interesados y la dirección del proyecto
- Para recopilar métricas que puedan resultar útiles durante y después del proyecto.
Distinguir 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 el punto de vista de las pruebas e influye en cuándo se resolverá un incidente. El probador debe decidir si un incidente es de alta o baja prioridad (o el grado intermedio permitido). La prioridad indica la urgencia de este fallo para los propios probadores y se basa en el impacto que la falla tiene sobre el resto de las pruebas.
- La gravedad se asigna desde la perspectiva del usuario e indica la aceptabilidad (o no) de un defecto (normalmente). Los usuarios finales o sus responsables deberían asignar la gravedad, o (de manera más eficiente) anular si lo consideran necesario el criterio inicial del probador. La gravedad refleja el impacto que tendría ese defecto en el negocio si no se corrigiera antes de la puesta en producción. Normalmente, un defecto grave hace que el sistema sea inaceptable. Si un defecto es de baja gravedad, puede considerarse demasiado trivial como para corregirlo antes del lanzamiento, pero podría solucionarse en una versión posterior.
Si un incidente detiene las pruebas y estas están en la ruta crítica, entonces todo el proyecto se detiene.
Un incidente de alta prioridad detiene todas las pruebas, y normalmente el proyecto.
Lo importante a tener en cuenta en los esquemas de clasificación de incidentes es que no todos los incidentes urgentes son graves y que no todos los incidentes graves son urgentes.
Gestión de la recta final
Llamamos a las etapas finales de nuestro proceso de pruebas la ‘recta final’ porque la gestión de las actividades de prueba durante estos días finales, que pueden ser frenéticos y estresantes, requiere una disciplina diferente de la que se requiere durante el período anterior, aparentemente mucho más relajado, de planificación de pruebas.
Recuerda, el propósito de las pruebas es proporcionar información a los interesados para que puedan tomar una decisión: aceptar, corregir, rechazar, extender el proyecto o abandonarlo por completo.
Si existe un entendimiento común sobre los modelos que deben utilizarse para las pruebas, resulta mucho más sencillo explicar qué ‘funciona’ (según el modelo), así como dónde las cosas fallan y los riesgos de estos fallos. Corresponde a los interesados utilizar 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 en una fase tardía del proyecto, podemos utilizar el riesgo residual para fundamentar la necesidad de seguir probando o incluso de añadir más pruebas.
Cuando la dirección insiste en reducir el tiempo de las pruebas, los testers simplemente deberían presentar los riesgos que están siendo "intercambiados". Esto es mucho más sencillo cuando se ha realizado una evaluación temprana de riesgos, utilizada para orientar las actividades de pruebas y monitoreada durante todo el proyecto. Cuando la dirección es consciente continuamente de los riesgos residuales, es menos probable que reduzcan las pruebas en primer lugar.
¡Eso es todo amigos, buena suerte con sus pruebas!
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando se publiquen nuevas partes de la serie. Estas entradas son extractos del curso de Liderazgo en Pruebas de Paul, el cual recomendamos encarecidamente para profundizar en este y otros temas. Si decides inscribirte, ¡usa nuestro cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso!
