Cómo escribir un plan de prueba para un microservicio

Yo no lo haría ¿Qué valor agrega un plan de prueba? ¿De qué pruebas es el tiempo dedicado a tomar?

Un microservicio es una cosa demasiado fina para escribir documentos de planificación.

Pero probablemente sea un elemento en la lista de verificación de alguien de lo que piensan que es el desarrollo de software.

Una de las ventajas de un microservicio es que es pequeño y comprobable. Tendrá una funcionalidad claramente definida. El plan es simplemente, prueba que lo hace.

¿Pero una arquitectura de microservicios? Ah, ahora estamos en una imagen más grande. Ahora un plan escrito puede tener sentido. ¿Qué políticas de prueba aplicaremos a través de microservicios, para cosas como la validación de entrada y la seguridad? ¿Cómo probaremos la integración, que la salida de un servicio se enviará a otro?

¿Cómo podemos verificar, a nivel de sistema, que los microservicios correctos se están llamando correctamente, para un caso de nivel de sistema dado?

Si está pensando en un plan de prueba para un microservicio, no estará pensando en estos problemas. Estarás ocupado haciendo trabajo ocupado.

Un plan de prueba debe ser la comunicación. Desde alguien que conoce la idea de la prueba, hasta alguien que necesita saberla. Eso puede ser más allá de los límites del equipo, o puede ser temporal, desde un ahora hasta un futuro. O, a veces, desde un ahora usted hasta un futuro auditor regulatorio (por ejemplo, auditoría de cumplimiento de FDA GMP).

Pero algo así como “Para cada microservicio, verifique que cumpla con su contrato de servicio especificado, que las entradas inválidas se detecten y se manejen adecuadamente, que se respeten los límites de seguridad y que cumpla con cualquier restricción de rendimiento. Los resultados deben validarse, sin sensibilidad a la variación permisible. Utilizaremos la herramienta X para alimentar a cada servicio un conjunto definido de parámetros en cada categoría, especificado como JSON en un archivo específico del servicio. Las pruebas se ejecutarán automáticamente en cada compilación. Los resultados se registrarán y se retendrán para cada hito y publicación “.

Esa es una dirección clara para que un ingeniero de control de calidad y un desarrollador trabajen juntos para producir las pruebas. Es un criterio claro para la administración juzgar las pruebas resultantes. Con una enumeración de los servicios y los registros correspondientes, tiene su registro de cumplimiento (que también es útil para detectar cuándo se introdujo un problema).

El sitio web de Martin Fowler tiene una excelente plataforma de diapositivas en las pruebas. Estrategias de prueba en una arquitectura de microservicios.

Cuando dices plan de prueba, creo que vienes de un entorno de control de calidad. Eso está bien, y aún tiene valor en una arquitectura impulsada por pruebas altamente automatizadas como los microservicios.

Nuevamente para robarle a Martin Fowler: concéntrese en productos, no en proyectos. Su plan de prueba debe cubrir el área funcional de su equipo y no necesariamente un servicio individual.

Para ser específico:

¿Qué se incluiría en un plan de prueba?

Un plan que alcanza todos los límites de servicio entre los servicios del producto, con la menor intervención manual posible.

¿Cómo evaluaría los requisitos funcionales?

De la misma manera que lo haría con cualquier otra pieza de software. Una gran parte de los microservicios es la automatización, por lo que es ideal usar herramientas automatizadas tanto como sea posible.

¿Qué frecuencia necesita ser probado?

Idealmente en cada actualización incremental de cualquiera de los servicios subyacentes. Aún mejor si la automatización puede ejecutarlo cada minuto.

Además de los elementos del plan de prueba específico para microservicio, el plan de prueba es un documento relacionado con los procesos de gestión de prueba, que debe tener la estructura típica del plan de prueba: capítulos y contenido de los capítulos. El joven estándar internacional de documentación de pruebas es ISO 29119–3, que ofrece recomendaciones sobre cómo debe verse el documento del plan de pruebas en proyectos tradicionales y ágiles. Cuando este estándar no está disponible, se pueden usar materiales gratuitos para escribir el plan de prueba, como los modelos de proceso, por ejemplo, TMMi.

Estoy escribiendo sobre el contenido típico de los documentos del plan de prueba, porque varios estándares dan instrucciones listas para usar y el autor del plan de prueba puede defenderse contra las objeciones relacionadas con la incompletitud del plan de prueba o el contenido demasiado grande y no necesario, al decir que el documento del plan de prueba fue escrito de acuerdo con las mejores prácticas populares.