Probamos, pero… ¿evolucionamos?

Dado que el testing es un servicio, queremos ejecutarlo “con calidad”, para que nuestro cliente (interno o externo) nos siga contratando ese servicio, al entender él que colaboramos a obtener un mejor producto, lo que preserva su inversión.

Y recalco el colaboramos: todo el equipo de proyecto es responsable de la calidad del producto generado o modificado, de que se entregue a satisfacción de los interesados, y con una calidad suficiente para lograrla.

Componentes fundamentales en la calidad de nuestro servicio serán la continua capacitación de nuestros testers, y lograr que ellos evolucionen en sus procesos mentales, para ser cada vez más eficaces y eficientes.

Revisando algunas definiciones históricamente aceptadas de qué es probar, de qué es un tester, o qué es calidad, vemos que existe una importante evolución en esas definiciones o conceptos.  Esa evolución está muy bien resumida en, y tiene correlato con, las llamadas “fases mentales del tester”  que describe Beizer en su clásico libro "Software Testing Techniques":

• Fase 0: El testing y el debugging son aproximadamente lo mismo. El propósito único del testing es ayudar a hacer debugging.        
• Fase 1: El propósito del testing es mostrar que el software funciona.
• Fase 2: El propósito del testing es mostrar que el software NO funciona.
• Fase 3: El propósito del testing no es mostrar que funciona o no funciona, sino reducir los riesgos percibidos a un valor aceptable.
• Fase 4: El testing no es un acto, es una disciplina mental que resulta en software de bajo riesgo, sin demasiado esfuerzo en hacer pruebas. 
        

Cómo nos impactan estas fases

 Aunque sea básico en cualquier curso de testing explicar axiomas como “nunca podemos encontrar todos los defectos”, “sólo podemos probar la existencia de defectos, no su ausencia” y otros, no siempre los entendemos, o no siempre todos los que están a nuestro alrededor en un proyecto los entienden o aceptan. Pese a que desde que Beizer describió estas fases, la profesión se ha difundido y avanzado mucho. Al igual que el entendimiento de la necesidad de prevenir los problemas de  calidad, mejorar procesos y productos, y hacer pruebas.

Por lo tanto, dependiendo de la madurez de la organización en que estemos trabajando, en muchos casos surgirán problemas a la hora de definir / pedir lineamientos / consensuar mecanismos de:

• Separación de ambientes (probemos en producción / probemos en desarrollo)
• Control de configuraciones (para qué?)
• Control de versiones (seguro que se necesita?)
• Registración y seguimiento de defectos (sólo luego de que los desarrolladores los aceptan…)
• Conjunto básico de métricas (horas de trabajo, qué más?)
• Criterios de reporte (sólo los defectos importantes, o quedaremos mal!!!)
• Criterios de planificación (lo más difícil o complejo al final, testing sólo al final…)
• Priorización de defectos / diferencias Severidad-Prioridad (es lo mismo!…)
• Criterios de finalización de pruebas (fecha fija / cero defectos!!)
• ….

La imposibilidad de consensuar sobre estos puntos, afecta a la calidad de nuestro trabajo, y a nuestra “calidad de vida” durante los proyectos.  Pero lo más grave, es que dificulta cumplir el principal objetivo del testing, que es el que se logra cuando se llega a Fase 4:

Ayudar a construir software
con la funcionalidad y atributos de calidad requeridos,
entregándolo a tiempo,
con costes que lo hagan financieramente posible,
y logrando la satisfacción de usuarios, clientes y otros interesados

Un punto muy importante sobre el que volveré, tiene que ver con la Fase 3: reducir los riesgos percibidos.

Nota: Revisión del artículo originalmente publicado en excelza el 21/01/2010