Un plan perfecto.

Normalmente, con o sin una metodología formal, el programador estima el número de componentes de software, sus dimensiones aproximadas, el toolkit y lenguaje que va a usar, el estimado de horas en que desarrollará y algunas veces, incluso, algunas de las pruebas que realizará sobre lo que pretende escribir. Un plan general y a veces detallado de las actividades de desarrollo pues.
Si el programa o sistema a desarrollar es grande, seguramente hará un programa más detallado, en el cual incluya detalles de quién potencialmente hará un diseño detallado, quién escribirá el código, de que tamaño va a ser, en que fechas se espera iniciar y terminar... y a veces pondrán una actividad más que diga "pruebas". Esa normalmente no irá detallad.
Un sistema grande en manos de un grupo de desarrollo responsable, seguramente intentará llevar un control aún más riguroso, intentando usar alguna metodología o framework (o ambos) y comenzará a detallar aún más: particionando componentes, actividades, y algunos elementos más, como contingencias, recursos humanos y materiales y a veces "hasta" un plan de pruebas.

La actividad de pruebas muchas veces es ignorada o al menos menospreciada en las metodologías, muchas veces se le resta la formalidad que puede y debe tener.

Demasiadas veces, tratándose de testing, dicha planeación se omite,y las pruebas se van improvisando conforme el sistema crece. Esto, desde luego, representa muchos riesgos, particularmente que las pruebas sean incompletas o incluso que no puedan ser realizadas en absoluto por falta de planeación.

¿Qué requiere un buen plan de pruebas para incrementar las probabilidades de que sea exitoso?

Afortunadamente el IEEE (Instituto de Ingenieros Eléctricos y Electrónicos) ha publicado un estándar que nos guía en términos generales por el camino correcto, el estándar IEEE 829 "Estándar para documentación de Pruebas".
Como todos los documentos de IEEE es extensivo y detallado, y además existen literalmente docenas de plantillas en Internet de donde podemos escoger aquella que resulte más adecuada para nuestros proyectos y nuestra empresa.

El plan de pruebas consiste en 19 partes, que aunque suenan muchas, son simples de trabajar, a continuación las revisaremos:

1. Identificador del plan de pruebas.
Simplemente nos debe decir con un identificador único, de qué plan de pruebas se trata, si es un plan maestro o de nivel, o un plan especializado como puede ser de desempeño. Regularmente incluiremos autores, control de cambios y otra información relevante directamente relacionada con el mantenimiento del documento.
2. Referencias.
Referencias a otra documentación del proyecto, como calendarios, documentos de diseño de alto y bajo nivel, requerimientos, estándares, otros planes de prueba y cualquier documento que resulte relevante para la creación y ejecución de las pruebas.
3. Introducción.
Descripción sumaria del plan de prueba. Normalmente se indica el nivel del plan, su relación con otros planes, alcance y la relación del plan con otros items del proyecto como pueden ser recursos, calendario, etapas del ciclo de vida donde se ejecutará el plan, etcétera.
4. Items de prueba.
Funcionalidades, especificadas a muy alto nivel, de lo que será probado. Si se trata de un plan de alto nivel (Maestro) describir el area funcional o de aplicación a probar, o la versión específica. Si se trata de un nivel más bajo, enunciar los módulos o componentes a probar.
5. Riesgos.
Descripción general de los riesgos del plan de prueba, como puede ser una pobre documentación de análisis y diseño, software de terceros, (des)conocimiento de ciertas herramientas de prueba, requisitos específicos de seguridad, áreas del sistema de las que se conoce de demasiados defectos anteriores.
6. Características a probar.
Lista de características desde el punto de vista del usuario que serán probadas, no una descripción técnica de las mismas.
7. Características que NO serán probadas.
También, desde el punto de vista de usuario, todas aquellas características que no serán probadas, especificando la razón por la que no serán probadas, por ejemplo una característica que fue probada previamente, una que no será incluída en la versión.
8. Estrategia.
Describir en términos generales la estrategia para el plan, incluyendo herramientas de prueba, métricas de prueba, administración de configuraciones, hardware y software requerido.
9. Criterios de fallo y éxito.
Especificar cuando se considera que el plan de pruebas pasa y cuando es fallido. Esto no necesariamente quiere decir que todas las pruebas sean exitosas, así que se debe especificar también el nivel de tolerancia de fallos, por ejemplo "no más de 10 defectos cosméticos".
10. Criterios de suspensión y reinicio de pruebas.
Indicar si existe un nivel crítico de fallos que haga inviable seguir probando.
11. Entregables.
Lista de todos los entregables del plan de pruebas, como el plan mismo, sus casos de prueba, los reportes de defectos, bitácoras de servidores, reportes de framework de pruebas automatizadas.
12. Pruebas pendientes.
Listar todas aquellas pruebas que deberán ejecutarse en otro momento, por ejemplo en una versión posterior o que depende de un software de terceros no instalado aún.
13. Requerimientos de ambiente.
Herramientas específicas y características de hardware y software específicos que serán necesarias para efectuar las pruebas, por ejemplo un cliente que usa una versión antigua de navegador requerirá de esa misma versión en el ambiente de pruebas.
14.Necesidades del equipo de trabajo y entrenamiento.
¿Todo el equipo necesita una herramienta de pruebas escogida por el cliente y no la conoce? ¿El sistema es de tal complejidad que requiere de entrenamiento para poder ser probado?
15. Responsables.
Quien hace que dentro del contexto del plan de pruebas.
16. Calendario.
Quién y cuándo va a efectuar las tareas del plan de pruebas.
17. Riesgos y contingencias.
Especificar cuales son los riegos y posibles contingencias del plan de pruebas y cómo se va a reaccionar frente a ellos, por ejemplo que el sistema no sea entregado a tiempo, que no haya datos para probar, que existan restricciones de acceso del cliente.
18. Aprobaciones.
¿Qué y quien aprueba los resultados del plan de pruebas?
19. Glosario.

Espero que esta introducción a IEEE 829 les ayude en su plan perfecto.