Es una buena idea probar algo antes de liberarlo. La prueba es como todo lo demás: un tema grande y hay diferentes escuelas sobre cómo hacerlo. Obviamente no estamos hablando de una "fase de prueba" a la antigua usanza de la gestión de proyectos.
Esperar a probar todo hasta el final de un proyecto puede parecer ridículo hoy en día, pero era una práctica común y aún lo es en muchos proyectos de Cascada. Afortunadamente, la mayoría ha avanzado. Esperar con las pruebas y los desarrolladores han seguido adelante y olvidado, y es casi un nuevo proyecto para arreglar todas las cosas pequeñas.
Hoy en día, las empresas utilizan pruebas continuas, que deben ocurrir en un entorno de prueba antes de que la entrada/ticket/corrección vaya a producción (se libere).
De esta manera, podemos codificar características, probarlas, dar retroalimentación, codificar de nuevo y continuar probando hasta que estemos satisfechos con el resultado. Podemos liberar cuando esté listo en función de cada característica.
En muchos procesos de desarrollo, el desarrollador codifica algo, luego prueba un poco en su computadora local y luego comete el código y hace una solicitud de extracción para revisión por pares (en el mejor de los casos). Luego está en el entorno de prueba.
Aquí, algunos desarrolladores les gusta entregar a un equipo de QA ("Garantía de calidad") que asume la responsabilidad de las pruebas y "asegura" que tiene "la calidad correcta". Esto se ve bien en el papel. ¡No lo hagas! Al menos no así.
Lee más en "El Manual del CTO" disponible en Amazon/Kindle.
Ayudamos a las empresas con su tecnología, proporcionando servicios de CTO y gestión de productos. Confiados en nuestros servicios de CTO, trabajamos con tanto startups como empresas establecidas en los países nórdicos, Suiza y EE. UU.
Somos una Compañía Suiza (LLC) con sede en 
Suiza.