Probamos, pero… evolucionamos?

Anteriormente publiqué un artículo sobre la mejora de procesos de testing y el Test Maturity Model.

Parte de la mejora sin duda debe provenir de la continua capacitación de nuestros testers, y de lograr que ellos evolucionen y optimicen su trabajo.

Revisando hoy 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. Y creo que esa evolución está muy bien resumida en, y tiene correlato con, las llamadas “fases mentales del tester” que describe Beizer:

· 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 nada, 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.

Por lo tanto, dependiendo de la madurez de la organización en que estemos trabajando, surgirán inevitablemente 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…)

· Criterios de finalización de pruebas (fecha fija / cero defectos!!)

· ….

La imposibilidad de consensuar sobre estos ítems, 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 las funcionalidades / no funcionalidad requeridas,
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 volveremos, tiene que ver con la Fase 3: cómo analizar y reducir los riesgos percibidos.

Hasta la próxima!!!!

Bibliografía:

[1] Boris Beizer. Software Testing Techniques.