Como hacer Testing cuando no tienes Test Cases

¿Alguna vez han entrado en un nuevo proyecto y no tiene documentación, ni siquiera Test Cases? O han encontrado que la documentación es deficiente o no se ha actualizado durante un tiempo ... si su respuesta es sí, quiero presentarles  algunas herramientas que podrían ser útiles para el entendimiento y testeo de una aplicación, y que les pueden llevar a crear los casos de prueba (en caso de que su jefe/cliente desee tener casos de prueba) y su base de conocimientos.

Primer paso: Mapas Mentales
Los Mapas Mentales pueden ser una herramienta poderosa, tanto para una tormenta de ideas como para resumir una charla en una conferencia o un backlog review. Pero también se puede utilizar para crear un plan de pruebas. Pueden utilizar un mapa mental para ayudarlos a decidir sobre cómo podrían asignar sus recursos, cuando se trata de una situación incierta.
Al enfrentarnos con una nueva funcionalidad en la aplicación, se puede ejecutar una sesión de análisis, con el objetivo de identificar lo que hay que analizar. Las sesiones de análisis puede ayudarnos a decidir en donde están los potenciales riesgos, lo que queremos cubrir, o cómo queremos cubrirlo. Estas sesiones se pueden traducir en un mapa mental para tener una perspectiva visual de la situación.
Los mapas mentales son la herramienta perfecta para desarrollar y ejecutar las pruebas, evolucionando sus ideas, mientras realiza el testing. Nuestros resultados se pueden expresar en unos mapas mentales como un punto de inicio para agregar nuevas ideas y cobertura.

Test Planning Mind Map by http://www.ministryoftesting.com

Hay un montón de herramientas que podrían ser utilizadas para crear mapas mentales, he aquí algunas:

LucidChart: un software on-line de diagramas, tiene múltiples tipos de diagramas, incluyendo mapas mentales.
XMind: la herramienta más utilizada para realizar mapas mentales.
SimpleMind: visualmente, los mapas se ven mucho mejor con esta herramienta, por haber sido creado para iOS, aunque tiene su versión de escritorio, sólo tiene una prueba de 30 días.

Pequeña UI,Gran herramienta

Segundo Paso: Qtrace
Incluso si estás haciendo pruebas exploratorias o Scripting Testing, tienes que escribir un informe de bugs si has encontrado defectos.
Qtrace es una herramienta potente y fácil de usar, que te permite grabar tu sesión de pruebas con varias snapshots y capturar cada paso que haces en esas imágenes, añadir tus propias notas y generar un informe para exportar en varios formatos (Word, PDF, etc ) o que puede ser integrado con múltiples trackers como Quality Center, Jira o Version One.
Estos informes podrían ser utilizados como casos de prueba, ya que tienen pasos para reproducir, el ambiente de testing, especificaciones e imágenes que podrían ayudar a los Testers a seguir el caso de prueba y a los desarrolladores a solucionar el defecto.
Puedes bajarlo aquí.

Tercer Paso: Hexawise
Cuando necesitas comenzar a planificar tu pruebas de cobertura o de regresión, puedes encontrarte con múltiples posibilidades, que generan miles de casos de prueba que puede hacer que sea imposible cubrir todo.
Hexawise es una herramienta web, que maximiza la cobertura de la pruebas con un número mínimo de casos de prueba, ya que te permite crear un plan de pruebas mejor sin omitir cualquier combinación de las funcionalidades y configuraciones.
Sólo tienes que crear tus inputs, y Hexawise va a generar los casos de prueba y analizar su cobertura en pocos segundos.
Fácil de usar, con un poco de práctica, puedes crear fácilmente tus planes de prueba y exportarlo a un archivo de Excel o exportarlo a una herramienta de test management o a herramientas de automatización de pruebas como Quality Center, QTP, selenium, etc
Lo puedes descargar aquí:

Cuarto Paso: Wikis
¿Y dónde podríamos guardar toda esta información para que la puedan usar otros Testers?
Como Leah Stockley dice en su blog:
 "Un método eficaz consiste en capturar la información esencial del proyecto (el conocimiento del dominio, aspectos técnicos, consideraciones de prueba, etc) en un wiki. Parte del tiempo ahorrado por no escribir scripts, puede ser invertido en la actualización de la wiki, la captura de los puntos más importantes en un documento conciso que se puede leer y está disponible para cualquier persona en el proyecto que puedan estar interesados, no sólo el equipo de pruebas.
Cuando un tester nuevo comienza, deben comenzar por leer la wiki ... pero para hacerlo más interactivo, les pedimos que revisen la exactitud y que sean responsables de hacer cambios y mejoras en la base de conocimientos. " (Traducción libre hecha por mí)

En "tiempos ágiles", tener un conjunto de potentes herramientas y personas capaces de adaptarse a cualquier situación, puede hacer la diferencia en el desarrollo de software.

Quiero agradecer la inspiración de este post a:
Michael Bolton, específicamente a este post, pero pueden leer todo su blog que es más que interesante.
A este post de Mauri Edo, que habla de mapas mentales.
Y a Leah Stockley que hizo un gran post en su blog y ojalá muchas empresas en Latinoamerica pudieran leerla y empezar a cambiar el modelo de testing actual en la región.