Testing para la Implementación de Sistemas

O, cómo comprobar que los sistemas implementados satisfacen los requerimientos del negocio y que efectivamente se cuenta con personal capaz de operarlos y entenderlos. En consecuencia este artículo presentará una metodología para hacer Testing de Implementaciones de Sistemas, independientemente si estos son para una PYME o una corporación.

En general, cuando los especialistas Informáticos se refieren al Testing es en cuanto a su dimensión de chequear si un determinado programa, sistema o software tiene la funcionalidad señalada en su especificación, en simple: les preocupa asegurarse que el software haga correctamente lo que se supone que debe hacer. A este tipo de Testing no nos referiremos en este artículo, en todo caso para mayor detalle sobre los métodos para hacer el Testing del software un buen punto de partida, como siempre, es la Wikipedia [1].

El Objetivo
Su empresa ha hecho o tiene proyectado hacer un Proyecto de Implementación de Sistemas –ERP, CRM, SRM, Contabilidad, Inventarios, Personal, etc. – independiente del tamaño de su empresa o del sistema a implementar, tiene que considerar que su Proyecto de Implementación tendrá al menos las siguientes etapas:

• Preparación u organización del Proyecto.
• Modelamiento o ajuste entre sus necesidades y las funcionalidades del sistema que compró.
• Carga de Datos (de clientes, proveedores, cuentas corrientes, inventarios, etc.)
• Capacitación de su personal.
• Pruebas de Aceptación o Testing.
• Puesta en operación – Go Live.

Luego, la ejecución de un actividad de Testing siempre ocurre en una implementación, aún de modo informal. El objetivo de este artículo es proveerle de información y conceptos que le permitan hacer un Testing adecuado, de manera que no se encuentre con grandes sorpresas una vez que este operando con su nuevo software y, que además pueda comprobar que el trabajo de implementación está bien realizado.

La Base de Comparación
Durante el proceso de negociación de la Implementación, Ud. estableció sus requerimientos. Estos pueden o no estar en un documento (contrato, propuesta, descripción detallada del requerimiento, RFP, etc.) pero, al muy menos Ud. tendrá un folleto o una especificación técnica del software que compró. A partir de estos documentos se establece la Lista de Verificación de Requerimientos, es decir los puntos, tópicos o funciones que su empresa necesita asegurar que efectivamente estén operativos de acuerdo a su particular necesidad.

Suponiendo que Ud. cuenta con una lista de requerimientos que están documentados y son parte del acuerdo con su proveedor, a partir de ella puede genera la Lista de Verificación de Requerimientos, típicamente esta lista tiene el formato siguiente:

N°	Requerimiento	Observaciones
1	VENTAS
1.1	Análisis de GM (margen bruto) al momento de ingreso de transacciones de ventas.
1.2	Condiciones de pre-aprobación y enrutamiento de transacciones para aprobación por niveles superiores según condiciones.
1.3	Centralización o traspasos de factura de ventas en forma instantánea a contabilidad.
…

Ahora, si por alguna razón no tiene un documento que explícitamente identifique sus requerimientos, esta lista la puede igual confeccionar a partir de documentos como las cotizaciones, el contrato, los folletos del producto o las especificaciones técnicas. Ciertamente esta documentación es de tipo general pero, de todas maneras compromete al proveedor que las funcionalidades estándares deben ser operativas, por ejemplo para el caso de Ventas: que maneje clientes, productos, listas de precios, cotizaciones, etc.

Otro aspecto importante es que con su Implementador, en la etapa de Planificación llegue a un acuerdo respecto a la Lista de Requerimientos a Verificar y al procedimiento de Testing. Por supuesto está Lista se puede ir modificando durante la ejecución del Proyecto, siempre y cuando haya establecido un procedimiento para ello con su Implementador. No se sorprenda si la lista tiene más de 200 funciones a verificar.

Advertencia: A veces parece obvio o superfluo hacer pruebas, como por ejemplo el ingreso de un producto, de un asiento contable, de mercadería a bodega, etc. pues se suponen que son parte del núcleo del producto comprado y que de todas maneras funcionan. El punto está que Ud. necesita que funcionen de acuerdo a SU necesidad por, eso asegúrese que las funciones obvias este debidamente verificadas.

Tipos de Pruebas
La cantidad de pruebas que es posible realizar para verificar una implementación es amplia, sin embargo es necesario tener en cuenta los siguientes criterios

• No es posible probar al 100% que su sistema está libre de fallas, teniendo en cuenta que existen fallas de los programas (bugs) y fallas de implementación (modelamiento, parametrización, documentación, etc.). Existen razones matemáticas y de costo que justifican este criterio.
• Se recomienda probar cada uno de los puntos incluidos en la Lista de Requerimientos a Verificar.

Los tipos de pruebas que recomiendo realizar son:

• De capacidad, asegurarse primero que su personal está debidamente capacitado y en condiciones de operar y entender el nuevo sistema.
• De Documentación, comprobar que dispone de documentación adecuada del sistema, del modelamiento y parametrización. Independientemente si gente leerá o no estos materiales. Por lo general, en la denominada Lista de Entregables debe estar incluida la documentación que proveerá el implementador.
• Pruebas Funcionales Unitarias, comprende la verificación de cada requerimiento en si mismo, por ejemplo: ejecutar un pago a un proveedor.
• Pruebas Funcionales Integradas, corresponde a la verificación de la funcionalidad de requerimientos del sistema que está implementado que necesariamente deben operar con otros sistemas. Por ejemplo: la lectura de la cartola del banco, el traspaso de datos con su sistema de remuneraciones, sistema B2B, factura electrónica, conexión con el e-mail, etc.

Los Actores
En el proceso de Testing podemos identificar los actores según la obra a representar. Si la obra es el Proyecto de Implementación los actores serán: Ud. o quién tenga como Jefe de Proyecto, el Implementador y los Usuarios. Ahora si la obra es la Acción de Testing propiamente tal, los actores son: el Bug (falla), el Producto (sistema) y el Usuario [2].

De manera que si consideramos ambas obras los actores son:

• El Jefe de Proyecto,es la persona a la que su empresa le ha asignado la responsabilidad del Proyecto de Implementación.
• El Implementador, es la consultora o persona que su empresa a contratado para hacer la implementación.
• Los Usuarios, el personal de su empresa que tiene las responsabilidades de: a) transferir conocimientos de su operación al Implementador; b) capacitarse en el nuevo sistema y c)hacer las pruebas de verificación –testing- para asegurar que el nuevo sistema pueda operar en concordancia con las necesidades de la empresa. Dada esta última responsabilidad a los usuarios que ejecutan los test se le denomina también Tester.
• Bug, este es el nombre con el que se designa una falla de software, para el caso del Proyecto de Implementación significa una falla funcional, es decir algo no opera de acuerdo a los requerimientos de su empresa.
• Producto, es el sistema o software que se está poniendo en operación en su empresa.

Las funciones según los roles son:

Rol	Función (referida al Testi
Jefe de Proyecto	Concordar con el Implementador la Lista de Requerimientos a Verificar y el procediemitno de Testing. Asignar los Tester al Proyecto de Implmentación. Controlar la ejecución del Plan de Test. Dar la conformidad o rechazo a la ejecución del Plan de Test.
Implementador	Propone el Plan de Test. Identifica la cantidad de Tester que requiere el Plan. Propone el procedimiento de Testing. Capacita a los Tester. Corrige los Bug detectados.
Tester	Usuario con la responsabilidad de ejecutar los test. Se capacita en el nuevo sistema y en el procedimiento de ejecución de los Test. Ejecuta los Test conforme al Plan y genera la documentación correspondiente (funciones OK, lista de Bug, etcJ Verifica que las correcciones a los Bug, efectivamente resuelven el problema señalado.

El Procedimiento
Existen, dependiendo del tamaño de la empresa y de la extensión del alcance funcional del sistema implementado varias alternativas para establecer el Procedimiento de Testing, la que presentaré a continuación es una que incluye todos los aspectos que me parecen indispensables y que puede ser adaptado a la realidad específica de cada proyecto.

1. Planificación
   • Definir cuales son los tipos de pruebas a analizar.
   • Identificar los Tester.
   • Afinar con el Implementador los criterios de aceptación.
   • Establecer el calendario de Testing.
2. Preparación
   • Generar el Plan de Test General (el que incluye todas las funciones a verificar).
   • Asignar a cada Tester el conjunto de Test que les corresponderá ejecutar.
   • Capacitar a los Tester.
   • Generar las plantillas donde se documentará el resultado de la ejecución del test (copias de las pantallas en la que se ingresan los datos y de las pantallas con los resultados obtenidos).
   • Disponer de la capacidad de consultoría para resolver los errores que se generen durante el proceso de testing.
   • Asignar consultoría para dar soporte a los Tester.
3. Ejecución
   • Cada Tester ejecuta uno por uno los test que le corresponden.
   • El Tester asigna, según su criterio, el estado del resultado del test, que pueden ser: OK (verde), OK pero con reparos (amarillo) y Con problemas (rojo).
   • El Tester documenta la ejecución del test y justifica el porque del estado asignado.
   • Para el caso de test rechazados el o los consultores buscarán la solución al problema y cuando tengan la situación corregida pedirán la repetición de la ejecución del test.
   • La documentación de los test ejecutados es entregada al Jefe de Proyecto para su control y archivo.
4. Cierre
   • Terminada la ejecución de todos los test se generará una lista con las funciones que pasaron satisfactoriamente las pruebas y otra lista con la funciones que se aceptan con reparos.
   • Para el caso de la lista de funciones con reparo se acordará con el Consultor si procede un trabajo posterior de revisión y/o reparación.
   • Se levanta un acta para indicar que los Test se han realizado y que el Cliente y el Implementador están satisfechos con los resultados obtenidos. Esta acta es hito que señala que es posible iniciar la etapa de Go Live o Puesta en Marcha.

Herramientas de Apoyo
Por lo general los sistemas para las PYME no incluyen elementos específicos para el Testing, sin embargo esto no es impedimento para su organización y ejecución, ya que siempre es posible utilizar MS Word para definir las plantillas de los documentos que se precisen, las listas es fácil hacerlas con MS Excel, todo esto es particularmente efectivo cuando los Tester son menos de diez. Para situaciones más compleja es adecuado utilizar para la planificación el MS Project o similar.

Para el caso de sistemas como mySAP ERP la herramienta más adecuada para administrar los test es el SAP Solution Manager.

Y, aquí los invito a incluir en este artículo otras herramientas que Uds. conozcan, usando los comentarios del Blog.

Referencias
[1]Software Testing http://en.wikipedia.org/wiki/Software_testing
[2] The Tester’s Triad:Bug, Product, User – Brian Marick – http://testing.com/writings/triad/triad.pdf
[3] CTG Testing of ERP Packages http://www.ctg.com/testing/graphics_images_etc/ERPTesting.pdf
[4] Drive Better ROI from ERP Applications by Improved Testing (Webcast on demand require inscribirse)
http://www.bitpipe.com/detail/RES/1162585236_74.html

Los link se verificaron el 3 de Diciembre de 2006.