¿Por qué las compañías de software tienden a tener grandes equipos dedicados de control de calidad, pero la mayoría de las compañías de Internet tienen pequeños?

Si bien he votado a favor de la respuesta de Raghavendra Kidiyoor, también cuestionaré su suposición básica de que las compañías de software tienen grandes equipos dedicados de control de calidad. Las proporciones promedio de dev: QA se ejecutan en cualquier lugar de 2: 1 a 7: 1 en toda la industria. No llamaría 6 o 6: 1 un equipo grande. Yo llamaría a eso una pandilla de cadenas mal trabajadas y mal trabajadas. También diría que 2: 1 es casi imposible de ver; En el camino, cada compañía reducirá los costos en algún momento y disparar cabezas es * casi siempre * en la estrategia de 3 viñetas (reducir los costos discrecionales (T&E, etc.), reducir las cabezas (como el RIF inferior del 5%, etc.) y salir de la rentabilidad. unidades de negocio (que es reducir cabezas, pero en su totalidad)).

Sin embargo, al final, cuanto más largo sea el ciclo de lanzamiento, más QA de fondo debe hacerse. Solo hay dos variables para sintonizar; tiempo y recursos. De ahí los números. En las compañías de software, los ciclos de lanzamiento rara vez son de integración continua y rara vez incluso los resultados de 2 o 3 semanas de sprints.

Impacto de un error en un producto lanzado = (a) Impacto en los usuarios + (b) Costo de reproducirlo + (c) Costo de arreglarlo + (d) Costo de liberar el arreglo.

Los cuatro (a) – (d) son más bajos para una compañía de internet.
(a) El impacto en un usuario en particular podría ser igual de grande, pero debido a que la solución se puede implementar más rápido, la duración del impacto es menor. Todos los usuarios se benefician de la solución de inmediato, por lo que el impacto general del usuario es menor.
(b) Errores más fáciles de reproducir, porque no hay configuraciones y personalizaciones ambientales particulares del cliente con las que lidiar
(c) El costo de la reparación es menor porque puede reparar, probar y lanzar solo la corrección de un solo error, sin un ciclo de prueba de integración para un “paquete de servicio” completo.
(d) El costo de liberar la corrección es mucho menor porque simplemente la implementa en sus servidores y no tiene que “actualizar” a todos sus clientes y mantener varias versiones y correcciones de puerto de retroceso / reenvío.

Por lo tanto, es más rentable hacer menos control de calidad inicial y sustituirlo con medidas que puedan “atrapar y solucionar” problemas posteriores al lanzamiento (operaciones, análisis de uso, lanzamientos diarios, etc.).

Obviamente, todavía se necesita un control de calidad inicial, pero los procesos de control de calidad estándar para el software retráctil no se aplican a los servicios de Internet.