CalidadySotware.com / Testing / BPM - Business Process Management - BIZAGI

Autor: Ing. Daniel Cafferata.

BPM - Business Process Management - BIZAGI

 

La nueva generación de WorkFlow ha evolucionado tomando las mejores prácticas de muchas tecnologías de la información naciendo así el BPM por sus siglas en inglés (Business Process Management). Es estas líneas procederemos a dar algunos conceptos al respecto y tomaremos como bandera la herramienta BPM BIZAGI dejando claro que existen muchas herramientas BPMs en el mercado, por tema de experiencia hemos tomado BIZAGI como referencia.

Proceso de Negocio

Un proceso de negocio es cualquier agrupamiento de actividades dentro de una organización que tiene como objetivo desarrollar y entregar productos o servicios al cliente

 
 

BPM (Business Process Management) es una solución que apoya las empresas orientadas a procesos, brindándole herramientas que facilitan las tareas de toma de decisiones, gestión, operación, control, y automatización, en forma simplificada y unificada.

El término Gestión de Procesos de Negocio se refiere al entendimiento, diseño, ejecución y optimización de las actividades de negocio de las empresas que involucran personas, procesos, sistemas y estrategia.  David Lyneham-Brown 3ª Conferencia Anual BPMG.

El BPM toma lo mejor de las tecnologías de la información:

BIZAGI

BizAgi es la solución preferida por los expertos en BPM ya que permite automatizar procesos con la mínima cantidad de programación gracias a un novedoso concepto en el cual “El proceso es la aplicación”, es decir, que cuando se modifica el proceso (cualquier elemento del modelo de negocio) la aplicación se adapta de forma automática. Este poderoso concepto brinda a nuestros clientes una adaptabilidad al cambio sin precedentes. (concepto tomado de la pagina de BIZAGI).

Ciclo de implementación con BIZAGI:

Atención de Requerimientos BPM en el área de pruebas

Teniendo como referencia en las organizaciones que existen “áreas de pruebas” que a su vez están organizados por equipos de testers (analistas de Pruebas) clasificados por tipo de aplicativo o por giro del negocio, así podemos ver que existen equipos que ven aplicativos WEB, otros aplicativos Cliente Servidor, o si la clasificación es por giro del negocio podríamos tener equipos que vean aplicativos de Logísticas, otro vería aplicativos de Recursos Humanos, etc.

Partiendo de esta idea de organización de un área de pruebas en las sgtes líneas veremos que equipo debería realizar las pruebas cuando el aplicativo es un BPM y además algunas ideas de cómo realizar pruebas a este tipo de aplicaciones.

Este tipo de requerimientos BPMs cuando llegan al área de Pruebas se plantea la disyuntiva de ¿Que equipo debe atender el requerimiento?:

  • Un grupo especializado en pruebas sobre BPMs .
  • Cada equipo puede atender estos requerimientos.

Sobre estas opciones se tienen algunas reflexiones:

1.- En el caso que se trabaje con un grupo especializado sobre BPM,

  • Se tendría la ventaja de que el grupo ya entiende esta tecnología, lo que conlleva a que la estrategia de pruebas, la creación de casos, la forma de trabajo es un asunto aprendido.
  • El tema esta que en la parte del negocio este grupo estaría limitado al no ser el especialista en el tema y el tiempo de inducción podría afectar el tiempo del proyecto.
  • Además al existir un solo grupo que atienda este tipo de requerimientos, el equipo para no estar limitado en su capacidad de atención tendría que crecer para poder atender  a más de un requerimiento a la vez, así este requerimiento sea sobre una mejora o nueva implementación.
  • Asimismo el equipo especializado acapararía temas que no ha visto antes y se rompería el equilibrio que existe actualmente con la distribución de aplicativos entre los distintos equipos del área de pruebas.
  • Entonces el tema con este tipo de atención iría por la parte logística y el desequilibrio en la distribución de las tareas entre los distintos equipos.

2.- En el Caso que Cada Equipo atienda este tipo de requerimientos,

  • Se tendría que realizar una capacitación apuntando a dos frentes: primero a que se conozca en forma general la nueva tecnología y segundo se muestre una metodología o forma de realizar pruebas a este tipo de requerimientos, por lo que cada equipo tenga en su haber gente que pueda atender estos requerimientos.
  • Esta capacitación implica un costo y tiempo, ya que se debe determinar en que momento se realiza y quien lo hará, además debe realizarse fuera de los requerimientos para no impactar en el tiempo de ellos.
  • El tema sobre el conocimiento del negocio queda descartado dado que cada equipo atendería la implementación de esta tecnología sobre los temas que manejan y el personal conoce el negocio.
  • No se rompería el equilibrio en la distribución de los requerimientos dado que cada equipo de certificación  mantendría a cargo sus aplicaciones.
  • Entonces el tema con esta opción seria costos y tiempos.

Propuesta,

  • La opción 2, Que cada equipo tenga a su cargo este tipo de implementaciones con el asesoramiento de personal que ya conozca este tipo de requerimiento y que apoye y oriente en la correcta creación de los casos de pruebas y la estrategia de pruebas, sobretodo en proyectos de primeras implementaciones de flujos.
  • Este asesoramiento generará al final del proyecto que los involucrados estén en la capacidad de atender solos los próximos requerimientos que vengan.
  • Con esta propuesta se espera combinar el conocimiento que tiene cada equipo por los temas del negocio con el conociendo y experiencia que tuviera el personal de asesoramiento respecto a temas de pruebas en BPM.
  • Dada la experiencia del personal de trabajar en equipo, el objetivo de diseminar el conocimiento adquirido sobre pruebas en BPM esta asegurado.
  • Los equipos seguirán con la misma estructura de coordinadores y analistas, por lo que el asesor trataría directamente con el coordinador y este planteamiento es temporal hasta que los mismos equipos tengan en sus coordinadores el conocimiento necesario.

Estrategia de Pruebas para BPMs

En este tipo de implementaciones parte de un análisis y levantamiento de información de los procesos involucrados que  luego es plasmado en un flujo con distintas ramas de acuerdo a la complejidad del proceso, este flujo contiene a su vez formularios y reglas que indican por que rama del flujo debe seguirse de acuerdo a las condiciones de entrada.

  • La forma correcta de validar este tipo de implementaciones es realizar casos de prueba que pasen por todas las ramas posibles
  • Además considerar probar las reglas de negocio que indiquen algún comportamiento distinto en una rama.
  • Considerar las interfaces que hubiera con entes externos al flujo, las tramas que sirven de nexo.
  • Las notificaciones deben probarse considerando casos a parte para que no sean cuellos de botella en los caos sobre las ramas del flujo y además para tener mapeadas las notificaciones y ser más efectivo en las pruebas.
  • Los temas de Perfiles y accesos como siempre se han probado.
  • Si existieran Servicios externos que envían información al flujo y viceversa (servicios Web) considerarse validarlos en un ambiente apropiado dado que la lógica interna de los servicios puede ser más compleja que lo requerido por el flujo, esto en el caso que estos servicios se hayan construido o modificado para ser consumidos por el flujo.

EjemploOrganización de Casos de prueba:


Ejemplo Flujo en BIZAGI

En este flujo por ejemplo los casos de prueba deben estar orientados a pasar por las todas ramas posibles, en este caso seria:
* Rama 1: Validar firma -> Firma Ok? -> FIN
* Rama 2: Validar firma -> Firma Ok? -> Ingresar firma -> Validar firma -> Firma Ok?-> FIN

Así estaríamos cubriendo el paso por las ramas del flujo, y tendríamos la base para nuestros casos de prueba y luego ya podríamos buscar la data necesaria para estos casos.

Si tenemos en cuenta que cada Actividad (Validar Firma, Ingresar Firma) es una pantalla de la aplicación, deberíamos considerar también validaciones de campos, validar que el diseño cumpla con lo especificado entre otras consideraciones.

NOTA FINAL:
Un punto muy importante es considerar la participación de los analistas de pruebas desde las pruebas integrales como una buena práctica, con el fin de que el personal entienda mejor el flujo y así mismo detectar en forma temprana errores críticos antes de entrar a la etapa propia de pruebas funcionales, por lo mismo nuestra participación debería estar limitada a validar los puntos importantes del flujo y además de utilizar los casos de prueba de desarrollo deberíamos tener ya una batería de casos para lo más revelante.

Esta participación sería a tiempo parcial, considerando que tenemos labores propias del área de pruebas con respecto a las pruebas funcionales, pero es real que esta participación enriquecerá al personal y tendremos casos de prueba con mayor calidad para las pruebas funcionales.

Ing. Daniel Cafferata



 
 
 
CalidadySoftware.com 2009 - © Todos los derechos reservados
Sitio Web Alojado por NazcaSoft.com