Liderazgo en Pruebas: ¿Cuánto Testeo es Suficiente?
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 funciones de líder de pruebas y gestión.
En el artículo anterior, esbozamos un manifiesto sobre riesgos para ayudar a los gerentes. En este artículo, plantearemos la tradicional pregunta "¿Cuántas pruebas son suficientes?". Spoiler: depende de los 'stakeholders'.
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, el cual recomendamos mucho si quieres 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!
¿Cuántas pruebas son suficientes? Esta es la clásica, inabarcable y filosófica pregunta que todos los testers plantean porque sus propios stakeholders se la hacen a ellos.
Los stakeholders quieren saberlo porque desean tener la confianza de que los sistemas han sido probados adecuadamente, pero, dado que están pagando por ello y deben respetar fechas límite, también quieren saber el costo potencial de probar y cuánto tiempo tomará.
Por lo tanto, son los stakeholders quienes deben juzgar cuántas pruebas son suficientes. Tu trabajo como jefe de pruebas es aportarles el mayor valor posible ayudándoles a tomar una decisión. En este artículo abordaremos:
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 las pruebas para los stakeholders
- La teoría cuántica y la teoría de la relatividad (no física)
- Usar el lenguaje adecuado
- Estimaciones, presupuestos y negociación
Comencemos.
El valor de las pruebas para los stakeholders
Cada prueba que realizamos debe aportar valor a los stakeholders porque les proporciona evidencia para apoyar su toma de decisiones de cuatro formas:
- Evidencia de que el sistema cumplirá los objetivos de negocio del proyecto.
- Evidencia de que el sistema no fallará, o si falla, que el impacto del fallo es aceptable.
- Evidencia para reproducir, diagnosticar fallos y reparar y volver a probar el sistema fallido.
- Evidencia para apoyar la toma de decisiones en el contexto de un proyecto (aceptar, liberar, rechazar, etc.)
Nuestro objetivo al probar es crear pruebas que incrementen progresivamente la cobertura del sistema respecto a un modelo de pruebas reconocible. Nuestras pruebas deberían demostrar que el sistema cumple con los objetivos del negocio y que el riesgo de fallo es conocido y, con suerte, aceptable.
De los cuatro tipos de evidencia anteriores, los primeros tres sustentan el cuarto. En última instancia, los stakeholders necesitan tomar una decisión basada en la evidencia. Es su decisión, no la de los testers, así que son ellos quienes deben juzgar si tienen suficiente confianza. En cualquier caso, el valor de las pruebas está en el ojo del stakeholder.
Ahora bien, todo tester toma decisiones sobre qué probar usando un modelo formal o incluso la intuición. Estas decisiones se toman en función de algún valor percibido.
A menos que el tester también sea stakeholder, el tester generalmente evalúa el valor en función de una medida de completitud o cobertura. O, si conoce las prioridades de los stakeholders, en si la prueba apoyará alguna decisión de aceptación.
Las afirmaciones anteriores tienen consecuencias importantes.
En primer lugar, si no conoces la mentalidad del stakeholder, tu percepción del valor de la prueba probablemente no coincida con la suya. Si seleccionas pruebas sin tener en cuenta sus valores, cuando llegue el momento de presentar tus resultados, es posible que tus stakeholders encuentren que tienen datos insuficientes en algunas áreas y un exceso en otras. Seguramente no se sentirán tan confiados como deberían.
En segundo lugar, cuando diseñas o ejecutas una prueba, ¿cuál es su contribución a la toma de decisiones de los stakeholders? Si una prueba no aporta información incremental que respalde una decisión, o si a los stakeholders no les importa si tu prueba pasa o falla, entonces no debería estar en un plan de pruebas.
Decíamos en el artículo 3 sobre modelos que los modelos de prueba que utilices deben ser relevantes para los stakeholders. Si tus resultados de pruebas se corresponden con modelos que los stakeholders comprenden y valoran, entonces valorarán tu contribución.
La teoría cuántica y la teoría de la relatividad
Hay otros dos principios relativos al valor y la importancia de las pruebas. A uno lo llamo la Teoría Cuántica y al otro la Teoría de la Relatividad. Estos nombres suenan pretenciosos (y lo son, en tono de broma), pero describen dos fenómenos que sustentan todas las discusiones sobre el valor de las pruebas, su priorización y alcance.
Cuando ejecutamos una prueba, normalmente interpretamos el resultado como un éxito o un fallo. El juicio de aprobado/reprobado es un resultado binario: verdadero o falso, sí o no, uno o cero. Ese resultado de la prueba genera una cantidad discreta de evidencia. La evidencia se acumula a medida que ejecutamos más y más pruebas. Sea cual sea el resultado, esa prueba incrementa la cobertura de nuestro modelo de pruebas y el conocimiento que tenemos sobre el comportamiento del sistema. Las pruebas que no aportan a tu conocimiento no aportan valor.
Si una prueba no incrementa la cobertura de alguna manera, tiene poco valor.
El segundo aspecto es el valor de una prueba. ¿Cuál es el valor de una prueba? ¿Realmente podrías poner un valor en dólares, libras o euros sobre una sola prueba? Probablemente no. Pero lo que sí podemos hacer—y a menudo con bastante facilidad—es decir, ‘esta prueba es más valiosa que aquella’.
Supongamos que utilizamos un modelo de cobertura de código como la cobertura de sentencias. Podemos ejecutar una prueba que cubra cinco líneas de código o cinco mil líneas de código. ¿Cuál es el valor de cada una? Es difícil de decir. Pero si nuestro objetivo es la cobertura de sentencias, la segunda prueba tiene más valor.
No podemos poner un valor absoluto a ninguna prueba, pero normalmente podemos comparar pruebas e inferir un valor relativo de cada una. Es decir, si estamos bajo presión de tiempo, normalmente podemos decir que una prueba tiene menos valor que otra y, por lo tanto, excluir la primera prueba si es necesario.
Podemos comparar el valor de las pruebas pero solo si provienen del mismo modelo.
Necesitamos enfatizar, sin embargo, que estas comparaciones realmente solo tienen sentido si comparten el mismo modelo. Una prueba que cubre una amplia gama de condiciones extremas en un proceso probablemente tiene más valor que una prueba del camino ‘directo’. Las pruebas de extremo a extremo de un proceso complejo no se pueden comparar directamente con las pruebas unitarias de componentes críticos, por ejemplo.
Aunque las teorías de la física cuántica y la relatividad no se apliquen directamente a las pruebas, los principios de adaptabilidad y perspectiva sí lo hacen. Encuentra una herramienta de gestión de pruebas que se alinee con estos principios para optimizar tu estrategia de pruebas.
Usar el Lenguaje Adecuado
Ahora que hemos establecido quién es responsable de decidir ‘cuánto testing es suficiente’, ¿cómo podemos nosotros, como testers concienzudos, apoyar esa toma de decisiones?
Observa que nuestro tratamiento del valor de las pruebas es muy similar a nuestra evaluación de riesgos. Como se discutió en el artículo anterior, es muy difícil asignar valores numéricos a la escala o exposición al riesgo. Sin embargo, normalmente es posible comparar un riesgo con otro y clasificarlos para tomar decisiones sobre los riesgos que quedan dentro del alcance de las pruebas.
Utilizando el lenguaje del riesgo, los testers serán escuchados por la gerencia.
Los líderes de equipos de desarrollo a menudo parecen ser escuchados por la dirección, incluso cuando hablan en términos técnicos. La diferencia es que presentan la tecnología como algo emocionante y beneficioso. Cuando los testers hablan en sus propios términos técnicos—sobre los detalles ‘administrativos’ de las pruebas, como las estadísticas de incidencias—el mensaje tiende a ser negativo, y los gerentes pueden aburrirse o irritarse.
La gerencia puede ya considerar que los testers son un poco aburridos como especie, pero esto es quizás porque muchos gerentes realmente no entienden lo que hacen los testers ni el valor que aportan. Así que los testers deben elevar su lenguaje al nivel de la gerencia.
Las pruebas basadas en riesgos hablan con el usuario y la gerencia de proyectos en su idioma.
Estas son personas que piensan mucho en términos de riesgos y beneficios. Si los testers se dirigen a ellas en términos similares, la gerencia es más propensa a escuchar a los testers y, en consecuencia, tomar mejores decisiones. Al relacionar las pruebas con los objetivos del proyecto, podemos centrar la atención en los entregables de mayor valor para las partes interesadas, de modo que dediquemos nuestro tiempo a probar lo más importante.
Además, a medida que se avanza en las pruebas, podemos demostrar que los beneficios más valiosos ya están disponibles. La decisión de lanzamiento es, en última instancia, un juicio de si los beneficios obtenidos superan los riesgos, por lo que las pruebas proporcionarán mejores datos a la administración para que puedan basarse en ellos para tomar decisiones.
Usa el lenguaje de los riesgos (y los beneficios) para delimitar, planear y reportar el progreso de las pruebas.
Obviamente, los testers necesitan hablar técnicamente con los desarrolladores y otros perfiles técnicos. Por ejemplo, la calidad de los informes de incidencias es un factor clave para conseguir que los fallos se corrijan rápida y fiablemente. Simplemente digo que, al dirigirse a la gerencia, el tester debe hablar en términos de riesgos abordados y pendientes, en lugar de pruebas, incidencias y errores.
Estimaciones, Presupuestos y Negociación
Al inicio de un nuevo proyecto tu jefe de proyecto te pregunta: “Necesito programar y dotar de recursos el testing a tiempo; ¿puedes darme una estimación de cuántas personas y cuánto tiempo necesitas para hacer las pruebas del sistema?”
Piensas un poco y vas a hablar con el jefe.
“Necesito seis testers durante ocho semanas.”
El gerente de proyecto piensa por un momento y consulta su cronograma y plan de recursos preliminar.
“Puedes tener cuatro testers durante seis semanas y eso es todo.”
Tú objetas diciendo: “¡Pero nos llevará más de seis semanas! Costará más de lo que has asignado para probar este sistema. El sistema es más grande que la última vez. Es más complicado. Sin duda, es demasiado arriesgado que escatimemos en las pruebas esta vez. Simplemente no es suficiente.”
Pero el gerente es inflexible, murmurando algo sobre otras dependencias, autoridades superiores y demás…
¿Cuál crees que era el objetivo de hacer una estimación si el gerente siempre supo el presupuesto que debía tener? ¿Qué relevancia tiene un presupuesto arbitrario para el trabajo que se debe realizar? ¿Por qué nunca toman en serio las pruebas? Los desarrolladores siempre reciben el tiempo que solicitan, ¿no? No parece justo.
Puedes sentirte molesto y que tu juicio profesional está siendo menospreciado. Pero el problema es, y siempre fue, que el presupuesto de pruebas en esta situación era fijo. Todo lo que puedes hacer es averiguar cuáles son las pruebas más valiosas que puedes realizar con tu presupuesto.
Pero, muchas veces, el PM sí quiere saber cuánto tiempo tomarán las cosas para poder ajustar el plan. Si crees que estás en una negociación, necesitas argumentos para negociar. También necesitas discutir los resultados del plan, no los insumos. El alcance es el resultado de la planificación, el esfuerzo que aplicas es un insumo.
Necesitas negociar el alcance.
La negociación de los presupuestos de pruebas siempre debe ser sobre el alcance, no sobre el esfuerzo.
El alcance puede presentarse en uno o varios formatos, y la forma en que presentas y discutes el alcance variará, pero aquí hay algunos patrones comunes. Sea cual sea el alcance que tengas, lo usarás como base para tu estimación y tu defensa de la misma:
Alcance como inventario de requisitos o funcionalidades
Cuando se recorte la estimación en un 30%, pregunta: “¿Qué 30% del sistema no debería probar?”
Alcance como inventario de riesgos
Cuando se recorte la estimación en un 30%, pregunta: “¿Qué riesgos de las partes interesadas debo eliminar del plan?”
Alcance como modelo tabulado o gráfico
Cuando se recorte la estimación en un 30%, pregunta: “¿Qué caminos/recorridos/elementos debo indicar a las partes interesadas que no se probarán?”
Espero que veas lo que está ocurriendo aquí.
- El alcance de las pruebas se basa en algún modelo que se haya discutido y acordado previamente con las partes interesadas. Este alcance es provisional, sujeto a la disponibilidad de recursos y tiempo, y debes asegurarte de que las partes interesadas sean conscientes de ello.
- Realizas la estimación sobre la base de ese alcance provisional. Utiliza el modelo (riesgos, requisitos, proceso de negocio o cualquier otro modelo) para establecer un objetivo de cobertura, cuenta los ítems de cobertura y estima sobre esa base.
- Mantén una conversación con el Gerente de Proyecto. Si la estimación es demasiado alta, utiliza las respuestas anteriores para activar las discusiones con las partes interesadas.
Como tester o jefe de pruebas, no estás en una buena posición para negociar pruebas con el gerente de proyecto. Las partes interesadas son quienes tienen las preocupaciones y, si compartes los modelos que definen el alcance de las pruebas, tendrán opiniones, se involucrarán en el alcance y podrán defenderlo. Los stakeholders también son responsables de justificar el presupuesto para su sistema, por lo que están en la mejor posición para equilibrar el costo de las pruebas con la necesidad de abordar sus preocupaciones.
Para Reflexionar
Piénsalo: en tus proyectos, ¿quién tiene la responsabilidad de definir la cantidad de pruebas que se realizarán?
- ¿Eres tú como tester quien define el alcance y la cantidad de pruebas?
- ¿El gerente de proyecto fija un presupuesto y tú haces lo mejor que puedes con el tiempo asignado?
- ¿Se negocia el alcance con el gerente de proyecto y las partes interesadas hasta encontrar un equilibrio entre el esfuerzo y el alcance de las pruebas a realizar?
Una de las responsabilidades clave de un tester es asegurar que el proyecto sea consciente de los riesgos del producto que se están asumiendo y documentarlos. Sólo si estos riesgos son visibles la gestión puede reconocer los riesgos que asumen al recortar pruebas.
No existe una fórmula para la cantidad exacta de pruebas. En la mayoría de los entornos, el nivel de pruebas sólo puede determinarse por consenso entre gestión del proyecto, patrocinadores de clientes, desarrolladores, especialistas técnicos y los testers: se consideran dentro del alcance aquellas pruebas que abordan los riesgos de interés.
La cantidad adecuada de pruebas debe determinarse por consenso, con el tester facilitando y aportando información en ese proceso.
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 Leadership In Test de Paul, que recomendamos para profundizar en este y otros temas. Si lo haces, usa nuestro código exclusivo QALEADOFFER y obtén $60 de descuento en el precio total del curso.
Artículos Relacionados: