No se cuan común sea, pero en mi carrera como desarrollador muchas veces me a tocado cumplir el rol de tester. Como primer acción siempre pido una instancia de capacitación sobre el software a testear (a nivel usuario), luego de esto pido la documentación del desarrollo (casos de prueba o, en su ausencia, los casos de uso).
Pero, ¿Que hago cuando solo me dan un pequeño curso introductorio de la aplicación y me exigen que lo pruebe?.
Lo que mayor beneficio (costo-beneficio en función del tiempo y la validez de la respuesta) me ha dado es convertirme en un pseudo documentador y luego en tester. No es difícil llegar a la conclusión de que no se puede probar un sistema (correctamente) sin su documentación. Pero aún así para realizar las pruebas de caja negra se pueden generar los casos de prueba usando como base un buen análisis del sistema.
En base a lo anteriormente dicho, durante el período de capacitación que recibo, realizo una captura de las necesidades y requerimientos del sistema. Con estos requerimientos y el sistema en mis manos escribo el documento de casos de uso y en base al mismo genero mi plan de pruebas.
Generalmente esté plan de pruebas no es tan completo como debería serlo, pero al menos logro, a través del mismo, mejorar el desarrollo del sistema no solo a través del testing sino también a través del inicio de la documentación del mismo.

Muy buen post,la verdad que lo voy a tener en cuenta para el futuro. Y es como vos decis, primero siempre hace falta conoces los casos de uso para saber que es lo que se debe testear y de que forma.
Un abrazo