Documentacion de pruebas de software

Documentación y
pruebas

Antes del paradigma de
objetos

Pablo Suárez
Carlos Fontela
2003

ÍNDICE
Índice

2

Documentación y pruebas en el desarrollo tradicional del software
Documentación y desarrollo de software
Las pruebas en el desarrollo de software
Calidad, errores y pruebas
Categorías de pruebas
Las pruebas y el desarrollo de software
Tipos de pruebas
Revisiones decódigo
Pruebas unitarias
Pruebas de integración
Pruebas de sistema
Pruebas de aceptación
Herramientas a usar por los propios programadores
Reacción ante los resultados de las pruebas
Depuración
Reacción ante los errores en las pruebas de sistema y de aceptación

-2-

3
3
4
4
5
5
6
7
7
10
13
13
14
14
14
15

DOCUMENTACIÓN Y PRUEBAS EN EL DESARROLLO
TRADICIONAL DELSOFTWARE
DOCUMENTACIÓN Y DESARROLLO DE SOFTWARE
En general se habla mucho de la documentación, pero no se la hace, no se le asigna
presupuesto, no se la mantiene y casi nunca está al día en los proyectos de desarrollo de software.
Lo importante es la disponibilidad de la documentación que se necesita en el momento en que se la
necesita.
Muchas veces se hace porque hay que hacerla y se escribe, conpocas ganas, largos
textos, a la vez que se está convencido de estar haciendo un trabajo inútil. A veces se peca por
exceso y otras por defecto. Ocurre mucho en la Web y con productos RAD. En ocasiones se olvida
que el mantenimiento también debe llegar a la documentación.
dirigida:

La documentación se suele clasificar en función de las personas o grupos a los cuales está
•
•
•Documentación para los desarrolladores
Documentación para los usuarios
Documentación para los administradores o soporte técnico

La documentación para desarrolladores es aquélla que se utiliza para el propio desarrollo
del producto y, sobre todo, para su mantenimiento futuro. Se documenta para comunicar estructura y
comportamiento del sistema o de sus partes, para visualizar y controlar laarquitectura del sistema,
para comprender mejor el mismo y para controlar el riesgo, entre otras cosas. Obviamente, cuanto
más complejo es el sistema, más importante es la documentación.
En este sentido, todas las fases de un desarrollo deben documentarse: requerimientos,
análisis, diseño, programación, pruebas, etc.. Una herramienta muy útil en este sentido es una
notación estándar de modelado, demodo que mediante ciertos diagramas se puedan comunicar
ideas entre grupos de trabajo.
Hay decenas de notaciones, tanto estructuradas como orientadas a objetos. Un caso
particular es el de UML, que analizamos en otra obra. De todas maneras, los diagramas son muy
útiles, pero siempre y cuando se mantengan actualizados, por lo que más vale calidad que cantidad.
La documentación paradesarrolladores a menudo es llamada modelo, pues es una
simplificación de la realidad para comprender mejor el sistema como un todo.
Otro aspecto a tener en cuenta cuando se documenta o modela, es el del nivel de detalle.
Así como cuando construimos planos de un edificio podemos hacer planos generales, de
arquitectura, de instalaciones y demás, también al documentar el software debemos cuidar el nivelde detalle y hacer diagramas diferentes en función del usuario de la documentación,
concentrándonos en un aspecto a la vez.
De toda la documentación para los desarrolladores, nos interesa especialmente en esta
obra aquella que se utiliza para documentar la programación, y en particular hemos analizado la que
se usa para documentar desarrollos orientados a objetos en el capítulo respectivo.
Ladocumentación para usuarios es todo aquello que necesita el usuario para la
instalación, aprendizaje y uso del producto. Puede consistir en guías de instalación1, guías del
1

Incluye los requisitos del sistema, el procedimiento de instalación en pasos bien definidos y las posibilidades de personalización.

-3-

usuario2, manuales de referencia3 y guías de mensajes4.
En el caso de los...