Combinación de testing sobre casos de prueba y testing exploratorio

Hay que ir más allá de los casos de prueba o de las fuentes que se tengan para poder realizar este tipo de testing: casos de uso, requisitos, historias de usuario, etc… porque resulta muy complicado que la documentación disponible cubra todas las casuísticas que se han desarrollado (aún cubriéndolas, que hayan descendido al nivel de detalle necesario en todos los casos) y porque una cosa son las especificaciones y otra los componentes software que se han desarrollado y su engranaje.
Lo ideal es la combinación de ambos tipos de testing (basado en casos de prueba y exploratorio) porque el testing exploratorio salvo que se tenga colaboración del equipo de proyecto o lo recursos del proyecto permitan conocer bien el negocio, no podrá corroborar de manera adecuada el funcionamiento del sistema.
El testing exploratorio básicamente consiste en realizar el testing con los recursos disponibles y en donde la habilidad, conocimientos y experiencia del tester o del equipo de testing resultan fundamentales para hacer un trabajo de calidad. Desde este punto de vista también cabría dentro de este testing la aplicación de los casos de prueba basado en documentación existente en el proyecto: “esta es la documentación que hay, tu te lo guisas y tu te lo comes”, si bien me gusta hacer una diferenciación entre un caso y otro ya que en uno hay una intención de hacer una documentación que pueda ser de utilidad para las pruebas (aunque no sea ese su propósito principal) y en el caso del testing exploratorio se basaría más en ir recopilando piezas (documentales, prototipos, consultas al equipo de desarrollo, etc…) y en el trabajo en profundidad con el producto.

http://jummp.wordpress.com/2012/10/30/combinacion-de-testing-sobre-casos-de-prueba-y-testing-exploratorio/?relatedposts_exclude=7928