Diez reglas para la gestión de pruebas SAP

No todos, pero muchos obstáculos en la gestión de pruebas pueden eliminarse de antemano con las siguientes reglas.

Regla 1

Redactar un concepto de prueba: con recursos limitados y plazos ajustados, ¿por qué debería el equipo de gestión de pruebas tomarse la molestia de crear y aprobar un concepto de prueba?

El truco está en mantener el concepto lo más breve y conciso posible y visualizar mediante gráficos cuestiones complejas, como un entorno de pruebas con muchas interfaces.

Los componentes esenciales de un concepto de prueba incluyen, por ejemplo, la definición de los objetos y objetivos de la prueba, los criterios de aceptación y el procedimiento de aceptación, así como la presentación de la infraestructura de la prueba (sistemas SAP, rutas de transporte, fechas de transporte). Haga aprobar el concepto por el departamento de desarrollo y la parte empresarial.

Regla 2

Invertir tiempo suficiente en la calidad de los casos de prueba. Los departamentos especializados suelen carecer de tiempo para crear los casos de prueba. Como resultado, estos se "reciclan" de proyectos antiguos, son demasiado generales, demasiado granulares o no cubren las funciones que hay que probar y aceptar.

El resultado: los probadores especializados prueban demasiado o demasiado poco, pero no las funciones necesarias. El progreso es demasiado lento, la tasa de error es demasiado alta y las mejoras de calidad son demasiado pequeñas. Los departamentos especializados (y no los de TI) deberían tomarse el tiempo necesario para crear los casos de prueba.

Regla 3

Priorice sus casos de prueba. El Departamento A suele querer probar todas las funciones nuevas hasta el último detalle y someter el software ya implantado a una prueba de integración completa que incluya pruebas por lotes y pruebas de extremo a extremo con terceros y otros sistemas.

El Departamento B, por su parte, opta por un enfoque pragmático con sólo unos pocos casos de prueba, en función de los plazos y la situación de los recursos. Es importante encontrar la medida adecuada para el alcance de las pruebas.

La mejor práctica consiste en priorizar los casos de prueba. Un buen método son las pruebas basadas en el riesgo. En este caso, se priorizan los casos de prueba, sobre todo en función del alcance de los daños en caso de mal funcionamiento.

Regla 4

Planifique varios ciclos de pruebas. El primer ciclo de pruebas suele tener un comienzo muy accidentado. Hay bloqueos, los probadores aún no están familiarizados con la aplicación y se producen muchos errores.

El elevado número de correcciones puede provocar efectos secundarios que obliguen a volver a probar casos de prueba que ya se han completado con éxito. Antes de que se dé cuenta, el ciclo de pruebas ha terminado.

Por lo tanto, tómese un descanso después del primer ciclo y dé al equipo de desarrollo la oportunidad de rectificar todos los errores críticos. A continuación, inicie otro ciclo con un estado consolidado del software y los datos, en el que pruebe al menos todos los casos de prueba de calificación alta y media del primer ciclo.

Regla 5

Ocúpese a tiempo del entorno de pruebas. Una situación típica: los casos de prueba están listos, los empleados del departamento quieren empezar, pero la prueba no puede iniciarse porque el sistema SAP no está disponible.

Hay muchas razones para ello. El sistema no se reservó a tiempo y está ocupado por otros proyectos. O el equipo de desarrollo no fue capaz de desplegar el software en los sistemas de prueba, o no del todo.

A menudo faltan interfaces importantes y necesarias o identificadores y autorizaciones de usuario adecuados. Por lo tanto, debe planificar su entorno de pruebas en una fase temprana y supervisar el despliegue completo y correcto.

El primer pilar se establece definiendo los criterios de entrada en el concepto de prueba. Si no se cumplen las condiciones esenciales, no se inicia.

Defina en el concepto o en un plan de entorno de prueba exactamente qué sistemas SAP con qué stock de datos son necesarios y cuándo, qué interfaces deben conectarse a través de qué sistemas de terceros, qué ID de usuario deben disponer de qué autorizaciones y cuándo deben transportarse las correcciones de software.

Regla 6

Utilice una herramienta integrada de gestión de pruebas y defectos. La herramienta más utilizada para la gestión de pruebas y defectos es Excel.

Funciona bastante bien hasta un número de 100 a 150 casos de prueba con un bajo volumen de defectos. En cuanto aumenta el volumen, resulta cada vez más problemático gestionarlo con soluciones Excel propias.

En particular, a menudo no hay una visión general de qué defectos afectan a qué casos de prueba. También es difícil generar el estado general actual o el progreso de las pruebas, posiblemente con previsiones.

A menudo, las hojas de cálculo de Excel (y especialmente las macros) sólo pueden ser mantenidas por unas pocas personas o, en el peor de los casos, por un experto, y el uso de una herramienta integrada de gestión de pruebas y defectos es la mejor opción.

Los componentes Test Workbench y Help Desk de SAP Solution Manager son ideales para los usuarios de SAP. No conllevan gastos de licencia, el esfuerzo de implantación es manejable, de tres a cinco días-persona, y los usuarios están familiarizados con las interfaces SAP.

Regla 7

Realice una puesta en marcha de la prueba. El esfuerzo que invierta en una puesta en marcha bien preparada se recuperará en las operaciones de prueba diarias.

El orden del día debe incluir temas como objetivos, procedimientos, plazos, puertas de calidad, restricciones a las pruebas, informes de pruebas y defectos, así como reuniones periódicas y conferencias telefónicas.

Aunque haya muchos participantes, invite a la inauguración a todos los implicados, como los probadores especializados, el equipo de gestión de pruebas, el equipo de desarrollo, el equipo de control de lotes y el equipo de gestión del proyecto.

Esto facilita la comunicación posterior y ayuda a evitar muchas consultas innecesarias. Hacer que los documentos de lanzamiento y los informes de situación, así como los conceptos, estén disponibles en un medio de fácil acceso como MS SharePoint ha demostrado ser una buena idea.

Regla 8

No empieces las pruebas demasiado pronto. El escenario habitual: las fechas de prueba y aceptación están firmemente programadas. Los especialistas en pruebas están programados. Los responsables de la toma de decisiones quieren que el proyecto sea un éxito.

Y el equipo de desarrollo sigue luchando contra las graves y/o numerosas deficiencias del software. El jefe de desarrollo quiere aplazar la prueba; la dirección del proyecto quiere cumplir el plazo a toda costa.

Los responsables suelen ceder a sus deseos e inician la prueba con conocimiento de los déficits y los riesgos asociados. ¿Qué ocurre?

Las primeras pruebas de aceptación pueden seguir siendo positivas. Pero luego se encuentran muchos errores y se producen bloqueos en las pruebas. Los probadores se sienten frustrados. Y, sobre todo, esto repercute negativamente en los comités de proyecto, los departamentos implicados y, en algunos casos, el Consejo de Administración.

De ahí la recomendación: aunque esté muy presionado para cumplir la fecha prevista de inicio de las pruebas especializadas, posponga las pruebas si el software aún no está listo para ser probado. Te ahorrarás muchos problemas a ti y a los probadores y, sobre todo, evitarás dañar la imagen de tu proyecto.

¿Qué se puede hacer de forma preventiva? Definir y comprobar las puertas de calidad ha demostrado ser una buena idea. Definir en el concepto de prueba qué condiciones previas deben cumplirse para que las pruebas comiencen.

Esto incluye, por ejemplo, pruebas de desarrolladores documentadas, la creación de documentación para el usuario, la puesta a disposición de la infraestructura de pruebas y el listado de errores sin resolver con fecha de corrección. Si no se cumple el requisito de calidad o no se cumple en grado suficiente, no se da luz verde a la prueba.

Artículo 9

Interrumpir las pruebas en caso de bloqueos. La ausencia de funciones importantes, un elevado número de errores o restricciones en la infraestructura de pruebas, como sistemas que no funcionan, pueden provocar bloqueos en las pruebas.

Los probadores no pueden empezar debido a la situación general actual. Al mismo tiempo, hay mucha presión para completar el trabajo rutinario en el escritorio. Por supuesto, no es divertido enviar a los probadores a casa en ventanas de tiempo muy ajustadas.

Sin embargo, en caso de duda, son más importantes las consecuencias negativas, como probadores insatisfechos y pánico en los departamentos especializados o, posiblemente, en el consejo de administración debido a la mala calidad del software. Puede aprovechar la interrupción para consolidar el software.

Regla 10

Comuníquese con los probadores. La comunicación regular con los probadores es un factor clave para el éxito de su proyecto. Es importante la transparencia sobre la situación actual, el estado de los errores, las restricciones, etc. Celebre reuniones periódicas sobre la situación y los errores con los probadores y el equipo de desarrollo.

Las reuniones diarias, por ejemplo, han dado buenos resultados. Intente hablar directamente con todo el mundo todos los días para saber más sobre situaciones concretas de pruebas y supuestos errores. Implicar a los desarrolladores en las pruebas o para volver a probar los errores también ha demostrado ser una buena idea en situaciones complejas.

Conclusión

Cada proyecto de gestión de pruebas en el entorno SAP es diferente y probablemente nunca habrá un proceso de proyecto perfecto. Pero muchas cosas serán más fáciles con las reglas básicas mencionadas anteriormente.

En última instancia, el objetivo es llevar la calidad del software al nivel necesario para un funcionamiento productivo en un proceso aceptado por todas las partes implicadas. El hecho de que no todos los errores se rectifiquen antes de la puesta en marcha es la norma y no la excepción.