Probar la aplicación justo antes del lanzamiento ya no es suficiente para garantizar la calidad del software moderno, según un artículo publicado en el blog de JetBrains por Kerry Beetge. La idea central es distribuir las comprobaciones de calidad a lo largo de todo el ciclo de vida del desarrollo de software, de modo que los defectos aparezcan más cerca del momento en que se introducen, en lugar de descubrirse después de acumular cambios y complejidades adicionales.
El artículo relaciona esta transformación con la creciente dependencia del código generado mediante inteligencia artificial; señala, citando una encuesta de Stack Overflow de 2025, que el 84% de los desarrolladores utiliza herramientas de inteligencia artificial o planea utilizarlas en el proceso de desarrollo. JetBrains considera que el aumento del volumen de código producido por estas herramientas hace que las revisiones frecuentes y escalables sean más importantes, aunque la verificación humana sigue siendo necesaria debido a la posibilidad de que se transfieran errores al resultado automatizado.
De la puerta previa al lanzamiento a una garantía continua
El artículo distingue entre la garantía de calidad del software (SQA), que supervisa el cumplimiento de los requisitos de funcionamiento, fiabilidad, seguridad y estándares durante todo el ciclo de desarrollo, y el control de calidad tradicional (QC), que suele centrarse en el producto final y aborda los defectos de forma reactiva. El enfoque continuo permite detectar los problemas mientras se escribe o integra el código, cuando corregirlos resulta menos costoso y está más relacionado con el contexto original del cambio.
El artículo señala que los ciclos de lanzamiento han pasado, en los entornos de desarrollo modernos, de meses a días, mientras que las canalizaciones de CI/CD permiten que el código pase del commit a producción con una intervención humana limitada. Por ello, no basta con depender de una sola herramienta; cada capa de pruebas detecta un tipo diferente de problema.
¿Qué cubren las herramientas en la práctica?
- Análisis estático: examina el código sin ejecutarlo para detectar defectos, vulnerabilidades e incumplimientos de los estándares de codificación; Qodana es un ejemplo.
- Pruebas unitarias: verifican el funcionamiento aislado de funciones y componentes, con ejemplos como JUnit, Jest, PyTest y NUnit.
- Pruebas de integración: examinan la interacción entre servicios, las API y el flujo de datos; entre sus herramientas se encuentran Postman y Soap UI.
- Pruebas funcionales y de interfaz: simulan los recorridos del usuario a través del navegador mediante herramientas como Playwright, Cypress y Selenium.
- Pruebas de rendimiento: miden el comportamiento bajo carga y ayudan a detectar cuellos de botella, fugas de memoria y lentitud en las consultas, utilizando herramientas como JMeter, LoadRunner y k6.
- Pruebas de seguridad: combinan SAST, SCA, el análisis de dependencias y DAST, así como la detección de secretos o claves de API incorporados por error.
¿Cómo se eligen las herramientas y se integran en el trabajo?
El artículo propone evaluar las herramientas según su integración con CI/CD, su compatibilidad con los lenguajes y marcos de trabajo utilizados, su capacidad para automatizar tareas repetitivas, su escalabilidad a medida que crecen el código y los equipos, y la posibilidad de ofrecer informes prácticos, además de las prácticas de seguridad propias de la herramienta.
En cuanto a la implementación, recomienda trasladar las comprobaciones al momento de escribir el código, automatizar las pruebas repetitivas, ejecutarlas con cada commit o compilación y supervisar la deuda técnica mediante indicadores como la complejidad del código, la duplicación y la cobertura de pruebas. También insiste en la necesidad de incluir el análisis de seguridad en el flujo habitual de garantía de calidad, en lugar de posponerlo a una revisión independiente antes del lanzamiento.
Lectura de certi.news
El cambio real que plantea el artículo no consiste en añadir una nueva prueba, sino en redistribuir la responsabilidad de la calidad dentro del ciclo de desarrollo. Este enfoque resulta útil para los equipos que trabajan con lanzamientos frecuentes o dependen de arquitecturas distribuidas y dependencias externas, pero no elimina las pruebas manuales ni el criterio de ingeniería; la automatización, especialmente la basada en inteligencia artificial, puede acelerar la detección de problemas sin garantizar por sí sola que la cobertura sea completa o que los resultados sean correctos. Asimismo, la fuente ofrece directrices generales y ejemplos de herramientas, pero no establece un marco cuantitativo para compararlas ni demuestra resultados independientes de comparación del rendimiento.