Universidad Abierta Para Adultos
(UAPA)
Nombre:
Edgar juan Simón Álvarez
Matricula:
100066944
Asignatura:
Ingeniería de Software 1
Tema:
Tarea 9
Facilitador@: Loida Charles
Ramírez
I. Investigar en la web acerca de la prueba de software.
Las pruebas de software (en inglés software testing) son las investigaciones empíricas y
técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la
calidad del producto a la parte interesada o stakeholder. Es una actividad más en el
proceso de control de calidad.
Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de
software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas
en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de
desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel
distinto de involucramiento en las actividades de desarrollo.
▪ Objetivos de las pruebas de software:
1. Detectar defectos en el software.
2. Verificar la integración adecuada de los componentes.
3. Verificar que todos los requisitos se han implementado correctamente.
4. Identificar y asegurar que los defectos encontrados se han corregido antes de
entregar el software al cliente.
5. Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases
de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
▪ Principios de las pruebas de software:
Las pruebas se rigen por una serie de principios, una buena comprensión de estos
facilitará el posterior uso de los métodos en un efectivo diseño de casos de prueba. A
continuación, se citan:
1. La prueba puede ser usada para mostrar la presencia de errores, pero nunca su
ausencia.
2. La principal dificultad del proceso de prueba es decidir cuándo parar.
3. Evitar casos de pruebas no planificados, no reusables y triviales a menos que el
programa sea verdaderamente sencillo.
4. Una parte necesaria de un caso de prueba es la definición del resultado esperado.
5. Los casos de pruebas tienen que ser escritos no solo para condiciones de entrada
válidas y esperadas sino también para condiciones no válidas e inesperadas.
6. El número de errores sin descubrir es directamente proporcional al número de
errores descubiertos.
▪ Etapas involucradas en las pruebas de software:
1. Seleccionar qué es lo que debe medir la prueba, es decir, cuál es su objetivo, para
qué exactamente se hace la prueba.
2. Decidir cómo se va a realizar la prueba, es decir, qué clase de prueba se va a
utilizar para medir la calidad y qué clase de elementos de prueba se deben usar.
3. Desarrollar los casos de prueba. Un caso de prueba es un conjunto de datos o
situaciones de prueba que se utilizarán para ejecutar la unidad que se prueba o
para revelar algo sobre el atributo de calidad que se está midiendo.
4. Determinar cuáles deberían ser los resultados esperados de los casos de prueba
y crear el documento que los contenga.
5. Ejecutar los casos de prueba.
▪ Tipos de pruebas de software:
Todos los tipos de pruebas de software que existen, básicamente, se pueden agrupar en
dos grupos: las pruebas funcionales y las pruebas no funcionales.
Dentro de las pruebas funcionales tenemos:
1. Pruebas unitarias.
2. Pruebas de aceptación.
3. Pruebas de integración.
4. Pruebas de regresión.
Las pruebas no funcionales son:
1. Pruebas de carga.
2. Pruebas de estrés.
3. Pruebas de escalabilidad.
4. Pruebas de portabilidad.
Tal vez hayas oído hablar de las pruebas de caja blanca y las pruebas de caja negra,
pero lo que ocurre con las mismas es que no son tipos de pruebas, sino técnicas de
pruebas de software.
▪ Tipos de pruebas por su ejecución:
1. Pruebas manuales: son llevadas a cabo por personas, quienes navegan e
interactúan con el software (usando herramientas adecuadas para cada caso).
2. Pruebas automáticas: por el contrario, son realizadas por máquinas, que
ejecutan un "test script" que ya ha sido escrito previamente.
▪ Alcance de pruebas de software:
La prueba de software tiene limitantes, tanto teóricos como prácticos. Desde el
punto de vista teórico, la prueba es un problema que llamamos no-decidible; esto
implica, grosso modo, que no podemos escribir un programa que pruebe los
programas sin intervención humana. Sin embargo, como mencionábamos
anteriormente, la prueba sí es automatizable en muchos aspectos.
Desde el punto de vista práctico, la cantidad de posibilidades para probar
exhaustivamente un sistema es sencillamente inmanejable; es necesario entonces
utilizar técnicas adecuadas para maximizar la cantidad de fallas importantes
encontradas con los recursos asignados. Cada método que se utilice para detectar
defectos deja un residuo de defectos más sutiles contra los cuales ese método es
ineficaz (la llamada “Paradoja del Pesticida”).
La prueba de software implica pues, la aplicación de técnicas y herramientas
apropiadas en el marco de un proceso bien definido, determinado por el tipo de
proyectos de desarrollo de software que se abordan. En el siguiente número
veremos con mayor detalle las principales técnicas de prueba de software.
▪ Herramientas de testing de software:
Para poder realizar todas estas pruebas, tenemos multitud de herramientas que
pueden hacer nuestro trabajo mucho más sencillo.
Por ejemplo, una herramienta de gestión de casos de prueba, dónde queden
grabadas todas las pruebas que estamos realizando o todas las pruebas que
deberemos de ejecutar en una regresión.
Otros ejemplos serían:
1. JMeter: una herramienta para intentar realizar nuestras pruebas de
rendimiento.
2. Selenium: para hacer nuestras pruebas automatizadas.
3. JUnit 5: para nuestras pruebas unitarias.
4. TestNG: como ejecutor de las pruebas de Selenium.
II. Elaborar una prueba de caja negra para el siguiente caso:
Al momento de hacer una cotización debe enviar un correo al departamento de venta, si el monto está en el rango de 10,000 a 20,000
pesos el correo debe de enviarse tanto a venta como a gestión de operaciones. Si la cotización pasa de los 10 días sin completar la 20,
enviar notificación al servicio al cliente para que realice una llamada.
III. ¿Porque entiende usted que debemos elaborar pruebas al software?
Porque las pruebas de software son las que garantizan que el programa funcione de manera
eficiente. Estas pruebas son muy necesarias antes de poner a trabajar el programa en todo
su esplendor, esto porque permite detectar posibles errores y corregirlos antes de que el
programa entre en funcionamiento en la empresa o entidad que lo va a utilizar como destino
final.
Las pruebas de software se deben hacer a las partes que componen el programa según se
van desarrollando, la ventaja de esa forma es que el programa se visualiza como un conjunto
de partes y puede ser analizado con más facilidad.
IV. Elabore una síntesis sobre la planificación de pruebas de software:
Un plan de prueba se elabora para atender los objetivos de calidad en un desarrollo de sistemas,
encargándose de definir aspectos como por ejemplo los módulos o funcionalidades sujeto de
verificación, tipos de pruebas, entornos, recursos asignados, entre otras cosas.
Para elaborar una planificación de pruebas de software lo primero que debemos hacer es
entender los requerimientos de usuario que son los que componen la iteración o proyecto, que
son el sujeto de la verificación de calidad que se va a realizar. Se debe analizar la información de
ingeniería de requisitos, como, la matriz de trazabilidad, especificaciones y diseño funcional,
también los requisitos no funcionales los casos de uso, historias de usuario. Otro punto son las
realizaciones de entrevistas a con el equipo encargado de la ingeniería de requisitos para aclarar
cualquier duda y ampliar información que sea necesaria.
▪ Es importante hacer las siguientes preguntas:
¿Es un sistema nuevo o existente?
¿Cuáles funcionalidades existentes están siendo modificadas?
¿Cuáles son los requisitos no funcionales?
Lo segundo que debemos hacer es que partiendo de la documentación del análisis de requisitos
y las entrevistas, se debe identificar e incluir en el plan de pruebas de software la lista de las
funcionalidades (Características) totalmente nuevas. Si es un sistema nuevo no habrá problemas.
En el caso de que estemos trabajando con un sistema ya existente es necesario revisar con los
analistas de negocio y también con los arquitectos de software las funcionalidades que forman
parte del desarrollo de software, en todas las capas de la arquitectura.
El tercer paso que debemos hacer es identificar las funcionalidades existentes que estén siendo
impactadas por el desarrollo de alguna forma. Se deben considerar todos los componentes
afectados en todas las capas de la arquitectura de software.
Al identificar estas funcionalidades podemos encontrarnos con dos situaciones:
▪ Funcionalidades modificadas de cara al usuario:
Una funcionalidad que este siendo modificada agregando más pantallas o cambios a su flujo de
proceso, debe ser incluida en el plan de pruebas de software.
▪ Funcionalidades modificadas en sus componentes internos:
Son funcionalidades que no son modificadas de cara al usuario, se mantiene la misma interfaz
gráfica y el mismo flujo de proceso. Sin embargo, se modifican componentes internos que
comparten con otras funcionalidades del sistema, en las capas de lógica de negocios o acceso a
datos. Estas también deben incluirse en el plan de pruebas de software para determinar a partir
de ellas pruebas de regresión a realizar. Los que pueden suministrar la información serán
personas familiarizadas con el sistema y los Analistas de negocio o Arquitectos de software.
Avanzamos con el pazo cuatro, aquí se definen las estrategias de pruebas a implementar, para
esto es recomendable seguir un marco de referencia para determinar los tipos de prueba, como
por ejemplo (Tipos de pruebas de software definidos por el ISTQB)
▪ La prueba funcional:
En esta se determinan los conjuntos de pruebas a realizar, correspondiente con cada
funcionalidad nueva o existente que se esté modificando. Un ejemplo serio, las pruebas de
sistema (o pruebas integradas de sistemas) que se desarrollan después de que el equipo ha
integrado los componentes de distintas capas.
Dentro de las pruebas funcionales también están las pruebas de aceptación, consiste en que el
equipo de calidad e inclusive personas del área de negocio o cliente del proyecto verifican el
funcionamiento del sistema o funcionalidad.
▪ Pruebas no funcionales:
Aquí se pueden incluir pruebas sobre el desempeño, tiempo de respuesta, mantenibilidad,
Pruebas de seguridad de software, entre otros aspectos.
Pruebas de caja blanca
Según la estructura y arquitectura del software que se esté desarrollando.
Pruebas de regresión
Se definen sobre las funcionalidades modificadas en sus componentes internos.
EL paso número cinco debemos definir los criterios de inicio, aceptación y suspensión
de pruebas:
▪ Criterios de aceptación o rechazo:
Para definir los criterios de aceptación o rechazo, es necesario definir el nivel de tolerancia a fallos
de calidad. Lograr este margen en todos los casos de prueba principales y casos bordes será
muy difícil, y podría comprometer los plazos del proyecto, pero asegura la calidad del producto.
Una vez logradas las condiciones, se dará por aceptadas las pruebas y el desarrollo de software.
▪ Criterios de inicio o reanudación:
Definen las condiciones que deben cumplirse para dar inicio o reanudar las pruebas. Para el caso
de la reanudación las condiciones están relacionadas, se determina a partir de cuales criterios de
suspensión se presentaron para detener las pruebas.
▪
Criterios de suspensión:
Las condiciones van a depender de los acuerdos de nivel de servicio (SLAs) internos de la
organización y también de los acuerdos establecidos en cada proyecto individual. Ejemplo. Si se
tiene un equipo de pruebas que comparten su esfuerzo entre varios proyectos, se puede definir
un criterio de suspensión exigente, un determinado porcentaje de casos fallidos que resulten en
incidencias. Si la condición se cumple, se detienen las pruebas y se ocupa en personal a otras
actividades.
De lo contrario si se tiene un personal dedicado para hacer pruebas, se puede hacer un criterio
de suspensión que no sea muy exigente.
▪ Paso 6:
Posteriormente se definen y documentan las características de los entornos de hardware y
software necesarios para realizar la ejecución de las pruebas de software. Como mejor práctica,
el ambiente de pruebas de software debería ser lo más similar posible al entorno de producción,
sin embargo, esto no siempre es posible debido a limitaciones de recursos. Además, en esta
sección del plan de pruebas, También se definen los requisitos de sistema operativos, software y
herramientas de las estaciones de trabajo de los Testers.
Si el alcance del proyecto incluye pruebas de aplicaciones para móviles, será necesario definir
los emuladores y teléfonos inteligentes, con sus respectivos requerimientos.
• Herramienta de gestión de calidad de software
• Herramientas para automatización de pruebas
• Herramientas de BDD, TDD y Testing de web services.
▪
Paso 7:
Determinar necesidades del personal y entrenamiento, se debe completar previamente la
estimación del esfuerzo de pruebas a partir del diseño de casos de prueba. Si todavía no cuentan
con una estimación, se puede comenzar por definir los tipos de perfiles de habilidades y
conocimientos en software Testing que se necesitan. Para esto se puede buscar la respuesta a
las siguientes preguntas.
• Que conocimientos de procesos de negocio se necesitan?
• Que sistemas se están probando y quienes tienen experiencia en su funcionamiento.?
• Se necesitan conocimientos específicos en pruebas de requisitos no funcionales?
▪ Paso 8:
Establecer la metodología y procedimiento de prueba, la metodología de pruebas de software
dependerá de la que se esté utilizando para la gestión del proyecto. Si se está utilizando una
metodología predictiva, las pruebas de software comenzaran con la estimación del esfuerzo de
pruebas, diseño y luego la ejecución de las pruebas
▪ Paso 9:
Elaborar la planificación de las pruebas, la planificación de las pruebas abarca, la matriz de
responsabilidad, puede usarse una matriz RACI o matriz RAM como plantilla. Esta se define con
perfiles genéricos o inclusive con el equipo de trabajo si ya se conoce cuál es el que será
asignado.
Cronograma:
Elaborado a partir de la estimación de las actividades se software Testing realizada por el equipo.
Es importante definir actividades criticas como por ejemplo los tiempos de instalación de
▪
versiones en los entornos de pruebas, pruebas de validación de ambiente antes de comenzar a
hacer las pruebas y las iteraciones por incidencias.
Paso 10:
Identificar los riesgos y definir planes de respuesta, Para identificar los riesgos es necesario
enumerar cada una de estas dependencias y por medio de mesas de trabajo y tormentas de ideas
pensar en las posibilidades de que algo salga mal.
