testing - software - testers
¿Cuál es una buena proporción de desarrolladores a probadores? (10)
Además, ¿usaría probadores "puros", o combinaría las pruebas con otros roles (por ejemplo, documentación, capacitación del usuario, etc.)?
Depende del tipo de prueba, pero no me gustaría cargar a los probadores con otros roles. Los ingenieros de pruebas competentes valen su peso en oro (lo mismo que los ingenieros de software competentes). Si les asigna tareas fuera de su dominio de experiencia, las ralentizará y se las quitará. ¿Los ingenieros de software les gusta hacer documentación o capacitación del usuario? Usualmente no. Tampoco lo hacen los probadores.
Sin embargo, no hay nada de malo en complementar su equipo de prueba con personas de otras áreas, especialmente para pruebas de usabilidad, pruebas de aceptación, revisiones rápidas, etc.
¿Qué proporción de desarrolladores [senior] a probadores cree la gente que es mejor?
Obviamente, esto dependerá en parte del rendimiento del desarrollo / mantenimiento, pero ¿existe una regla empírica de la que una nueva empresa / proyecto podría funcionar?
Además, ¿usaría probadores "puros", o combinaría las pruebas con otros roles (por ejemplo, documentación, capacitación del usuario, etc.)?
Obviamente, las respuestas pueden depender de los modelos de estrategia / desarrollo de la empresa utilizados, así que especifique si está respondiendo en general, o si se trata de un estilo específico de producto / versión, y así sucesivamente.
Blogé sobre esto una vez aquí . El extracto más relevante está debajo.
"He visto productos de alta calidad producidos en una proporción 10: 1 de desarrollo: prueba, y productos horribles creados con una proporción 1: 1. La diferencia está en la atención y el cuidado de la calidad. Si todos (incluida la gerencia) en el equipo profundamente se preocupa por la calidad del producto, tiene una buena posibilidad de suceder, independientemente de la relación. Pero si la calidad es algo que se supone que debe probarse en el producto, de todos modos tenga al menos 1 probador por cada desarrollador, más si puede obtener ellos."
En mi opinión, una buena métrica para determinar el número de probadores necesarios es la complejidad de los requisitos, no la cantidad de desarrolladores. Si estuviera contratando probadores, echaría un vistazo a la lista de requisitos (o dividiría el documento de diseño en una lista de requisitos si fuera necesario) y pensaría cuánto tiempo de prueba necesitaría cada requisito para verificar que funcionaba correctamente. Utilizaría ese análisis inicial para contratar una base de probadores, y luego agregaría probadores más adelante si la carga de trabajo resultaba demasiado alta para mi base inicial.
Si está preparando un presupuesto y la contratación de probadores más adelante no es una opción, es posible que desee presupuestar en un poco más de recursos de prueba de lo que indica su análisis. Demasiado siempre es mejor que no lo suficiente.
Si usar comprobadores "puros" es otra cuestión que depende realmente de la cantidad de recursos de prueba que necesita. Descubrí que un buen compromiso es contratar probadores que sean capaces de realizar otros trabajos y utilizarlos en otras capacidades en momentos en que la carga de prueba sea leve.
Editar: si tienes la suerte de tener un conjunto de pruebas de aceptación desde el principio, por favor sustituye "pruebas de aceptación" por "lista de requisitos" más arriba. :-)
Hubo un artículo reciente y relevante sobre InfoQ que podría resultarle interesante.
Yo diría (dependiendo de la velocidad que necesites probar) con la automatización, podrías tener 1 o 2 probadores por cada 5 desarrolladores.
Por qué:
- Con la automatización solo tienen que preocuparse por probar los nuevos módulos
- Las pruebas de regresión se ocuparán de las más antiguas.
- 1 o 2 probadores pueden cubrir fácilmente todo el trabajo que 5 desarrolladores harán, por ejemplo, semana / semana
- Una buena proporción que me han enseñado es que por cada 10 horas de desarrollo, el equipo de control de calidad tomará alrededor de 3 o 4 horas para rastrear la mayoría de los defectos que generan esas 10 horas.
Espero que ayude :)
Joel hace un buen argumento para 1 probador por cada 2 ingenieros, además de cubrir las excusas que las personas usan para no tener esos probadores.
No hay una relación "buena" generalizada.
Claramente, el tiempo requerido para probar algo es contextual, depende de factores que pueden tener poco o nada que ver con el tiempo que tomó desarrollar esa característica.
Considera también:
- ¿Qué cuenta como Desarrollo?
- ¿Qué cuenta como Prueba?
- Si de todos modos hiciéramos las pruebas de regresión, ¿eso cuenta como horas de prueba adicionales "cero"?
Antes que nada, los desarrolladores de probadores son una buena regla general , pero es una mala regla .
Lo que debe tener en cuenta es el número de casos de uso que tiene su aplicación. Las aplicaciones con las que los usuarios interactuarán de forma incontrolada (aplicaciones web de IE o aplicaciones de escritorio) requerirán más probadores que una aplicación de consola similar.
Una aplicación que toma un solo archivo y detecta patrones regex en ella requerirá menos probadores que un nuevo sistema operativo.
Si bien esas son máximas generales, el consejo práctico sería utilizar algún tipo de fórmula aproximada basada en estos factores
1) ¿Cuántos casos de uso (compartimentados) hay?
Digo casos de uso compartimentados porque si incluye cambios de estado y variables persistentes, partes aparentemente no relacionadas de un programa pueden resultar relacionadas. IE 2 + 2 = 4 (1 caso de uso) 2 * 2 = 4 (2do caso de uso). Eso es dos operadores simples entonces, dos clases de casos de uso. Sin embargo, si puede add luego multiply , entonces no puede marcar SÓLO add y multiply individualmente, debe verificarlos en todas sus permutaciones posibles.
Al examinar el número de casos de uso, asegúrese de incluir los casos de uso que implican el encadenamiento de comandos.
2) ¿Cuánto tiempo lleva probar cada uno?
Esto no significa (para extender la metáfora de la calculadora) solo agregar 2 + 2 y mirar la respuesta. Debe incluir el tiempo que lleva recuperarse de un bloqueo. Si la respuesta es incorrecta, esperaría que el probador registrara el error con una captura de pantalla e instrucciones específicas sobre cómo recrear el error. Si no les das tiempo para este tipo de trabajo de administración, entonces estás contribuyendo a tu plan con la suposición de que no tienes errores. Y si estamos asumiendo eso, ¿por qué los probadores en absoluto;)
Un proyecto complejo tendrá un gran número de casos de uso y un alto número de desarrolladores, pero no son una correlación garantizada. Es mejor que examine exhaustivamente sus casos de uso y tome una decisión informada acerca de cuántos probadores se requerirán.
Bono agregado. Una vez que haya desglosado por completo la aplicación, es posible que encuentre algunos casos de uso que nunca se consideraron en la fase de diseño, y los solucione antes de que el probador los encuentre.
Esta cadena es aparentemente bastante vieja. Pero las respuestas me parecieron todas perdieron el punto.
1). La cuestión de una relación de desarrollador y probador es válida, ya que cuanto más complejos sean los requisitos, más desarrolladores serán necesarios y, por lo tanto, se necesitarán más evaluadores. Algunas de las respuestas parecieron descartar esto.
2). Independientemente de los dominios de la aplicación, una buena proporción que funciona en el mundo real para el software de "alta calidad" es de 2: 1. Puede vivir con 4: 1, pero realmente es estirarlo. Por supuesto, hay muchas variables en esta estimación, no solo la complejidad de los requisitos, los sistemas / entornos para implementar, sino también cuán productivos son los desarrolladores y cuán ajustado es el cronograma de entregas.
HTH
Una cosa es segura. El número de probadores debe ser mayor que el número de desarrolladores. Para cada función creada por un desarrollador, un probador debe ejercer la función bajo varios tipos de pruebas: funcionalidad, usabilidad, límite, estrés, etc. Aunque la proporción exacta dependerá más de la cantidad de casos de prueba y de cuánto tiempo debería durar un ciclo de prueba. ser (1 semana, 3 días, 1 día o medio día), un único desarrollador generará suficiente actividad de prueba para múltiples probadores. Además, puede haber escenarios que requieren que varios probadores simulen dos o más usuarios que trabajen simultáneamente en el sistema.