Es todo lo que deberíamos haber hecho a nivel técnico para que el

producto sea de calidad y potencialmente entregable en producción.

Es todo lo que debemos hacer para que el desarrollo no tenga bugs. Debe ser potencialente entregable

Son todas las funciones deprecadas que deben ser reemplazadas en el proximo desarrollo. No afecta el paso a produccion

Es todo lo pendiente del sprint que queda para el proximo. Lo prioriza el equipo de desarrollo

Acumular un buen numero y hacer un sprint de solo deuda técnica

Pagarla lo antes posible en base a su impacto

Esperar que el product owner la priorice

Nada, no afecta en nada a la calidad del producto

Funcionalidades no desarrolladas/eliminadas

Bugs detectados

Rigidez para actualizar a nuevas tecnologías o plataformas

Funcionalidades no terminadas

Clases, métodos, archivos, pieza de código que no hace muchas cosas, con pocas líneas de código, que probablemente se podría eliminar e incorporar en otro lado.

Clases, métodos, archivos, demasiado grandes con gran cantidad de líneas de código

Cambios escopeta: cuando se cambia una clase, un método, funciones o variables se produce una cascada de cambios a otras clases, métodos, funciones o variables.

Redundancia en los nombres de los métodos

Reescribir todo el código desde cero

Eliminar por completo el código existente

Añadir nuevas funcionalidades al código

Modificar el código sin cambiar su funcionamiento

Crear un código más claro y sencillo

Agregar complejidad al código existente

No cambiar nada en el código original

Eliminar todas las funciones del código

Para garantizar que el código original se mantenga intacto

Para evitar introducir errores de código al modificar partes del mismo

Para añadir nuevas funcionalidades de forma segura

Para acelerar el proceso de desarrollo del programa

Limpieza del código y mejor comprensión

Eliminar todas las funciones existentes

Agregar más líneas de código innecesarias

Complicar la lectura del programa

Cuando un código se repite en distintas partes del programa y debe unificarse

Cuando un código tiene errores de sintaxis

Cuando un código es demasiado corto y necesita ser alargado

Cuando un código es muy largo y difícil de entender

Dificulta la comprensión del código al realizar distintas tareas

Es más eficiente tener métodos largos que cortos

Facilita la reutilización del código al ser más extenso

No representa ningún problema en el código

Asegurar la apropiada navegación dentro del sistema, ingreso de datos, procesamiento y recuperación.

Detectar los errores en realeases tempranos y de manera fácil.

En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante el debugging, mantenimiento o desarrollo de la nueva versión del sistema buscando efectos adversos en otras partes.

Ninguna de las Anteriores

Prueba funcionalidad

Prueba de Usabilidad

Prueba de Performance

Todas las anteriores

FALSO

VERDADERO

Prueba de Seguridad y Controles

Pruebas del Sistema

Prueba de Regresión

Pruebas de Integración

verificación de requerimientos del sistema

la aceptación o rechazo del sistema desarrollado

verificación de todos los elementos de calidad del sistema

la instalación dentro de un ambiente de producción

validar un número de características al mismo tiempo, a diferencia de otras pruebas que sólo se centran en uno o dos aspectos

Verificar que el sistema funciona apropiadamente y sin errores, bajo saturación

Validar el tiempo de respuesta para las transacciones o funciones de negocios

Verificar el tiempo de respuesta del sistema para transacciones o casos de uso de negocios, bajo diferentes condiciones de carga

VERDADERO

FALSO

Serie de actividades con el propósito de encontrar fallas de implementan de un programa

Serie de actividades que determinan si un programa es funcional

Serie de actividades que determinan las fechas en que se debe entregar el software

Ninguna de las anteriores

Detectar defectos en el software

Identificar cuales son los elementos para que el cliente interactue

identificar y asegurar que los defectos encontrados sean corregidos antes de la entrega al cliente.

Ninguna de las anteriores

La prueba puede ser usada para mostrar presencia de errores

Verificación de cada linea de código inestable

Decidir cuando debe parar el proceso de prueba

Ninguna de las anteriores

4

3

2

5

Diseño, codificación, ejecución, análisis

Diseño, decodificación, ejecución, análisis

Elaboración, decodificación, ejecución, análisis

Ninguna de las anteriores

Pruebas de humo, Pruebas de integración, Pruebas de regresión

Ninguna es correcta

Pruebas unitarias, Pruebas de interfaz, Pruebas de regresión

El negocio, La funcionalidad y La usabilidad

El negocio, La funcionalidad y La usabilidad

Completitud funcional, Corrección funcional y Pertenencia funcional

Recuperación o vuelta atrás, Referentes a la Instalación y Pruebas Estructurales

Ejercitar profundamente el sistema comprobando su integración

Comprobar que un método concreto del código de producción funciona correctamente

Comprobar la características críticas para el negocio

Nos permite poder probar o depurar un módulo

Ayudan a entender mejor el código

La vida del desarrollador sea mucho más fácil

las pruebas fomentan el cambio y la te factorización

Todas las anteriores

Verdadero

Falso