Liderazgo en Pruebas: Garantía de Procesos Empresariales
Nota del editor: Bienvenido a la serie Liderazgo en Pruebas del experto y consultor en pruebas de software Paul Gerrard. La serie está diseñada para ayudar a testers con algunos años de experiencia—especialmente quienes trabajan en equipos ágiles—a destacar en sus roles de líder de pruebas y gestión.
En el artículo anterior examinamos las herramientas necesarias para realizar pruebas y colaborar de manera efectiva. En este artículo, vamos a tratar la fase final de las pruebas y cómo confirmar que tus sistemas entregarán lo planeado.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul, el cual te recomendamos encarecidamente para profundizar en este y otros temas. Si lo haces, usa nuestro código exclusivo de cupón QALEADOFFER para obtener $60 de descuento en el precio total del curso.
Hemos llegado a los dos últimos artículos de la serie Liderazgo en Pruebas. Hasta ahora hemos cubierto cómo planificar y gestionar un proyecto de pruebas de principio a fin y muchos de los procesos y herramientas involucrados.
En este artículo, quiero hablar sobre la Garantía de Procesos de Negocio Empresariales (EBPA) — qué es y cómo abordarla. Trataremos:
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- ¿Qué es la Garantía de Procesos de Negocio Empresariales?
- Entender la Integración de Sistemas y las Pruebas
- Pruebas Horizontales: el enfoque de pruebas E2E
- Riesgos de integración y pruebas E2E
Hay mucho de qué hablar, así que vamos al grano.
¿Qué es la Garantía de Procesos de Negocio Empresariales?
Cada organización que implementa nuevos sistemas ha experimentado problemas al usarlos por primera vez. Los sistemas que incluso difieren ligeramente de la infraestructura y los procesos de negocio existentes pueden causar caos y ser difíciles de reparar.
Las prácticas iterativas, ágiles y más colaborativas ayudan, pero los desafíos de la integración a nivel empresarial sólo pueden abordarse con una fase final de pruebas.
A esta fase final la llamamos Garantía de Procesos de Negocio Empresariales (EBPA). El éxito depende de una o varias fases de pruebas que demuestren que los sistemas, procesos de negocio y datos estén integrados y entreguen los servicios prometidos.
Hay pocos artículos académicos sobre el tema, aunque las etapas finales de todo proyecto a gran escala están dominadas por esta actividad. Para informar nuestra estrategia EBPA, primero echaremos un vistazo más de cerca a los tipos de integración de sistemas y pruebas con los que tendrás que lidiar.
Para proyectos a nivel empresarial, la complejidad se incrementa exponencialmente. Por eso, elegir un software de gestión de bases de datos de nivel empresarial puede ser un diferenciador en tus esfuerzos de ingeniería de calidad.
Entender la Integración de Sistemas y las Pruebas
Integración vertical
Desde una perspectiva técnica, la integración representa la conexión entre los distintos niveles de la arquitectura técnica. Las pruebas de integración para desarrolladores consisten principalmente en comprobar que los datos introducidos mediante la interfaz de usuario en una transacción de actualización se almacenan correctamente en la base de datos.
En la dirección opuesta, se verifica que los datos almacenados puedan presentarse correctamente en la interfaz de usuario cuando se solicite. Las conexiones y rutas a través de la arquitectura técnica pueden visualizarse como rutas verticales o pruebas de integración vertical.
Integración horizontal
Los usuarios finales no ven la arquitectura técnica ni toda su complejidad. Ellos ven el sistema como una serie de funcionalidades ejercidas por diferentes usuarios en lo que podría llamarse un recorrido de usuario.
Estos recorridos trazan rutas en los procesos de negocio de los usuarios y acceden a distintos sistemas y funciones en cada paso usando la interfaz de usuario.
Los equipos ágiles trabajan en historias a menor escala y no ven la épica completa. Normalmente, los desarrolladores no pueden trazar ni probar recorridos de usuario más largos porque no disponen de los entornos ni los datos. Por eso, las organizaciones suelen depender de pruebas a mayor escala y equipos de testers para validarlas.
Los recorridos de usuario naturalmente abarcan tanto el proceso de negocio como las funcionalidades del sistema en combinación. De este modo, las pruebas horizontales ponen a prueba la integración entre los sistemas y el proceso de negocio.
Las pruebas de integración vertical adoptan una perspectiva más técnica; las pruebas horizontales adoptan una perspectiva de usuario o de proceso de negocio.
Ahora, usemos estos conceptos para construir un modelo que nos ayude a comprender y planificar la EBPA. Haremos referencia a los enfoques de integración horizontal y vertical en el modelo.
Un modelo para la integración y las pruebas
La integración es un concepto a menudo malentendido. El proceso de integración en realidad comienza casi en cuanto se inicia la codificación. Podríamos decir que la integración comienza cuando tenemos dos líneas de código: la segunda línea de código debe integrarse con la primera. La integración termina cuando concluyen todas las pruebas funcionales en la aceptación del usuario.
Centrémonos en un ejemplo utilizando software comercial (COTS) y módulos de planificación de recursos empresariales (ERP).
La empresa desarrolladora de módulos COTS o ERP ha realizado pruebas unitarias y funcionales. Cuando estos componentes llegan, generalmente se puede suponer que funcionan y se integran técnicamente. Sin embargo, siempre existe el riesgo de que los componentes integrados de diferentes proveedores interactúen de formas imprevistas.
Además, si los componentes son personalizados, su comportamiento cambiará y de nuevo esto puede provocar efectos secundarios sutiles (y no tan sutiles) en otros lugares. Sigue siendo necesario realizar integración vertical para verificar el intercambio de control y datos en la pila tecnológica, e integración horizontal a través de los componentes y el proceso de negocio.
Representamos las cuatro actividades de integración en un modelo de cuatro cuadrantes con dos ejes. En el eje X se representa la escala del sistema bajo prueba: puede ser un solo componente o subsistema en aislamiento, o los sistemas integrados en el contexto del proceso de negocio.
El lado derecho del modelo está sombreado en azul y representa la EBPA. Probar nuestro sistema en el contexto de otros sistemas (SIT) y del proceso de negocio (BIT) es lo que denominamos Garantía de Procesos de Negocio Empresariales.
Veamos los cuatro cuadrantes uno a uno.
Pruebas de módulo, funcionalidad o componente
El módulo debe someterse a pruebas funcionales, ya sea personalizado o un componente COTS. La experiencia del usuario siempre es importante y debe integrarse con algún paso o actividad en el proceso de negocio.
Pruebas de integración de subsistemas
La integración es incremental. A medida que los componentes y funcionalidades de bajo nivel están disponibles, se integran en un sistema cada vez más grande y se prueban hasta que el sistema completo y coherente está listo. A esto lo llamamos pruebas de integración de subsistemas.
Pruebas de integración de sistemas (SIT)
Ningún sistema existe de manera aislada, por lo que cuando nuestro sistema está completo, necesitamos integrarlo con otros sistemas. Instalamos nuestro sistema en un entorno junto con sus sistemas de interfaz y probamos estos sistemas trabajando como un 'sistema de sistemas' a través de estas interfaces. El objetivo en esta etapa es abordar los riesgos técnicos de la integración y llamamos a esto pruebas de integración de sistemas.
Pruebas de integración de negocio (BIT)
Existe una etapa final de integración cuyo objetivo es garantizar que los sistemas construidos se integran con los procesos de negocio y los procedimientos (a menudo manuales) de los usuarios de esos sistemas. Incluyendo las interfaces externas del sistema (si no se han probado antes), validamos que los sistemas y los procesos de negocio, trabajando en conjunto, proporcionan recorridos de usuario coherentes y eficientes, y que gestionan y transfieren los datos de forma correcta y consistente. Normalmente, a esto lo llamamos pruebas de integración de negocio.
En lo que resta de este artículo, nos centraremos mucho en el lado horizontal, el de EBPA, del modelo.
Lectura relacionada: LAS 10 MEJORES HERRAMIENTAS DE GESTIÓN DE DATOS DE PRUEBA
Pruebas horizontales: el enfoque E2E
La integración horizontal depende en gran medida de lo que a menudo se denomina pruebas de extremo a extremo (E2E).
Las pruebas E2E son una técnica de diseño de pruebas que invoca una serie de transacciones conectadas, normalmente abarcando múltiples sistemas, incluido nuestro(s) sistema(s) bajo prueba. Estas pruebas tienden a seguir recorridos de usuario a través de sus procesos de negocio.
Dado un modelo de proceso de negocio, se trazan rutas a través del proceso para crear una serie útil de transacciones que simulan la forma en que los usuarios utilizarán el sistema en producción.
Estos modelos pueden ser diagramas familiares como diagramas de flujo o diagramas de carriles, o pueden ser representaciones más técnicas como diagramas de secuencia UML o diagramas de colaboración. (UML es el Lenguaje de Modelado Unificado utilizado por muchas organizaciones de TI).
Las pruebas E2E abordan riesgos específicos que no se pueden cubrir fácilmente mediante pruebas anteriores sobre subsistemas o entornos que dependen en gran medida de interfaces simuladas y datos puramente sintéticos.
En el ámbito de las pruebas horizontales, el enfoque E2E suele complementarse con software especializado. Para una lista seleccionada de software que puede optimizar este proceso, consulta estas soluciones de gestión de pruebas mejor valoradas
Aceptación
El concepto de «adecuación» es relevante para la integración de componente a componente, de sistema a sistema y de sistemas a procesos empresariales.
La aceptación normalmente se basa en los resultados de las pruebas E2E horizontales porque los responsables de negocio pueden confiar en que estas pruebas muestran cómo el nuevo sistema encaja y apoya su forma de trabajar. Las pruebas E2E horizontales les proporcionan la confianza de que el servicio entregado funcionará.
El proceso de aceptación de los sistemas suele depender, al menos en parte, del éxito de las pruebas E2E horizontales. Esto se debe a que solo las pruebas E2E ejercitan el sistema en un entorno realista y simulan la actividad real de los usuarios.
En muchas organizaciones, solo es posible en las etapas finales de las pruebas demostrar el funcionamiento de los sistemas y esto brinda confianza a los responsables de negocio de que el sistema funcionará como se requiere.
Si te piden planificar una prueba de aceptación, esperamos que la técnica de pruebas E2E desempeñe un papel importante en tu planificación.
Riesgos de integración y pruebas E2E
Como se ha comentado, los riesgos de integración se relacionan con la integración de sistema a sistema o la integración de sistema a proceso de negocio.
Algunas organizaciones eligen dividir las pruebas que abordan estos dos tipos de riesgo en Pruebas de Integración de Sistemas (SIT) y Pruebas de Integración de Negocios (BIT). Pero frecuentemente los riesgos y pruebas se fusionan en una única etapa de pruebas etiquetada como E2E, Aceptación o Pruebas de Negocio.
Sin importar cómo se estructuren las pruebas, se hace un uso intensivo del enfoque de pruebas E2E explicado anteriormente. En tu entorno, los riesgos que enfrentas pueden ser variaciones de estos temas y puede que necesites ajustar el objetivo y el enfoque de las pruebas de acuerdo a ello.
La lista de riesgos que se presenta aquí debe considerarse solo un punto de partida y servir para recordarte en dónde deberías enfocar tus pruebas. Es probable que existan riesgos específicos de tu organización, sector o tecnología que debas añadir a esta lista inicial.
En la tabla a continuación, «sistemas» se refiere al conjunto de sistemas integrados que comprenden el nuevo sistema o sistemas en desarrollo, otros sistemas heredados o de infraestructura y sistemas externos como bancos u organizaciones asociadas.
| Riesgo | Objetivo de la prueba | Enfoque de prueba |
| Los sistemas no están integrados (transferencia de datos). | Demostrar que los sistemas están integrados y realizan la transferencia de datos correctamente. | Prueba de Integración de Sistemas (SIT) |
| Los sistemas no están integrados (transferencia de control). | Demostrar que los sistemas están integrados (la transferencia de control con los parámetros requeridos se realiza de forma correcta). | SIT |
| Las interfaces fallan cuando se usan durante un periodo prolongado. | Demostrar que las interfaces pueden ser utilizadas continuamente durante un período extendido. | SIT (estas comprobaciones también pueden realizarse como parte de las pruebas de confiabilidad y/o conmutación por error) |
| Los sistemas no están integrados (los datos no se reconcilian entre interfaces). | Demostrar que los sistemas están integrados (los datos transferidos a través de la interfaz se utilizan de manera consistente, por ejemplo, moneda, idioma, métricas, tiempos, precisión, tolerancias). | SIT |
| Los sistemas no están sincronizados (las transferencias de datos no se desencadenan, se desencadenan en el momento incorrecto o varias veces). | Demostrar que las transferencias de datos se desencadenan correctamente. | SIT |
| Los objetos o entidades que existen en varios sistemas no se reconcilian entre los sistemas. | Demostrar que los estados de los objetos de negocio se representan con exactitud en los sistemas que contienen datos de los objetos. | Prueba de Integración de Negocios (BIT) |
| Los sistemas no están integrados con el proceso de negocio (cadena de suministro). | Demostrar que los sistemas se integran con los procesos de negocio y apoyan el proceso de la cadena de suministro. | BIT |
| Los procesos empresariales de back-end no apoyan los front-end web o móviles. | Demostrar que los procesos de la cadena de suministro son funcionales y respaldan el objetivo de negocio. | BIT |
| Los sistemas integrados utilizados por el mismo personal presentan interfaces de usuario o comportamientos inconsistentes para tareas similares o relacionadas. | Demostrar que los usuarios experimentan un comportamiento consistente en los sistemas al realizar tareas similares o relacionadas. | BIT (estas comprobaciones también pueden ejecutarse durante el chequeo de UX) |
Notas sobre la tabla de riesgos
Algunos de los riesgos anteriores requieren una explicación adicional.
Problemas de transferencia de datos
A menudo, los datos se transfieren entre sistemas a través de redes. Si estas transferencias se ejecutan como procesos por lotes y fallan, o si fallan como transferencias en tiempo real desencadenadas por un usuario, negocio u otro evento del sistema, los datos estarán ausentes en el sistema de destino.
Transferencia de control defectuosa
Una transferencia de control ocurre cuando una actividad del usuario o proceso del sistema transfiere al usuario o proceso a otra funcionalidad del sistema.
Normalmente, hay una elección de la funcionalidad de destino y, dependiendo de la acción del usuario o del contenido de datos de una transacción, se elige una ruta diferente a través de la aplicación.
Desde la perspectiva del usuario, se lo lleva al lugar equivocado en la aplicación o un proceso del sistema espera operar el proceso incorrecto y pierde la sincronización.
Los datos no se reconcilian
Un sistema puede distribuir datos relacionados, por ejemplo, con dinero, ubicación de activos o alguna cantidad física que debe «cuadrar» entre todos los sistemas.
Por ejemplo, cuando se compran y trasladan 100 artículos de inventario, se venden, se usan en procesos de fabricación, se consideran defectuosos y se devuelven o desechan, la cantidad de artículos registrada en cada subsistema debe conciliar con el conteo original de 100.
Una variación de este problema es, por ejemplo, las unidades utilizadas en los sistemas que almacenan datos. Los tamaños de lote o las agregaciones de conteo deben ser contabilizados, o los sistemas deben hacer coincidir las medidas métricas e imperiales, y así sucesivamente.
Sistemas no sincronizados
Relacionado con el problema de transferencia de datos anterior, los procesos del sistema que realizan las transferencias están programados para ejecutarse en la secuencia correcta, desencadenados por procesos o personas debidamente autorizadas, y se activan de manera oportuna y por el evento apropiado o la combinación de eventos adecuada.
Algunos procesos por lotes deben ejecutarse cada hora, diariamente, semanalmente, al final del mes, trimestre o año y necesitan ser verificados. Gran parte del comportamiento funcional depende del tiempo relativo de las transacciones o de la antigüedad de los datos entre sistemas y esto también debe revisarse.
Los objetos no concilian
En lugar de conteos de objetos, dinero o mediciones físicas, estos riesgos se relacionan con el estado de objetos que se mantienen en sistemas distribuidos. Por ejemplo, el estado de un registro de personal debe ser coherente entre los sistemas que contienen copias de ese objeto de datos. Los procesos que distribuyen los cambios de estado entre los sistemas que contienen copias del mismo objeto deben activarse y sus acciones comprobarse.
Sistemas no integrados con el negocio
El comportamiento de los sistemas debe sincronizarse con las intenciones de los usuarios. Los problemas típicos surgen cuando el sistema presenta información incompleta, desactualizada o incorrecta. La causa subyacente es que las transferencias de datos o las sincronizaciones no funcionan correctamente, pero estos problemas se manifiestan a través de la interfaz de usuario.
Los procesos de back-end no soportan el front-end
Este tipo de problema se manifiesta como una inconsistencia entre los sistemas de registro y los sistemas de interacción. Los procesos por lotes de back-end que no se ejecutan con suficiente frecuencia, o que no se ejecutan, no ponen los datos a disposición de los sistemas de interacción front-end. De la misma manera, las transacciones de los usuarios a través de los sistemas de interacción no se reflejan en los sistemas de registro.
Interfaces de usuario inconsistentes
Cuando un negocio o servicio se ofrece a través de interfaces móviles, web y basadas en quiosco, la interfaz de usuario se comporta de forma diferente o inconsistente. Es posible que todas hayan sido probadas de manera independiente, pero sus comportamientos difieren. Por ejemplo, se aplican reglas de validación de entrada diferentes, se capturan/visualizan distintos campos de datos, o la secuencia de entradas es distinta.
Reflexiones finales
Hemos presentado un modelo de integración y pruebas que da protagonismo a la integración a nivel empresarial y al proceso de negocio. El enfoque E2E es el único que requiere integración total de sistemas y basa las pruebas en recorridos completos de los usuarios. Así, las partes interesadas pueden ver evidencias de que los sistemas funcionan correctamente en un contexto realista.
Muchas organizaciones confían en que los usuarios apliquen una forma de prueba E2E en sus pruebas de aceptación y ejecuten esas pruebas manualmente. Por experiencia, abogo por un enfoque más sistemático y basado en el riesgo que permita automatizar gran parte de la ejecución de pruebas intensivas en mano de obra.
A medida que las organizaciones adoptan enfoques ágiles y de entrega continua más dinámicos, otorgando a los equipos ágiles mayor responsabilidad en las pruebas de sus subsistemas, es fácil descuidar la integración y las pruebas de aceptación a nivel empresarial en etapas posteriores.
El enfoque EBPA, especialmente si es automatizado, extiende el régimen de integración continua desde el subsistema hasta la garantía de procesos de negocio empresariales.
Los paquetes COTS y ERP permiten implementar sistemas sumamente capaces pero complejos con menos esfuerzo de desarrollo, pero los riesgos de integración son tan prominentes como en los desarrollos de software a medida.
En entornos más grandes, los enfoques ágiles y de entrega continua son cada vez más populares, por lo que a medida que aumenta la complejidad y la escala, también lo hace la frecuencia de entrega y el riesgo asociado.
La solución es clara: las organizaciones deben tomarse en serio el EBPA. Deben comprender los riesgos de integración y cómo estructurar las pruebas para abordarlos. Los testers deben avanzar hacia el enfoque moderno basado en modelos, abstraer sus procesos de negocio, sus sistemas y pruebas, e implementar la automatización de pruebas de manera sistemática.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando nuevas partes de la serie estén disponibles. Estas publicaciones son extractos del curso Leadership In Test de Paul, que recomendamos ampliamente para profundizar en este y otros temas. Si lo haces, usa nuestro código de cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso.
Lectura sugerida: 10 MEJORES HERRAMIENTAS DE GESTIÓN DE PRUEBAS DE CÓDIGO ABIERTO
