¿Cuándo debe detenerse el desarrollo y comenzar el control de calidad?

Escribimos una especificación funcional completa para nuestro equipo de desarrollo de dos. No tenemos probadores profesionales, sin embargo, hemos redactado con la ayuda de nuestro personal de servicio de asistencia disponible para realizar 'pruebas de control de calidad'.

Hemos tenido problemas en el pasado en los que no funcionan los trozos completos de funcionalidad, o el código se entrega simplemente no está de acuerdo con las especificaciones.

Mis preguntas son: ¿en qué etapa deberían los desarrolladores dejar de codificar al equipo de control de calidad? ¿Es demasiado pedirle a los desarrolladores que revisen su código contra las especificaciones antes de entregarlo al equipo de control de calidad?

¡No debería!

Es muy difícil hacer todo el trabajo, detenerse y luego solucionar todos los problemas. Cuando vaya a solucionar un problema que encuentre durante el proceso de control de calidad, es posible que aprenda que sería mejor hacer algo diferente.

En lugar de pensar en todo como un proceso de paso de bloqueo, intente hacerlo más cíclico. Codifique alguna funcionalidad y pruébela. Codifique un poco más y pruébelo (y las cosas viejas aún funcionan). Este proceso más fluido alivia la dificultad de tratar de cargar todo por adelantado. Todavía puede tener el concepto de un congelamiento de código (solo corrija los errores) cuando se acerque a la fecha límite, pero el punto es probar temprano y con frecuencia.

Bueno, si se entregan secciones enteras de código a QA en un estado que no funciona, tal vez debería considerar agregar algún tipo de prueba de unidad / integración a su proceso. No abuse de su personal de control de calidad haciéndoles descubrir que no pudo unir o probar la integración de su código.

Es una línea muy fina, porque si el código se entrega de acuerdo con las especificaciones, para mí eso significa que no hay errores (¡y no hay necesidad de control de calidad!). El hecho de que el código no se entregue rutinariamente a las especificaciones es la razón por la que hacemos QA en primer lugar.

Pero en realidad no creo que sea de eso de lo que estás hablando. Lo que quieres decir es que el equipo de desarrollo parece un poco flojo con su codificación, y hay grandes cosas obvias que no parecen funcionar. Establecer de antemano que las pruebas unitarias deben estar presentes para cada una de las características A, B y C (en la especificación) y luego hacer que el código y las pruebas sean revisadas de forma independiente (por un equipo o gerente del equipo) debería ayudar a aliviar este tipo de problema .

Yo diría que, como mínimo, los desarrolladores deberían haber probado el "camino feliz". Que si ingresan los datos esperados, entonces hace lo que la especificación dice que debería hacer. Los desarrolladores que no hacen tanto deben ser cuestionados.

También estoy decepcionado si un desarrollador no ha probado los casos extremos obvios: una cadena demasiado larga para la base de datos, texto obviamente inválido, si ingresa letras donde debería estar un número, etc. Si eso sucede con frecuencia, nuevamente se deben hacer preguntas .

Sin embargo, suponiendo que no se mencione específicamente en la especificación, si un desarrollador limita un nombre a letras mayúsculas y minúsculas, pero olvida que algunos nombres tienen apóstrofes, o permite una fecha del 29 de febrero de 2011, eso es un poco más comprensible . A menos que cometan el mismo error una y otra vez.

El equipo de control de calidad debería recoger los casos extremos. Prefiero QA para ser probadores de monos: simplemente ingresando basura aleatoria, para ver si pueden romper la aplicación de esa manera.

En el desarrollo web, el control de calidad debe probar diferentes navegadores e intentar encontrar complementos que puedan afectar el código. Deben desactivar Javascript y CSS y ver qué pueden hacer en ese momento. Ese tipo de cosas. Si espera que los desarrolladores hagan eso, está gastando demasiado dinero en ello.

Si se entrega una funcionalidad que no funciona, entonces el problema no está entre el desarrollo y el control de calidad, sino entre el desarrollo y los propietarios del producto.

Los propietarios y desarrolladores de productos deben ser parte del mismo equipo y deben trabajar juntos para definir qué debe funcionar para considerar una función "terminada" y para asegurarse de que el código cumpla con esa necesidad.

Cuando se entrega el código, las pruebas deben ser una mera formalidad, porque los propietarios del producto deberían haber estado trabajando con los desarrolladores en el camino para asegurarse de que todos los casos de uso estén cubiertos.

(Si tiene probadores profesionales, deben ser parte del equipo y deben participar en cada etapa).

Tenemos un proceso de selección para proyectos en el que pedimos a los desarrolladores que den un tutorial / demostración de su código antes de que entre en control de calidad. Incluimos no solo a los evaluadores de control de calidad, sino también a los propietarios del código, el servicio al cliente y el marketing / diseño. Esto tiende a centrarse en los desarrolladores al menos en los casos de uso fáciles, y a veces la discusión resultante entre los diversos equipos da como resultado cambios en las especificaciones y un retraso en la entrada al control de calidad. Cuando podemos, involucramos el control de calidad mucho antes en el proceso, lo que ayuda a corregir los errores mientras el código aún está activo, pero aún hacemos el recorrido antes de que comience el control de calidad "oficial".

A veces he dicho que el código no debe enviarse al control de calidad si está molesto si por error fue a producción en lugar de control de calidad. El código con disfuncionalidad mayor no pertenece al control de calidad (excepto en circunstancias específicas)