Probar software sin especificaciones

Estoy leyendo un artículo del señor Michael Bolton, ojo no es el cantante, publicado en junio del 2005 en http://www.stickyminds.com/, en donde desarrolla la idea de que es es posible probar el software sin tener las especificaciones desde el origen. Situación que obviamente comparto.
Lo que el señor Bolton nos plantea es que por medio de la experiencia y las destrezas personales es posible hacer un primer viaje exploratorio por la aplicación y a partir de este, formar un criterio acerca de su desempeño.
¿Por qué en un inicio no es necesario recurrir a las especificaciones? La respuesta es muy sencilla. En primer lugar, son muy pocos los casos en que tenemos acceso a todas las especificaciones, es decir, probablemente tengamos acceso a una parte del proyecto, pero no necesariamente a todo. En segundo lugar, si el software ya ha sido desarrollado hace algún tiempo, es probable que las especificaciones que encontremos no estén o se encuentren desactualizadas, y en tercer lugar los proyectos tecnológicos cambian constantemente y no necesariamente la documentación de las especificaciones se muevan al mismo ritmo.
¿Lugar de las especificaciones? El señor Bolton también nos llama la atención acerca de la fuente de las especificaciones, es decir de donde el responsable de las prueba las obtendrá, en el mejor de los casos estarán documentadas, pero puede darse el caso de que haya que recurrir a entrevistas, correos, etc, y deberán considerarse como oficiales o requerir que se oficialicen.
Técnicas de probar. Según el autor existen dos posibles categorías para agrupar las pruebas: las de oráculo y las heurísticas. La primera categoría alberga el criterio experto, el que es capaz de ver más allá de un documento con especificaciones y se deja llevar por su persepción del lugar donde el software presentará pulgas. La segunda categoría plantea que debe existir una guía provisional que facilite la exploración, la cual debe estar lista de previo.
Tips para el "tester". (Regla HIC-CUPPS) Para los que quieren obtener tips para llevar adelante una evaluación, el autor recomienda según un acrónimo, por donde entrarle al tema.
Historia: Revisar como la aplicación se ha comportado en el pasado.
Imagen: Fijarse en como el producto luce y a partir de su imagen evaluar el comportamiento.
Comparación: Buscar otros productos con funcionalidades similares para inferir las que el evaluado debe tener.
Claims: Revisar lo que se ha ofrecido que el producto haga.
Usuarios: Revisar lo que los usuarios han pedido que haga.
Producto: Verificar que lo que el producto dice que hace, lo haga.
Propósito: Verificar el propósito primario de cada función.
Statutes: Verificar lo que la regulación espera que el producto haga.
Con esto creo que somos casi unos expertos en llevar adelante una primera exploración a una determinada aplicación y estaríamos casí listos para hacer un test.