¿Crear un sistema completamente duplicado para el aseguramiento de la calidad (QA) de otro es una mala práctica?

En el trabajo tenemos un sistema bastante complicado. Llamemos a este sistema, System_A. Nuestro equipo de control de calidad ha creado otro sistema, llame a este sistema, System_B, para probar System_A.

La forma en que se usa System_B es la siguiente. Generamos entradas (usando el propio System_B), IN, procesamos dichas entradas a través de System_B y generamos salidas, O_B. Entonces el proceso es el siguiente:

System_B(IN) -> O_B.

Luego hacemos lo mismo para que System_A genere sus propias salidas, O_A:

System_A(IN) -> O_A.

En cualquier momento, se supone que O_B es la salida esperada y O_A es la salida observada / real. Implícito es que O_B es la fuente "dorada" (la verdad). Sin embargo, nos hemos encontrado con una combinación de problemas.

• O_A está mal, O_B está bien
• O_A tiene razón, O_B tiene razón
• O_A está mal, O_B está mal
• O_A está bien, O_B está mal

¿Quién determina lo correcto si se supone que O_B siempre tiene la razón (o lo que se espera)? Bueno, resulta que O_B a veces (o con frecuencia) está mal con la inspección y el análisis humanos. Las cosas pasarán QA usando este proceso, y los usuarios reales se quejarán, y volveremos a encontrar que O_B estaba mal después de todo.

La pregunta es esta: ¿es una mala práctica crear un "sistema de prueba" para probar el sistema real?

• ¿Qué pasa con la pendiente resbaladiza? Entonces, ¿no podemos argumentar que necesitamos otro sistema para probar el "sistema de prueba"?
• El costo es definitivamente prohibitivo, ya que los desarrolladores ahora necesitan aprender al menos 2 bases de código, con quizás la complejidad de System_B mayor que System_A. ¿Cómo cuantificaríamos cuán bueno o malo es tener System_B para la organización?
• Una de las razones "convincentes" originales para crear System_B fue "automatizar" las pruebas. Ahora estamos muy orgullosos de estar completamente automatizados (porque System_B genera la entrada para arrancar el proceso de usarlo para generar también la salida). Pero creo que hemos hecho más daño e introducido más complejidad, de manera no cuantificable. ¿El trabajo de QA debe ser completamente automatizado? ¿Es esa razón suficiente para justificar la creación de un sistema paralelo?
• Mi verdadera preocupación es esta, a pesar de que todos sabemos que System_B está mal (con bastante frecuencia). Si System_B es tan bueno procesando la entrada y su salida es la fuente de oro, ¿por qué no reemplazar System_A con System_B? A eso, nadie en el trabajo puede proporcionar una respuesta satisfactoria.

Cualquier orientación sobre este tema es apreciada.

• O_A está mal, O_B está bien

Fix A

• O_A está bien, O_B está mal

Fix B

• O_A tiene razón, O_B tiene razón

Con suerte, también están de acuerdo.

• O_A está mal, O_B está mal

Con suerte, no están de acuerdo, así que sabrás hacer algo al respecto.

Ningún proceso atrapa todo. Claro, ha duplicado su código, pero piense en él como el 2 en O (2n). El control de calidad automatizado hasta las pruebas de integración es algo maravilloso. Las pruebas manuales son un lastre para la innovación. Especialmente en los cambios transversales que exigirían una prueba completa. Además, dado que tendrás diferentes programadores que implementan lo mismo, puedes hacer que compitan.

Deben ser diferentes personas para aumentar las probabilidades de obtener diferentes errores. No recomiendo crear el sistema B haciendo frente al sistema A. Todo lo que le da es una prueba de regresión. Puede obtener lo mismo simplemente guardando copias antiguas de O_A para compararlas con las nuevas.

La pregunta es esta: ¿es una mala práctica crear un "sistema de prueba" para probar el sistema real?

Si es así, entonces todas las pruebas son malas.

• ¿Qué pasa con la pendiente resbaladiza? Entonces, ¿no podemos argumentar que necesitamos otro sistema para probar el "sistema de prueba"?

Sí, podemos argumentar eso. Llamaremos a este tercer sistema, system_A. :PAG

• El costo es definitivamente prohibitivo, ya que los desarrolladores ahora necesitan aprender al menos 2 bases de código, con quizás la complejidad de System_B mayor que System_A. ¿Cómo cuantificaríamos cuán bueno o malo es tener System_B para la organización?

Por la cantidad de clientes satisfechos que nos pagan por jugar con pistolas nerf. Se ha liberado del costo de las pruebas manuales. Has creado algo cuya utilidad se demostrará cada vez que un error sea detectado. Los errores detectados temprano cuestan mucho menos que los errores reportados tarde.

• Una de las razones "convincentes" originales para crear System_B fue "automatizar" las pruebas. Ahora estamos muy orgullosos de estar completamente automatizados (porque System_B genera la entrada para arrancar el proceso de usarlo para generar también la salida). Pero creo que hemos hecho más daño e introducido más complejidad, de manera no cuantificable. ¿El trabajo de QA debe ser completamente automatizado? ¿Es esa razón suficiente para justificar la creación de un sistema paralelo?

La complejidad de System_B está maravillosamente aislada de System_A. No es más difícil agregar características a System_A porque existe System_B. De hecho, es más fácil porque System_B les da la confianza para ir rápido.

• Mi verdadera preocupación es esta, a pesar de que todos sabemos que System_B está mal (con bastante frecuencia). Si System_B es tan bueno procesando la entrada y su salida es la fuente de oro, ¿por qué no reemplazar System_A con System_B? A eso, nadie en el trabajo puede proporcionar una respuesta satisfactoria.

¿Es esto un error tipográfico? System_B a menudo está mal, ¿es el estándar de oro que desea utilizar para reemplazar System_A?

Asumiré que querías decir que System_A a menudo está mal. Realmente no importa cuál está mal con más frecuencia. Cualquiera que esté equivocado es el que necesita trabajo. Estos sistemas no deciden lo correcto o lo incorrecto, los desarrolladores lo hacen. Lo que hace la prueba es producir un desacuerdo que significa que algo no está bien. Los desarrolladores descubren qué es eso. Recuerde, aquí no se produce ningún estándar de oro. Solo hay acuerdo o desacuerdo. El desacuerdo exige que el trabajo deba realizarse. Parte de ese trabajo es averiguar dónde.

Cuando tiene un sistema en producción que realmente utilizan los clientes, tener un sistema de control de calidad para verificar las correcciones de errores y la nueva funcionalidad es una necesidad absoluta. Desde el punto de vista de la calidad, debe ser una réplica del sistema de producción lo más cercana posible. De esa manera, si se asegura de que el sistema de producción y su sistema de control de calidad sean idénticos, lo que funciona en uno debería funcionar en el otro. Si no es el caso, entonces los sistemas no son idénticos, las entradas no eran idénticas y / o las salidas se malinterpretaron.

Esto ocurre doblemente si su sistema es de misión crítica y se requiere que esté disponible 24/7. Entonces no puede darse el lujo de no tener un sistema de control de calidad, ya que debe minimizar absolutamente el tiempo de inactividad en el sistema de producción. Y si se trata de un sistema 24/7, la réplica exacta del sistema de producción es una recomendación muy, muy fuerte.

Ahora, el inconveniente obvio de este enfoque es el costo. Duplica los costos de hardware y aumenta los costos de implementación y mantenimiento. Además, se tendría que implementar una replicación continua de datos del sistema de producción al control de calidad, de modo que minimizáramos la posibilidad de obtener resultados diferentes debido a la diferencia en los datos con los que trabajan los sistemas.

Por lo general, se puede encontrar cierto equilibrio reduciendo algunos de los componentes del sistema de control de calidad en relación con el sistema de producción, de modo que la mayor parte de la funcionalidad se pueda probar adecuadamente. Por lo general, son servidores redundantes, el tamaño de los servidores o la cantidad de estaciones de trabajo. Sin embargo, según mi experiencia, siempre se encuentra algún error exactamente en la parte que se redujo, y luego es una pesadilla reproducir el problema e implementar la solución mientras se mantiene el tiempo de inactividad mínimo permitido en el sistema de producción.

Cada vez que prueba un sistema, debe saber cuál es el resultado esperado.

El problema con tener un sistema que genere este resultado esperado es obviamente 'cómo pruebo ese sistema'

Aun así, no es habitual ver a las personas usar hojas de cálculo, por ejemplo, para generar conjuntos de resultados esperados.

Al final del día, aunque realmente necesita un humano para interpretar los requisitos del sistema y producir manualmente el resultado esperado. Si tiene un sistema, hágalo y solo verifique las diferencias, entonces se saltará sus pruebas.