La paradoja del tester SAP

SAP, como cualquier otro producto customizable que se implanta en una organización, requiere actividades de control de calidad. Implementar significa generar código y también configurar el producto de determinada manera. Así, las actividades más comunes de control resultan ser el testing y las revisiones de código.

Dejando para otro post el tema de las revisiones de código SAP, me concentro en el testing funcional. Las pruebas más técnicas como ser estrés o volumen no tienen, a mi entender, particularidades surgidas del hecho de que SAP sea el objeto a testear.

Cuando hablamos de testing funcional en implementaciones SAP, hay dos estrategias a seguir. La primera es hacer que los analistas funcionales realicen el testing una vez terminada la customización de los procesos. Esta estrategia, como todas, tiene pros y cons. Del lado de los pros tenemos que los analistas

• Conocen perfectamente la funcionalidad,
• Conocen a los usuarios y
• Conocen el ambiente y los datos requeridos para hacer las pruebas

Del lado de los cons tenemos que

• Su costo horario es alto
• Su motivación para la tarea muy baja (no sueñan con ser testers, por eso se convirtieron en analistas funcionales) y
• Su conocimiento de la actividad de testing podría ser bajo.

La segunda estrategia es utilizar testers para el testing. Y cuando digo testers digo gente que se especializa en hacer testing y no en SAP. Los pros aquí son

• El costo horario menor de la hora de testing (esta es una realidad de mercado)
• El alto conocimiento de la actividad de testing y
• La alta motivación para con la tarea.

Del lado de los cons tenemos que

• El conocimiento de los procesos de negocio es bajo
• El conocimiento del ambiente y los datos es bajo.

Llegados a este punto y teniendo que tomar una decisión, en muchos casos el viejo refrán "billetera mata a galán" se hace presente y se opta por elegir la segunda estrategia.

Para armar un equipo de testing sobre SAP, lo ideal desde el punto de vista técnico, sería armar un equipo formado por analistas funcionales que sepan hacer testing. El problema de esto es que, en cierto sentido, el mercado nos lo impide.

Si alguien sabe hacer testing y sabe lo suficiente de SAP como para hacer análisis funcional, va a estar trabajando de analista funcional y no de tester por la sencilla razón de que el mercado paga mejor el segundo rol. Por el contrario, si alguien está trabajando de tester es porque no sabe lo suficiente de SAP como para trabajar de analista funcional (y esto es lo que yo llamo la paradoja del tester SAP).

Antes de que alguien lo diga, admito que hay gente que tiene conocimientos fuertes de SAP y aún así hace carrera en testing. Sin embargo, seguramente estas personas no estarán trabajando como testers, sino como consultores o en roles de más alto nivel (que se pagan mejor de lo que cobra un analista funcional SAP).

Dicho todo esto, solo queda el escenario de hacer un equipo mixto que combine expertise SAP que garantice un nivel de interacción mínimo con el equipo de analistas funcionales y a su vez solvencia técnica como para afrontar correctamente las pruebas. El equipo estará integrado por testers (que deberán tener nociones básicas de SAP) y expertos en SAP (tal vez analistas funcionales o usuarios con experiencia) que no necesariamente sabrán de testing. La cantidad que pongamos de cada rol dependerá, en última instancia, de la realidad del proyecto.

Seguimos pensando...