La realización de pruebas de uso exhaustivas tiene un rol crítico en el éxito final del proyecto y debe considerarse y planificarse con mucha antelación en un proyecto de implementación, de manera que se asigne el tiempo suficiente, se forme al equipo necesario y se incorpore el ciclo de pruebas en el programa global.

Finalidad de una estrategia de pruebas

Intentar usar un software que no funciona del todo de la forma en que se supone que debe hacerlo es frustrante para el usuario. Un software lento, con errores o que no realiza tareas sin problemas siempre es problemático, pero puede serlo especialmente cuando las empresas confían en programas de software específicos como herramientas vitales para respaldar las operaciones diarias. Ahí es donde entran en juego las pruebas de uso.

Una estrategia de pruebas debe cubrir, como mínimo:

• Los tipos de pruebas a implementar en el proyecto.
• Los roles y responsabilidades de cada evaluador de pruebas.
• Las herramientas y sistemas que se usarán durante las pruebas.
• Los criterios de éxito para salir de la prueba.
• Los procedimientos para el registro y la respuesta ante errores encontrados durante la prueba.

Es recomendable documentar la estrategia de pruebas para la implementación, para que se comprenda claramente los recursos y el tiempo que estarán comprometidos en las pruebas.

Prueba funcional/validación

Esta se realiza durante la última fase de implementación del proyecto. El foco de las pruebas funcionales es:

Cadenas de transacciones que fluyen en un proceso empresarial
Varias transacciones dentro de un área empresarial o escenario
Workflow

Procesos empresariales que vinculan áreas empresariales.

Ejemplos de prueba funcional:

• Desde la Cotización de venta a la entrega
• Desde la Facturación a su pago y conciliación
• Se debe realizar pruebas funcionales de escenario para los procesos empresariales clave durante la fase de realización de proyecto.

El evaluador principal de la prueba funcional es el usuario clave del proceso o área empresarial.

Prueba de Integración

La prueba de integración debe verse como el esfuerzo final que engloba y se basa en todos los esfuerzos de pruebas anteriores. Las pruebas de integración generalmente hacen uso de los escenarios de casos de una prueba funcional/validación.

Los escenarios seleccionados se pueden combinar para representar un flujo de procesos empresariales completo como el de un pedido de compra que genera una orden de compra basada en una verificación de disponibilidad de artículos.

Los casos de una prueba deben ampliarse para incluir procesos interdepartamentales e inter empresariales. Cualquier error que se produzca y se resuelva posteriormente durante las pruebas de funcionalidad se debe probar nuevamente en el entorno integrado. El consultor debe planificar detenidamente las prueba de integración con el jefe de proyecto del cliente.

Se recomiendan las siguientes mejores prácticas:

Proyectos pequeños

Designar un líder de pruebas. En el caso de proyectos pequeños, el jefe de proyecto o el usuario clave puede asumir este rol.

Proyectos grandes

Se debe asignar otra persona del equipo de proyecto. El líder de pruebas se concentrará en las actividades día prueba de integración, organizará el equipo y el lugar de trabajo para la prueba.

Preparación de los datos

El elemento clave de una prueba integrada son los datos “en vivo”. Por lo tanto, la configuración se debe completar antes de comenzar la prueba.

Esto incluye la configuración final:

• plan de cuentas
• datos maestros de artículos
• listas de precios
• tasas de impuestos
• bancos
• parametrizaciones generales
• parametrizaciones de documentos, diseños de impresión
• informes
• usuarios

Sistema de Pruebas

Las pruebas se realizarán en una base de datos de prueba, que es una copia de la base de datos final y lista para la producción.

• Se tomarán los Casos de Uso entregados junto con la definición de éxito esperada.
• El consultor verificará uno a uno los Casos entregados por el Cliente, recorriendo todo el flujo definido por la operativa de la empresa. Estos casos deberán haber sido probados previamente por el implementador.
• Los Casos de Uso deberán comportarse tal como se espera. En caso que no se alcance a la definición de éxito esperado, se realizará un acta con lo siguiente: Se identificará el caso de uso no exitoso y se identificará qué parte del proceso no se comportó como se esperaba.
• Los Usuarios Clave podrán continuar realizando Pruebas.
• En el caso que surjan nuevos casos de uso se tomará nota y se agendará una nueva sesión de pruebas.
• Se agendará una nueva sesión para: verificación de casos no exitosos y verificación de nuevos Casos de Uso.
• Una vez verificados todos los Casos de Uso suministrados por la empresa la funcionalidad se entenderá como entregada sin observaciones.

Flujo de solicitud de modificación del cliente:

A modo de conclusión…

Las pruebas de uso tienen varios beneficios, tales como ahorro de tiempo y costes, una mayor confianza por parte del usuario, una migración de datos más segura y el cumplimiento de requisitos reglamentarios.