¿Cuándo debe un equipo de startups tecnológicas traer un ingeniero de control de calidad / prueba dedicado?

En lugar de cuándo, puedo responder qué valor puede aportarle un ingeniero experto en control de calidad / pruebas en las diferentes etapas de un inicio tecnológico.

  • Etapa de idea: no es realmente útil. Distracción.
  • Etapa MVP: cuestionando sus suposiciones. No se requiere a tiempo completo.
  • Etapa alfa: absolutamente importante. Pruebas de preparación de demostración de inversores. Buen momento para participar si existe financiación inicial.
  • Etapa beta: el cliente se conecta, encuentra errores antes de que lo hagan tus clientes beta. Disminuya la velocidad de exceso de velocidad con errores. Ayude al propietario del producto a conectarse mejor con los clientes.
  • Pre-go-live: prueba de preparación de lanzamiento. Pruebas de preparación de demostración. Mantenerlo al tanto de los riesgos que está tomando en función de los errores.
  • Después de la puesta en marcha: contrate un equipo de control de calidad / probadores que pueda ayudarlo a encontrar más errores, escribir automatización de pruebas y, lo que es más importante, seguir hablando con los clientes y comprender lo que están haciendo con el producto. Aprenda de la analítica y cambie las pruebas y escenarios para las pruebas. Esté constantemente atento si estamos navegando hacia un iceberg.

Una startup de tecnología puede no requerir un control de calidad dedicado al principio, una vez que haya adquirido fondos para los próximos 5 años y tenga lista la hoja de ruta, ese es el momento de pensar en un equipo de control de calidad dedicado.

Un buen departamento de control de calidad consta de un equipo dedicado para desarrollar / personalizar / soportar herramientas de automatización, configuración genérica de bancos de pruebas y otras actividades genéricas de control de calidad.
Inicialmente, es bueno tener un ingeniero de prueba para cada característica (que es un componente ejecutable de forma independiente y tiene interfaces bien definidas), que se encarga de las pruebas de esa característica de extremo a extremo (plan de prueba de escritura, programación de pruebas mediante herramientas de automatización e informes de resultados ) Una vez que la característica está en producción, el ingeniero de pruebas puede tomar otro componente además de mantener las pruebas del componente anterior.

El desarrollador generalmente puede manejar múltiples funciones dependiendo de su tamaño.

Entonces, para la proporción de desarrolladores / evaluadores, estoy de acuerdo con Boris, 3 a 1 suena bien.

No hay nada como cuándo debería traer ingenieros de control de calidad / pruebas, deberían ser parte del primer día. Ayudará a organizarse mejor para el producto final, la gente de QA puede participar en la configuración / preparación de la infraestructura para la automatización de pruebas y contar con un amplio período de tiempo durante la fase de inicio para mezclarse con el equipo.

Se les puede dar un papel diferente, así como scrum master, jugar como cliente, ser propietario de un producto proxy, ser músico, cualquier cosa que lo ayude a sentirse cómodo en el entorno inicial.

Una vez hecho esto, la gente de QA será más productiva y harán lo que se espera y, en el buen caso, harán más de lo esperado.

Un punto importante es sentirse cómodo con el equipo.

HTH

Si agrega un control de calidad dedicado, lo más probable es que ya no sea una startup. Puede haber excepciones, pero yo diría que debería ser la regla general. La calidad debe ser responsabilidad de los ingenieros que escriben el código. Es posible que necesiten ayuda, pero no tanta ayuda para justificar incluso un control de calidad.

3 a 1 a veces se cita como una relación general entre los desarrolladores de software y los ingenieros de control de calidad. Pero, por supuesto, hay muchas variables que afectarán esa relación. En algunos lugares con una alta proporción de desarrolladores con respecto al control de calidad, los desarrolladores realizan una gran cantidad de trabajo de control de calidad, como mantener conjuntos de pruebas automatizadas, administrar revisiones e impulsar mejoras en el proceso.

He trabajado en algunas empresas nuevas que son el único recurso de control de calidad. Por lo general, una startup contrata a alguien como ingeniero de control de calidad dedicado después de descubrir un negocio y / o si todo el producto que se vende se basa en la calidad. Una empresa de seguridad necesitará un equipo de control de calidad muy temprano, mientras que una red social puede prescindir de ella durante mucho tiempo.

En realidad es bastante tarde, pero preferimos tener uno al principio, justo después de la etapa de concepto. Entonces, un equipo real, ¿qué tan grande? Depende en gran medida de lo complicado que sea el producto real.

Cuando te das cuenta de que no sabes “¿Cómo probar correctamente el software?” y “¿Cómo gestionar la calidad del software?” – Es el momento de traer a alguien que tenga un profesional en calidad de software.

Un buen tipo de control de calidad sabe cómo hacer esto correctamente de manera efectiva y eficiente.


Para la proporción, si tiene un equipo pequeño como 4 desarrolladores, le sugiero que comience con 1 control de calidad senior.

¿Cuándo tiene una planificación aproximada sobre lo que debe probarse? ¿Cómo hacer la prueba? con una fecha límite difícil, pronto sabrá cuántos QA necesitaría.

Esto debe hacerse muy temprano, o al menos planeado. Debe hacerse antes de contratar desarrolladores más allá del grupo inicial.

Un proyecto de software de cualquier tamaño, que quiera ser relevante para cualquier período de tiempo, debe tener TDD (desarrollo basado en pruebas) y pruebas de unidades. Estos deberían seguir el ritmo del código. Estás pidiendo problemas cuanto más tiempo pases sin ellos.