Este documento presenta los nombres y matrículas de 5 estudiantes que realizaron un trabajo sobre pruebas de software. El trabajo incluye 10 preguntas sobre temas como la diferencia entre verificación y validación, los problemas de crear un grupo de prueba independiente, cómo afecta la programación a las pruebas de integración y por qué es más difícil probar módulos altamente acoplados.

1. Presentación
Nombres:
José Samuel Peña Acevedo
Ricardo David Muñoz Taveras
Rudy Peña Matos
Rhainer Peña
Eduin Cecilio Pérez Santos
Matriculas:
A00107391
A00107874
A00109417
A00106851
A00110750
Tema:
El Software y la Ingeniería de Software
Maestro:
Leandro Fondeur Gil
Periodo académico:
2022-C3
Fecha de entrega:
17 de noviembre de 2022

2. Luego de leer los capítulos 17 y 18 del libro de texto,
subrayar los conceptos centrales e investigar otras fuentes
para ampliar las ideas, realice las siguientes actividades
(en grupo):
1. Con sus palabras, describa la diferencia entre
verificación y validación. ¿Ambas usan los
métodos de diseño de casos de prueba y estrategias
de pruebas? Explique su respuesta.
La prueba de software es un elemento de un tema más amplio que usualmente se
conoce como verificación y validación (V&V).
La verificación es el conjunto de tareas que se encarga de garantizar que un
software emplea correctamente las funciones específicas. La forma más simple es:
Verificación: “¿Construimos el producto correctamente?”
La validación es en conjunto de diferentes tareas que se aseguran que el software
que se está construyendo sigue las pautas que planteo el cliente. La forma más,
simple es:
Validación: “¿Construimos el producto correcto?”
La diferencia seria que la verificación se enfoca en verificar y confirmar que el
software o su funcionalidad funciona sin problemas, mientras que las pruebas se
enfocan en garantizar que el producto se construya de acuerdo con los requisitos del
cliente, es decir, asegúrese de que es lo que pidió el cliente.
Las 2 utilizan los métodos de diseño de casos de prueba y estrategias de prueba
dado que se busca comprobar el producto, pero con un propósito diferente y desde
un ángulo diferente. Cada uno se enfoca en probar las características del producto
para garantizar que cumpla con todos los aspectos de un gran software y las
expectativas del cliente.
2. Mencione algunos problemas que pueden asociarse
con la creación de un grupo de prueba
independiente. ¿Los GPI y el SQA se integran con
las mismas personas? Justifique su respuesta.
Existe varios problemas relacionados con la creación de GPI:
No se sabe mucho acerca de cómo funciona correctamente el programa, y
cuando se trata de pruebas, no hacen las pruebas necesarias para verificar la
calidad y seguridad del proyecto.
Se puede decir que GPI y SQA consisten en el mismo grupo de personas, las
personas de GPI serán responsables de ejecutar pruebas y detectar errores de
ejecución, así como controles de calidad.

3. 3. ¿Por qué un módulo altamente acoplado es difícil
para la prueba de unidad?
Resulta más difícil aplicarle pruebas de unidad a un módulo altamente acoplado
debido a que a mayor conexión en el proceso del módulo implica que es mayor la
complejidad o exhaustividad que tendrá que tener las pruebas de unidad, al punto
tal que no pueden ser estrictamente aisladas a una parte del módulo, sino, que debe
irse realizando cada prueba pensando en cada paso necesario para que el módulo
sea probado de forma secuencial e individualizado a pesar de que al estar utilizando
varios componentes de un mismo módulo
4. El concepto de "antierrores” (sección 17.3.1) es
una forma extremadamente efectiva de brindar
asistencia de depuración interna cuando se
descubre un error:
⦁ Analice las desventajas.
1. Requiere un mayor tiempo de desarrollo
2. Requiere tiempo en el análisis de posibles errores y rediseño del módulo,
para limitar las opciones o elegir las formas más óptimas de desarrollar el
módulo de manera tal que el usuario cometa la mínima cantidad de procesos
necesarios
3. Menor flexibilidad a la hora de dar libertad al usuario de interferir en el
sistema.
5. ¿Cómo puede la calendarización del proyecto
afectar la prueba de integración?
es el proceso de establecer tiempos para tareas y etapas. Si el proyecto está
retrasado y la fase de prueba unitaria no se ha completado, la fase de prueba de
integración no puede comenzar. Por ejemplo, el diseño de las principales
actividades marco previstas para el proyecto. Si el proyecto está retrasado, las
pruebas de integración ni siquiera pueden comenzar. Las pruebas de integración se
realizan después de las pruebas unitarias que ocurren después de la codificación.
Además, si el tiempo es escaso, el administrador del proyecto puede reducir el
tiempo de prueba de integración, reduciendo la calidad o aumentando el costo.
6. ¿Quién debe realizar la prueba de validación: el
desarrollador o el usuario del software? Justifique
su respuesta.

4. Al considerar una verificación o inspección exhaustiva de nuestro software,
considerando su lanzamiento, debemos saber quién es el responsable de verificar
dicho software. Los desarrolladores deben verificar y hacer saber a las personas que
el código desarrollado puede cumplir correctamente con los requisitos establecidos
anteriormente. Debe hacerse de la siguiente manera: Debe escribir o ejecutar
manualmente las pruebas unitarias. Posteriormente, el Quality Assurance Engineer
(QA) tiene que realizar diferentes pruebas más exhaustivas, además de pruebas muy
importantes como la prueba de regresión, que se realiza cuando el software lo
requiere. Finalmente, necesitamos organizar las Pruebas de Aceptación del Usuario
(UAT). Con base en estos resultados, podemos decidir implementar una nueva
versión del software.
7. Myers [Mye79] usa el siguiente programa como
una auto-valoración de su habilidad para
especificar pruebas adecuadas: un programa lee
tres valores enteros. Los tres se interpretan como
representación de las longitudes de los lados de un
triángulo. El programa imprime un mensaje que
indica si el triángulo es escaleno, isósceles o
equilátero. Desarrolle un conjunto de casos de
prueba que crea que probarán este programa de
manera adecuada.
8. Diseñe e implemente el programa (con
manipulación de error donde sea adecuado) que se
especifica en el problema anterior. Derive un
gráfico de flujo para el programa y aplique prueba
de ruta básica para desarrollar casos de prueba que
garanticen la prueba de todos los enunciados en el

5. programa. Ejecute los casos y muestre sus
resultados.
9. Adicione algunos objetivos de prueba adicionales
que no se estudiaron en la sección 18.1.

6. • Identificar y asegurarse de que los defectos encontrados hayan sido corregidos
antes Entregue el software al cliente.
• Diseñar casos de prueba para exponer sistemáticamente diferentes tipos de
Comete errores con la menor cantidad de tiempo y energía.
• Una parte necesaria del caso de prueba es la definición del resultado esperado.
• No solo escribir casos de prueba para condiciones de entrada Efectivo y esperado,
pero también aplicable a situaciones inválidas e inesperadas.
• El número de errores no detectados es proporcional al número de errores error
encontrado.
10. ¿Las pruebas exhaustivas (incluso si es posible
para programas muy pequeños) garantizarán que el
programa es 100 por ciento correcto? Justifique su
respuesta.
No, incluso las pruebas exhaustivas no pueden garantizar que el software sea 100%
correcto. Deben tenerse en cuenta demasiadas preguntas. Cómo son:
•¿Se instaló el programa de acuerdo con las instrucciones?
•¿Funcionó correctamente cada función del programa?
•¿Requisitos del usuario y trabajado de acuerdo con el diseño del usuario?