¿Estrategia a largo plazo para implementar un sistema de control de calidad?

7

Se me ha asignado la tarea de implementar algunas pruebas de control de calidad en un sistema masivo existente. Vamos a comenzar con las pruebas a nivel del sistema y podríamos agregar pruebas unitarias si se considera necesario.

Realmente no sé por dónde empezar. Estoy pensando en crear un nuevo proyecto en la solución principal dedicada completamente a las pruebas de control de calidad. A partir de ahí, solo agregaré pruebas NUnit a nivel del sistema que se pueden ejecutar automáticamente desde ese proyecto.

¿Cómo suena eso? Quiero asegurarme de tomar las decisiones correctas ahora para que el sistema de control de calidad no se ensucie y se complique demasiado en el futuro. Dado que se ejecutará junto con un sistema grande, anticipo que también crecerá para ser un sistema grande, lo que lo hace vulnerable a convertirse en un incómodo desorden de código.

¡Cualquier sugerencia sería genial!

    
pregunta sooprise 31.05.2011 - 16:02

3 respuestas

5

Un buen punto de partida es el estándar IEEE en Planes de garantía de calidad del software .

Hay muchos factores a considerar -

  1. ¿Cómo gestiona el proceso de control de calidad?

  2. ¿Qué normas y convenciones seguirá su equipo?

  3. ¿Cuáles son tus métricas? (Es decir, ¿qué elementos medirá y cómo medirá e informará sobre ellos?)

  4. ¿Qué auditorías realizará para asegurarse de que se realizaron las pruebas, sus métricas son válidas, etc.?

  5. ¿Qué conjunto de documentación esperará y cómo revisará si esos documentos son correctos?

  6. ¿Cuál es su plan general de pruebas? (Esto incluye definiciones de prueba, horarios, recursos requeridos, etc.)

  7. ¿Qué equipo de prueba, herramientas, plataformas de prueba, etc. se usarán?

  8. ¿Cómo controla el equipo de prueba y las plataformas de prueba (incluyendo la calibración y gestión de la configuración de la (s) plataforma (s) de prueba?

  9. ¿Cómo se informan los problemas?

  10. ¿Cómo asignas y resuelves problemas y cómo controlas y gestionas este proceso?

  11. Gestión de la configuración y planes de control del código fuente.

  12. Control de medios para los elementos que publica y distribuye. Esto incluye cualquier material impreso, material que distribuya a través de CD o DVD, o software y documentación que ponga a disposición a través de la web.

  13. Si está utilizando subcontratistas y proveedores, ¿cómo está administrando y supervisando la calidad del producto y el material que le están suministrando?

  14. Usted planea crear, mantener y conservar registros de sus actividades.

  15. Capacitación que se requerirá para los miembros del equipo.

  16. Plan de gestión de riesgos.

respondido por el Jay Elston 31.05.2011 - 16:31
3

Probablemente querrá al menos un ensamblaje de prueba de unidad por ensamblaje en el sistema.

Podría argumentar que podría valer la pena dividir las pruebas de lógica de negocios en varios ensamblajes de prueba, diga "BllTests.Customer, CllTests.Product, BllTests.Basket" etc.

Lo peor que puedes hacer es meterlos todos en un gran ensamblaje, es el equivalente a tener todo tu proyecto en un solo ensamblaje: hace que las cosas sean mucho más difíciles de administrar. Es probable que su retroalimentación de prueba provenga de un servidor de integración continua, por lo que querrá una precisión bastante precisa de qué prueba está fallando y qué parte del sistema impacta en la prueba, para que pueda tomar decisiones sobre el impacto de la falla en sí.

DEFINITIVAMENTE no desea que las pruebas se realicen en el mismo ensamblaje que cualquier código de producción. ¡Si los incluyó todos con el código de producción, tendrá que implementar un conjunto de ensamblajes de terceros en su servidor de producción que no tienen ningún uso para el producto en sí y simplemente agregar otro posible punto de falla!

EDIT

Bien, entonces estamos tratando con un monolito. Esto significa que es poco probable que tenga una abstracción de interfaz (es decir, todas las clases que hacen lógica implementando un ILogicInterface, por lo que puede probar contra interfaces en lugar de intentar ejecutar pruebas contra clases concretas).

Esto va a ser un problema, tendrás que hacer pruebas sin el enfoque estándar de burlarse de las interfaces dependientes (usando algo como Rhock mock).

Le sugeriría que el mejor método para usted es comenzar poco a poco: haga un solo ensamblaje "BllTests.Customer". Luego, lentamente, mueva su implementación para heredar interfaces, comenzando justo en la parte inferior del código (abstraer el acceso a sus datos es un gran comienzo). Luego, realice una prueba de unidad de sus pequeños cambios (estamos hablando de 4-5 métodos dentro de una sola clase). Luego escoge la siguiente pequeña unidad de lógica y repite. Cuando tenga una buena cantidad de código heredado de la interfaz: comience a dividir su código en ensamblajes separados: "Bll.Implementation" y "Bll.Interfaces".

La mejora progresiva es el nombre del juego, no tiene mucho sentido probar el código de espagueti de unidad, sus pruebas de unidad serán muy frágiles o no probarán suficientes rutas a través del código para que sean indicadores útiles de si tiene un problema de código .

Si no puede editar la base de código principal (no siempre es una opción), aún así, sugeriría el enfoque de ensamblaje de prueba múltiple. Intente presionar para que todos los códigos nuevos se realicen en ensamblajes separados, para evitar que su monolito se vuelva aún más grande. Pero mientras tanto, muestre cómo un conjunto de ensamblajes pequeños y coherentes puede ser mucho más fácil de administrar: liderar con el ejemplo.

    
respondido por el Ed James 31.05.2011 - 16:10
2

Escucharía sugerencias sobre cómo separar los ensamblajes de prueba del código de producción y también cómo dividir los ensamblajes de prueba en componentes o inquietudes por separado. Además, un servidor de integración continua lo ayudará a ejecutar las pruebas unitarias para cada compilación y le informará cuando las pruebas unitarias estén fallando para que la compilación o las pruebas se puedan abordar.

Solo recuerde que una prueba de unidad verdadera debe ser independiente del sistema y debe probar una sola funcionalidad de un solo componente.

Mencionó pruebas del sistema que prueban la integración de varios componentes, como bases de datos, servicios web, recursos de archivos, etc., que son específicos de un entorno y no necesariamente de un solo componente. Estos también son importantes, pero deben excluirse de la integración continua, ya que cuando fallan, no necesariamente muestran un problema de código o lógica. Estas fallas deben indicar principalmente una falla de integración para un entorno en particular (como problemas de conexión con la base de datos, o no se pueden comunicar con un servicio web o archivo no encontrado, etc.)

    
respondido por el maple_shaft 31.05.2011 - 16:26

Lea otras preguntas en las etiquetas