Pruebas

Llegado a este punto, tendremos:

· Base de datos del cliente actualizada a la versión deseada (CLIENTE_[VERSIÓN]).

· En caso de ser necesario, el ERP con el externo de nuestro cliente con el hotfix correspondiente

Ahora es el momento de realizar las pruebas, tanto por nuestra parte como por parte del cliente, que es el que mejor se conoce sus personalizaciones y sus circuitos. Es una práctica recomendable planificar un periodo de pruebas para que el cliente se familiarice con la nueva versión y verifique que todos sus circuitos se desarrollan de forma correcta. El aprovechamiento de este periodo por parte del cliente simplificará la puesta en productivo de la actualización, por ello es importante que nos cercioremos de que se ha aprovechado este periodo. Para cubrir este cometido se ha diseñado un script que compruebe si se están o no realizando pruebas por parte de los usuarios.

El script incluye una stored “pActualizacion_FeedBackPruebas”, cuyo funcionamiento es muy sencillo. Cuenta con 2 parámetros, un inicializador y un finalizador:

@Inicializar: 1 = Inicializa la tabla para registrar pruebas

@Finalizar: 1 = Graba en la tabla el conteo final de pruebas realizadas

Pruebas: resultados

Para activar el periodo de pruebas, ejecutaremos la stored en la base de datos destinada a este fin: EXEC pActualizacion_FeedBackPruebas 1,0

Al finalizar las pruebas, ejecutaremos lo siguiente

EXEC pActualizacion_FeedBackPruebas 0,1

Esto nos devolverá el número de registros que se han incrementado los distintos objetos desde que dejamos la base de datos en pruebas, con lo cual ya tenemos una herramienta para medir realmente las pruebas realizadas.

Personalizaciones en el estándar

En numerosas ocasiones nos encontramos con clientes que tienen desarrollos personalizados desarrollados modificando las estructuras estándar de la base de datos. En estos casos, la actualización no las tiene en cuenta y por lo tanto se pierden.

Para detectar estos casos podemos hacer una comparativa entre la base de datos del cliente (CLIENTE_ORIGINAL) y la base de datos original vacía de esa misma versión (VACIA_ORIGINAL). Este proceso lo podemos hacer con Visual Studio.

Visual Studio: comprobaciones

En caso de encontrar modificaciones significativas, la recomendación es adaptarlas siguiendo las buenas prácticas para los desarrollos personalizados, evitando en todo momento modificar las estructuras estándar de la base de datos (procedimientos almacenados, tablas, funcione,s triggers, …)

En ocasiones, la adaptación del personalizado pasa por hacer que el estándar contemple una llamada al personalizado. En estos casos hay que comunicarlo a Fábrica para que incluyan la llamada en futuras versiones.