software-quality - talent - upc mytech

QA vs Ratio de desarrollo (12)

Estoy trabajando como desarrollador de software y tuve una disputa hoy con nuestro equipo de control de calidad acerca de lo siguiente:

¿Cuánto deben superar los miembros del equipo de QA al número de desarrolladores que trabajan en el mismo producto?

Sé que no se trata de cómo programar algo, pero creo que esta pregunta está muy relacionada con el desarrollo del software. Así que espero que esta pregunta no se cierre. En cambio, obtendré respuestas de programadores profesionales que tienen una buena experiencia en el trabajo en empresas de desarrollo SW para que pueda hacer una buena estadística.

Ahora mismo donde trabajo hay 3 desarrolladores para cada persona de control de calidad. Esto tiene sus altibajos ya que a veces QA encontrará un problema pero hay soluciones fuera de los cambios de código, por ejemplo, no haga clic donde no tenga sentido hacerlo.

Un par de veces no hay un QA en el que haya trabajado, que a veces es casi como una receta para el desastre, ya que los clientes se convierten en el QA ya que sus problemas se convierten en problemas para los desarrolladores.

Bueno, esto depende de la calidad del personal al final del día. Si un programador hace tanto trabajo como dos QA, entonces la proporción es 1: 2 y viceversa. La calidad del personal aquí sería # 1.

Depende de la organización y la web / aplicación que se esté desarrollando. Todas las empresas tienen su propio desarrollo: relación de garantía de calidad según sus requisitos.

En resumen, depende del tamaño del proyecto y de los recursos disponibles en la organización.

En mi experiencia, hay dos tipos principales de personal de QA: aquellos que simplemente siguen un guión escrito e interactúan con una aplicación en un esfuerzo por encontrar casos extremos, y aquellos que realmente pueden escribir códigos de prueba automatizados, y buscan encontrar nuevos y formas innovadoras (fuzzing, Selenium, escribir API clientes) para romper el código del equipo de desarrollo.

Si su equipo de control de calidad está compuesto principalmente por personas del primer tipo, entonces una proporción de 1: 1 o mejor frente a sus desarrolladores probablemente sea una necesidad. De lo contrario, tendrán dificultades para mantenerse al día con las nuevas funciones introducidas por el equipo de desarrollo y, a menudo, se opondrán a cualquier cambio realizado en el producto, ya que complica aún más el flujo de trabajo de las pruebas.

El último tipo (es decir, los ingenieros de prueba que pueden codificar), por otro lado, son un regalo del cielo para cualquier equipo de desarrollo productivo. Los codificadores pueden comunicarse con ellos como pares, y los evaluadores pueden encontrar formas útiles de automatizar y mejorar sus propios procesos escribiendo arneses y utilidades de prueba más inteligentes y mejor abstractas. Un buen ingeniero de pruebas probablemente pueda respaldar el trabajo de 2-3 desarrolladores, especialmente si esos desarrolladores ya están escribiendo pruebas útiles de unidad e integración que el probador puede usar como punto de partida.

En nuestra organización, la proporción es dev: QA es 5: 2, y para esto necesitamos entender más escenarios como

quién está trabajando en pruebas unitarias. En nuestro caso, una persona está completamente dedicada a escribir un plan de pruebas unitarias y un equipo de 5 miembros está ejecutando casos de pruebas unitarias y arreglando los errores. Nuestro PL no está involucrado en la codificación. cosas orientadas
las pruebas funcionales las realizan los evaluadores a tiempo parcial; puede decir que se trata de medio recurso y un ciclo de pruebas funcionales realizadas por los desarrolladores

Por lo tanto, depende del tamaño del proyecto, de los recursos escritos de la LOC y de los recursos de la empresa en función de su nivel de MMC

Hay muchos factores que entran en responder eso.

¿Tienes pruebas automatizadas?
¿Cómo están estructurados tus ciclos de lanzamiento?
¿Cuál es su% de cobertura de prueba de unidad?
¿Qué tan bueno es su gente (tanto QA como Dev)?
¿Incluyes control de calidad en todo el ciclo de vida del proyecto o los utilizas al final?
¿Estás haciendo lanzamientos incrementales para QA?

Trabajé en lugares donde variaba de 3: 1 (QA / DEV) a .5: 1 (QA / DEV). Todo se reduce a la cantidad de recursos de control de calidad que se necesitan para probar adecuadamente el producto y no hay una respuesta general.

Hay muchos factores, el más importante es el nivel de calidad requerido para la aplicación, ¿es un sitio web pequeño? o un instrumento médico importante? o un sistema financiero? Una sola línea de código modificada para el transbordador espacial podría requerir semanas de prueba ...

En un taller de desarrollo progresivo, las necesidades de recursos de control de calidad (como proporción al desarrollo) deberían reducirse con el tiempo a medida que se implementan mejoras de control de calidad, como TDD, revisiones de código, etc. Creo que la garantía de calidad centrada en las pruebas prácticas es un desperdicio. ser utilizado para mejorar el proceso y ayudar a los desarrolladores a sentirse tontos (eliminando errores antes del lanzamiento).

La cantidad de personal de control de calidad no debe depender de la cantidad de desarrolladores . Debería depender de la calidad deseable del producto, pero no de ninguna otra cosa.

Muchos aquí dicen que "para QA" un trabajo de un buen desarrollador es una tarea más fácil que "para QA" un trabajo de un desarrollador peor. Diablos, ¿por qué es así? Para "asegurar la calidad", y QA es "garantía de calidad", significa diseñar un proceso que marque el producto con "QA passed" y "QA failed". Solo conozco dos procesos que dependen del código en sí: verificación de código estático y revisión por pares. Mientras que el primero es algo usado, y a veces necesita gente de QA para mantenerlo, lo que se llama " calidad " del código no es lo que importa para una máquina sin alma. Y la revisión por pares la realizan los programadores, no el control de calidad. Espero que esto te convenza de que la cantidad de control de calidad no depende de los desarrolladores, ¿no?

En el dominio en el que está trabajando nuestra compañía, no hay competencia y el mercado es muy estrecho. Por lo tanto, obtenemos toda la información necesaria de los informes de errores y no tenemos control de calidad , por lo que la proporción es cero. Todas las pruebas las realizan los desarrolladores. Aún así, sí lo hacemos en vivo, porque la calidad requerida no requiere de ningún tipo de control de calidad.

La respuesta es muy subjetiva, pero esta es mi experiencia.

En Microsoft tenemos una sólida organización de desarrollo de pruebas. Eso es un poco diferente que el control de calidad tradicional porque contratamos programadores para que los prueben e involucren en el proceso desde la fase de diseño. Su trabajo es probar y especialmente automatizar las pruebas para el producto. En mi experiencia, el probador tarda aproximadamente tanto tiempo en probar y automatizar una función como lo hace el desarrollador para codificar y corregir errores en el producto. Eso implica un mapeo 1: 1. Esto es muy similar a la regla empírica que las pruebas de unidades de escritura toman aproximadamente el mismo tiempo que se escribe el código.

Esta mezcla variará según varios criterios:

Cuántas pruebas unitarias están haciendo los desarrolladores. Cuanto más lo hacen, menos pruebas necesita hacer.
Cuánto están redactando los desarrolladores desde cero versus aprovechando las bibliotecas existentes. Si hay muchos códigos preexistentes en uso y los evaluadores también deben verificar esa funcionalidad, ese costo de desarrollo irrecuperable debe tenerse en cuenta para el mapeo 1: 1.
Qué tan dinámico es el desarrollo. Si está escribiendo una interfaz de usuario donde los ajustes relativamente pequeños del desarrollador causan un gran cambio en la superficie comprobable, necesitará más probadores invovled.
Cuán crítica es la función. Para escribir algo como GMail, donde se usa casualmente y los errores se pueden tolerar y corregir en el campo, se necesitan menos probadores. En el otro extremo, si está trabajando en dispositivos de imágenes médicas , necesita muchas más pruebas porque los errores son difíciles de corregir en el campo y muy malos cuando ocurren.

Mi lugar de trabajo actualmente es de alrededor de 8: 1 dev: qa. La razón de esto es que tomamos las pruebas automáticas muy en serio. Se requiere todo el trabajo para tener una cobertura de prueba de unidad cercana a la completa. También realizamos pruebas funcionales con Fitnesse (todas las historias de usuarios deben tener una prueba de ajuste), las comprobaciones activan pruebas completas con un servidor de CI, los desarrolladores se registran con frecuencia, lanzamos con frecuencia.

Todo esto en una aplicación ENORME con varios miles de clases y un sinnúmero de escenarios. La ventaja es la velocidad, la agilidad y, por supuesto, el costo. Cualquier tiempo extra que un desarrollador (incluso uno costoso) gaste en escribir pruebas es menor que el capital humano de contratar / administrar más personal de control de calidad, o de encontrar errores en la producción (incluso el personal de control de calidad es humano después de todo).

El pequeño personal de control de calidad que tenemos pasa el tiempo escribiendo sus propias pruebas automáticas con Selenium o participando en nuevas funcionalidades. Pasan relativamente poco tiempo repitiendo la misma funcionalidad una y otra vez.

Para la mayoría de los proyectos en la empresa que trabajo en la proporción es de 1: 1. Pero esto puede variar en varios factores:

Dev de salida. He visto un desarrollador que tenía una gran cantidad de resultados y tenía 3 QA trabajando en sus características.
Barra de calidad para el producto. Un sistema de alta fiabilidad y misión crítica debe tener una barra de control de calidad más alta que un sitio web de informes internos, y necesitará más gente de control de calidad.
Algunos proyectos deben probarse en un mayor número de configuraciones y escenarios. Los desarrolladores podrían mantenerse constantes, pero obviamente necesitará más control de calidad para cubrir la matriz de prueba completa.
Cuán automatizable es la prueba Si las pruebas no se pueden automatizar fácilmente, necesitará más personas para realizar pases manuales.

Piense en términos de horas gastadas en comparación con la cantidad de personas. Es muy posible que para una aplicación bien probada y "aprobada", para cada hora de desarrollo, pueda haber una hora de esfuerzo de GC. Me refiero específicamente al rol técnico de QA, no a las pruebas funcionales. Un equipo de control de calidad y un equipo de desarrollo deben poder trabajar en estrecha colaboración, para que el equipo de control de calidad pueda escribir casos de prueba al mismo tiempo que se produce el desarrollo. Esto significa que todo debe escribirse en un contrato de implementación (nombres de funciones, parámetros de entrada, etc.).