Equipo QA – El recurso oculto

¿Que es lo primero que viene a mente cuando mencionamos Ingeniero QA o Tester?

Hay quienes piensan y asumen que las actividades típicas del Tester, las puede llevar a cabo cualquiera y esto se piensa independientemente de la metodología utilizada.

La razón puede estar fundada en el concepto erróneo de que cualquier persona puede determinar si una aplicación funciona o no, con solo seguir un plan de ejecución de pruebas predefinidas, lo cual es bastante típico en Waterfall.

También se asume que el aseguramiento de calidad es solo cumplir con actividades formales de Testing, aplicadas a distintas áreas de procesos en su debido tiempo.
Sin embargo con este pensamiento se deja de lado la especialización, enfoque, razonamiento y experiencia de los profesionales del QA-Testing y su importante aporte dinámico para el aprendizaje continuo durante todo el ciclo de vida de un proyecto de software.

La vereda más transitada

En metodologías tradicionales de desarrollo de software se tiene especial cuidado con la planificación detallada de las pruebas, de modo tal que esta sea acorde a la definición detallada de los requerimientos y a la planificación detallada de todo el proyecto. En base a un aprendizaje inducido por la documentación de como debería funcionar el sistema, se ejecutarán respectivos ciclos de pruebas de sistemas para verificar la completitud y correctitud del sistema en base a tales requisitos.

Como contrapartida se supone un Plan de Pruebas rígido, con muy baja adaptabilidad al cambios de requerimientos y a aparición de nuevos requisitos. También está la cuestión del enorme esfuerzo de mantenimiento del plan, la pérdida de tiempo en el circuito comunicaciones y la aplicación de responsabilidades a personas y/o grupos de personas “encargadas de tal artefacto”.

En la vereda del frente

Las metodologías Agiles presuponen una planificación estratégica del Testing en el orden de ser ampliamente adaptativa, acorde a la velocidad de cambios en los requerimientos del sistema e inclusive a la creación de nuevos requisitos para una misma iteración.  Este solo hecho presupone una total participación de los miembros QA-Testing al inicio de los proyectos, no desde el punto de vista de la inspección-auditoría, sino desde el punto de vista de “recorrer un camino” como equipo, hacia el verdadero aseguramiento de la calidad.

En estos dos enfoques diametralmente distintos, la participación del QA-Testing cambia de un rol de “full-Auditoria” para la detección de fallos y asignación de responsabilidades a “full-partner” del resto de los miembros del equipo para la generación de valor inmediato y motor de orientación a proyectos exitosos.
Esta concepción permite revalorizar los roles QA debido al uso potenciado de los mismos, aportando un valor más estratégico para las necesidades de los negocios que atienden los sistemas que se construyen.

Los Testers encuentran en Agile su máxima posibilidad de expansión, con actividades operativas que ayudan a los desarrolladores a promover la generación de soluciones más eficientes y en instancias cercanas al inicio del desarrollo, e inclusive previas.
A su vez como miembros del equipo QA podrían ser fuentes de información constante referido al comportamiento del sistema en construcción, permitiendo adelantarnos a cambios en los requerimientos, requerimientos mal concebidos o desarrollados en modo no deseado, promover mejoras y una lista larga de etcs. que en definitiva orientan a traves de todo el ciclo de vida del proyecto e inclusive supera las fronteras ayudando en el training a clientes y acercando el conocimiento a las áreas de soporte.

En ambas veredas

Esta revalorización del QA-Testing no debe ser abarrotada detrás de las metodologías Agiles, ya que el concepto puede ser aplicado a cualquier proceso de desarrollo. De hecho, las metodologías Agiles no han planteado este paradigma ni es algo que les pertenece, aún cuando se utilice la terminología “Testing Agile” y se explique algo similar a todo lo que digo.

La evolución de SQA-Testing

Aún cuando muchos “pseudoagilístas” consideran a un Tester como un recurso de menos rango y hasta despreciable para la organización por no generar aporte productivo, “los del palo del SQA-Testing”  nos damos cuenta de la evolución por la misma adaptación que debimos sufrir acorde a la velocidad de respuesta que requieren los procesos de desarrollos actuales.

Asumamos que un cambio de paradigma QA es posible aún dentro de procesos tradicionales. Aún así, el cambio no puede gestarse por si solo, debe surgir de un cambio en el paradígma organizacional.

Fuentes de inspiración:
Testers: The hidden resource

2 thoughts on “Equipo QA – El recurso oculto

  1. Hola.
    Me parece muy interesante tu comentario. Soy nuevo en el mundo del QA pero realmente creo y es algo que día a día me aseguro mas de que el verdadero rol de un ingeniero QA es garantizar un ambiente de producción mínimo de fallas y la satisfacción del usuario final, que al final de caso es quien paga por el desarrollo. Por lo que creo que si el QA no hace su trabajo pues simplemente el cliente no paga pues no tiene una garantía de su producto. En una empresa donde su negocio depende de sus ambientes de producción, la función del QA es importante pues debe asegurar que lo que va del ambiente de desarrollo al de producción no nos afectara el negocio negativamente.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s