🚀 Plataformas de desarrollo y pruebas (V&V)

1. Según la definición estándar de cómputo en la nube, ¿cuáles son los tres modelos de servicio que se ofrecen a los clientes?

1. Infraestructura como servicio (IaaS), plataforma como servicio (PaaS) y escritorio como servicio (DaaS)
2. Infraestructura como servicio (IaaS), software como servicio (SaaS) y backend como servicio (BaaS)
3. Infraestructura como servicio (IaaS), plataforma como servicio (PaaS) y software como servicio (SaaS)
4. Software como servicio (SaaS), función como servicio (FaaS) y plataforma como servicio (PaaS)

El NIST SP 800-145 define exactamente tres modelos de servicio: IaaS, PaaS y SaaS. DaaS, FaaS y BaaS son modelos reales del mercado, pero no forman parte de esta clasificación estándar. (NIST Special Publication 800-145, The NIST Definition of Cloud Computing (2011))

2. ¿Cuáles son los cuatro modelos de despliegue de la nube reconocidos por el NIST?

1. Privada, comunitaria, pública e híbrida
2. Privada, pública, distribuida y federada
3. Privada, pública, virtual y física
4. Comunitaria, pública, local y remota

El NIST SP 800-145 define cuatro modelos de despliegue de la nube: privada, comunitaria, pública e híbrida; las demás combinaciones no corresponden a esta clasificación estándar. (NIST Special Publication 800-145 (2011))

3. Una empresa desea desplegar su aplicación web sin instalar ni administrar el sistema operativo, el servidor de aplicaciones ni el entorno de ejecución; su equipo solo escribirá y subirá el código fuente. ¿Qué modelo de servicio en la nube debe contratar?

1. Infraestructura como servicio (IaaS)
2. Plataforma como servicio (PaaS)
3. Software como servicio (SaaS)
4. Un centro de datos propio (on-premises)

En PaaS el proveedor administra el sistema operativo y el entorno de ejecución, y el cliente solo se encarga de su aplicación y sus datos; en IaaS el cliente seguiría administrando el sistema operativo. (NIST Special Publication 800-145)

4. Un administrador de infraestructura requiere control total sobre el sistema operativo, sus parches y las bibliotecas instaladas, pero no quiere comprar ni mantener servidores físicos propios. ¿Qué modelo de servicio en la nube satisface mejor esta necesidad?

1. Plataforma como servicio (PaaS)
2. Software como servicio (SaaS)
3. Virtualización de escritorio local
4. Infraestructura como servicio (IaaS)

IaaS entrega recursos virtualizados de cómputo, almacenamiento y red, dejando al cliente la administración del sistema operativo y sus aplicaciones; en PaaS esa administración recae en el proveedor. (NIST Special Publication 800-145)

5. En el modelo de servicio SaaS, ¿qué administra típicamente el usuario final de la aplicación?

1. El uso de la aplicación y, en algunos casos, ciertos parámetros de configuración
2. El sistema operativo y las bibliotecas de la aplicación
3. La infraestructura de red, almacenamiento y cómputo
4. El entorno de ejecución y el middleware de la aplicación

En SaaS la aplicación completa se consume como servicio; el proveedor administra la infraestructura, el sistema operativo y la plataforma, mientras que el usuario final solo usa y, en su caso, configura la aplicación. (NIST Special Publication 800-145)

6. ¿Cuál de las siguientes afirmaciones describe correctamente la diferencia de responsabilidades entre IaaS y PaaS?

1. En IaaS el proveedor administra el sistema operativo del cliente; en PaaS el cliente administra la infraestructura física completa
2. En IaaS y en PaaS el cliente administra exactamente los mismos componentes del sistema, sin ninguna diferencia entre ambos modelos
3. En IaaS el cliente administra el sistema operativo; en PaaS el proveedor administra también el entorno de ejecución y el cliente solo la aplicación y sus datos
4. En IaaS el cliente administra solo la aplicación; en PaaS administra además el sistema operativo y el middleware completo

IaaS deja al cliente la administración del sistema operativo hacia arriba; PaaS traslada esa responsabilidad al proveedor, dejando al cliente solo la aplicación y sus datos. Las demás opciones invierten esta relación. (NIST Special Publication 800-145)

7. ¿Cuál de las siguientes NO es una de las características esenciales del cómputo en la nube según el NIST (SP 800-145)?

1. Autoservicio por demanda de recursos de cómputo
2. Acceso amplio a la red desde diversos dispositivos
3. Elasticidad rápida para escalar recursos automáticamente
4. Portabilidad garantizada del código entre proveedores de nube

El NIST define cinco características esenciales: autoservicio por demanda, acceso amplio a la red, agrupación de recursos, elasticidad rápida y servicio medido; la portabilidad entre proveedores es deseable, pero no forma parte de esta lista. (NIST Special Publication 800-145)

8. ¿Qué distingue principalmente a los contenedores de las máquinas virtuales como mecanismo de virtualización de aplicaciones?

1. Los contenedores están limitados a la nube pública, mientras que las máquinas virtuales están limitadas a servidores locales
2. Los contenedores comparten el kernel del sistema operativo anfitrión; las máquinas virtuales incluyen un sistema operativo invitado completo
3. Los contenedores incluyen un sistema operativo invitado completo, mientras que las máquinas virtuales comparten el kernel del anfitrión
4. Los contenedores y las máquinas virtuales requieren un hipervisor de tipo 1 para poder ejecutarse

Los contenedores usan virtualización a nivel de sistema operativo y comparten el kernel del anfitrión, lo que los hace más ligeros que las máquinas virtuales, que ejecutan un sistema operativo invitado completo sobre un hipervisor. (NIST Special Publication 800-190, Application Container Security Guide (2017))

9. Un equipo despliega su aplicación en un entorno de pruebas que usa una versión distinta del motor de base de datos y variables de configuración diferentes a las de producción; todas las pruebas pasan en ese entorno, pero al liberar a producción aparecen fallas no detectadas previamente. ¿Qué principio de las tuberías de despliegue se incumplió?

1. Paridad entre los entornos de desarrollo y producción (dev/prod parity)
2. Integración continua del código fuente en cada cambio
3. Elasticidad rápida de los recursos en la nube pública
4. Escalabilidad horizontal automática de los servidores

Mantener paridad entre los entornos de desarrollo, pruebas y producción reduce el riesgo de comportamientos distintos al desplegar; usar versiones y configuraciones diferentes rompe ese principio y oculta defectos hasta producción. (The Twelve-Factor App, factor X (Dev/prod parity); Humble, J. & Farley, D. (2010), Continuous Delivery)

10. ¿Cuántos niveles de prueba dinámica se reconocen típicamente en el ciclo de vida de pruebas de software?

1. Cinco niveles: unitaria, integración, sistema, aceptación y regresión
2. Cuatro niveles: unitaria, integración, sistema y aceptación
3. Tres niveles: unitaria, sistema y aceptación, sin integración
4. Dos niveles: prueba unitaria y prueba de aceptación

Los niveles de prueba dinámica se organizan típicamente en cuatro: unitaria, integración, sistema y aceptación; la regresión es un tipo de prueba aplicable en cualquier nivel, no un nivel adicional. (ISTQB Certified Tester Foundation Level Syllabus; ISO/IEC/IEEE 29119-2)

11. ¿Cuál de las siguientes describe correctamente el objetivo de la prueba unitaria (o de componente)?

1. Detectar defectos en las interfaces y en la interacción entre componentes ya integrados
2. Evaluar si el sistema completo cumple sus requerimientos funcionales y no funcionales
3. Confirmar que el sistema satisface las necesidades reales del usuario antes de su entrega
4. Verificar el comportamiento de un componente o módulo individual de manera aislada del resto del sistema

La prueba unitaria aísla un componente individual del resto del sistema; las otras opciones describen, respectivamente, integración, sistema y aceptación. (ISTQB Certified Tester Foundation Level Syllabus)

12. ¿Cuál es el objetivo principal de la prueba de integración?

1. Detectar defectos en las interfaces entre componentes o sistemas ya integrados
2. Verificar el funcionamiento aislado de una sola unidad de código fuente
3. Confirmar la aceptación formal del producto completo por parte del cliente
4. Medir el desempeño del sistema completo bajo condiciones de carga real

La prueba de integración se enfoca en las interfaces y la interacción entre componentes o sistemas integrados, a diferencia de la prueba unitaria, que aísla un único componente. (ISO/IEC/IEEE 29119-2; ISTQB Foundation Level Syllabus)

13. ¿Qué evalúa específicamente la prueba de sistema dentro del ciclo de vida de pruebas?

1. El funcionamiento aislado de una sola unidad de código fuente sin dependencias
2. La interacción entre dos módulos que acaban de integrarse en el sistema
3. El comportamiento del sistema completo frente a sus requerimientos funcionales y no funcionales
4. Si el cliente aprueba formalmente el producto antes de su liberación

La prueba de sistema valora el sistema completo e integrado contra sus requerimientos funcionales y no funcionales; las demás opciones describen la prueba unitaria, la integración y la aceptación. (ISTQB Certified Tester Foundation Level Syllabus)

14. ¿Cuál es el propósito principal de la prueba de aceptación?

1. Detectar defectos de programación dentro de un módulo individual
2. Determinar si el sistema cumple los criterios de aceptación para su entrega y uso
3. Medir la cobertura de código alcanzada por las pruebas unitarias
4. Comprobar la correcta interacción entre subsistemas antes de integrarlos

La prueba de aceptación busca confirmar que el sistema cumple los criterios de aceptación del cliente o usuario y está listo para su uso; las otras opciones describen niveles distintos. (ISTQB Certified Tester Foundation Level Syllabus; ISO/IEC/IEEE 29119-2)

15. En un proyecto que sigue el modelo en V, el equipo documentó los requerimientos del usuario durante la fase inicial de análisis. Según este modelo, ¿con qué nivel de prueba se empareja esa fase para su verificación posterior?

1. Prueba de aceptación
2. Prueba de sistema
3. Prueba de integración
4. Prueba unitaria

En el modelo en V, los requerimientos del usuario se emparejan con la prueba de aceptación, mientras que el diseño del sistema, el diseño arquitectónico y el diseño detallado se emparejan respectivamente con sistema, integración y unitaria. (ISTQB Foundation Level Syllabus (modelos de ciclo de vida de desarrollo y prueba))

16. Durante la fase de diseño arquitectónico, el equipo definió los módulos del sistema y las interfaces de comunicación entre ellos. De acuerdo con el modelo en V, ¿qué nivel de prueba corresponde específicamente a esta fase de diseño?

1. Prueba de aceptación
2. Prueba de sistema
3. Prueba unitaria
4. Prueba de integración

El modelo en V empareja el diseño arquitectónico con la prueba de integración, pues en ambos se trabaja sobre los módulos y sus interfaces; el diseño detallado corresponde a la prueba unitaria y el diseño del sistema a la prueba de sistema. (ISTQB Foundation Level Syllabus (modelos de ciclo de vida de desarrollo y prueba))

17. Un defecto solo se manifiesta cuando el módulo de facturación se comunica con el módulo de inventario a través de una interfaz compartida; cada módulo funciona correctamente cuando se ejecuta de forma aislada. ¿En qué nivel de prueba es más probable detectar este defecto antes de llegar a producción?

1. Prueba unitaria
2. Prueba de aceptación
3. Prueba de integración
4. Prueba de regresión

El defecto surge específicamente en la interfaz entre dos módulos integrados, que es justo lo que evalúa la prueba de integración; la prueba unitaria no lo detectaría porque cada módulo funciona bien de forma aislada. (ISO/IEC/IEEE 29119-2; ISTQB Foundation Level Syllabus)

18. ¿Cuál de las siguientes NO es uno de los cuatro niveles de prueba reconocidos en el ciclo de vida de pruebas de software?

1. Prueba de integración
2. Prueba de regresión
3. Prueba de sistema
4. Prueba de aceptación

La prueba de regresión es un tipo de prueba que puede ejecutarse en cualquier nivel para confirmar que los cambios no introdujeron nuevos defectos, pero no constituye uno de los cuatro niveles reconocidos. (ISTQB Certified Tester Foundation Level Syllabus; ISO/IEC/IEEE 29119-2)

19. El equipo interno de calidad certifica que el sistema completo cumple todos los requerimientos funcionales y no funcionales especificados en el diseño; después, el cliente ejecuta sus propios escenarios de uso real para decidir si aprueba la entrega. ¿A qué dos niveles de prueba corresponden, en ese orden, ambas actividades?

1. Prueba de sistema y prueba de aceptación
2. Prueba de integración y prueba de sistema
3. Prueba unitaria y prueba de integración
4. Prueba de aceptación y prueba de sistema

Certificar el cumplimiento de los requerimientos del sistema completo corresponde a la prueba de sistema, y la validación final por parte del cliente corresponde a la prueba de aceptación; invertir el orden es un error común de confusión entre ambos niveles. (ISTQB Certified Tester Foundation Level Syllabus)

20. El desarrollo guiado por pruebas (TDD, Test-Driven Development) organiza el trabajo en un ciclo iterativo conocido comúnmente como...

1. Analizar-Diseñar-Codificar-Probar
2. Planear-Hacer-Verificar-Actuar (PHVA)
3. Rojo-Verde-Refactorización (red-green-refactor)
4. Especificar-Implementar-Desplegar-Monitorear

El ciclo característico de TDD es rojo (prueba que falla), verde (código mínimo que la pasa) y refactorización (mejora del diseño sin cambiar el comportamiento observable). (Beck, K. (2003), Test-Driven Development: By Example)

21. Dentro de un ciclo de TDD, ¿en qué orden se realizan las siguientes actividades?

1. Primero se refactoriza el código existente, después se escribe la prueba y finalmente se implementa la función
2. Primero se escribe una prueba que falla, después el código mínimo para pasarla y finalmente se refactoriza
3. Primero se implementa la función completa, después se escribe la prueba y finalmente se refactoriza
4. Primero se documentan los requerimientos, después se escribe el código y finalmente se prueban ambos juntos

TDD exige escribir primero una prueba que falle (rojo), luego el código mínimo que la haga pasar (verde) y solo después refactorizar; invertir este orden contradice el principio de 'test-first'. (Beck, K. (2003), Test-Driven Development: By Example)

22. Un desarrollador que afirma practicar TDD codifica primero la función 'calcularDescuento()' por completo y solo después agrega pruebas unitarias para verificarla. ¿Qué principio fundamental de TDD está incumpliendo?

1. Aplicar refactorización continua sobre el código ya existente
2. Mantener un porcentaje mínimo de cobertura de código
3. Usar dobles de prueba (mocks) para aislar dependencias externas
4. Escribir la prueba antes que el código de producción (test-first)

El principio central de TDD es escribir la prueba antes que el código de producción; programar primero y probar después invierte ese orden, aunque después se agreguen pruebas unitarias. (Beck, K. (2003), Test-Driven Development: By Example)

23. ¿Qué caracteriza principalmente al desarrollo guiado por comportamiento (BDD, Behavior-Driven Development)?

1. Describir el comportamiento esperado del sistema en lenguaje natural, como el formato Dado-Cuando-Entonces
2. Medir exclusivamente la cobertura de sentencias alcanzada por las pruebas automatizadas
3. Eliminar por completo la necesidad de escribir pruebas unitarias en el proyecto
4. Establecer el número máximo de iteraciones permitidas dentro de un sprint de trabajo

BDD expresa el comportamiento esperado del sistema en lenguaje natural y estructurado (por ejemplo, Dado-Cuando-Entonces), de forma que personas técnicas y de negocio compartan una misma especificación. (North, D. (2006), 'Introducing BDD')

24. ¿Cuál es la principal diferencia conceptual entre TDD y BDD?

1. TDD se aplica únicamente en pruebas de sistema, mientras que BDD se aplica únicamente en pruebas unitarias
2. TDD elimina la necesidad de automatizar pruebas, mientras que BDD exige automatizarlas todas
3. TDD se enfoca en pruebas técnicas antes del código; BDD extiende ese enfoque a especificaciones de comportamiento en lenguaje natural
4. TDD y BDD son metodologías idénticas que solo difieren en el nombre con el que se les conoce

BDD nace como una evolución de TDD que traslada el enfoque técnico de 'probar primero' hacia especificaciones de comportamiento en lenguaje natural, compartidas entre desarrolladores y áreas de negocio. (North, D. (2006), 'Introducing BDD'; Beck, K. (2003), Test-Driven Development: By Example)

25. Un equipo redacta, junto con el área de negocio, escenarios en formato Dado-Cuando-Entonces para validar que una nueva funcionalidad de compra en línea satisface las necesidades reales del usuario antes de liberarla a producción. ¿A qué nivel de prueba se asocia más naturalmente esta práctica de BDD?

1. Prueba unitaria
2. Prueba de aceptación
3. Prueba de integración
4. Prueba de sistema

Los escenarios BDD redactados con el negocio para validar que el software satisface la necesidad real del usuario se usan típicamente como criterios de aceptación, por lo que se asocian con la prueba de aceptación. (North, D. (2006), 'Introducing BDD'; ISTQB Foundation Level Syllabus)

26. Un equipo aplica TDD de forma estricta y todas sus pruebas unitarias pasan; sin embargo, al integrar el sistema completo, este no cumple varios requerimientos de negocio porque las pruebas unitarias no reflejaban escenarios reales de uso. ¿Qué práctica complementaria ayudaría a cerrar esa brecha?

1. Incorporar especificaciones de comportamiento (BDD) en lenguaje natural con las partes interesadas del negocio
2. Aumentar el número de pruebas unitarias por método sin modificar su enfoque técnico
3. Eliminar la fase de refactorización del ciclo de TDD para acelerar las entregas
4. Sustituir las pruebas unitarias existentes por métricas de cobertura de sentencias

BDD complementa a TDD al expresar el comportamiento esperado en escenarios de negocio compartidos con las partes interesadas, reduciendo el riesgo de que las pruebas técnicas ignoren necesidades reales del usuario. (North, D. (2006), 'Introducing BDD')

27. En una API que sigue el estilo arquitectónico REST, la restricción de 'ausencia de estado' (statelessness) significa que:

1. El servidor debe conservar en memoria la sesión completa de cada cliente entre solicitudes.
2. Cada solicitud del cliente debe incluir la información necesaria para procesarla, sin depender de contexto previo.
3. El cliente debe reenviar la contraseña del servidor en cada encabezado HTTP que utilice.
4. El servidor puede procesar las solicitudes en cualquier orden sin garantizar una respuesta.

La restricción de statelessness de REST exige que cada solicitud sea autocontenida; el servidor no conserva el contexto del cliente entre solicitudes. (Fielding, R. (2000), Architectural Styles and the Design of Network-based Software Architectures, cap. 5 (REST).)

28. ¿Cuál de los siguientes métodos HTTP usados en una API REST NO es idempotente, de modo que invocarlo varias veces puede crear un recurso distinto en cada llamada?

1. PUT
2. DELETE
3. POST
4. GET

POST se usa para crear recursos y, por convención, no es idempotente: cada invocación puede generar un nuevo recurso; PUT, DELETE y GET sí son idempotentes. (RFC 9110, HTTP Semantics (semántica de idempotencia de los métodos HTTP).)

29. En una API REST, cuando el servidor procesa correctamente una solicitud y crea un nuevo recurso, el código de estado HTTP que debe devolver es:

1. 200 OK
2. 204 No Content
3. 201 Created
4. 202 Accepted

El código 201 Created indica que la solicitud tuvo éxito y se creó un nuevo recurso; 200 se usa para éxito general, 204 cuando no hay contenido y 202 cuando el procesamiento será asíncrono. (RFC 9110, HTTP Semantics, códigos de estado 2xx.)

30. Un cliente envía una solicitud a una API REST con un token de autenticación válido, pero el usuario asociado no tiene permiso para acceder al recurso solicitado. El código de estado HTTP que el servidor debe devolver es:

1. 403 Forbidden
2. 401 Unauthorized
3. 400 Bad Request
4. 404 Not Found

403 Forbidden indica que el servidor autenticó al usuario pero rechaza el acceso por falta de permisos; 401 se reserva para cuando la autenticación falta o es inválida. (RFC 9110, HTTP Semantics, definiciones de 401 y 403.)

31. En arquitecturas de software, se denomina 'middleware' al software que:

1. Se sitúa entre el sistema operativo y las aplicaciones y ofrece servicios comunes de comunicación o transacciones.
2. Reemplaza por completo al sistema operativo dentro de un servidor de aplicaciones distribuido.
3. Corresponde únicamente a la capa de presentación visible para el usuario final de la aplicación.
4. Es el motor de base de datos relacional encargado de almacenar los datos de la aplicación.

El middleware es el software intermedio que provee servicios comunes de comunicación, mensajería o transacciones entre el sistema operativo y las aplicaciones, o entre aplicaciones distribuidas. (ISO/IEC/IEEE 24765:2017, Systems and software engineering — Vocabulary (término middleware).)

32. Una organización necesita centralizar la autenticación, el enrutamiento de solicitudes y la limitación de tasa (rate limiting) para varios microservicios expuestos como APIs REST, sin modificar la lógica interna de cada servicio. El componente de middleware más adecuado es:

1. Un servidor de bases de datos replicado
2. Un compilador cruzado (cross-compiler)
3. Un API Gateway
4. Un sistema de archivos distribuido

El API Gateway es el patrón de middleware que centraliza el enrutamiento, la autenticación y el control de tráfico de múltiples APIs sin alterar la lógica interna de los microservicios. (Richardson, C. (2018), Microservices Patterns (Manning), patrón API Gateway.)

33. A diferencia de una llamada REST síncrona, en la que el cliente espera la respuesta inmediata del servidor, el middleware orientado a mensajes (message-oriented middleware) permite la comunicación entre componentes mediante:

1. Un enlace TCP persistente que bloquea al emisor hasta recibir confirmación síncrona.
2. Colas o tópicos de mensajes que desacoplan en el tiempo al emisor y al receptor.
3. Una tabla de decisión compartida que ambos componentes consultan en cada solicitud.
4. Un procedimiento remoto que solo se ejecuta si el receptor está disponible en ese instante.

El middleware orientado a mensajes (MOM) desacopla temporalmente a productor y consumidor mediante colas o tópicos, permitiendo comunicación asíncrona, a diferencia de una llamada REST síncrona. (Hohpe, G. y Woolf, B. (2003), Enterprise Integration Patterns (Addison-Wesley); middleware orientado a mensajes.)

34. Dentro de las restricciones del estilo arquitectónico REST, el principio que establece que las respuestas del servidor deben incluir enlaces que indiquen al cliente las transiciones de estado disponibles a partir del recurso actual se conoce como:

1. Cacheable (capacidad de cacheo)
2. Sistema en capas (layered system)
3. Ausencia de estado (statelessness)
4. HATEOAS (Hypermedia as the Engine of Application State)

HATEOAS es la restricción de REST según la cual las respuestas incluyen hipervínculos que guían al cliente hacia las transiciones de estado disponibles, distinta de statelessness o cacheable. (Fielding, R. (2000), Architectural Styles and the Design of Network-based Software Architectures, cap. 5.)

35. La técnica de prueba de caja negra que agrupa los valores del dominio de entrada en clases que, según la especificación, deberían producir un comportamiento equivalente del sistema se conoce como:

1. Análisis de valores límite
2. Partición de equivalencia
3. Tabla de decisión
4. Cobertura de sentencias

La partición de equivalencia divide el dominio de entrada en clases que, por especificación, deben tratarse de forma equivalente, reduciendo el número de casos de prueba necesarios. (ISO/IEC/IEEE 29119-4 (Test techniques); ISTQB Foundation Level Syllabus.)