Software Testing Fundamentals



Reactivos

Pregunta 1

¿Cuál es el principal propósito del software testing?

Opciones:

  1. Minimizar el riesgo de mal funcionamiento del software.
  2. Encontrar todos los errores posibles del software.
  3. Garantizar que el software es 100% libre de errores.
  4. Hacer que el software sea más rápido y eficiente.

Pregunta 2

¿Qué indica el principio de la paradoja del pesticida en el software testing?

Opciones:

  1. Las pruebas deben realizarse solo al final del desarrollo.
  2. Utilizar las mismas pruebas repetidamente no descubrirá nuevos errores.
  3. Las pruebas de software no son necesarias para proyectos pequeños.
  4. Los errores en el software son inevitables y no pueden ser resueltos.

Pregunta 3

¿Cuál de estos es un tipo de prueba de software?

Opciones:

  1. Prueba de hardware.
  2. Prueba de usuario.
  3. Prueba de compatibilidad.
  4. Prueba de diseño gráfico.

Pregunta 4

¿Cómo debería un tester abordar un error encontrado en una aplicación que no se reproduce consistentemente?

Opciones:

  1. Cambiar el enfoque a otros errores más consistentes.
  2. Informar el error solo si se reproduce en más del 50% de los intentos.
  3. Ignorar el error ya que no es constante.
  4. Documentar el error y los pasos exactos intentados, aunque sea inconsistente.

Pregunta 5

En una situación donde un software no cumple con un requisito no funcional de rendimiento, ¿cuál sería el siguiente paso adecuado?

Opciones:

  1. Informar a los stakeholders que el requisito es irrealizable.
  2. Cambiar el requisito para que coincida con el rendimiento actual.
  3. Optimizar el código y los recursos para cumplir con el requisito.
  4. Ignorar el requisito, asumiendo que los usuarios no notarán.

Pregunta 6

¿Cuál es el propósito de las pruebas de integración en el desarrollo de software?

Opciones:

  1. Probar la funcionalidad individual de los componentes.
  2. Evaluar cómo interactúan entre sí diferentes módulos o sistemas.
  3. Determinar la eficiencia del código.
  4. Verificar la estabilidad del sistema bajo condiciones extremas.

Pregunta 7

¿Qué caracteriza a las pruebas de aceptación del usuario (UAT)?

Opciones:

  1. Confirmar que el software cumple con las expectativas y necesidades del usuario.
  2. Verificar el cumplimiento de las especificaciones técnicas.
  3. Evaluar el rendimiento del software en condiciones de carga.
  4. Inspeccionar la calidad del código fuente.

Pregunta 8

En el software testing, ¿qué implica una prueba de regresión?

Opciones:

  1. Verificar que los cambios recientes no afecten negativamente las funcionalidades existentes.
  2. Evaluar la eficiencia del código después de una optimización.
  3. Realizar pruebas exhaustivas en cada componente del software.
  4. Probar el software en su totalidad en un entorno de producción.

Pregunta 9

En un proyecto de software, ¿cómo se debería actuar si se detecta que una prueba unitaria falla repetidamente?

Opciones:

  1. Eliminar la prueba unitaria.
  2. Ignorar el fallo, ya que puede ser un problema menor.
  3. Revisar y corregir el código relacionado con la prueba fallida.
  4. Continuar con las pruebas de integración sin resolver el fallo.

Pregunta 10

Si durante las pruebas de integración se encuentra que dos módulos no interactúan correctamente, ¿cuál es la mejor acción a seguir?

Opciones:

  1. Reemplazar uno de los módulos por completo.
  2. Ignorar el problema y continuar con las pruebas de sistema.
  3. Cambiar los requisitos para que los módulos no necesiten interactuar.
  4. Probar los módulos individualmente para identificar la fuente del problema.

Pregunta 11

¿Qué representa un "script de prueba" en comparación con un caso de prueba?

Opciones:

  1. Un conjunto de requerimientos de software.
  2. Una lista de errores conocidos en el software.
  3. Un documento detallado de los pasos de prueba.
  4. Un programa que ejecuta automáticamente las pruebas.

Pregunta 12

¿Qué factor no es típicamente evaluado en un caso de prueba?

Opciones:

  1. Funcionalidad del software.
  2. Estética de la interfaz de usuario.
  3. Seguridad informática.
  4. Integración de módulos.

Pregunta 13

¿Qué se evalúa en las pruebas de rendimiento del software?

Opciones:

  1. La capacidad del software para operar bajo carga.
  2. La exactitud de los cálculos realizados por el software.
  3. La facilidad de instalación y configuración del software.
  4. La coherencia estética de la interfaz de usuario.

Pregunta 14

Si durante las pruebas de integración se descubre que dos módulos no se comunican correctamente, ¿cuál sería el siguiente paso más apropiado?

Opciones:

  1. Cambiar los requerimientos para que los módulos no necesiten interactuar.
  2. Eliminar uno de los módulos problemáticos.
  3. Continuar con otras pruebas ignorando el problema.
  4. Revisar y corregir la interfaz de comunicación entre los módulos.

Pregunta 15

Si durante las pruebas se identifica un error crítico en la seguridad, ¿cuál sería el procedimiento adecuado?

Opciones:

  1. Suspender todas las pruebas hasta que se resuelva el error.
  2. Reportar el error y priorizar su corrección antes de continuar.
  3. Continuar las pruebas asumiendo que el error se solucionará en el futuro.
  4. Cambiar el alcance del proyecto para excluir la funcionalidad afectada.

Pregunta 16

¿Cuál es la diferencia principal entre un error y un defecto en el testing de software?

Opciones:

  1. Un error es una acción humana incorrecta, mientras que un defecto es un problema en el código resultante.
  2. Un error y un defecto son lo mismo.
  3. Un error es un problema en el código, mientras que un defecto es un fallo en el sistema.
  4. Un defecto es un error en el diseño, mientras que un error es un fallo en la implementación.

Pregunta 17

¿Cuál es el propósito de documentar un defecto en el desarrollo de software?

Opciones:

  1. Para mantener un registro de todos los errores cometidos durante el desarrollo.
  2. Para penalizar al desarrollador que cometió el error.
  3. Para proporcionar información detallada para que el defecto pueda ser corregido.
  4. Para mantener un registro de todos los errores cometidos durante el desarrollo.

Pregunta 18

¿Cuál es el impacto de no gestionar correctamente los defectos en el desarrollo de software?

Opciones:

  1. Mejora en la eficiencia del equipo de desarrollo.
  2. Aumento en los costos de desarrollo y posible pérdida de confianza del cliente.
  3. Reducción en el tiempo necesario para el desarrollo del software.
  4. Ninguno, ya que los defectos siempre se encuentran eventualmente.

Pregunta 19

Durante el testing de software, si un defecto es identificado, pero no afecta significativamente la funcionalidad, ¿cuál sería la acción más apropiada?

Opciones:

  1. Informar al cliente y pedir una extensión del plazo de entrega.
  2. Detener inmediatamente todo el desarrollo hasta que se resuelva el defecto.
  3. Ignorar el defecto y continuar con el desarrollo.
  4. Asignar baja prioridad y planificar su resolución en futuras actualizaciones.

Pregunta 20

Si un defecto identificado es crítico para la funcionalidad del software, ¿cuál debería ser el enfoque del equipo de desarrollo?

Opciones:

  1. Esperar a que el defecto se resuelva por sí solo.
  2. Asignar el defecto a un miembro junior del equipo para su aprendizaje.
  3. Priorizar la resolución del defecto antes de continuar con otras tareas.
  4. Cambiar los requisitos del software para acomodar el defecto.

Pregunta 21

¿Qué objetivo tienen las técnicas de pruebas estáticas en el desarrollo de software?

Opciones:

  1. Detectar y corregir defectos tempranamente en el proceso de desarrollo.
  2. Evaluar el rendimiento del software después de su implementación.
  3. Realizar pruebas de usabilidad y experiencia de usuario.
  4. Validar la funcionalidad del software en su entorno final de operación.

Pregunta 22

¿Cuál es la principal diferencia entre las pruebas de caja negra y las pruebas de caja blanca?

Opciones:

  1. La caja negra se enfoca en la funcionalidad externa y la caja blanca en la estructura interna del código.
  2. La caja negra prueba la interfaz de usuario, mientras que la caja blanca prueba la base de datos.
  3. La caja negra requiere conocimientos de programación, mientras que la caja blanca no.
  4. La caja negra es para pruebas de rendimiento y la caja blanca para pruebas de seguridad.

Pregunta 23

¿Qué se busca con las pruebas basadas en la experiencia?

Opciones:

  1. Automatizar completamente el proceso de pruebas.
  2. Utilizar la intuición y experiencia previa del probador para identificar posibles defectos.
  3. Cumplir estrictamente con los requisitos formales de prueba.
  4. Seguir un conjunto riguroso y predefinido de pruebas.

Pregunta 24

En un desarrollo de videojuego con múltiples niveles, ¿cuál técnica de prueba sería más adecuada para asegurar la funcionalidad antes de avanzar al siguiente nivel?

Opciones:

  1. Pruebas basadas en la experiencia.
  2. Pruebas de caja blanca.
  3. Análisis de valores límite.
  4. Pruebas de regresión.

Pregunta 25

Si estás desarrollando un módulo de registro de pacientes y necesitas garantizar la precisión de los datos ingresados, ¿qué técnica de prueba aplicarías?

Opciones:

  1. Pruebas de caja negra.
  2. Partición equivalente.
  3. Pruebas de caja blanca.
  4. Pruebas exploratorias.

Pregunta 26

¿Qué implica el enfoque Agile en las pruebas de software?

Opciones:

  1. Ignorar la documentación y centrarse únicamente en la codificación.
  2. Realizar pruebas solo al final del ciclo de desarrollo.
  3. Integrar las pruebas como parte continua del proceso de desarrollo.
  4. Dejar las pruebas únicamente a los especialistas en testing.

Pregunta 27

¿Cómo se diferencia el Agile Testing de los métodos tradicionales de prueba?

Opciones:

  1. Agile Testing es menos estructurado y carece de planificación.
  2. El Agile Testing se centra más en la documentación que en las pruebas prácticas.
  3. En el Agile Testing las pruebas se realizan solo después de completar todo el desarrollo.
  4. Agile Testing implica una colaboración constante y pruebas integradas en todo el ciclo de desarrollo.

Pregunta 28

¿Qué beneficio clave ofrece el Test-Driven Development (TDD) en Agile Testing?

Opciones:

  1. Se centra únicamente en las pruebas de rendimiento del software.
  2. Elimina la necesidad de realizar pruebas manuales.
  3. Permite escribir menos código y reducir el tiempo de pruebas.
  4. Facilita la detección y corrección temprana de defectos a través de un ciclo iterativo de desarrollo y pruebas.

Pregunta 29

Si estás implementando pruebas en un proyecto Agile que utiliza sprints, ¿cómo aplicarías las pruebas de sistema para maximizar la eficiencia?

Opciones:

  1. Integrar pruebas de sistema en cada sprint para evaluar la aplicación completa.
  2. Realizar las pruebas de sistema solo al final de todos los sprints.
  3. Limitar las pruebas de sistema a los primeros sprints.
  4. Evitar las pruebas de sistema en proyectos Agile debido a limitaciones de tiempo.

Pregunta 30

Al trabajar en un proyecto de desarrollo de software con metodologías Agile, ¿cómo se integrarían mejor las pruebas de aceptación del usuario?

Opciones:

  1. Omitirlas en favor de pruebas automáticas.
  2. Delegarlas exclusivamente a los usuarios finales sin participación del equipo de desarrollo.
  3. Realizarlas solo al final del desarrollo del proyecto.
  4. Llevarlas a cabo de manera continua a lo largo del proyecto.

Pregunta 31

¿Cuál es la importancia de gestionar los riesgos en el área de calidad de software?

Opciones:

  1. Anticiparse a problemas y mitigarlos para asegurar la calidad y eficiencia del software.
  2. Reducir los costos de desarrollo al eliminar las pruebas.
  3. Garantizar que no existan errores o fallas en el software.
  4. Acelerar el lanzamiento del software ignorando posibles riesgos.

Pregunta 32

¿Qué se entiende por "Riesgo RBT" en el testing de software?

Opciones:

  1. Los riesgos identificados y evaluados mediante el método de pruebas basadas en riesgos.
  2. El riesgo asociado con el uso de herramientas de prueba automatizadas.
  3. Riesgos asociados exclusivamente con pruebas de regresión.
  4. Riesgos que no pueden ser mitigados o gestionados.

Pregunta 33

¿Cómo se definen los riesgos en el testing de software?

Opciones:

  1. Como problemas que siempre llevan a fallas críticas del software.
  2. Como factores capaces de producir consecuencias negativas, evaluados por su probabilidad e impacto.
  3. Como errores menores que no afectan la funcionalidad general del software.
  4. Como desafíos técnicos que solo pueden ser abordados por expertos en seguridad.

Pregunta 34

En un proyecto de desarrollo de software Agile, ¿cómo se debería abordar la gestión de riesgos para maximizar la eficiencia?

Opciones:

  1. Dejando la gestión de riesgos hasta el final del proyecto.
  2. Ignorando los riesgos menores para centrarse en el desarrollo.
  3. Identificando y evaluando los riesgos al inicio de cada iteración o sprint.
  4. Externalizando la gestión de riesgos a un equipo independiente.

Pregunta 35

¿Cómo pueden los informes de prueba ayudar en la gestión de riesgos en proyectos de software Agile?

Opciones:

  1. Ofreciendo una visión general de los riesgos y el progreso de las pruebas.
  2. Proporcionando una descripción detallada de cada línea de código.
  3. Centrándose únicamente en los resultados de pruebas automatizadas.
  4. Documentando solo los defectos críticos encontrados.

Pregunta 36

¿Cómo se benefician los proyectos Agile de la implementación de pruebas exploratorias?

Opciones:

  1. Eliminan la necesidad de pruebas en etapas posteriores del desarrollo.
  2. Reducen la necesidad de comunicación entre el equipo de desarrollo y el de pruebas.
  3. Permiten una planificación detallada y exhaustiva de pruebas.
  4. Facilitan la detección temprana de defectos y mejoran la calidad del software.

Pregunta 37

¿Qué elemento NO es esencial en una bitácora de resultados de pruebas Agile?

Opciones:

  1. Diagramas detallados de diseño de software.
  2. Fecha de ejecución de la prueba.
  3. Estado de la prueba (aprobada o fallida).
  4. Resultados obtenidos.

Pregunta 38

¿Qué característica de las pruebas exploratorias las hace especialmente adecuadas para el testing Agile?

Opciones:

  1. Se enfocan exclusivamente en la funcionalidad del software.
  2. No requieren documentación ni seguimiento.
  3. Se basan en pruebas completamente automatizadas.
  4. Dependen del juicio y habilidad del equipo de pruebas.

Pregunta 39

¿Qué característica es clave para un examinador de pruebas exploratorias?

Opciones:

  1. Tener habilidades avanzadas en programación.
  2. Ser un experto en herramientas de automatización de pruebas.
  3. Ser altamente experimentado en desarrollo de software.
  4. Poseer un conocimiento detallado de los requisitos del cliente.

Pregunta 40

¿Cómo se documentan mejor los resultados de las pruebas exploratorias en Agile Testing?

Opciones:

  1. Solo mediante herramientas de seguimiento automatizadas.
  2. A través de informes formales detallados.
  3. Utilizando una bitácora de pruebas rápida y dinámica.
  4. No se requiere documentación para este tipo de pruebas.

La obra presentada es propiedad de ENSEÑANZA E INVESTIGACIÓN SUPERIOR A.C. (UNIVERSIDAD TECMILENIO), protegida por la Ley Federal de Derecho de Autor; la alteración o deformación de una obra, así como su reproducción, exhibición o ejecución pública sin el consentimiento de su autor y titular de los derechos correspondientes es constitutivo de un delito tipificado en la Ley Federal de Derechos de Autor, así como en las Leyes Internacionales de Derecho de Autor.

El uso de imágenes, fragmentos de videos, fragmentos de eventos culturales, programas y demás material que sea objeto de protección de los derechos de autor, es exclusivamente para fines educativos e informativos, y cualquier uso distinto como el lucro, reproducción, edición o modificación, será perseguido y sancionado por UNIVERSIDAD TECMILENIO.

Queda prohibido copiar, reproducir, distribuir, publicar, transmitir, difundir, o en cualquier modo explotar cualquier parte de esta obra sin la autorización previa por escrito de UNIVERSIDAD TECMILENIO. Sin embargo, usted podrá bajar material a su computadora personal para uso exclusivamente personal o educacional y no comercial limitado a una copia por página. No se podrá remover o alterar de la copia ninguna leyenda de Derechos de Autor o la que manifieste la autoría del material.