Integración y pruebas del sistema

Este capítulo cubre tanto las pruebas como la documentación. El capítulo comienza
con los principios de prueba, las estrategias de prueba y la planificación de la
prueba. Luego, revisamos la medición y el seguimiento de las pruebas, los módulos
propensos a defectos y las implicaciones del análisis propenso a defectos en las
pruebas. A continuación, discutimos las cosas a considerar cuando usted produce
la documentación del usuario. Finalmente, utilizando los scripts TEST1 y TESTn,
revisamos el proceso de prueba de TSPi.

9.1 PRINCIPIOS DE PRUEBAS

En TSPi, el propósito de las pruebas es evaluar el producto y no arreglarlo. Aunque
ciertamente debería corregir cualquier defecto que encuentre en las pruebas,
debería haber encontrado y arreglado casi todos los defectos antes de la fase de
prueba. Cuando los productos de mala calidad se ponen a prueba, el tiempo de
prueba se amplía considerablemente y es probable que no encuentre la mayoría de
los defectos restantes.
La Figura 9.1 muestra el tiempo que puede tomar para probar los sistemas de
software. El software para la nave espacial Magellan fue desarrollado por un grupo
de software experimentado y capaz que utilizó métodos tradicionales de desarrollo
y prueba de software [Nikora]. Los datos de defectos muestran que incluso después
de dos años y medio de pruebas del sistema, el producto aún tenía defectos críticos.
Incluso con todas estas pruebas, la misión de Magellan tuvo problemas operativos.
Aunque cumplió su misión, tuvo una serie de emergencias relacionadas con el
software.
El punto clave que se debe tomar de la Figura 9.1 es que, con una estrategia de
calidad basada en pruebas, puede llevar mucho tiempo lograr que incluso los
sistemas pequeños funcionen de manera razonablemente confiable. El sistema
Magellan tenía solo 22 KLOC de software. Tenía un total de 186 defectos en la
prueba del sistema, 42 de ellos críticos. Además, solo se encontró un defecto crítico
en el primer año de pruebas del sistema. Con la nave espacial Galileo en la Figura
9.2, las pruebas demoraron seis años. Los 10 defectos críticos finales se
encontraron después de 288 semanas de prueba. Eso es más de cinco años.
La calidad de un producto se determina cuando se desarrolla. Ahora hay evidencia
irrefutable de que los ingenieros competentes que usan métodos de desarrollo de
software estándar producen programas de baja calidad de manera consistente.
Luego, cuando ponen a prueba estos programas, las pruebas llevan mucho tiempo
y no encuentran todos los problemas. Cuando pone un producto de baja calidad en
la prueba, generalmente obtiene un producto de mala calidad fuera de la prueba.
9.2 LA ESTRATEGIA DE PRUEBAS
TSPI
Con TSPi, el objetivo es poner a prueba programas de calidad. Luego, en las
pruebas, verificas que los productos son de alta calidad. Las principales actividades
de prueba de TSPi son las siguientes.
1. Usando las partes desarrolladas y probadas por unidades, construya el sistema.
2. Integración: pruebe el sistema para verificar que esté correctamente construido,
que todas las partes estén presentes y que funcionen juntas.
3. Haga una prueba del sistema del producto para validar que hace lo que requieren
los requisitos del sistema.
Mientras haces esto, también debes hacer lo siguiente.
1. Identifique los módulos o componentes de baja calidad y devuélvalos al
administrador de procesos / calidad para su evaluación y limpieza.
9.3 LA ESTRATEGIA DE
CONSTRUCCIÓN E INTEGRACIÓN
2. El propósito del proceso de construcción es asegurar que todas las piezas
necesarias estén presentes, ensamblar un sistema en funcionamiento y
proporcionar este sistema para la integración y la prueba del sistema.
3. La estrategia de integración define el enfoque de las pruebas de integración.
Básicamente, las pruebas de integración deberían simplemente verificar que
todos los componentes están presentes y que todas sus llamadas y otras
interacciones funcionan. No debes probar las funciones de los componentes.
Eso se hace en las pruebas del sistema. La estrategia de integración
depende en gran medida de la estrategia de desarrollo, pero también
depende del trabajo que haya realizado hasta ahora. Por ejemplo, puede
integrar solo los componentes disponibles. Es por eso que el plan de
implementación es importante: asegurarse de que implementa las partes del
sistema en un orden que tenga sentido para la integración. Este fue también
un objetivo principal de la estrategia de desarrollo.
2. Identifique los componentes de baja calidad que aún son problemáticos después
de la limpieza y devuélvalos al administrador de calidad / proceso para su reproceso
o reemplazo.
Los pasos generales de prueba son la compilación, la prueba de integración y la
prueba del sistema. El paso de compilación ensambla las diversas partes del
sistema en un sistema completo listo para la prueba. Esto se llama una compilación
del sistema. Las pruebas de integración aseguran que todas las partes adecuadas
se hayan incluido en el sistema y que sus interfaces sean compatibles y funcionen
juntas. Finalmente, las pruebas del sistema validan las funciones y el rendimiento
del sistema en función de los requisitos.
En los ciclos de desarrollo posteriores, las pruebas de regresión también son
necesarias para garantizar que el trabajo de desarrollo para este ciclo no haya
cambiado involuntariamente la funcionalidad o el rendimiento producido en ciclos
anteriores. Aunque todas estas funciones generalmente se han probado antes, si
no vuelve a ejecutar las pruebas anteriores en lo que se denomina un grupo de
regresión, a menudo no sabe si un cambio posterior causó problemas de regresión.

La estrategia de Big Bang

Con las partes que están disponibles, tiene varias opciones sobre cómo proceder.
El enfoque más obvio es juntar todas las partes y ver si funcionan. Esta llamada
estrategia de Big Bang es una alternativa atractiva porque requiere la menor
cantidad de desarrollo de pruebas. Sin embargo, rara vez tiene éxito,
particularmente con sistemas de baja calidad. En un sistema grande, por ejemplo,
las pruebas de integración encontraron 30,000 defectos. Aunque esto fue para un
sistema de varios millones de LOC, no es raro encontrar 10 o más defectos por
KLOC durante las pruebas de integración. Esta es la razón por la cual la calidad del
desarrollo es importante: para corregir cada defecto encontrado en la prueba de
integración puede tomar un promedio de 5 a 10 horas o más. En general, cuanto
más grande y complejo sea el sistema, más tiempo llevará diagnosticar y corregir
cada defecto. A menos que tenga piezas de muy alta calidad, la estrategia del Big
Bang no es una buena idea.

La estrategia de uno en uno

Una segunda estrategia es agregar las partes disponibles una a la vez. Debido a
que tendrá un sistema más simple con menos problemas, esta estrategia
generalmente es más efectiva. Primero, obtienes dos partes trabajando juntas, y
luego agregas una tercera y la ejecutas. Luego puede agregar una cuarta parte, una
quinta parte, y así sucesivamente. Con cada adición, busca problemas con las
partes recién agregadas. Esto usualmente lo llevará bastante rápidamente a las
causas del problema. Esta estrategia tiene la desventaja de que posiblemente
requiera más trabajo de desarrollo de pruebas.

La estrategia de cluster
Una tercera estrategia es agregar partes en grupos. Sin embargo, no puede
simplemente tomar las partes implementadas. En su lugar, examina las partes
disponibles y elige aquellas de un tipo particular; es decir, identifica una clase de
componentes relacionados y los integra. Un ejemplo podría ser todas aquellas
partes relacionadas con el manejo de archivos, la impresión o alguna otra área de
sistemas. Este enfoque podría ser útil, por ejemplo, si se necesita una determinada
función para probar el resto del sistema. Esta estrategia también podría reducir la
necesidad de controladores de prueba o instalaciones especiales.

La estrategia del sistema plano

La cuarta estrategia es construir un sistema plano. Aquí, la idea es integrar todas
las partes del nivel más alto primero y luego profundizar en capas sucesivas del
sistema en paralelo. Nuevamente, puede probar todas las partes nuevas a la vez o
agregar un componente a la vez. La ventaja de esta estrategia es que puede
detectar problemas en todo el sistema de manera temprana. También proporciona
la mayor flexibilidad al construir rápidamente un esqueleto total del sistema. El
principal problema con la estrategia de sistema plano es que generalmente requiere
un gran número de talones o andamios especiales para proporcionar retornos
ficticios para todas las funciones que aún no están disponibles.
Desafortunadamente, ninguna estrategia de integración será la mejor para todos los
sistemas. El mejor enfoque es considerar todas las opciones y elegir la que parezca
mejor para su proyecto en particular. A menos que tenga un sistema de mala
calidad, casi cualquier estrategia de integración lógica funcionará, así que no pierda
mucho tiempo agonizando sobre la mejor opción. En general, sin embargo, intente
agregar código nuevo en incrementos razonablemente pequeños.

9.4 LA ESTRATEGIA DE PRUEBA DEL

SISTEMA
En las pruebas del sistema, busca responder cuatro preguntas:
1. ¿El sistema realiza correctamente las funciones que se supone que debe
realizar?
2. ¿El sistema cumple con sus objetivos de calidad?
3. ¿Funcionará correctamente el sistema en condiciones normales?
4. ¿Funcionará correctamente el sistema en condiciones adversas?
Al responder estas preguntas, verifique una serie de áreas clave. Por ejemplo, ¿se
puede instalar el sistema? ¿Se inicia correctamente? ¿Realizará todas las funciones
dadas en los requisitos? ¿Se recuperará de fallas de hardware o de energía? ¿Es
adecuado su rendimiento? Para el rendimiento, evalúe el tiempo de respuesta, el
rendimiento y la capacidad. También necesita saber si el sistema es utilizable. ¿Le
resultará conveniente a los usuarios o les resultará difícil ejecutar las tareas y
responder a las preguntas normales de funcionamiento?
Por lo tanto, la prueba del sistema tiene muchos objetivos. Debido a que rara vez
tendrá tiempo suficiente para realizar todas las pruebas que puede visualizar,
necesita un plan de prueba para cubrir las pruebas que son más importantes para
su proyecto. El primer paso es identificar los objetivos principales del sistema y
luego diseñar una estrategia para asegurar que se cumplan todos estos objetivos.

Estrategias alternativas de prueba del sistema

Puede abordar estos objetivos de varias maneras. Por ejemplo, podrías probar cada
objetivo en serie. Primero prueba cada una de las funciones previstas del sistema.
Luego verifica la operación en condiciones de estrés, evalúa la usabilidad y
finalmente mide el rendimiento.
Esta es la estrategia de prueba del sistema más común porque, con productos de
baja calidad, la mayor parte del tiempo de prueba del sistema disponible se dedica
a que el sistema funcione. Desafortunadamente, este enfoque deja poco o ningún
tiempo para realizar pruebas reales del sistema. Con TSPi, debe tener un sistema
de alta calidad y debe ser capaz de ejecutar pruebas del sistema más completas.
Para pruebas exhaustivas, sin embargo, la estrategia de primera función
probablemente no sea eficiente. Con un plan de prueba cuidadosamente diseñado,
probablemente pueda evaluar varias características del producto con cada prueba.
Una segunda estrategia se enfoca en áreas funcionales seleccionadas, cubriendo
todos los aspectos de cada área antes de pasar a la siguiente área funcional. Por
ejemplo, puede comenzar por probar los cálculos numéricos para el funcionamiento
normal y adverso, la facilidad de uso, el rendimiento y la calidad. Esta estrategia
elimina en gran medida la duplicación de pruebas, pero no aborda el
comportamiento general del sistema. Al realizar pruebas a nivel microscópico, es
posible que no verifique adecuadamente el rendimiento general y la "sensación" del
sistema.
Esto sugiere una tercera estrategia que combina las dos anteriores. Comience
probando las funciones de nivel inferior para el comportamiento normal, anormal y
de estrés. A continuación, pase al siguiente nivel superior y pruebe los agregados
funcionales para asegurarse de que funcionan juntos. Una vez más, verifíquelos
bajo diversas condiciones normales y de estrés. Luego continúe con las pruebas en
niveles cada vez más altos hasta que haya cubierto todo el sistema. Esta estrategia
es esencial con sistemas de baja calidad porque muchas funciones de todo el
sistema inicialmente no funcionan en absoluto. La desventaja de esta estrategia es
que puede llevar mucho tiempo probar progresivamente todas las combinaciones
funcionales importantes para un sistema grande.
La cuarta estrategia tiene el enfoque inverso. Aquí, empiezas con las funciones de
nivel más alto y trabajas hacia abajo, nuevamente haciendo pruebas normales y de
estrés. Dependiendo del tamaño del sistema y de las principales preocupaciones
del sistema, es posible que desee realizar pruebas exhaustivas de varias
combinaciones funcionales. Aquí, esencialmente está probando el sistema contra
una serie de perfiles operativos, casos de uso o scripts de prueba. Aunque esta
estrategia cubre los problemas del sistema más rápidamente, solo funciona con un
producto de alta calidad. En general, puede determinar la calidad del producto a
partir de los datos de sus componentes, así como a partir de los datos de prueba de
compilación e integración. En general, después de la integración, debe pasar a las
pruebas en el nivel del sistema lo más rápido posible. Si tiene problemas de calidad,
devuelva los componentes ofensivos al administrador de calidad para su reparación
o reemplazo.

9.5 PLANIFICACIÓN DE PRUEBAS

La planificación de la prueba se realiza en varios lugares del proceso TSPi. Al igual
que con la PSP, comience produciendo un diseño de prueba conceptual, estimando
los tamaños de los materiales de prueba que se desarrollarán y el tiempo que
tomará el desarrollo de la prueba y el trabajo de prueba. Necesita planes de prueba
para las actividades de construcción, pruebas de integración y pruebas del sistema.
Aunque los planes de compilación e integración deben ser simples, aún es
importante planificar las pruebas antes de hacerlo.
Una vez completado, el plan de prueba describe qué pruebas planea ejecutar, el
orden para ejecutarlas y los materiales de prueba necesarios para cada prueba.
Con un plan completo, debería poder mostrar cómo se prueba cada requisito y cómo
los scripts o escenarios de prueba cubren las áreas de requisitos. También debe
saber qué áreas de requisitos se someten a pruebas exhaustivas y cuáles tienen
poca cobertura.
Además, debe asignar un nombre a cada prueba anticipada, definir los resultados
que debe producir y predecir durante cuánto tiempo probablemente se ejecutará.
Además, estime los defectos que se encontrarán en cada fase de prueba, el tiempo
total de reparación de defectos y el tiempo total de prueba. A continuación, estime
los tamaños de los materiales de prueba requeridos. Además de las estimaciones
de tamaño de LOC, es probable que necesite scripts de prueba para las pruebas
interactivas, así como datos de prueba. Para algunos sistemas, la preparación de
datos de prueba puede ser un trabajo más grande que el desarrollo de casos de
prueba.
Al final de la planificación de la prueba, debe tener
Una lista de todos los pasos de prueba a realizar.
Los materiales de apoyo requeridos para cada prueba.
Los resultados que las pruebas son para producir.
Una estimación del tiempo de ejecución sin defectos, los defectos que se
encontrarán y el tiempo total para cada prueba
Una estimación del trabajo requerido para desarrollar cada elemento en el plan de
prueba
También necesitará una lista de
Todos los materiales de soporte de prueba requeridos y qué pruebas apoyan
Los objetivos para cada prueba.
¿Qué tan grande se espera que sean estos materiales?
Cuánto tiempo es probable que tome su desarrollo
 ¿Quién desarrollará cada elemento de soporte de prueba?
Cuando estas tareas de desarrollo deben ser completadas
Finalmente, desarrollar los materiales de prueba. Si planea un programa de prueba
sustancial, es posible que también desee casos de prueba de autocomprobación.
Ellos comparan automáticamente los resultados reales de las pruebas con los
planificados y proporcionan una salida que indica si el resultado fue correcto. Con
tales casos de prueba, puede ejecutar un gran lote de pruebas y verificar solo al
final para ver qué pruebas encontraron defectos. En general, si carece de un
conjunto completo de herramientas de prueba, no es práctico desarrollar pruebas
de autocontrol.

9.6 SEGUIMIENTO Y MEDICIÓN DE

PRUEBAS
Si anticipa realizar muchas pruebas, querrá datos sobre la efectividad de las
pruebas, es decir, cuántos defectos se descubren en función de su tiempo de
ejecución. Luego, puede usar estos datos de defectos / horas como una figura de
mérito al seleccionar pruebas para incluir en un grupo de pruebas de regresión. Una
regla de oro es incluir en el grupo de regresión todas las pruebas que hayan
encontrado defectos, así como todas las pruebas que verifiquen las áreas de
sistemas previamente probadas que se modificaron en el ciclo de desarrollo más
reciente.
Debido a que ejecutará un conjunto completo de pruebas para cada ciclo de
desarrollo de TSPi, algunas mediciones de prueba serían útiles. Además de los
datos que registra en LOGD y LOGT, debe responder las siguientes preguntas.
¿Cuánto tiempo tomó la ejecución de esta prueba?
¿Cuántos defectos encontró?
¿Requiere intervención manual, o puede combinarse con otras pruebas?
¿Es autocomprobación?
Para responder a todas estas preguntas, debe registrar los datos sobre el tiempo
de ejecución de la prueba, la cantidad de defectos encontrados y las condiciones
de la prueba. Una forma conveniente de mantener estos datos es en un registro de
prueba.

El registro de prueba
Los siguientes son los tipos de información para registrar en el registro de prueba.
La fecha en que se ejecutó la prueba.
El nombre de la persona que realiza la prueba.
Las pruebas corren, nombre y / o número.
El producto y la configuración que se está probando.
La hora en que se inició cada prueba.
El tiempo en que se completó cada prueba.
El número de defectos encontrados, con las referencias y números de LOGD.
Los resultados de la prueba
Además, es posible que desee incluir lo siguiente.
La configuración del sistema que se está probando.
Cualquier herramienta especial o instalaciones utilizadas
Si la intervención del operador fue requerida y cuánto
La forma más sencilla de registrar la información básica es en un registro
cronológico que se parece mucho al registro de tiempo. Un ejemplo se muestra en
la Tabla 9.1. Luego incluya toda la información agregada en un informe de prueba
que presente en el cuaderno del proyecto junto con una copia del registro de prueba.

Módulos propensos a defectos

Los datos de calidad de muestra para un producto IBM grande se muestran en la
Figura 9.3 [Kaplan]. Aquí, el eje x muestra los defectos por componente encontrados
en la prueba de desarrollo, y el eje y muestra los defectos reportados por los
clientes. La correlación entre estos dos es 0.9644, con un alto significado de más
de 0.001. Esto significa que cuando los componentes tienen muchos defectos en la
prueba, también es probable que queden muchos defectos después de la prueba.
En otras palabras, mientras más defectos encuentre en la prueba, más no
encontrará.
Esto sugiere que uno podría usar datos de prueba para evaluar el riesgo de que el
sistema tenga una o más partes propensas a defectos. Para hacer esto, ordene los
datos de defectos del módulo para encontrar qué módulos tenían la mayoría de los
defectos encontrados en cada prueba. Por lo general, es probable que aquellos
módulos con la mayoría de los defectos tengan la mayoría de los defectos restantes
después de la prueba. Si algunos módulos parecen particularmente pobres, a
menudo puede ahorrar una gran cantidad de tiempo de prueba y producir productos
de mayor calidad suspendiendo temporalmente las pruebas. Luego vuelva a
inspeccionar y corregir estos componentes propensos a defectos antes de continuar
con las pruebas.

Table 9.1 Sample Test Log (Form Logtest)

Figure 9.3 Development Versus Usage Defects IBM Release 1 (R = 0.9644)

Módulo de datos de defectos
La herramienta TSPi proporciona dos formas de examinar los datos de defectos del
módulo. El formulario SUMP para un módulo proporciona el número de defectos
eliminados en cada fase. También puede generar un formulario SUMQ que
proporcione todas las medidas de calidad para un módulo individual. Con estos
datos para cada módulo, debería poder identificar rápidamente cualquier módulo
propenso a defectos. Tenga en cuenta, sin embargo, que al realizar esta
comprobación, debe observar cada fase de eliminación de defectos de cada ciclo
de desarrollo del producto. Luego, puede determinar la fase en la que comenzaron
los problemas de un módulo.

Seguimiento de datos de defectos

Para rastrear y analizar módulos propensos a defectos, necesita datos sobre cada
defecto para cada prueba. Además, en la reunión semanal, revise todos los defectos
encontrados en la compilación, integración o pruebas del sistema con todo el
equipo. Estos defectos escaparon a todo el proceso de desarrollo, y sus datos
pueden proporcionar pistas importantes para encontrar o prevenir defectos similares
en el futuro. Las siguientes son algunas de las preguntas que puede responder con
estos datos.
¿Qué pasos del proceso escaparon los defectos?
¿Cómo puedes cambiar estos pasos para que esto no vuelva a suceder?
¿Cómo se puede modificar el proceso de desarrollo para prevenir estos defectos
en el futuro?
¿En qué parte del sistema podrían permanecer defectos no descubiertos
similares?
¿Cómo puedes encontrar y reparar estos defectos ahora?
Después de la prueba, el administrador de calidad / proceso debe llevar a cabo una
revisión de todos los defectos de compilación, prueba de integración y prueba del
sistema con todo el equipo. Luego haga que alguien busque y solucione los defectos
no descubiertos que sospecha que permanecen en el sistema. Además, actualice
el proceso con los cambios que haya identificado.

9.7 DOCUMENTACION
Como es el caso con muchas otras partes del proceso del software, la
documentación es un tema grande que vale todo un curso propio. Este capítulo
cubre algunos de los puntos clave sobre la documentación del software y
proporciona referencias a algunos textos sobre el tema. Si ha tenido un curso sobre
escritura técnica, ahora es un buen momento para practicar lo que ha aprendido. Si
no ha tenido un curso de este tipo, ahora es un buen momento para comenzar a
pensar en este tema importante.
En la fase de prueba de TSPi, parte del equipo redacta y revisa la documentación
del usuario, mientras que el resto del equipo realiza las pruebas. Si bien los sistemas
comerciales generalmente necesitan una amplia gama de documentos para cubrir
las necesidades de instalación, mantenimiento, capacitación y mercadeo, con TSPi
solo abordamos la documentación básica del usuario.
La proporción de miembros del equipo para asignar a las pruebas o a la
documentación varía según la calidad y el contenido funcional del producto. Durante
el primer ciclo de desarrollo, es una buena idea asignar más ingenieros a las
pruebas y luego, en ciclos subsiguientes, aumentar el número asignado a la
documentación. La necesidad de desarrollar pruebas debería disminuir en ciclos
posteriores, y la carga de trabajo de la documentación probablemente aumentará
con cada incremento de la funcionalidad agregada del producto.

La importancia de la documentación
La documentación es una parte esencial de cada producto de software. En muchos
sentidos, la documentación es más importante que el código del programa. En una
empresa, por ejemplo, los ingenieros siguieron la práctica común de diferir el trabajo
de documentación hasta que terminaron las pruebas. A menudo, incluso diferían el
trabajo en algunos documentos hasta después de que los productos habían sido
enviados a los clientes. Los clientes se enojaron tanto con esto que finalmente se
negaron a pagar los programas. Le dijeron a la compañía que no querían que se
enviaran los programas hasta que vinieran con toda la documentación requerida.
En lo que a ellos se refería, un programa sin la documentación era inútil.
El mejor momento para documentar una función es justo después de haberlo
diseñado. Si produce los documentos antes de completar el diseño, probablemente
tendrá que hacer muchos cambios. Por otro lado, si demora el trabajo de
documentación demasiado tiempo, este trabajo tomará más tiempo que si lo hiciera
cuando el diseño estaba fresco en su mente. El TSPi, por lo tanto, incluye el trabajo
de desarrollo de documentos en la fase de prueba. Con sistemas más grandes, este
trabajo generalmente debería comenzar mucho antes y continuar hasta el final de
las pruebas. De hecho, es una buena idea probar los documentos del usuario como
parte de las pruebas del sistema.

Diseño de documentación
Escribir manuales de usuario útiles y útiles es un problema difícil para los ingenieros
de software. Después de diseñar y construir un producto, es natural querer describir
lo que usted construyó. Desafortunadamente, este deseo natural, para describir su
maravillosa creación, generalmente conduce a un documento terrible. La razón es
que estás escribiendo sobre lo que hiciste y no lo que el lector necesita.
Una guía útil para determinar la calidad de un manual es mirar la tabla de contenido.
Si el manual está organizado en torno al diseño del producto, probablemente sea
un documento deficiente. Un manual bien diseñado debe organizarse en torno a las
necesidades del lector y no a la estructura del producto. En general, la primera
sección debe abordar lo que el usuario debe saber primero: cómo comenzar. A
continuación, puede explicar qué puede hacer el usuario con el producto.
Finalmente, facilite que las personas encuentren lo que quieren saber. Aquí hay
algunas sugerencias.
Use un glosario para definir cualquier término que no esté en un diccionario
estándar.
Incluya una sección sobre mensajes de error, procedimientos de solución de
problemas y procedimientos de recuperación.
Tener un índice de temas clave.
Proporcionar una tabla de contenidos detallada.

Esquema de la documentación
El primer paso en la documentación es producir un resumen detallado. Comience
con un esquema de alto nivel y luego entre en detalles. Antes de comenzar a escribir
el texto, verifique el esquema para asegurarse de que cubra todos los escenarios
de usuario clave para esta compilación. Las únicas excepciones son los escenarios
que se cambiarán en ciclos de desarrollo posteriores. Describirlos ahora
probablemente sería una pérdida de tiempo.
Cuando termine el esquema, revíselo con los ingenieros que están haciendo el plan
de prueba para asegurarse de que ambos entiendan las mismas funciones de la
misma manera y que ninguno de los dos haya omitido nada importante. Esta simple
comprobación a menudo descubre defectos del sistema que ninguno de los grupos
puede ver por sí mismo. La documentación y la planificación de las pruebas
proporcionan diferentes perspectivas de las utilizadas en el diseño. De hecho, los
equipos a menudo encuentran más defectos en la documentación y en la
planificación de pruebas que durante las pruebas.

Estilo de escritura
En general, escriba oraciones cortas, use palabras y frases simples y use muchas
listas y elementos con viñetas. Por ejemplo, al explicar un procedimiento como el
desarrollo de prueba en el script TEST1, escríbalo de la siguiente manera.

A menudo, las personas escriben tal listado en forma de párrafo, como sigue:
El gerente de desarrollo o desarrollo de pruebas de leads alternativos. Los
miembros del equipo de prueba realizan sus tareas de desarrollo de prueba.
Asignan las tareas de desarrollo de prueba a los miembros del equipo de prueba,
definen los procesos y procedimientos de compilación requeridos, desarrollan los
procedimientos e instalaciones de prueba de integración, desarrollan los
procedimientos e instalaciones de prueba del sistema, miden el tamaño y el tiempo
de ejecución de cada prueba, revisan los materiales de prueba , y corregir errores.
Aunque las palabras son casi idénticas, el lector debe pasar por el párrafo para
averiguar qué hacer. Cuando organiza las mismas palabras en forma de lista, es
más fácil entender el trabajo y ver cómo hacerlo. Esta estructura también hace que
sea mucho más fácil para el usuario repasar un procedimiento después de no usarlo
por un tiempo.
Un comentario final se refiere a la calidad del documento. La mayoría de los
escritores experimentados pasarán de 5 a 10 veces más tiempo reescribiendo un
documento como se necesita para escribir el primer borrador. Después de muchas
reescrituras, sin embargo, es fácil terminar con una prosa que sea técnicamente
correcta pero difícil de leer. Una forma de resolver este problema es leer cada
párrafo en voz alta. Si es difícil de decir, probablemente sea difícil de leer. Vuelve a
escribirlo hasta que puedas decir fácilmente lo que escribiste. Entonces es probable
que tenga un documento legible. Para obtener más información sobre la redacción
técnica, le sugiero que consulte algunos libros sobre el tema [Chicago, Dupre,
Strunk, Tichy, Williams, Zinsser].

Revisión de documento
Después de redactar y volver a escribir la documentación del usuario, haga que uno
o más de sus compañeros la revisen. Si este es un producto para clientes o
usuarios, ejecute pruebas de usuario para asegurarse de que la escritura sea clara,
precisa, completa y comprensible. Algunos de los elementos para verificar en esta
revisión son los siguientes.
Organización de documentos. ¿El documento está organizado en torno a lo que
hará el usuario o en torno al contenido del producto? Los documentos del usuario
deben abordar las necesidades del usuario y no la estructura o el contenido del
producto.
Terminología del documento. ¿El documento supone conocimiento que el usuario
podría no tener? Los expertos en software a menudo utilizan terminología especial,
incluso cuando escriben para personas que podrían no entenderlo. Cualquier
palabra que no esté en el diccionario debe ser definida.
Contenido del documento. ¿El documento cubre todo el material requerido?
Exactitud. ¿Los métodos y procedimientos funcionan realmente como se describe?
Legibilidad. ¿Es el documento fácil de leer? Léalo en voz alta y vea si se siente
cómodo diciendo lo que está escrito.
Comprensibilidad ¿Pueden los laicos entender lo que está escrito? Esta pregunta
es generalmente la más difícil de responder. La mejor prueba es reclutar a alguien
que no haya estado expuesto previamente al sistema y pedirle que siga el manual
para usar el sistema. Luego observe las reacciones de su sujeto, registre cualquier
problema y vuelva a trabajar en el documento para resolver estos problemas.

9.8 LOS ESCRITOS DE PRUEBA TSPI

Los scripts TEST1 y TESTn se muestran en las Tablas 9.2 y 9.3. Son casi idénticos,
excepto que en TESTn tendrá datos de los ciclos de prueba anteriores. También
realiza pruebas de regresión con el script TESTn, algo que no es necesario con
TEST1.

Criterio para entrar

Los criterios de entrada para los scripts TEST requieren que
Usted tiene las especificaciones SRS y SDS completadas e inspeccionadas
Usted tiene los componentes implementados, inspeccionados y probados por
unidades bajo el control de configuración
Para TESTn, tiene una versión anterior del producto controlada por la
configuración

Desarrollo de la prueba
Los siguientes son algunos de los elementos que se deben producir durante el
desarrollo de la prueba.
1. Una prueba de completitud de construcción. Este primer paso en las pruebas de
integración comprueba que el sistema se ha construido y que se incluyen todos los
componentes planificados. Piense en esta prueba como una verificación de la lista
de verificación que verifica que cada componente está presente. Haz esto tan simple
como un paquete de prueba como puedas. Para sistemas pequeños, incluso podría
ser un procedimiento manual.
2. Los procedimientos de integración para probar todas las interfaces en
condiciones normales y de error. Estas pruebas verifican que la compilación ha
producido un sistema que está listo para la prueba del sistema. A partir de la prueba
de completitud de compilación, usted sabe que todos los componentes están
presentes. Ahora se asegura de que el sistema construido pueda iniciarse y
ejecutarse, que todos los componentes puedan llamar a los otros componentes y
que todas las interfaces del sistema coincidan y funcionen correctamente. Esta no
es una prueba exhaustiva; solo demuestra que las interfaces coinciden y funcionan
correctamente.

Table 9.2 TSPi Cycle-1 Integration and System Test: Script TEST1
Table 9.3 TSPi Cycle n Integration and System Test: Script TESTn
3. Los materiales de prueba de integración. Aunque cada una de las pruebas es
simple, las pruebas de interfaz requieren preparación. Debido a que es posible que
tenga que probar muchas interfaces bajo una amplia variedad de condiciones y
valores de parámetros, es posible que desee un procedimiento automatizado simple
para recorrer las pruebas e indicar que se han completado con éxito. Sin embargo,
para sistemas pequeños, las pruebas de interfaz accionadas manualmente son
generalmente adecuadas.
4. Los materiales de prueba del sistema. Estos materiales deben probar todas las
funciones del sistema en condiciones normales y de estrés. También deben verificar
cómo se utilizará el sistema: durante la instalación, conversión, operación o
recuperación. Las pruebas del sistema también deben considerar la facilidad de uso,
el rendimiento, las anomalías de fecha y la exactitud y precisión matemática. Debido
a que este producto se está construyendo en varios ciclos, debe realizar las pruebas
de usabilidad y rendimiento con el primer ciclo si es posible. Resolver los problemas
de rendimiento y usabilidad es difícil después de que un producto se haya creado
inicialmente. Si se requieren cambios importantes, deben obtener la máxima
prioridad en el próximo ciclo de desarrollo.
5. Una declaración clara de los resultados esperados de cada prueba. Cuando sea
posible, haga que los materiales de prueba del sistema sean autocomprobados.
Como se señaló anteriormente, un caso de prueba de autocomprobación es uno
que enumera los resultados reales y si son correctos o no. Cuando ejecuta un lote
de pruebas, esta capacidad le permite verificar rápidamente si hubo problemas.
Hacer autocontrol de las pruebas puede requerir un trabajo adicional, pero a
menudo es una buena inversión, especialmente para las pruebas que espera usar
en las compilaciones de sistemas posteriores de pruebas de regresión. Sin
embargo, si no tiene un conjunto completo de herramientas de prueba, el esfuerzo
adicional para proporcionar la capacidad de autocomprobación probablemente no
valga la pena.

Construir
Después de la planificación y el desarrollo de pruebas, el siguiente paso en los
scripts TEST1 y TESTn es la compilación. Los pasos de compilación son los
siguientes.
1. Verifique todos los componentes necesarios para asegurarse de que estén
disponibles y cumpla con los requisitos de dependencia. Aquí, una dependencia de
componente es una capacidad requerida en el sistema base para admitir ese
componente. Los ejemplos incluyen una base de datos, una capacidad de manejo
de errores y soporte de dispositivos. Donde los componentes necesitan funciones
que no están disponibles, pueden ser necesarios controladores de prueba
especiales o talones; Comprueba que estén previstas y estén disponibles. También
puede haber otras dependencias, como para reparaciones de defectos. Por
ejemplo, un componente puede haberse caído en el ciclo de desarrollo anterior
debido a un error de interfaz. Compruebe que todos estos defectos hayan sido
reparados.
2. Revise los elementos suministrados para la construcción e identifique las piezas
faltantes. Asegúrese de que el sistema pueda construirse sin estas piezas y
asegúrese de que estas necesidades también se aborden durante la planificación
de la integración y el desarrollo de pruebas.
3. Compruebe la construcción propuesta para la coherencia y la integridad. Esta es
una verificación final del trabajo de todos para garantizar que se incluyan todas las
piezas necesarias y que una compilación de estos componentes sea un producto
completo adecuado para las pruebas de integración.
4. Construye el producto. Para productos pequeños, esto consiste en compilar y
vincular los componentes del sistema y registrar su tiempo en el registro de prueba
(LOGTEST) y cualquier defecto en los formularios LOGD de los propietarios del
producto.
Si se encuentran defectos durante la compilación, decida si continuar con la
compilación o devolver uno o más componentes a los desarrolladores para su
reparación. Informe los defectos en los formularios LOGD del propietario del
producto y pídale al administrador de procesos / calidad que lo ayude a decidir cómo
proceder. Si la reparación se puede hacer rápidamente, podría reconstruir. De lo
contrario, es posible que tenga que reprogramar la construcción.

Integración
Las tareas de integración son las siguientes.
1. Compruebe la integridad del producto construido. Ejecute una verificación de
integridad en la compilación para verificar que todas las piezas necesarias estén
presentes en la compilación.
2. Ejecutar las pruebas de integración. Ejecutar las pruebas de integración
planificadas.
3. Para estas pruebas, registre los datos de la prueba en el registro de prueba
(formulario LOGTEST). Registre su nombre, la fecha, la hora, el sistema que se está
probando, las pruebas ejecutadas, sus tiempos de ejecución y los defectos
encontrados.
4. Si se encuentran defectos, el propietario del producto registra todos los defectos.
Luego haga que el gerente de calidad / proceso determine si las pruebas deben
continuar. Si es posible, continúe con las pruebas de integración y arregle los
defectos en paralelo. Sin embargo, si el sistema tiene componentes muy
defectuosos, cancele las pruebas de integración y realice una inspección completa
de estos componentes defectuosos.
Si hubiera defectos, devuelva los datos de defectos a los ingenieros apropiados
para su reparación. Después de la corrección, haga que un miembro del equipo
inspeccione la corrección para asegurarse de que sea correcta. El gerente de
calidad / proceso también debe revisar estos defectos en la próxima reunión del
equipo. Para sistemas y proyectos más grandes, normalmente necesita suficiente
información para recrear el problema para que los ingenieros de desarrollo puedan
diagnosticarlo y repararlo. Esta información generalmente incluye la configuración
de hardware y software, los trabajos que se están ejecutando, cualquier información
sobre archivos y datos requeridos, etc. Para TSPi, sin embargo, los datos simples
de LOGD y LOGTEST deberían ser adecuados.

Prueba del sistema

Para probar el sistema, siga el plan de prueba para probar el sistema. Nuevamente,
registre todos los defectos en el registro de defectos del propietario del producto y
realice una revisión del equipo. Cuando se encuentran defectos, haga que el
gerente de calidad / proceso determine si las pruebas deben continuar o abortarse.
Al igual que en la integración, generalmente desea continuar con las pruebas del
sistema si puede y tiene los defectos resueltos en paralelo. Sin embargo, si el
sistema tiene componentes gravemente defectuosos, cancele las pruebas del
sistema y realice una reinspección completa de las piezas defectuosas. Cuando se
hayan encontrado y arreglado los defectos, y cuando se hayan inspeccionado los
arreglos, continúe con las pruebas del sistema hasta que se completen.
Pruebas de regresión
El paso final en las pruebas del sistema es ejecutar pruebas de regresión de ciclos
de desarrollo anteriores para garantizar que el producto siga funcionando como
antes. Las pruebas de regresión implican volver a ejecutar algunas pruebas del
sistema de ciclos de desarrollo anteriores. Generalmente, el grupo de prueba de
regresión sería un subconjunto de las pruebas de las pruebas del sistema del ciclo
anterior. Después de que el sistema y las pruebas de regresión se hayan ejecutado
con éxito, el sistema está listo para la entrega o el siguiente ciclo de desarrollo. Con
TEST1, no hay necesidad de pruebas de regresión. Nuevamente, complete los
formularios LOGD, LOGT y LOGTEST.

Documentación
Completa la documentación del usuario.

Criterio de salida
Al finalizar la fase de prueba, debe tener lo siguiente.
Una versión del producto completa, integrada, probada por el sistema y por
regresión
Un registro de prueba completo en el registro de prueba.
Entradas de LOGD completadas y un análisis de defectos por cada defecto
encontrado
Documentación de usuario completada y revisada
Se actualizaron los formularios SUMP y SUMQ para el sistema y todos sus
módulos o componentes.
Una copia de todos los datos y formularios de prueba en el cuaderno del proyecto.

9.9 RESUMEN
Este capítulo cubre tanto las pruebas como la documentación. El propósito de la
prueba es evaluar el producto, no arreglarlo. Sin embargo, con TSPi, tiene los datos
para juzgar qué partes del sistema tienen más probabilidades de ser propensas a
defectos. Por lo general, es probable que aquellos módulos con la mayoría de los
defectos en la prueba tengan la mayoría de los defectos restantes después de la
prueba. Estos módulos deben ser extraídos de la prueba y arreglados por los
desarrolladores. Tratar de corregirlos en la prueba lleva mucho tiempo y rara vez es
eficaz.
En los pasos de compilación e integración, ensambla las partes del sistema, se
asegura de que se incluyan todas las partes necesarias y se asegure de que todas
sus interfaces funcionan correctamente. En las pruebas del sistema, busca
responder las siguientes preguntas.
¿El sistema realiza correctamente las funciones que se supone que debe realizar?
¿El sistema cumple con sus objetivos de calidad?
¿Funcionará correctamente el sistema en condiciones normales?
¿Funcionará correctamente el sistema en condiciones adversas?
¿El sistema arranca correctamente?
¿El sistema realizará todas las funciones dadas en los requisitos?
¿Se recuperará de fallas de hardware o de energía?
¿Es adecuado el rendimiento del sistema?
¿Es utilizable el sistema?
En la planificación de pruebas, describa las pruebas que planea ejecutar y en qué
orden y describa los materiales de prueba que se necesitan para ejecutar cada
prueba. Luego nombre cada prueba planificada y especifique cuánto tiempo espera
que se ejecute, los resultados de prueba anticipados y los tamaños de los materiales
de prueba que se desarrollarán. Además del código de prueba especial, es posible
que necesite scripts de prueba interactivos y datos de prueba.
En la fase de prueba de cada ciclo de desarrollo, algunos miembros del equipo
redactan y revisan la documentación del usuario mientras que otros miembros
realizan la prueba. Un manual bien diseñado se organiza en torno a las necesidades
del usuario y no a la estructura y funciones del producto. El primer paso de la
documentación es producir un resumen completo y luego revisarlo con el grupo de
prueba para asegurarse de que ambos grupos estén cubriendo los mismos temas
de la misma manera. Al escribir, use oraciones cortas, palabras y frases simples y
muchas listas y elementos con viñetas. Después de que hayas escrito y revisado
personalmente el manual, haz que otros lo revisen. Para los productos que se
entregarán a los usuarios finales, también pruebe los documentos con usuarios
típicos y durante las pruebas del sistema.