Al igual que muchos equipos, solíamos tener un miembro de control de calidad manual. Después de un tiempo se transfirió a la posición de desarrollador. No tenemos ninguna prueba funcional o unitaria automatizada. Lo que sí tenemos es la llamada sesión de errores. El objetivo es reunir a todo el equipo para realizar pruebas manuales. Ayuda compartir el conocimiento sobre el comportamiento esperado, pero no creo que sea suficiente porque la gente no lo toma en serio.
Para mejorar la situación, le sugerí al jefe que contratara a una persona subcontratada a tiempo parcial para minimizar los gastos. La nueva persona puede simplemente ocuparse de los problemas pendientes para el control de calidad.
El gerente dice que no ve el valor de traer un nuevo control de calidad porque cualquiera de los ingenieros puede hacer pruebas manuales. Me pide que demuestre que necesitamos una nueva persona a bordo. ¿Cómo hago esto? ¿Cuáles son las ventajas comerciales de tener un miembro de control de calidad en el equipo?
Control de calidad dedicado
Bueno, esto es una especie de "gotcha" aquí. Por lo general, cuando planteo un caso de control de calidad adecuado, lucho por demostrar que se dedican XX horas al control de calidad por sprint. Por lo general, puede armar las matemáticas en función de la investigación de otros para descubrir cuál será un equilibrio bastante bueno entre el tiempo invertido y los errores eliminados.
Haciendo de este tiempo una persona
La mayoría de las veces, esas horas pueden ser comprometidas por ingenieros y, de hecho, funcionan lo suficientemente bien. Una persona de control de calidad dedicada es más eficiente, pero si su necesidad no es suficiente para justificarla, el tiempo de los ingenieros será suficiente.
Para venderle a su jefe una persona de control de calidad dedicada, realmente necesita demostrar que necesita suficiente tiempo de control de calidad para cubrir un puesto de tiempo completo. Subcontratar un tiempo de control de calidad a tiempo parcial es una venta REALMENTE difícil y, en mi experiencia, es algo que generalmente perjudica más que ayuda.
Aprovechar al máximo el tiempo de control de calidad
Así que todo el equipo de desarrollo deja lo que está haciendo y realiza un control de calidad manual... Esto... es malo. Si puede dedicar un montón de tiempo para probar todo manualmente, ¡debería poder dedicar tiempo a realizar pruebas de unidad e integración adecuadas! Por lo general, la mejor inversión por su dinero es del 15% al 20% de su tiempo de desarrollo dedicado a limpiar el código antiguo, corregir errores y proyectos que no son de producción, como la construcción de pruebas, la limpieza de la base de datos, la optimización, etc. (La basura eso necesita hacer eso no gana dinero directamente)
Como desarrollador, un buen TDD puede ser invaluable y ahorrarle HORAS de problemas de depuración. Puede contar con confianza con cada parte de su código haciendo su trabajo, y en caso de que algo se rompa, tiene una prueba que dice qué se rompió y dónde se rompió, incluso antes de activar la interfaz de usuario para ver si se rompió. Esto reduce MUCHO el tiempo de control de calidad necesario. Ahora, en lugar de "probar todas las cosas", realmente solo se está asegurando de que la interfaz de usuario esté en buen estado... (lo que en realidad va en contra de que obtenga una persona de control de calidad, a menos que simplemente descargue la construcción de pruebas automatizadas en esta persona... lo cual no es ideal, pero es MUCHO mejor que no hay automatización)
Resumen
Una persona de control de calidad dedicada es una venta difícil y debe mostrarle a su jefe que todo el tiempo del ingeniero dedicado a las pruebas sería más útil en manos de una persona de control de calidad...
Pero ese no es realmente su problema... Necesita automatizar sus pruebas para reducir su tiempo de control de calidad por completo.
Cronax
Thorbjorn Ravn Andersen