menu_superior

El tester ágil como fusión de perfiles (II)

El tester agil como fusión de perfilesEste post forma parte de una pequeña serie de post que tengo intención de escribir para profundizar en la figura del “tester ágil”, entendiendo como tal al tester que desarrolla su actividad dentro de un modelo de desarrollo ágil. En principio la serie no tiene una duración concreta, de momento tengo 3 posts en mente, pero es posible que a la larga acabe ganando contenido y se convierta en uno de los topics del blog.

El tester de caja blanca o tester con aptitudes de desarrollador

Es un tipo de tester que conoce y ha trabajado en grupos de desarrollo, por lo tanto conoce cómo está construído el software: conoce la estructura, los módulos, las clases, la base de datos, las entidades externas con las que interactúa, conectividad, etc. Es decir, tiene una visión muy cercana al código y muy técnica.
Las pruebas que suele diseñar este tester son pruebas fundamentalmente de caja blanca, es decir, pruebas basadas en la estructura, que sirven para recorrer el código en sus diferentes caminos: pasamos por todas las decisiones (bloques IF-THEN-ELSE), por todos los bucles (FOR, WHILE, REPEAT), se prueban los métodos, las funciones, las sentencias SQL, etc.
En principio este tipo de prácticas contrinuyen de manera decisiva a construir un buen software, un software de calidad, ya que hacer pruebas a tan bajo nivel y de manera tan exhaustiva detectan y corregen multitud de defectos, amén de generar pruebas automáticas que podemos lanzar cada vez que haya cambios para verificar que la funcionalidad modificada no afecta a la funcionalidad.
Sin embargo este enfoque es parcial ya que no se tiene en cuenta el criterio de negocio, no se conoce como el usuario o el cliente utiliza la aplicación, ni qué situaciones se pueden llegar a dar usando el aplicativo, y lo que es más importante: no tienen en cuenta los riesgos ni las prioridades del negocio. En resumidas cuentas, al no probar procesos de negocio completos, corremos el riesgo de omitir defectos que tengan relación con la casuística del usuario/cliente.

Tester de caja negra, tester de sistema o de aceptación

Un tester de caja negra se ocupa de probar las aplicaciones desde el punto de vista del usuario o del cliente, es decir, es alguien que conoce el uso que se le va a dar al software y es capaz de simular ese uso para detectar si el aplicativo construido cumple o no los criterios para los que fue construido. Hay que tener en cuenta que el tester en este caso no tiene porqué conocer la estructura del software, cómo está construido, puede conocerlo, pero no es indispensable para certificar que los procesos de negocio se pueden llevar a término de la manera en la que han sido diseñados.

La problemática en este caso es muy clara: el número de casos de prueba suele ser muy muy grande ya que la casuística también suele ser muy amplia. En este caso el tester está obligado a elegir de todos los casos cuales son los más frecuentes, los más problemáticos, los estratégicos para el negocio… Como es obvio, la selección siempre incurre en el riesgo de ser incompleta y que haya defectos en las casuísticas que no han sido probadas que acaben manifestándose en producción.

, ,

Comments are closed.