Ac vidad integradora Unidad I

Metodología de Prueba de Sistemas

2023

Alumna: Sabrina Galassi

Profesor: Federico Carbone
ti

 Ac vidad integradora Unidad I

Con los contenidos vistos en clase más tu experiencia personal, responde las siguientes
preguntas:

1. ¿Por qué podemos decir que el Tes ng o Prueba de Sistemas puede ser considerado un
proyecto dentro de otro más abarca vo, como el Desarrollo de So ware?
2. ¿Cómo relacionarías el análisis de riesgos con el principio de no exhaus vidad de las
pruebas?
3. ¿Por qué los expertos dicen que es un error comenzar un proyecto de tes ng
directamente con las pruebas?
4. Describe brevemente cómo encararías, y qué roles y equipo tendría, el proyecto de
prueba de un so ware en los siguientes escenarios:
a. Empresa de supermercadismo, proyecto grande, con equipo de desarrollo, y
equipo Agile
b. Empresa pequeña, contratada como consultora de desarrollo en un Banco
c. Empresa únicamente de tes ng que es contratada para probar videojuegos
d. Producto propio de ges ón de puntos de venta
5. ¿Cómo describirías la relación que existe entre los casos de prueba, el plan de pruebas,
y la estrategia de pruebas?

1. ¿Por qué podemos decir que el Tes ng o Prueba de Sistemas puede ser considerado un
proyecto dentro de otro más abarca vo, como el Desarrollo de So ware?

Desde mi punto de vista, el Tes ng o Prueba de Sistemas puede considerarse un proyecto

dentro de otro más abarca vo, como el Desarrollo de So ware, debido a varias razones.
En primer lugar, el tes ng implica un conjunto de ac vidades plani cadas y controladas con el
obje vo de evaluar y veri car el funcionamiento de un sistema de so ware. Estas ac vidades
requieren empo, recursos y un enfoque sistemá co para garan zar que el sistema cumpla con
los requisitos y expecta vas establecidos.
Al igual que un proyecto de desarrollo de so ware, el tes ng ene un alcance de nido y metas
especí cas. Se establecen obje vos claros para iden car y solucionar problemas, mejorar la
calidad del so ware y asegurar su correcto funcionamiento. Además, tanto el desarrollo de
so ware como el tes ng requieren la coordinación de recursos ya pueden ser humanos y
técnicos, y deben seguir una metodología adecuada para lograr resultados exitosos.
Considero que el tes ng puede considerarse un proyecto dentro del desarrollo de so ware
debido a su plani cación, sus obje vos especí cos, la necesidad de recursos y la coordinación
requerida. Ambos se complementan mutuamente en el proceso de creación de so ware de

ft
ti
fi

ti

ft

ft
fi
ti
ti
ti
ti
ti

fi
ti

ti
ti

ti
ti
ti
ti
ti
ti
ti

ft
fi

ti

ti
ti
fi
ft
ti
ti

ti
ft
fi
ft
ft
ti
ti

fi
ft

ti
ft

 calidad, donde el tes ng cumple un papel crucial para garan zar la funcionalidad y
con abilidad del sistema desarrollado.

¿Cómo relacionarías el análisis de riesgos con el principio de no exhaus vidad de las

pruebas?
El análisis de riesgos en el tes ng se u liza para iden car y priorizar los posibles problemas
que pueden surgir. Dado que las pruebas exhaus vas son imposibles debido a las limitaciones
de empo y recursos, el análisis de riesgos ayuda a focalizar los esfuerzos de pruebas en las
áreas de mayor riesgo, maximizando así la efec vidad de las pruebas realizadas. Al combinar
estos enfoques, se puede lograr una estrategia de pruebas mas e ciente y efec va,
centrándose en mi gar los riesgos crí cos iden cados. Entonces, la relación entre el análisis
de riesgos y el principio de no exhaus vidad de las pruebas radica en que el análisis de riesgos
se u liza para iden car los riesgos mas crí cos y prioritarios a los que se enfrenta el sistema.
Esto permite que el equipo de pruebas se enfoque en las áreas de mayor riesgo y realice
pruebas más efec vas en esos aspectos clave.

¿Por qué los expertos dicen que es un error comenzar un proyecto de tes ng directamente
con las pruebas?

Comenzar un proyecto de tes ng directamente con las pruebas, sin una plani cación adecuada
y sin comprender los requisitos y el diseño del sistema, es considerado un error por parte de
los expertos. Esta prác ca ene varias consecuencias nega vas. En primer lugar, la falta de
plani cación puede resultar en una falta de dirección y enfoque, lo que afecta la calidad y
e ciencia de las pruebas. Además, al omi r fases importantes como el análisis de requisitos y
el diseño, se corre el riesgo de pasar por alto problemas fundamentales en el sistema, lo que
lleva a pruebas ine caces e incompletas. Además, existe un mayor riesgo de errores no
detectados, ya que se introducen problemas en el so ware sin una revisión adecuada. Por
úl mo, si se detectan problemas durante las pruebas sin una comprensión del sistema, se
di culta que su resolución sea e ciente, lo que puede resultar en retrasos y esfuerzos
adicionales. Por úl mo comenzar un proyecto de tes ng sin plani cación, comprensión de
requisitos y diseño es un error. Conlleva falta de dirección, pruebas ine caces, errores no
detectados y di cultad en su resolución, por lo cual se recomienda un enfoque sistemá co que
incluya plani cación y comprensión del sistema antes de iniciar las pruebas.

Describe brevemente cómo encararías, y qué roles y equipo tendría, el proyecto de prueba
de un so ware en los siguientes escenarios:
a. Empresa de supermercadismo, proyecto grande, con equipo de desarrollo, y
equipo Agile

• Plani cación: Iniciaría de niendo los obje vos, requisitos y plazos del proyecto de prueba.
Colaboraría estrechamente con el equipo de desarrollo para comprender el alcance del
so ware. Con base en esta información, elaboraría un plan de pruebas que incluya los
diferentes pos de pruebas a realizar
fi
fi
ti
ft
ti
fi
ti
fi
fi
ft

ti
fi
fi

ti
ti
ti
ti
fi
fi
ti

ti
fi
ti
ti
ti
fi

ti
ti
ti

ti
ti
ti

ti
ti
fi
ti
ti
ti
ft
fi
ti
ti
fi
fi
fi
ti
ti

fi
ti
ti
 • Roles: Formaría un equipo de pruebas como un Líder de Pruebas, que sería quien
supervisa todo el proceso de prueba. Analistas de Pruebas que se encargarían de ejecutar
las pruebas y reportar los resultados. Desarrolladores, el equipo de desarrollo sería
responsable de solucionar los problemas iden cados durante las pruebas y de
implementar los cambios necesarios en el so ware. Tendía en el equipo un Product
Owner quién sería el responsable de de nir los requisitos y prioridades del proyecto.
Trabajaría en colaboración con el equipo de pruebas y el equipo de desarrollo para
asegurar que las expecta vas se cumplan. Cada miembro del equipo trabajaría en
colaboración con el equipo de desarrollo.
• Metodología Agiles: U lizaría metodologías ágiles, como Scrum, para ges onar el proyecto
de prueba. Organizaría el trabajo en iteraciones o sprints, establecería reuniones regulares
de seguimiento y coordinación con el equipo de desarrollo. Trabajaría en estrecha
colaboración con el equipo de desarrollo, par cipando en las reuniones diarias de
seguimiento, revisiones. Considero que la comunicación constante entre el equipo de
pruebas, el equipo de desarrollo y el Product Owner sería fundamental.
• Pruebas Con nuas: Implementaría prác cas de pruebas con nuas, lo que signi ca realizar
pruebas de forma regular y frecuente a medida que se desarrolla el so ware.
• Ges ón de incidencias: Implementaría un proceso para ges onar incidencias durante las
pruebas, u lizando una herramienta de seguimiento. Trabajaría en colaboración con el
equipo de desarrollo para registrar, priorizar y resolver los problemas iden cados.

b. Empresa pequeña, contratada como consultora de desarrollo en un Banco.

• Análisis de Requisitos: Comenzaría por comprender los requisitos especí cos del so ware
y las expecta vas del Banco. Hablaría con los representantes del Banco para comprender
los requisitos del proyecto y los plazos establecidos. Les consultaría cuáles son los
términos de funcionalidad, seguridad y los entrañables esperados.
• Roles: Formaría un equipo con un líder de pruebas, quien sería el encargado de coordinar
el proceso de pruebas y también de ejecutarlas, además sería el encargado de coordinar el
equipo de desarrollo. Un encargado de ciberseguridad, este se encargaría de garan zar
que se implementen las mejores prác cas de seguridad en el so ware desarrollado y de
proteger los datos con denciales del banco y de sus clientes. Un equipo de
desarrolladores, los cuales serían el equipo encargado de desarrollar y entregar el so ware
solicitado por el banco. Trabajaría en colaboración con el equipo de pruebas y el encargado
de ciberseguridad para solucionar los problemas iden cados y realizar las mejoras
necesarias.
• Diseño de Pruebas: Trabajaría en la plani cación detallada de las pruebas, incluyendo la
de nición de casos de prueba, estrategias de prueba. Diseñaría un enfoque adecuado para
evaluar la seguridad del so ware, considerando las regulaciones y estándares aplicables en
el sector bancario. Par ciparía en reuniones regulares con el Banco y revisiones conjuntas
para garan zar la calidad y la conformidad con los estándares establecidos.
• Pruebas de Rendimiento y Seguridad: Realizaría pruebas exhaus vas de rendimiento y
seguridad para cumplir con los estándares del banco. Esto involucraría pruebas de carga,
estrés y vulnerabilidad.
fi
ti
ti
ti

ti
ti
ti
ti
fi

ti
ft
ti
ti
fi
fi

ft
ti
ti
fi
ti
fi
ti
ti
ft
ti

ft
fi

ti
ti

fi

fi
ti

ft
ft
 • Documentación : Registraría y documentaría los resultados de las pruebas, incluyendo
errores, mejoras y evidencia de cumplimiento. Esto serviría como base para auditorías y
revisiones futuras.

c. Empresa únicamente de tes ng que es contratada para probar videojuegos

• Análisis de Requisitos: Trabajaría con el cliente para comprender los requisitos del
videojuego, incluyendo funcionalidad, jugabilidad, grá cos, sonido y el obje vo del juego.
• Roles: Formaría un equipo de pruebas especializado en pruebas de videojuegos. Este
equipo podría incluir roles como un líder de pruebas de videojuegos, que sería el
encargado de coordinar todo el proceso de pruebas, testers especializados en pruebas de
videojuegos. Serían responsables de ejecutar las pruebas según el plan establecido,
iden car y reportar problemas, y veri car que el videojuego cumpla con los requisitos de
jugabilidad, grá cos y sonido.
• Diseño de Pruebas: Realizaría una plani cación detallada de las pruebas, incluyendo la
de nición de casos de prueba, escenarios de juego y pruebas de rendimiento,
compa bilidad y usabilidad.
• Ejecución de Pruebas: Registraría y documentaría los resultados de las pruebas, incluyendo
errores, mejoras sugeridas y observaciones de la experiencia del usuario.
• Comunicación con el cliente: Mantendría una comunicación uida y con nua con el cliente
para compar r hallazgos, discu r problemas y brindar actualizaciones periódicas sobre el
progreso de las pruebas.
• Casos de Prueba: Realizaría documentos que detallan los escenarios especí cos que se
probarán en el videojuego, incluyendo los pasos a seguir, los datos de entrada y los
resultados esperados.

d. Producto propio de ges ón de puntos de venta.

• Análisis de Requisitos: Trabajaría para comprender los requisitos del so ware de ges ón
de puntos dado a las ventas, incluyendo la integraciones con otros sistemas, haciendo
hincapié en la seguridad.
• Equipo de Pruebas : Formaría un equipo con un líder de Técnico, Analistas y Especialistas
en Pruebas de Seguridad. En endo que el tamaño del equipo dependería del alcance y la
complejidad de implementar el proyecto.
• Diseño de Pruebas: Realizaría una plani cación detallada de las pruebas, incluyendo la
de nición de casos de prueba y pruebas de seguridad. Diseñaría estrategias de pruebas
que aborden los puntos crí cos de la ges ón de puntos.
• Ejecución de Pruebas: Registraría y documentaría los resultados de las pruebas, incluyendo
errores. Realizaría pruebas de rendimiento para evaluar la capacidad del so ware de
ges onar un alto volumen de transacciones en entornos de punto de venta. Esto incluiría
pruebas de carga y estrés para garan zar un rendimiento óp mo.
• Documentación: Registraría y documentaría los resultados de las pruebas, incluyendo
errores encontrados, mejoras sugeridas y evidencia de cumplimiento de los requisitos.
fi
fi
ti
ti
fi
ti
ti
fi

ti

ti

ti
ti

ti
ti
fi
fi
fi
ti

fi

ti
fl

ti
ft

fi
ft
ti

ti

 ¿Cómo describirías la relación que existe entre los casos de prueba, el plan de pruebas, y la
estrategia de pruebas?
Los casos de prueba, el plan de pruebas y la estrategia de pruebas están estrechamente
relacionados en el proceso de pruebas de so ware. Los casos de prueba representan
escenarios especí cos que se ejecutan para veri car el comportamiento del so ware. El plan
de pruebas describe la estrategia general para llevar a cabo las pruebas, incluyendo los
obje vos, alcance, recursos y enfoques u lizados. Mientras tanto, la estrategia de pruebas es
un enfoque más amplio que abarca la plani cación, diseño y ejecución de las pruebas,
de niendo los métodos y técnicas u lizadas.
fi
ti
fi

ti
ti
fi
ft

fi
ft