Respuestas a la pregunta

Respuesta muy corta: No

Respuesta corta: Depende de la madurez y cultura de calidad del equipo.

Respuesta larga…

En los años que llevo dentro del mundo del QA, esta ha sido una pregunta recurrente y sobre la que siempre surgen debates interesantes.

Los que me conocéis, sabéis que no suelo ser muy dogmático en mis opiniones ya que, la realidad del día a día es compleja y si hay algo que debe guiar siempre cualquier decisión es EL CONTEXTO.

Introducción al Risk-Based Testing

Si llevas un tiempo en esto del testing, seguro que te suena el concepto de Risk-Based Testing (RBT). Básicamente, se trata de optimizar el coste (tiempo) / impacto de las pruebas. Se consigue priorizando la ejecución de aquellos casos que cubran las funcionalidades críticas de la aplicación o con una mayor probabilidad de error. Es definitiva, cubrir antes las zonas de mayor riesgo.

La teoría es clara, pero. ¿Cómo identificamos realmente las zonas de mayor riesgo en el día a día?

Hace años diseñé un itinerario formativo por niveles para el equipo de QA de Sngular. Era un path progresivo que llevaba desde el nivel inicial hasta la especialización avanzada.

Creo que está bien estructurado y sigue siendo muy útil. No obstante, el contexto ha cambiado radicalmente y no le vendría mal una actualización.

Cualquier itinerario debería seguir manteniendo una base sólida de testing. Porque no se trata de abandonar los fundamentos, sino de construir sobre ellos de forma diferente.

Hace unas semanas escribí en la Bonilista sobre el aporte de valor del testing en IT. El mensaje que quise transmitir fue claro: el testing no va de “hacer pruebas”, sino de su impacto en el negocio.

Esa era la idea principal de mi artículo, pero David me retó a añadir cómo veo el futuro del QA con la evolución de las IAs. Entonces dejé algunas ideas básicas que ahora quiero ampliar.

Hace unos años fui a un nutricionista. No tenía ningún problema con la comida, pero quería verme mejor. Cuando llegué, me preguntó cuál era mi objetivo. “Bajar grasa y ganar músculo”, le dije. En aquel momento, su respuesta me dejó descolocado: “Eso es imposible. No funciona así. Primero tienes que hacer una cosa y luego la otra. Las dos a la vez no pueden ser”.

Trabajando en el mundo de la calidad, me he dado cuenta de que esta conversación resume perfectamente uno de los mayores problemas cuando los equipos intentan mejorar sus prácticas de testing. Se parte de objetivos contradictorios o poco claros.