Tres preguntas básicas para hacernos sobre la estrategia de testing son “¿para qué molestarse?”, “¿a quién le importa?”, y “¿cuánto?” (1)

A la larga, hay una sola razón por la que testeas: Algo importarte puede salir mal. Tu proceso de test existe para identificar, investigar, y reportar los riesgos de que el producto pueda fallar. Es por eso que necesitas hacer tres preguntas, reiteradamente, sobre tu estrategia de test:

¿Para qué molestarse? El testing es costoso. No incluyas en tu estrategia actividades a menos que traten un riesgo que importe lo suficiente para dedicar tiempo en el testing.
¿A quién le importa? Las razones  para testear no son leyes de la naturaleza; están arraigadas en los sentimientos y valores de personas que importan. No incluyas actividades en tu estrategia, a menos que sirvan al interés de alguien.
¿Cuánto? Algunas estrategias son más fáciles de decir, que de hacer. “Probaremos todas las combinaciones de características de la impresora” es una oración corta que establece miles de pruebas (o cien mil). ¿Cuánto de todo eso realmente harás?

Tu estrategia de pruebas es más que tus pruebas (2)

Tu estrategia de pruebas contiene el razonamiento detrás de las pruebas que haces. Cuando te preguntan sobre tu estrategia de testing, pareciera ser que la mejor respuesta es señalar tus pruebas y decir, “Estos 500 casos de prueba son mi estrategia para probar este producto”. Bueno, esta puede ser una respuesta correcta, pero no es muy útil. Es información sobrecargada, y no dice nada acerca de cuán bien esos casos de prueba cumplirán tu misión. Provée información que ayude: Sumariza las técnicas y motivaciones que produjeron tus casos de prueba.

¡Tu estrategia de prueba explica tus pruebas! (3)

Cuándo tienes en mente una estrategia de pruebas clara, y pruebas de acuerdo a tú estrategia, puedes explicar tu proceso de test rápida y convincentemente a quién te pregunte. Esto gana el soporte para tu proceso de test, de todo el resto del equipo (entiéndase líderes, mánager, desarrolladores, usuarios, etc). Cuando no sos claro con tu estrategia, tus explicaciones es probable que suenen confusas y poco convenientes.

Una buena estrategia de test es:

• Específíca al producto. Sin importar lo buena que una estrategia genérica pueda ser, una estrategia que sea específica para el producto y tecnología a mano será mucho mejor.

• Focalizada en el riesgo. Muestra cómo el proceso de test tratará las cosas más importantes. Conecta el proceso de test a tu misión en el proyecto.

• Diversificada. En la mayoría de las situaciones, un estrategia diversificada es mejor que una estrategia monolítica. Una estrategia diversificada es aquella que incluye una variedad de técnicas de test o enfoques diferentes. Problemas que “se escabullen” de un enfoque de test serán capturados por otro enfoque.

• Práctica. Debes ser capaz de llevar adelante la estrategia. No sugieras una estrategia de pruebas que esté mucho más allá de las capacidades del proyecto.

Cultiva la materia prima de estrategias de prueba poderosas (4)

Tu estrategia de test se hace posible por los recursos disponibles para llevarla adelante. Durante todo el proyecto, y a través de todos los proyectos, cultiva aquellos recursos para maximizar tus opciones estratégicas. Alguno de estos recursos son:

• Tus habilidades en cada técnica de test.
• Tu conocimiento de las tecnologías subyacentes del producto.
• Amigos con habilidades técnicas o especiales de testing.
• Repositorios con datos de prueba crudos.
• Una variedad de plataformas de test, que incluyen múltiples sistemas operativos y configuraciones de hardware.
• Una variedad de herramientas de test.
• Datos de usuario actuales.
• Funciones de prueba incorporadas al producto (por ejemplo: archivos de log, aserciones, y menúes de test).

El buen  testing de software es un proceso intelectual desafiante(5). Solo a través del juicio y la habilidad, ejercitados coperativamente durante todo el proyecto, somos capaces de hacer las cosas correctas en el tiempo correcto para efectivamente probar un productos(6).
__________________________

(1) (2) (3) (4) Lecciones 274, 281, 282 y 284, respectivamente, extraídas del libro “Lessons Learned in Sofrware Testing, A Context-Driven Aproach” de Cem Kaner, James Bach y Bret Pettichord. Publicado por John Wiley & Sons, Inc., 2002, Nueva York.

(5) (6) Sexto y séptimo principio de los siete principios de la escuela de testing de software basada en el contexto, de la cuál los autores del libro son miembros.