(Ex-01) Examen Obligatorio - Aseguramiento de Calidad (Mar2018)

11/5/2018 [EX-01] Examen Obligatorio: ASEGURAMIENTO DE CALIDAD (MAR2018)
[EX-01] Examen Obligatorio

Fecha límite 12 mayo en 17:00 Puntos 100 Preguntas 20
Disponible 7 mayo en 0:00-12 mayo en 17:00 6 días Tiempo límite 45 minutos
Intentos permitidos 2
Instrucciones
Te invitamos a desarrollar el Examen, aplicando los contenidos centrales aprendidos durante los 4 módulos de
esta asignatura.
IMPORTANTE
Tienes 1 solo intento para realizar el Examen*, en un tiempo de 45 minutos.
* Para acceder al Examen, deberás ingresar un código de acceso, el cual será otorgado por el
Examinador.
Para ello, deberás:
1. Hacer clic en “Realizar la evaluación”.

2. Ingresar código de acceso.
3. Leer atentamente cada enunciado y seleccionar la respuesta correcta.
Ten en cuenta que:
Los resultados estarán disponibles una vez que cierre el período de plazo para rendir el examen.
La calificación de esta evaluación corresponde al 40% de la nota final de la asignatura.
Volver a realizar la evaluación
Historial de intentos
Intento Tiempo Puntaje
ÚLTIMO Intento 1 23 minutos 55 de 100
 Las respuestas correctas estarán disponibles el 13 mayo en 0:00.
Calificación para este intento: 55 de 100
https://ipp.instructure.com/courses/914/quizzes/8369 1/13
Presentado 10 mayo en 19:37

Este intento tuvo una duración de 23 minutos.
Pregunta 1 5 / 5 ptos.
Una de las definiciones de SQA (Aseguramiento de la Calidad de

Software), es:
Control de Calidad del Software
Una etapa del Control de Calidad del Software
Una etapa del ciclo de vida del producto
Una equivalencia al término “Testing” o “Pruebas”
Que está presente en todo el ciclo de vida del producto para garantizar la
satisfacción del cliente
Correcto, el Control de Calidad es una actividad de SQA. EL SQA está

presente en todo el ciclo de vida del producto (no es solo Testing o
Pruebas) para garantizar la satisfacción del cliente y su respectiva
aceptación del producto.
Uno de los principios que guían el SQA, es que:
Se debe utilizar exclusivamente en la última etapa del desarrollo de software,

para verificar el cumplimiento de los requisitos
Se alcanza con la contribución exclusiva del Gerente del proyecto
Se deben dirigir los esfuerzos exclusivamente a detectar los defectos y

corregirlos, sobre todo en las etapas finales del ciclo de vida del desarrollo
de software
La calidad del proyecto está al mismo nivel de importancia, que los plazos de
entrega, los costos y la productividad
Correcto, la importancia de la calidad del proyecto está al mismo nivel de

importancia que los plazos de entrega, costos y productividad. Se aplica
a todas las etapas del desarrollo de software y debe incorporar todos los
esfuerzos para detección de defectos en las primeras etapas.
Es una estrategia que se debe aplicar para mejorar el Testing o Pruebas del
software
Incorrecto Pregunta 3 0 / 5 ptos.
El concepto que usamos para referirnos a la acción, en que se

comprueba que el sistema cumple con los requisitos del cliente en la
finalización del ciclo de vida del desarrollo, se denomina:
Validación
Verificación
Pruebas Unitarias
Pruebas de Testing
El cliente no valida la construcción del software
De acuerdo al modelo de McCall, los factores de la calidad del software,

son:
operativo – de mantenimiento - evolutivo
Correcto, para el modelo McCall los factores de la calidad del software

están compuestos por las perspectivas operativa, de mantenimiento y
evolutiva. Es el modelo aceptado por la ISO.
operativo – fiabilidad – seguridad
fiabilidad – seguridad - evolutiva
flexibilidad – fiabilidad - mantenimiento
mantenimiento - seguridad
El siguiente es un Artefactos del proceso de SQA:
Datos de Prueba
Correcto, los Datos de Prueba son un artefacto que se genera en la

etapa de construcción del proceso de SQA
El Diseño Detallado del producto
El Plan de Desarrollo del Software
La Especificación de Requerimientos
El código de desarrollo
Un tester argumenta que cualquiera de las técnicas de prueba que

existen pueden ser usadas en pruebas de Integración y pruebas
unitarias. Al respecto podemos decir que:
Está equivocado, porque no existen pruebas de Stress unitarias
Está equivocado porque las Pruebas de Integración solo usan técnicas de

rendimiento
Tiene razón, porque las pruebas unitarias e integrales son técnicas de

prueba
Tiene razón, porque las pruebas unitarias e integrales son etapas de prueba
en que puedo usar diversas técnicas
Correcto, las técnicas de prueba que hemos visto tales como pruebas
exploratorias, función, riesgo, stress, etc., son todas técnicas que se
pueden usar tanto en la ETAPA de pruebas unitarias como de pruebas
integrales.
Está equivocado porque es un Tester, y solo el analista de Testing sabe de

estos temas
¿Cuál de los siguientes ejemplos corresponde a una prueba de Stress?
Inyectar 100.000 de transacciones simultáneas
Cortar la luz en el Data Center
Simular falla de un disco duro en el Servidor
Simular conectividad de 8 usuarios a la vez
Ingresar a través de portal web de la aplicación
Una ventaja de las pruebas de Caja Blanca, es:
Las pruebas de Caja Blanca no tienen ventajas
Se requiere conocimientos de programación y de las herramientas usadas

para programar
Las puede hacer un usuario
Se pueden hacer en todos los sistemas siempre que sean transaccionales
Se evita errores por construcción de los programas
Los tipos de prueba de la Ingeniería del Software, son:
Pruebas Unitarias, Pruebas Integrales, Pruebas de Usuario
Pruebas de Caja Blanca
Pruebas de Caja Blanca, Pruebas de Caja Negra y Pruebas de Caja Gris
Pruebas de Caja Negra
Pruebas de Caja Gris
Para definir el Alcance de la Prueba utilizamos como entrada:
El documento de Requerimientos del Sistema
Correcto, ya que la prueba debe asegurar que se cubrirá el alcance del

sistema y este se describe en dicho documento.
El documento de Diseño del Sistema
El documento de Análisis del Sistema
El documento de Plan de Desarrollo
La carta Gantt del Desarrollo del Sistema
¿Cuándo es necesario variar la configuración de una prueba?
Para saber cuál es la configuración correcta
Para poder repetir la prueba en las condiciones señaladas en la pre

condición
Para saber si cuando la configuración es modificada, se soluciona el defecto
No se debe modificar la configuración de una prueba
Para corregir el ambiente de pruebas
Para efectos de realizar una prueba se entrega al Tester un Script de

prueba. ¿Puede el Tester evitar hacer alguno de los pasos descritos en
la prueba?
Sí, cuando descubre que no hay fallas en el software
Sí, porque si tiene experiencia en la aplicación puede saltarse pasos
No, porque si detecta defectos, no será posible reproducirlos
No, porque los pasos del script son obligatorios
No, porque no funcionarían los datos de prueba seleccionados
Las métricas permiten a las organizaciones:
Despedir a los empleados malos
Mejorar el proceso y el producto continuamente
Correcto, lo anterior se logra ya que a través de las métricas puedo

obtener conocimiento cuantitativo de las características del proceso y del
producto, valorando las fallas de modo cuantitativo.
Saber qué productos se deben eliminar
Saber qué está clasificado como rojo, verde o amarillo
Detectar a los responsables de las fallas
En el informe de resultado de las pruebas, la evaluación de si los

criterios de aprobación de prueba se cumplen o no, se coloca en:
Las conclusiones del informe
La descripción del Alcance de las pruebas
Junto al detalle de defectos detectados
Junto al resumen de las pruebas
Este dato no se incluye en el informe de resultado de pruebas
El tester de una prueba, detecta que la aplicación emite mensajes en

inglés cuando se ingresan datos incorrectos. De acuerdo a la
clasificación de Juran, este es un defecto:
Grave
Serio
Bloqueante
Mayor
Menor
En las metodologías tradicionales, los grupos de trabajo son en

general:
No hay una característica especial de los grupos de trabajo en metodologías

tradicionales
Grupos pequeños en que el jefe de proyecto también programa
Grupos grandes y distribuidos, incluso en diferentes zonas geográficas
Son formados solo por gente especializada en las herramientas que se

utilizarán en el desarrollo
Formados por personas de la empresa en que se desarrollará el software
Uno de los principios del Manifiesto Ágil de Testing, es:
Romper el Sistema sobre Construir el Mejor Sistema
Testing durante sobre testing al final
Correcto. Se refiere a la necesidad de hacer el testing como parte del

desarrollo y no al final, como lo señalan las metodologías clásicas.
Solo el tester es el responsable de la calidad del software
Verificar la funcionalidad sobre Validar la funcionalidad
Pruebas del cliente sobre pruebas del Tester
¿Por qué hacer solo pruebas funcionales manuales es deficiente y

puede resultar en la obtención de un desarrollo de baja calidad?
Porque frecuentemente se contrata testers sin experiencia y estos se

equivocan con frecuencia
Porque se requiere que los testers tengan un nivel de experiencia que es

difícil de encontrar
Porque las pruebas funcionales se hacen después del desarrollo y los

errores no se pueden corregir
Porque el alcance y valor agregado de ese tipo de prueba es limitado pues

sólo incluye interfaces de usuario
Correcto. Las pruebas funcionales manuales no permiten, por ejemplo, la

detección de errores con respecto a perfomance o en procesos masivos.
Por su alto costo se suele limitar al alcance, luego no se prueba todo.
Porque estas pruebas siempre son pruebas unitarias que son difíciles de
hacer
¿Por qué es particularmente crítico que el tester ágil tenga excelentes

habilidades de comunicación?
Porque es el tester el que entrega el desarrollo al cliente
Porque el tester se comunicar solo con el cliente
Porque el tester debe sugerir mejoras al producto de software
Porque es el encargado de definir los requerimientos con el cliente
Porque existe mucha interacción con los miembros del equipo
Correcto. En los contextos ágiles, el equipo completo es responsable del

desarrollo y su calidad. Por tanto, el trabajo en equipo es vital así como
la comunicación entre todos los miembros del equipo.
Algunas de las cosas que se hacen para “refactorizar” un código son:
Hacer el código más fácil de entender y modificar
Correcto. La idea es que el código sea fácil de mantener por cualquier

técnico.
Definir claramente las principales funciones y variables
Probar al menos tres veces el código del programa
Que otra persona revise el programa una vez que el desarrollador lo terminó
Guardar la versión del código, una vez que este ha funcionado
Calificación de la evaluación: 55 de 100

(Ex-01) Examen Obligatorio - Aseguramiento de Calidad (Mar2018)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

(Ex-01) Examen Obligatorio - Aseguramiento de Calidad (Mar2018)

Încărcat de

Drepturi de autor:

Formate disponibile

11/5/2018 [EX-01] Examen Obligatorio: ASEGURAMIENTO DE CALIDAD (MAR2018)

[EX-01] Examen Obligatorio

Tienes 1 solo intento para realizar el Examen*, en un tiempo de 45 minutos.

Para ello, deberás:

1. Hacer clic en “Realizar la evaluación”.

Ten en cuenta que:

Volver a realizar la evaluación

 Las respuestas correctas estarán disponibles el 13 mayo en 0:00.

Calificación para este intento: 55 de 100

Presentado 10 mayo en 19:37

Una de las definiciones de SQA (Aseguramiento de la Calidad de

Control de Calidad del Software

Una etapa del Control de Calidad del Software

Una etapa del ciclo de vida del producto

Una equivalencia al término “Testing” o “Pruebas”

Correcto, el Control de Calidad es una actividad de SQA. EL SQA está

Uno de los principios que guían el SQA, es que:

Se debe utilizar exclusivamente en la última etapa del desarrollo de software,

Se alcanza con la contribución exclusiva del Gerente del proyecto

Se deben dirigir los esfuerzos exclusivamente a detectar los defectos y

Correcto, la importancia de la calidad del proyecto está al mismo nivel de

Incorrecto Pregunta 3 0 / 5 ptos.

El concepto que usamos para referirnos a la acción, en que se

El cliente no valida la construcción del software

De acuerdo al modelo de McCall, los factores de la calidad del software,

operativo – de mantenimiento - evolutivo

Correcto, para el modelo McCall los factores de la calidad del software

operativo – fiabilidad – seguridad

fiabilidad – seguridad - evolutiva

flexibilidad – fiabilidad - mantenimiento

El siguiente es un Artefactos del proceso de SQA:

Correcto, los Datos de Prueba son un artefacto que se genera en la

El Diseño Detallado del producto

El Plan de Desarrollo del Software

Un tester argumenta que cualquiera de las técnicas de prueba que

Está equivocado, porque no existen pruebas de Stress unitarias

Está equivocado porque las Pruebas de Integración solo usan técnicas de

Tiene razón, porque las pruebas unitarias e integrales son técnicas de

Está equivocado porque es un Tester, y solo el analista de Testing sabe de

Incorrecto Pregunta 7 0 / 5 ptos.

¿Cuál de los siguientes ejemplos corresponde a una prueba de Stress?

Inyectar 100.000 de transacciones simultáneas

Cortar la luz en el Data Center

Simular falla de un disco duro en el Servidor

Simular conectividad de 8 usuarios a la vez

Ingresar a través de portal web de la aplicación

Incorrecto Pregunta 8 0 / 5 ptos.

Una ventaja de las pruebas de Caja Blanca, es:

Las pruebas de Caja Blanca no tienen ventajas

Se requiere conocimientos de programación y de las herramientas usadas

Las puede hacer un usuario

Se pueden hacer en todos los sistemas siempre que sean transaccionales

Se evita errores por construcción de los programas

Incorrecto Pregunta 9 0 / 5 ptos.

Los tipos de prueba de la Ingeniería del Software, son:

Pruebas Unitarias, Pruebas Integrales, Pruebas de Usuario

Pruebas de Caja Blanca

Pruebas de Caja Blanca, Pruebas de Caja Negra y Pruebas de Caja Gris

Pruebas de Caja Negra

Pruebas de Caja Gris

Para definir el Alcance de la Prueba utilizamos como entrada:

El documento de Requerimientos del Sistema

Correcto, ya que la prueba debe asegurar que se cubrirá el alcance del