Hoy os quiero compartir cómo estamos aprovechando la IA para mejorar el desarrollo de aplicaciones en Technosylva. Hemos creado el plugin “Quality Flow”.

Cuando empecé con la idea de desarrollar este conjunto de skills para desarrollo y aseguramiento de la calidad, me paré a pensar en las cosas que sabemos que deberíamos estar haciendo pero que finalmente no hacemos por pereza, por silos en la empresa, por falta de conocimiento técnico, por falta de tiempo, etc.

Spoiler: la automatización fue lo último que tocamos

En marzo cumplí un año en Technosylva. Y como en casi todo lo que hago, necesito pararme a reflexionar: ¿qué funcionó? ¿qué no? ¿dónde estamos realmente?

Este artículo es eso. Una revisión de un año intenso y lleno de aprendizajes.

El contexto: de consultora a producto

Venía de nueve años en Sngular. Una consultora española donde llegamos a ser casi 1.500 personas. A pesar del día a día intenso, ya estaba en mi zona de confort. Un mundo conocido, con sus reglas, sus ritmos y sus inercias.

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?