Prueba de regresión de SAP con un repositorio de prueba

Una prueba de regresión pretende garantizar que los cambios en una parte de un sistema existente no produzcan efectos no deseados en otras áreas. Por lo general, consiste en repetir los casos de prueba existentes que vuelven a probar todo el sistema o los procesos y debe realizarse después de que los cambios se hayan probado con éxito. Por lo general, las pruebas regresivas se realizan bastante tarde en el ciclo de prueba.

Debido a la naturaleza repetitiva y la frecuencia de estas repeticiones, tiene sentido utilizar un procedimiento formalizado o automatizado para las pruebas de regresión.

Con este propósito, configuramos y mantenemos un repositorio de casos de prueba «global», es decir, una administración central y almacenamiento de casos de prueba reutilizables. Óptimamente, todas las partes involucradas tienen acceso.

Este repositorio es la base para las pruebas manuales y automatizadas.

Objetivo

Un repositorio de prueba es una colección de casos de prueba para que todos los procesos en el entorno del sistema se prueben de forma regresiva. Se puede utilizar como alcance para todos los tipos y fases de prueba. Por lo tanto, inicialmente solo contiene procesos que ya se utilizan productivamente.

• Completo: Mapeo de todos los procesos de negocio
• Estandarizado: utilizado como base para todas las fases de prueba en proyectos de lanzamiento y despliegue
• Actualizado: se adoptan cambios y nuevos procesos

Ventajas

• Alta reutilización en el contexto de una amplia variedad de tipos y fases de proyectos
• Reducción del esfuerzo en la preparación de las fases de prueba individuales
• Reducción del esfuerzo en las pruebas
• Fuerte estandarización de las fases de prueba

Realización

Dependiendo de las herramientas utilizadas en una empresa, todos los casos de prueba se recopilan en un catálogo de casos de prueba, por ejemplo, en Excel.

Estructurado de acuerdo a los requerimientos:

• empezando por el área, proceso central y procesos
• Prioridad, esfuerzos de prueba, relevancia de prueba para diferentes pruebas o país
• información adicional como usuario de prueba, hardware, requisitos, etc.

son información útil y se pueden almacenar en el catálogo o casos de prueba. La estructura y el catálogo pueden ampliarse en cualquier momento en función de nuevos requisitos.

Una numeración razonable y flexible facilita encontrar, asignar y luego probar los casos de prueba.

Los casos de prueba en sí se pueden almacenar en un recurso compartido o en la documentación de la solución SAP Solution Manager (casos de prueba o pasos de prueba). Todos los casos de prueba deben mantenerse con la misma plantilla o con pasos de prueba de tipo de caso de prueba. Esto simplifica el mantenimiento y las pruebas.

Si desea planificar una prueba regresiva, simplemente puede recopilar los casos de prueba del catálogo definido según lo requiera el negocio, y el mismo alcance también se puede usar para pruebas recurrentes.

Prioridad

• Prio1 (muy alto) Procesos centrales del negocio (máx. 5-7 casos de prueba por WS) –

Evaluación por riesgo: ¿qué procesos generan los mayores costos y/o el mayor número de empleados que no pueden trabajar en caso de falla? Pruebas regresivas: alcance de prueba para pruebas de realidad y se prueban en todos los tipos de proyectos para garantizar antes de la entrega al país.

• Prio 2 (alto): procesos críticos para el negocio

Requerido para las operaciones diarias del almacén, es decir, responsable de los procesos físicos utilizados con regularidad Relevante para una gestión de inventario sin errores Los casos de prueba Prio 1 + 2 cubren el alcance de la prueba para una garantía integral de las funciones del sistema, por ejemplo, al poner en marcha nuevos almacenes en un país existente

• Prio 3 (medio): Todos los demás procesos

Para los despliegues en nuevos países, se requiere una prueba del sistema al 100%, para lo cual se prueban Prio 1-3, así como nuevos desarrollos específicos. Cuando se ponen en marcha nuevos almacenes, estos casos de prueba se probarán opcionalmente para aumentar la seguridad.

ggf. casos especiales, en su caso

Para una versión, por ejemplo, solo se pueden seleccionar los casos de prueba prio 1 y 2, para un proyecto de implementación o actualización también se pueden seleccionar los casos de prueba prio 3 y 4. Se pueden agregar fácilmente casos de prueba adicionales según sea necesario. Para tareas de prueba recurrentes, se pueden crear, probar e informar fácilmente alcances de prueba predefinidos y coordinados.

A continuación, se crean los planes y paquetes de prueba como de costumbre.

Versionado y actualización

Con cada cambio introducido en el sistema, también puede cambiar una prueba regresiva, o se deben agregar nuevas y eliminar las antiguas. La revisión lenta e impopular de los casos de prueba debe planificarse y monitorearse como parte integral del procedimiento de prueba..

Durante cada proyecto/lanzamiento, el negocio verifica si el catálogo de casos de prueba existente todavía está actualizado y corresponde a la producción actual y los cambios planificados para el proyecto/lanzamiento (o cambios introducidos mientras tanto) de los procesos.

• Para los deltas, los casos de prueba existentes se complementan o se crean nuevos y, si es necesario, se almacenan por separado, por ejemplo, propuestas de versiones o proyectos.
• Los cambios los implementa la propia empresa directamente en Excel y los casos de prueba/pasos de prueba o se comunicarán a la gestión de pruebas.
• La empresa puede crear nuevos casos de prueba para probar desarrollos y cambios en una versión o proyecto.
• Al final de una fase de prueba de integración, se almacena una versión actual del repositorio de prueba y sirve como base para las fases de prueba posteriores y futuras.

Después de un lanzamiento/lanzamiento, los deltas finalmente se incorporan y el Test Rep se almacena como una nueva versión.

Conclusión

El proceso debe estar claramente definido, coordinado con todas las partes involucradas y comunicado. Deben designarse personas de contacto responsables para todas las tareas y áreas. Una vez que se haya creado el repositorio de prueba inicial y las ventajas y la simplificación sean claras para todos, la planificación futura de las fases de prueba regresivas debería ser mucho más fácil y transparente para todos.

Conclusiones clave

• Un repositorio de pruebas puede ahorrarles a sus equipos mucho tiempo, trabajo y mejorar la calidad de las pruebas
• Un recurso compartido global con accesibilidad (lectura y escritura) para todos los participantes ahorra mucha coordinación y tráfico de correo.
• El establecimiento de este repositorio es un proceso iterativo que requiere aportes de todos los equipos/áreas funcionales del proyecto.