Las pruebas en grandes empresas, en empresas, son a menudo una tarea complicada e ingrata. La brecha entre las divisiones de negocios y TI es enorme: cuando un desarrollador tiene una visión a nivel de código y una verificación a nivel de pruebas unitarias, y el cliente piensa que funciona o no funciona incluso con servicios, pero con procesos completos que van más allá de un equipo de desarrollo, o incluso el conjunto divisiones \ empresas. Y pide organizar pruebas comerciales, o pruebas de extremo a extremo, o pruebas basadas en escenarios de principio a fin (fin 2 fin).
Comencemos desde el principio: desde los dos pilares de donde provienen estas notorias "pruebas comerciales de extremo a extremo", es decir, de la pirámide de pruebas y el estándar ISO9000.
Pirámide de prueba
La pirámide de prueba probablemente sea familiar para cualquier evaluador que se haya vuelto competente en su profesión y haya acumulado golpes al comunicarse con las unidades relacionadas. Especialmente a menudo es necesario recurrir a él cuando se corrobore la automatización de pruebas. ¿Qué pruebas son más baratas y más importantes de desarrollar? Y correr?
La esencia de la pirámide de prueba no es complicada: la prueba debe basarse en las pruebas más simples y rápidas de escritura y ejecución: pruebas unitarias. Por supuesto, verificar las interfaces de clases y funciones no es lo que se puede mostrar al cliente, pero sin esta base sólida, monolítica y sin problemas, es casi imposible construir algo más alto. Como regla, varias docenas de funciones, métodos y clases implementan algún tipo de funcionalidad para el cliente, y de hecho, una docena de pruebas unitarias pueden reducirse a algunas pruebas de nivel superior. El cliente ya necesita un hermoso departamento con decoración, pero es poco probable que esté satisfecho cuando las ventanas torcidas de su departamento dejen de abrirse, y el piso y el techo se quiebren por la primera brisa. Sin embargo, el cliente mismo para ir al apartamento y verificar su calidad puede no ser la mejor idea. De acuerdo, es difícil para el usuario verificar la calidad del concreto en los cimientos y reproducir todas las condiciones climáticas. Entonces, en las pruebas, por supuesto, se necesitan pruebas de nivel superior, luego solo cuando hemos elaborado pruebas unitarias, también lo son las pruebas de un nivel superior.
Es más difícil desarrollar y llevar más tiempo realizar pruebas de nivel superior: pruebas de integración, que verifican el funcionamiento correcto de los módulos de trabajo simultáneos en los que trabajó todo el equipo, lanzando su producto (sistema). Es decir, se verifica la integración del código, se prueba el sistema sin tener en cuenta la interacción con sistemas externos. Dichas pruebas ya implican una verificación de alto nivel, muy probablemente a través de una llamada al sistema a través de la API del sistema o incluso una GUI (frontal). Trabajar con este tipo de prueba es más difícil: para cubrir todas las ramas y matices del código, lo más probable es que necesite usar una gran cantidad de comprobaciones superpuestas en varios datos de prueba, y durante la automatización a menudo se desarrollan un montón de condiciones y ramas en los scripts. Es decir, por un lado, ya nos hemos acercado al usuario, lo que nos dificulta la vida, pero por otro lado, todavía nos resulta difícil encontrar un lenguaje común, nos cuesta más y la calidad de los controles aún no es suficiente. Es decir, podemos lanzar al cliente a un nuevo departamento, él puede verificar todo, pero sin tener en cuenta la interacción con otros residentes, las condiciones climáticas y los servicios públicos. De acuerdo, el sentido de un mundo ideal, un modelo, en la vida real, por regla general, no es mucho.
Si agregamos estas condiciones, veremos cómo nuestro sistema interactúa con sistemas externos: proveedores y consumidores, con nuestro entorno, es decir, llevamos a cabo pruebas del sistema, entonces podemos ver fácilmente que la complejidad de las pruebas también aumentará. Tendremos que lograr la operatividad simultánea de todos los sistemas que interactúan, aunque sin la participación de especialistas en ellos. Por ahora, es suficiente para nosotros simplemente aceptar algunos datos de nuestros proveedores y transferirlos a nuestros consumidores. En la secuencia y formato correctos. El destino adicional de los datos no nos molesta. Lo principal es que nuestro sistema funciona correctamente en el entorno adecuado. Y todo estaría bien aquí: para nuestro cliente ya podemos realizar una demostración a gran escala, pero solo en la vida real no son todos los criterios de éxito para nuestro desarrollo. Por supuesto, es bueno que el cliente tenga su apartamento en una casa sólida, pero si necesita salir de él, trepar por el alambre de púas, luego pasear en canoa por el lago con cocodrilos en chozas repletas de serpientes, entonces tal vez no tengamos razón lo hizo allí?
Por lo tanto, aquí la primera idea para las pruebas de extremo a extremo es verificar no solo nuestro entorno, sino también todos los sistemas interconectados a través de los cuales pasan los datos recibidos o enviados por nuestro sistema. Y esto, a su vez, significa que tendremos que combinar varias de estas "pirámides de prueba" entre sí. La construcción de un puente frágil sobre el cual mantendremos los datos valiosos para el usuario por el asa.
La única pregunta es cómo hacer esto. ¿Quién debería hacer esto? ¿Cómo armar?
ISO9000
Una serie de estándares que describen el sistema de gestión de calidad, incluido el hecho de que cualquier proceso en la organización debe ser descrito, documentado, incluso si es el proceso de emitir un rastrillo en el otoño al conserje. Y si es así, no se puede describir un solo proceso que tenga lugar dentro del software utilizado y desarrollado en la organización. La pregunta es cómo hacer esto. Por supuesto, la mejor descripción, desde el punto de vista de BDD, es la descripción del comportamiento mediante pruebas, bajo la cual se ubicará la pirámide de prueba. Pero volveremos inmediatamente a nuestro dilema combinando varias pirámides con cuerdas delgadas de arriba a abajo, a lo largo de las cuales nuestro equilibrista y sus usuarios caminarán sin seguro.
El enfoque basado en procesos es una estrategia de gestión que requiere que las organizaciones gestionen sus procesos y las interacciones entre ellos. Por lo tanto, debe considerar cada proceso importante de la empresa y sus procesos de soporte.
Por lo tanto, es más fácil usar abstracciones: cree al menos un diagrama de proceso e indique sus entradas y salidas, haga que el proceso sea controlado y medible, garantice la interconexión con los procesos primarios y secundarios, como lo exige ISO9000
Todos los procesos tienen:
• entradas;
• salidas;
• control operacional;
• medición y monitoreo apropiados.
Cada proceso tendrá procesos de soporte que apuntalarán y permitirán que el proceso se realice
Los diagramas de negocios son los más adecuados para este propósito, y los estándares como UML, BPMN, ARIS, etc. se usan con mayor frecuencia, y los procesos en sí mismos se convierten en diagramas de flujo con "cubos" colgados en ellos. Existe interacción entre los "cubos", en el estándar BPMN es un flujo de acciones y un flujo de mensajes. ¡Y esto es justo lo que necesitamos!
Cualquier compañía que quiera tener un certificado y siga el estándar ISO9000, muy probablemente, ha adquirido dichos esquemas, y son una parte integral de los requisitos de nivel superior. Si la empresa tiene buenos analistas, lo más probable es que los enlaces a los requisitos para acciones individuales de los esquemas se reduzcan a los requisitos de bajo nivel. Los necesitamos
De hecho, en los diagramas podemos ver todo el proceso y comprender qué escenario necesitamos construir y qué sistema / equipo ejecutar con qué datos en cada momento.
No estoy subestimando el trabajo de los desarrolladores que escriben código competente que envía mensajes entre diferentes partes de sistemas de software y hardware, pero es imposible tener todo en mente. Y cuando el proceso se usa en muchos otros procesos, es mejor tener una "tarjeta" con usted para realizar pruebas competentes, y aún más para construir un modelo de prueba.
Que en la practica
Entonces, tenemos dos introductorios: cada equipo / sistema debe tener una pirámide de pruebas preparadas, desde las pruebas unitarias más pequeñas hasta las pruebas de sistemas complejos, así como el hecho de que dentro de la organización, debemos describir los requisitos en forma de negocio -procesos. Este hecho nos permitirá responder rápidamente al cliente qué proceso de negocio funciona y en qué momento se rompe, y nosotros, cuando recibimos defectos de la operación industrial, realizamos rápidamente un análisis de la causa raíz (análisis de las causas raíz de los defectos). En teoría
Pero en la práctica, todo nuevamente recae en el probador: ¿cómo, desde un montón de pruebas, especialmente las extrañas, seleccionar las correctas, construirlas en una cadena y la entrada de cada uno de los sistemas para enviar los datos necesarios y compararlos con el resultado esperado correctamente determinado?
La opción más fácil es desarrollar inicialmente pruebas basadas en modelos comerciales y dividir los equipos en proyectos que implementen un proceso comercial particular. Para esto, en algunas herramientas de administración de pruebas, ya es posible cargar esquemas BPMN (por ejemplo, para HPE ALM, se admite la carga en formato XPDL). HP ALM dividirá el esquema en un conjunto de requisitos (acciones) y, si lo desea, creará una jerarquía de requisitos (módulo Requisitos-> Modelos de negocio). Luego, nuestro negocio es cubrir los requisitos con pruebas y luego construir los requisitos y, por lo tanto, las pruebas en cadenas que cubren nuestro proceso comercial. Estas cadenas en HPE ALM se denominan "rutas" y le permiten ver todas las combinaciones de secuencias. Si lo desea, las cadenas se pueden convertir inmediatamente en pruebas.
Pero incluso si no utiliza herramientas de prueba, aún tiene que hacer cadenas a partir del proceso comercial. Especialmente teniendo en cuenta la imperfección de las herramientas (no todo es tan color de rosa), así como el hecho de que, muy probablemente, el modelo de prueba deberá ensamblarse después de los hechos y ejecutarse en forma de regresión por parte de un "equipo común" que no esté atascado en nuevos proyectos.
¿De cuántas maneras puede una ardilla alcanzar un bulto?En este caso, tendremos que abrir las pruebas de cada equipo, encontrar las que están vinculadas a los requisitos que aparecen en el modelo de negocio y construir cadenas a partir de ellas, guardándolas en un "espacio común". Crear un espacio común es algún tipo de sustituto, pero en cualquier caso debería serlo, incluso en forma de un libro de granero, Excel o un área de proyecto en una herramienta de gestión de pruebas. Si hablamos de HPE ALM nuevamente, el módulo BPT (Business Process Testing) es responsable de esta funcionalidad, que al mismo tiempo le permite transferir los resultados de una prueba a los parámetros de otra. Sin embargo, si desea y trabaja duro en HPE ALM, es posible implementar esto mediante la reconstrucción de los conjuntos de prueba (Conjunto de prueba) en el flujo de ejecución (Flujo de ejecución). Luego, al iniciar el conjunto completo, se llamará a los probadores responsables de pasar cada uno de los componentes del script de extremo a extremo.
Y, por desgracia, las pruebas por sí solas no son suficientes. Según mi práctica, casi todas las herramientas tienen algunos defectos fatales, y por lo tanto, si llegas a la etapa de prueba de automatización en un proceso de negocios, llegarás a la creación de un script que extraerá las pruebas en la secuencia correcta.
Como resultado, se pueden hacer dos conclusiones:
1) para escenarios de extremo a extremo, es muy probable que se utilicen pruebas desarrolladas previamente para cada uno de los sistemas incluidos en la cadena de procesos de negocio (escenario)
Es posible presentar todos los conjuntos de pruebas completos de una empresa en forma de matriz dispersa, donde las pruebas para cada sistema se distribuyen en columnas (por simplicidad: pruebas del sistema) y los procesos comerciales en filas. Es decir, para ciertos procesos comerciales, debe seleccionar \ crear pruebas que cubran el proceso comercial, establecer relaciones. Si no hay cobertura, esta es una ocasión para llenar los vacíos en el modelo de prueba, o para asegurarse de que la calidad esté garantizada por otros niveles de prueba (prueba de integración, prueba de unidad, revisión de código y ejecución a través de analizadores).
2) Se necesita una herramienta para monitorear, rastrear y actualizar el proceso comercial para la sincronización con el modelo de prueba.
Y si las herramientas de prueba soportan más o menos tolerablemente la creación de un modelo de prueba, entonces todo es realmente malo con la actualización, a menudo es más fácil recrear el modelo nuevamente que tratar de ver cambios en el proceso y el modelo de prueba. Y la experiencia de equipos reales sugiere que es mejor crear una visualización en vivo de la arquitectura. La forma más fácil de hacerlo es en el área común, usando un tablero de marcadores y pegatinas simples. Luego, los equipos que participan en el proceso de negocio pueden ver claramente cómo se está modificando el proceso (se eliminan y agregan conexiones, se eliminan y agregan acciones). Lo principal es que todos tengan acceso al tablero. Además, tenga en cuenta que si el proceso involucra mensajes entre sistemas, entonces, como regla, al menos debería haber dos pruebas de cada sistema: para enviar y recibir datos. Sin embargo, en lugar de pegatinas, puedes usar una ciudad entera de Lego (desde grandes bloques), o algo aún más creativo. Lo principal aquí es un idioma y un espacio de información, que es muy escaso en la empresa.
En conclusión
Organizar pruebas visuales y adecuadas de los procesos comerciales es algo complejo y muy costoso. Tenga en cuenta que las pruebas E2E no son solo la aceptación, las pruebas del usuario que realizará el cliente, sino la construcción de un puente, teniendo en cuenta todas las situaciones posibles que el cliente seguirá y guiará a los usuarios en el pie.
Una vez más, E2E, este no es un paseo por Lada Kalina a través del puente, y ni siquiera dos pasos de kamaz. Este es un trabajo de ingeniería complicado, sopesar puentes con sensores y llevar a cabo todas las comprobaciones y situaciones posibles, al menos una descripción de estos escenarios.
El hecho de que su empresa necesite o no una ejecución de acabado tan ideal depende exclusivamente de sus objetivos y necesidades. Siempre, como con cualquier prueba, debe evaluar los riesgos potenciales de defectos faltantes en esta etapa, así como el costo de la preparación y realización de pruebas de extremo a extremo. Evaluar lo que le costará más de esto y solo entonces actuar. Pero en el caso de las pruebas de extremo a extremo en los procesos comerciales, debe recordarse que no tiene sentido sin una base sólida en forma de pruebas de unidad de tasa de 100% (~ 90-100% de cobertura), sin pruebas de integración (~ 60-80% de cobertura, 90- 100% de tasa de paso), sin pruebas del sistema (20-40% de cobertura, 80-100% de tasa de paso). Establecer criterios para el éxito (puertas de calidad) es más que un requisito para la calidad del producto, lo principal a recordar aquí es que el volumen de las pruebas E2E es solo la parte superior de la pirámide (1-2% de cobertura, ~ 99% de tasa de aprobación), que no debe ser mayor que su base, no al mismo tiempo sea un tapón de agujeros de los pasos anteriores. Este es un suplemento que a priori se considera cerrado en las etapas anteriores.
La organización de tales pruebas es principalmente el trabajo de preparar y sincronizar casos y datos de prueba (análisis de prueba), así como un conjunto de medidas organizativas, sincronizando equipos en un lugar al mismo tiempo en un sitio de prueba viable. Teniendo esto en cuenta, no se debe tratar de mostrar al cliente "pruebas de extremo a extremo" con anticipación, para no perder tiempo de una vez a una gran cantidad de personas sin todos los componentes de trabajo ensamblados.
PS describió las herramientas, así como las prácticas, por ejemplo, el autor no se fijó el objetivo de anunciar productos y declaró que este enfoque para las pruebas de extremo a extremo es la única forma verdadera.