¿Qué hace un QA?

No, no es lo que crees.

· Kelly Aguilar

¿Qué hace un QA?

Es probable que estés aquí porque estás buscando entrar en el mundo del testing, o que seas un desarrollador interesado en el área de pruebas. También podría ser que ya hayas leído el syllabus de Fundamentos de Prueba y tengas la interrogante de ¿Y cómo rayos aplico este montón de teoría en la vida real?

En el ciclo tradicional de desarrollo de software (SDLC) existe una secuencia estándar: Análisis del problema > Diseño > Desarrollo > Pruebas > Despliegue en producción. El error más común es ver las pruebas como un simple paso al final del proyecto. Si se ejecutan con rigor, las pruebas funcionan como un proyecto integral dentro del proyecto de desarrollo, con fases propias que corren en paralelo a cada etapa de la construcción.

El proceso formal arranca con la Planificación; aquí se evalúan los objetivos del negocio, se analizan los riesgos del producto y se recopilan las bases de prueba (especificaciones funcionales, historias de usuario, requerimientos). El resultado de esta etapa es el Plan de Pruebas, un documento que define El resultado de esta etapa es el Plan de Pruebas, un documento que define qué haremos y cómo lo haremos.

Continúa la etapa de análisis, y aquí el equipo de QA recibe las bases de prueba: la misma historia de usuario o especificación técnica que recibe el desarrollador para programar.

Uno de los principios esenciales del testing señala que las pruebas tempranas ahorran tiempo, dinero y esfuerzo. Corregir un error de redacción en un documento de requerimientos toma minutos; corregir ese mismo error cuando el código ya está en producción cuesta muchas más horas de reproceso (o litros de agua, si estamos hablando de que la IA lo programa).

En esta fase también se gestionan los datos de prueba: qué valores de entrada, válidos e inválidos, vamos a usar para evaluar límites, formatos y reglas de negocio del sistema bajo prueba.

Hasta este momento del proceso, solo hemos analizado el QUÉ vamos a hacer. De aquí en adelante ponemos manos a la obra y empezamos a ejecutar el CÓMO. ¿Sorprendido, eh?

En la fase de diseño empezamos a escribir los casos de prueba, con la especificación de requerimientos que recibimos en la fase de análisis; creamos escenarios paso a paso sin valores concretos que definen cómo se va a probar el sistema. Por ejemplo: creamos escenarios de validación de tipo y longitud de datos a introducir en un campo, combinaciones de datos, valores inválidos que prueben los límites, etc. Esto es lo que se llama casos de prueba de alto nivel o abstractos.

En la implementación se refinan estos escenarios, se definen con qué valores se va a probar y los resultados que esperamos como salida de esos datos de entrada. Y aquí ya hablamos de casos de prueba de bajo nivel o concretos. Por ejemplo: Para el campo Edad (entero de 1 a 100) se van a probar valores 0, 1, 45, 99, y 100. No son valores al azar, son valores que prueban las particiones de equivalencia y los valores límite del campo. ¡Uff, la belleza de la ciencia!

En esta fase también se prepara el entorno de pruebas, se configuran roles, permisos, etc., en el sistema bajo prueba.

Seguimos con la ejecución de las pruebas. ¡Ya por fin! En este punto, el software está desarrollado; el equipo de desarrollo hizo y aprobó sus pruebas unitarias, y empezamos a ejecutar los casos de prueba, validando que, en efecto, los resultados que arroja el sistema concuerdan con los requerimientos acordados, o no, y allí empieza la gestión de defectos y generación de reportes, y se refina día a día el arte de comunicar los resultados de las pruebas, enfocados en describir que es lo que hace el sistema y no en lo que "el desarrollador se equivocó".

Todo este proceso ocurre generalmente en una maquila cada dos semanas. Y si en tu trabajo ya adoptaron el uso de la IA, todo esto se reduce ¡a horas!

Como verás, el trabajo de un QA no se resume a sentarse frente al computador, abrir una aplicación y navegar hasta que encuentres el "error". Exige un conocimiento que te permita ajustarte a los procesos de la organización y navegar al ritmo que el capitán exija. Pero ¡ey! No entres en pánico, claro que se puede, y estás en el sitio correcto para aprender sobre cómo hacer esto y cómo hacerlo bien.

Déjame tus opiniones o dudas en los comentarios, te leo.

Tu profe, Kelly.





Artículos relacionados

¿Quieres escribir un artículo para Full Advanced?

Puedes escribir un artículo y lo publicaremos junto con tus redes previa revisión del equipo. Haz click aquí.

Comentarios

Todavía no hay comentarios. ¿Empiezas tú?

Entra para comentar (con tu cuenta de alumno del campus).