Como primera contribución al capítulo español de TMMi (QASpain), he pensado de dar una ligera visión de mi carrera profesional y compartir con vosotros mis pensamientos haciendo buen testing!
Hace ya muchos años (1991 para ser exactos), comencé mi carrera profesional en las pruebas de software. En aquellos tiempos, a los testers se les mantenía al margen, y solo se les involucraba al final de los proyectos para confirmar que el sistema ‘funcionaba’!. La vida como tester era solitaria y parecía que era el único que quería hacer pruebas (en condiciones). No había emails, no había redes sociales, ni internet; era como estar a bordo de StarTrek en un viaje a lo desconocido!
Con los años, todo cambio! En la conferencia inaugural del Eurostar Testing de 1993, encontré que había muchos otros testers solitarios a mi alrededor, y comenzó el viaje del reconocimiento del testing como carrera oficial en la Industria IT. Las actividades de validación y verificación del software, incluso ahora, suponen entre el 40 y el 80% del presupuesto de un proyecto; una buena razón para hacerlo bien y asegurar (continuamente) que las actividades de pruebas eran cada vez mas efectivas y eficientes.
El modelo TMMi es un documento que define un conjunto de prácticas que un buen proceso de pruebas debe contemplar, es decir, establece lo que un proceso de pruebas debe hacer. El modelo no define ‘cómo’ implantar las prácticas en un ciclo de vida de software determinado, o como una organización debe satisfacer los requisitos de TMMi. Son los Assessors y Lead Assessors los que deben interpretar el modelo y discernir, cómo las prácticas TMMi, son realizadas en una organización para asegurar que los requisitos TMMi han sido satisfechos a la vez que son útiles y adecuadas para dicha organización.
Desde mi punto de vista, un modelo de referencia estándar que se utiliza para medir la capacidad de un proceso de pruebas no debe utilizarse, solamente, para medir la capacidad del proceso en un momento puntual. También debe utilizarse para identificar maneras para mejorar la eficiencia y eficacia del proceso de pruebas de forma continua.
La madurez del proceso de pruebas se establece en niveles de capacidad como los siguientes:
-
- Demostrar que los requisitos son satisfechos y que se detectan defectos
- Encontrar defectos en fases tempranas y eliminarlos
- Prevenir defectos de que aparezcan
Esto mismo se refleja al ir pasando por los diferentes niveles de TMMi, desde el nivel 2 y hasta el 5.
Antes de terminar, me gustaría añadir algunas palabras relacionadas con la capacidad humana de complicarlo todo! En mi opinión, la vida debería ser simple; si complicas el proceso, aumentas el riesgo de que los usuarios del proceso traten de no seguir el (complicado) proceso!
Si por nos preguntamos “por qué pruebo”, es frecuente llegar a una respuesta complicada pero tradicionalmente (e incluso actualmente), la respuesta sería:
“probamos para demonstrar que lo que debería pasar, pasa, y lo que no debería pasar, no pasa”
Esta visión se basa, en utilizar los requisitos y otra documentación para identificar qué probar. Esta es la misma fuente de documentación utilizada por los desarrolladores de software para construir el software. Esto implica que se desarrolla lo que establecen los requisitos (y tal y como están definidos) y posteriormente las pruebas confirmarán que el sistema funciona tal y como se recoge en dicha documentación.
Por tanto, una respuesta mejor a la pregunta seria:
“probamos para demonstrar que lo que debería pasar no pasa y no lo que no debería pasar pasa”
Con esta visión, los testers se focalizan en lo que podría pasar y que no ha sido tenido en cuenta por los usuarios, analistas de negocio y desarrolladores. Esto supone una mayor probabilidad de encontrar defectos que no han sido tenidos en cuenta por los desarrolladores; creedme, está estadísticamente probado.
Para concluir, me gustaría comentar lo que me preguntaron en una conferencia en 1995, y cuál fue mi respuesta, (que aún sigue siendo válida):
“¿Que hace a un buen tester?”
“Un buen tester tiene un cerebro altamente lógico, a la vez que está muy corrupto por pensamientos paralelos.”
Traducido, quería decir, que hay probar lo que es obvio y está documentado, a la vez que mirar lo que nadie ha pensado!
Brian Wells
12 de Febrero de 2021
To read the full version in english, click here!
