Externalización IT
QA y testing externalizado
Un equipo de calidad independiente del equipo que escribe el código, que es de donde viene su valor.
En resumen: pruebas manuales y automatizadas, control de calidad de versiones y validación de rendimiento. El valor de externalizar calidad viene precisamente de la independencia respecto al equipo que desarrolla.
Hay una razón estructural por la que externalizar QA funciona bien: quien escribe el código es la peor persona para probarlo, porque prueba lo que pensó al escribirlo. Un equipo independiente prueba lo que el usuario hará.
Eso también implica que el equipo de calidad debe poder decir que una versión no está lista, y que esa opinión debe tener peso. Si no lo tiene, el servicio genera informes en lugar de calidad.
Qué incluye
Según el stack y el proceso de entrega.
- Pruebas funcionales manuales sobre casos definidos con usted
- Automatización de pruebas de regresión
- Pruebas de integración y de interfaz de usuario
- Validación de rendimiento y pruebas de carga
- Pruebas de accesibilidad sobre criterios acordados
- Informes de defectos con pasos de reproducción y criticidad
Qué no incluye
Para no confundir calidad con desarrollo.
- Corrección de los defectos encontrados, que corresponde al equipo de desarrollo
- Decisión final sobre si una versión se publica, que es suya
- Auditoría de seguridad, que es un servicio distinto con perfiles distintos
- Garantía de ausencia de defectos, que ninguna estrategia de pruebas puede ofrecer
Desde dónde se presta
Desde Polonia cuando se requiere coordinación síncrona con su equipo de desarrollo, o desde Uzbekistán cuando el trabajo se organiza por ciclos de entrega.
En pruebas conviene trabajar sobre datos sintéticos o seudonimizados siempre que sea posible. Probar sobre una copia de producción con datos personales reales es una práctica extendida y es precisamente la que más riesgo innecesario introduce.
Preguntas frecuentes
¿Automatizan todo?
No, y desconfíe de quien lo prometa. La automatización compensa en regresión y en flujos estables; en funcionalidad nueva y en exploración, la prueba manual encuentra lo que un guion no busca.
¿De quién son las pruebas automatizadas?
Suyas, versionadas en su repositorio junto al código. Un conjunto de pruebas que vive en el sistema del proveedor pierde valor el día que termina el contrato.
¿Pueden probar sobre datos reales?
Preferimos no hacerlo. Datos sintéticos o seudonimizados cubren la mayoría de los casos y evitan tratar datos personales reales en entornos que rara vez tienen los controles de producción.
¿Qué pasa si encuentran un defecto crítico antes de una fecha comprometida?
Lo reportamos con su criticidad y los pasos de reproducción. La decisión de publicar o no es suya, y nuestro trabajo es asegurarnos de que la toma con la información completa.
¿Necesita capacidad de pruebas?
Cuéntenos el stack, la frecuencia de despliegue y el estado actual de la automatización.