11 consejos para los que hacen Test Plan con estandar IEEE 829

Comento a continuación algunos consejos que me han sido dados, para cuando uno hace un test plan siguiendo el estándar IEEE 829.
1. Al completar el espacio requerido de referencias, si no se cuenta con un identificador interno del documento dentro de la organización, se debe poner la referencia completa con el formato formal que incluye los autores, el título, la editorial, el lugar y el año (o si es web, el URL y la fecha en que se consultó).
2. Para probar la funcionalidad no necesitan ver la documentación interna (del código). De hecho, a menos que usen pruebas de caja blanca, tampoco se tiene la necesidad de usar el código de la aplicación, bastaría con correr el ejecutable de la aplicación.
3. La usabilidad abarca muchos aspectos más de la interfaz gráfica que sólo verificar la respuesta a las opciones del menú. De igual forma, cuando se habla de navegabilidad, se puede incluir aspectos como: si estando en una pantalla de la aplicación, siempre hay un botón que permita al usuario devolverse a la anterior o al menos a la pantalla principal de la aplicación.
4. La seguridad no es sólo verificar que los roles estén definidos correctamente, sino intentar violar los mecanismos de seguridad y control de acceso sobre esos roles.
5. ¨Altos volúmenes¨ no es medible. En general, si van a hacer pruebas de volumen es porque existen requerimientos explícitos de manejo de volúmenes mínimos para la aplicación, y en tal caso debería hacerse las pruebas contra estos requerimientos medibles (p.ej., la aplicación debe soportar hasta 100 consultas concurrentes)
6. Cuando se habla de baja prioridad, quiere decir los menos importantes, y éstos son los que se dejan para el final (si da tiempo); mientras que los de alta prioridad con los que se corren primero. Talvés la confusión está en que típicamente alta prioridad se indica con cero o uno; mientras que los de baja prioridad se indican con 2 o 3 en un test normal
7. Típicamente cuando las pruebas se suspenden, para dar el visto bueno de reanudación de pruebas se deben correr pruebas de regresión básicas (de prioridad 0) que aseguren la usabilidad del sistema.
8. El plan debe indicar el software que se necesita en el servidor y en el cliente. Por ejemplo, indicar que se necesita Microsoft SQL Server 2008 (para la base de datos) y Microsoft Team Foundation Server (para registrar todo lo concerniente a las pruebas).
9. "Herramientas" es un término demasiado general. Se debe especificar cuáles herramientas, porque si hay herramientas para las cuales necesitan licencia, o que llevan un proceso de instalación complejo y de mucho tiempo, hay que considerarlo dentro del plan de pruebas. Igualmente, hay ocasiones en que sólo la configuración del ambiente de pruebas (software, comunicación, etc) toma más tiempo que las pruebas mismas, entonces hay que indicar cuál es todo el software requerido.
10. Debe indicarse el entrenamiento o capacitación requerida por el equipo de trabajo. Si el equipo de testing necesita capacitarse en el uso de la herramienta VS2010 para poder realizar con éxito sus tareas esto debe planificarse.
11. En la sección de aprobaciones debe citarse el rol de quien tiene que aprobar el plan, no sólo su nombre. Es decir, si es el Test Managar, si es el QA Manager, el Developer Manager, etc.

Gracias a la profesora Martinez por estos consejos, los cuales obviamente son de su autoría.