Metodologías de desarrollo, pruebas y control de versiones — Cuerpo de Técnicos Auxiliares de Informática de la Administración del Estado
Test de 32 preguntas con explicaciones justificadas.
Pregunta 1: En Scrum, ¿cuál es el objetivo principal de la reunión de Sprint Planning?
- A) Revisar el trabajo completado en el sprint anterior.
- B) Definir el objetivo y el trabajo a realizar durante el próximo sprint.
- C) Identificar y eliminar impedimentos que afectan al equipo.
- D) Inspeccionar el incremento de producto y adaptar el Product Backlog.
En Scrum, el Sprint Planning es un evento donde el equipo de desarrollo, junto con el Product Owner, define el objetivo del sprint (Sprint Goal) y selecciona los elementos del Product Backlog que se compromete a completar durante el sprint.
Pregunta 2: ¿Cuál de las siguientes es una característica distintiva del método Kanban frente a Scrum?
- A) Kanban utiliza iteraciones con duración fija (sprints).
- B) Kanban limita el trabajo en curso (WIP) en cada etapa del flujo.
- C) Kanban define roles específicos como Scrum Master y Product Owner.
- D) Kanban requiere planificación en reuniones ceremoniales para cada lote de trabajo.
Kanban se centra en la visualización del flujo de trabajo y la limitación del trabajo en curso (Work In Progress - WIP) para mejorar la eficiencia. A diferencia de Scrum, no prescribe iteraciones temporales fijas ni roles ceremoniales específicos.
Pregunta 3: ¿Qué práctica de Extreme Programming (XP) implica que dos programadores trabajen juntos en el mismo código, en un mismo ordenador?
- A) Refactorización
- B) Integración Continua
- C) Programación en Pareja
- D) Desarrollo Guiado por Pruebas
La Programación en Pareja (Pair Programming) es una práctica central de XP donde dos desarrolladores colaboran en una misma estación de trabajo: uno escribe el código (conductor) y el otro revisa cada línea (navegante).
Pregunta 4: En el modelo de desarrollo en cascada (Waterfall), ¿cuál es la secuencia típica de fases?
- A) Planificación, Diseño, Implementación, Pruebas, Mantenimiento.
- B) Análisis, Diseño, Codificación, Pruebas, Despliegue.
- C) Requisitos, Diseño, Implementación, Verificación, Mantenimiento.
- D) Concepción, Elaboración, Construcción, Transición.
El modelo clásico en cascada, definido por Royce, sigue una secuencia lineal y secuencial de fases: Requisitos, Diseño, Implementación, Verificación (Pruebas) y Mantenimiento.
Pregunta 5: El modelo de desarrollo en espiral se caracteriza principalmente por:
- A) Ser un proceso lineal con fases bien definidas y sin iteraciones.
- B) Combinar la naturaleza iterativa del prototipado con los aspectos controlados del modelo en cascada.
- C) Entregar funcionalidad en iteraciones cortas y regulares llamadas sprints.
- D) Utilizar un tablero visual para gestionar el flujo de trabajo y limitar el WIP.
El modelo en espiral, propuesto por Boehm, es un modelo de proceso de software iterativo y evolutivo que combina el desarrollo iterativo (prototipado) con los aspectos sistemáticos y controlados del modelo en cascada, haciendo hincapié en la gestión de riesgos.
Pregunta 6: ¿Qué tipo de prueba se centra en verificar el correcto funcionamiento de un módulo o componente individual de software de forma aislada?
- A) Pruebas de integración
- B) Pruebas de sistema
- C) Pruebas de regresión
- D) Pruebas unitarias
Las pruebas unitarias (unit testing) tienen como objetivo validar que cada unidad individual del software (por ejemplo, una función o método) funcione correctamente de forma aislada, sin dependencias externas.
Pregunta 7: Las pruebas de integración se realizan para:
- A) Asegurar que el sistema completo cumple con los requisitos especificados.
- B) Verificar la interacción correcta entre diferentes módulos o componentes.
- C) Validar que los cambios nuevos no afectan negativamente a la funcionalidad existente.
- D) Determinar si el software es aceptable para el usuario final.
Las pruebas de integración (integration testing) tienen como objetivo detectar defectos en las interfaces y en la interacción entre componentes o sistemas integrados, una vez que han pasado las pruebas unitarias.
Pregunta 8: ¿Cuál de las siguientes afirmaciones describe mejor el propósito de las pruebas de aceptación?
- A) Verificar que cada unidad de código funciona de manera aislada.
- B) Validar que el sistema completo cumple con los requisitos de negocio y es usable por el cliente.
- C) Comprobar que los diferentes módulos se comunican correctamente.
- D) Garantizar que el rendimiento del sistema es adecuado bajo carga.
Las pruebas de aceptación (acceptance testing) son la fase final de las pruebas, donde se valida que el sistema cumple con los criterios de aceptación definidos por el cliente o usuario final, asegurando que satisface las necesidades de negocio.
Pregunta 9: En el contexto de las pruebas de software, ¿qué son las pruebas de regresión?
- A) Pruebas que se ejecutan la primera vez que se desarrolla una funcionalidad.
- B) Pruebas diseñadas para verificar que los cambios o correcciones no han introducido nuevos defectos en la funcionalidad existente.
- C) Pruebas que se centran únicamente en la interfaz de usuario y la experiencia del usuario.
- D) Pruebas que determinan la velocidad de respuesta del sistema bajo condiciones normales.
Las pruebas de regresión (regression testing) consisten en volver a ejecutar un subconjunto de pruebas ya realizadas para asegurar que las modificaciones recientes en el código (nuevas funcionalidades o correcciones) no han afectado adversamente a la funcionalidad existente.
Pregunta 10: ¿Cuál es la secuencia correcta de pasos en el ciclo de Desarrollo Guiado por Pruebas (TDD)?
- A) Refactorizar, Escribir prueba, Escribir código que pase la prueba.
- B) Escribir código, Escribir prueba, Ejecutar prueba.
- C) Escribir prueba, Escribir código que pase la prueba, Refactorizar.
- D) Diseñar arquitectura, Escribir código, Escribir pruebas.
El ciclo de TDD sigue tres pasos fundamentales: 1. Rojo: Escribir una prueba que falle (define el comportamiento deseado). 2. Verde: Escribir el código mínimo necesario para que la prueba pase. 3. Refactorizar: Mejorar la estructura del código manteniendo el comportamiento (pasando las pruebas).
Pregunta 11: La Integración Continua (CI) es una práctica que consiste en:
- A) Entregar automáticamente cada cambio a producción.
- B) Fusionar frecuentemente el trabajo de todos los desarrolladores en una rama principal y verificar mediante builds automatizados.
- C) Planificar las entregas de software en intervalos trimestrales.
- D) Realizar pruebas manuales exhaustivas antes de integrar cualquier cambio.
La Integración Continua (Continuous Integration) es una práctica de desarrollo donde los miembros de un equipo integran su trabajo frecuentemente (varias veces al día), en una rama compartida (main), y cada integración se verifica mediante un build automatizado y ejecución de pruebas para detectar errores rápidamente.
Pregunta 12: ¿Qué se entiende por Entrega Continua (Continuous Delivery) en el contexto de CI/CD?
- A) Un proceso manual donde el equipo decide cuándo desplegar a producción.
- B) La capacidad de desplegar automáticamente cada cambio en el código a producción sin intervención humana.
- C) La capacidad de liberar cualquier versión del software a producción de forma segura y rápida, de manera manual o automática.
- D) Un modelo de desarrollo donde las entregas se realizan solo en fechas fijas cada mes.
La Entrega Continua (Continuous Delivery) extiende la Integración Continua asegurando que el software pueda ser liberado de forma confiable en cualquier momento, típicamente mediante un proceso automatizado que prepara paquetes listos para producción, aunque el despliegue final a producción puede ser manual.
Pregunta 13: Jenkins es principalmente una herramienta de:
- A) Control de versiones distribuido.
- B) Automatización de servidores de aplicaciones.
- C) Integración y entrega continua (CI/CD).
- D) Gestión de proyectos ágil.
Jenkins es un servidor de automatización de código abierto ampliamente utilizado para orquestar pipelines de Integración Continua y Entrega Continua (CI/CD), permitiendo automatizar builds, pruebas y despliegues.
Pregunta 14: GitHub Actions es una plataforma que permite:
- A) Gestionar exclusivamente el control de versiones de proyectos privados.
- B) Automatizar flujos de trabajo de CI/CD directamente desde el repositorio de GitHub.
- C) Realizar únicamente despliegues manuales a entornos de producción.
- D) Sustituir completamente a Git en el control de versiones local.
GitHub Actions es una herramienta de integración y entrega continua (CI/CD) integrada en GitHub que permite automatizar flujos de trabajo (workflows) para compilar, probar y desplegar código directamente desde el repositorio.
Pregunta 15: En Git, el comando 'git merge' se utiliza para:
- A) Crear una nueva rama a partir de la rama actual.
- B) Integrar los cambios de una rama en la rama actual.
- C) Reescribir el historial de commits de una rama.
- D) Etiquetar un commit específico con un nombre descriptivo.
En Git, el comando 'git merge' combina los cambios de una o más ramas en la rama actual. Crea un nuevo commit de 'merge' que tiene dos padres, integrando las historias de ambas ramas.
Pregunta 16: ¿Cuál es el propósito principal del comando 'git rebase'?
- A) Fusionar una rama en otra, creando siempre un commit de merge.
- B) Mover o transplantar una secuencia de commits a una nueva base, resultando en un historial lineal.
- C) Eliminar commits del historial de manera permanente.
- D) Comparar las diferencias entre dos ramas.
El comando 'git rebase' reaplica los commits de la rama actual sobre la punta de otra rama (por ejemplo, main), resultando en un historial de proyecto más limpio y lineal, ya que evita los commits de merge innecesarios.
Pregunta 17: En Git, ¿para qué se utilizan principalmente las 'tags' (etiquetas)?
- A) Para crear ramas de desarrollo aisladas para nuevas funcionalidades.
- B) Para marcar puntos específicos en el historial como importantes, como releases de versiones.
- C) Para guardar temporalmente cambios no confirmados en el directorio de trabajo.
- D) Para sincronizar el repositorio local con un repositorio remoto.
En Git, una 'tag' (etiqueta) es una referencia estática a un commit específico, comúnmente utilizada para marcar puntos de lanzamiento (por ejemplo, v1.0, v2.1). Son inmutables y facilitan la referencia a versiones estables del software.
Pregunta 18: El flujo de trabajo Git Flow propone, entre otras, una rama principal llamada 'develop' cuyo propósito es:
- A) Almacenar el historial oficial de releases listos para producción.
- B) Servir como rama de integración para las funcionalidades en desarrollo.
- C) Albergar correcciones críticas de producción (hotfixes).
- D) Ser la única rama donde se realizan commits directamente.
En Git Flow, la rama 'develop' es la rama de integración principal donde se fusionan las ramas de características (feature branches) y desde donde se crean las ramas de release para preparar nuevas versiones.
Pregunta 19: La cultura DevOps promueve principalmente:
- A) La separación estricta entre los equipos de desarrollo y operaciones para mantener la especialización.
- B) La automatización y colaboración entre los equipos de desarrollo y operaciones para entregar software de forma más rápida y confiable.
- C) La adopción exclusiva de metodologías ágiles como Scrum en todos los proyectos.
- D) La gestión manual de la infraestructura para mantener un mayor control.
DevOps es una cultura y conjunto de prácticas que busca la colaboración y comunicación estrecha entre los equipos de desarrollo (Dev) y operaciones (Ops), junto con la automatización de procesos, para acelerar el ciclo de vida de entrega de software manteniendo la calidad y estabilidad.
Pregunta 20: En Scrum, ¿quién es el responsable de maximizar el valor del producto y gestionar el Product Backlog?
- A) El Scrum Master
- B) El Product Owner
- C) El equipo de desarrollo
- D) El Stakeholder principal
El Product Owner es el rol en Scrum responsable de representar los intereses de las partes interesadas, gestionar y priorizar el Product Backlog, y asegurar que el equipo entregue el máximo valor posible.
Pregunta 21: En Kanban, la métrica 'Tiempo de Ciclo' (Cycle Time) mide:
- A) El tiempo total desde la concepción de una idea hasta su entrega al cliente.
- B) El tiempo que un trabajo tarda en moverse desde que empieza hasta que se completa en el flujo de trabajo.
- C) La cantidad máxima de ítems que pueden estar en una columna del tablero.
- D) El número de ítems completados en un período de tiempo fijo.
En Kanban, el Tiempo de Ciclo (Cycle Time) es una métrica clave que mide el tiempo promedio que un elemento de trabajo (por ejemplo, una tarea) tarda desde que se inicia su desarrollo (entra en 'En progreso') hasta que se completa (estado 'Terminado').
Pregunta 22: ¿Cuál de las siguientes es una práctica de Extreme Programming (XP)?
- A) Sprint Retrospective
- B) Refactorización continua del código
- C) Limitación del Trabajo en Curso (WIP)
- D) Reuniones diarias de 15 minutos
La Refactorización (Refactoring) es una práctica fundamental en XP que implica mejorar continuamente la estructura del código sin alterar su comportamiento externo, para mantenerlo simple, legible y fácil de modificar.
Pregunta 23: El modelo de desarrollo en 'V' se caracteriza por:
- A) Entregar software en incrementos funcionales cortos.
- B) Tener fases de verificación y validación que se corresponden con cada fase de desarrollo.
- C) Ser un proceso iterativo e incremental centrado en la gestión de riesgos.
- D) Utilizar un tablero Kanban para gestionar el flujo de trabajo.
El modelo en V es una extensión del modelo en cascada donde, para cada fase de desarrollo (lado izquierdo de la V), existe una fase de prueba correspondiente (lado derecho). Por ejemplo, el diseño de alto nivel se verifica con las pruebas de sistema.
Pregunta 24: Las 'pruebas de humo' (Smoke Testing) tienen como objetivo principal:
- A) Verificar exhaustivamente todas las funcionalidades del sistema.
- B) Determinar si una build es lo suficientemente estable como para proceder con pruebas más profundas.
- C) Evaluar la seguridad del sistema contra ataques externos.
- D) Medir el rendimiento del sistema bajo carga extrema.
Las pruebas de humo (Smoke Testing) son un conjunto de pruebas superficiales que se ejecutan sobre una nueva build para verificar que las funcionalidades críticas básicas funcionan y que la build es estable antes de realizar pruebas más exhaustivas.
Pregunta 25: Un pipeline de CI/CD típicamente incluye las siguientes etapas, en orden:
- A) Despliegue a producción, Build, Pruebas.
- B) Build, Pruebas, Despliegue a producción.
- C) Pruebas, Build, Análisis de requisitos.
- D) Build, Despliegue a producción, Pruebas.
Un pipeline de CI/CD generalmente automatiza una secuencia de etapas que comienza con la compilación (Build) del código fuente, seguida de la ejecución de pruebas automatizadas (unitarias, de integración, etc.) y, si estas son exitosas, procede al despliegue (Deploy) a entornos de staging o producción.
Pregunta 26: El comando 'git cherry-pick' se utiliza para:
- A) Aplicar los cambios introducidos por un commit específico de otra rama a la rama actual.
- B) Fusionar todos los commits de una rama en la rama actual.
- C) Eliminar commits antiguos del historial.
- D) Crear una nueva rama a partir de un tag.
El comando 'git cherry-pick' permite aplicar los cambios de un commit específico (identificado por su hash) desde cualquier rama a la rama actual. Es útil para incorporar una corrección o funcionalidad específica sin fusionar toda la rama.
Pregunta 27: En metodologías ágiles, las 'historias de usuario' sirven principalmente para:
- A) Documentar exhaustivamente todos los requisitos técnicos del sistema.
- B) Describir una funcionalidad deseada desde la perspectiva del usuario final.
- C) Definir la arquitectura técnica de la solución.
- D) Planificar las tareas de mantenimiento del equipo de operaciones.
Una historia de usuario (User Story) es una descripción informal y simple de una característica de software escrita desde la perspectiva del usuario final o cliente. Sigue la estructura: 'Como [rol], quiero [objetivo] para [beneficio]'.
Pregunta 28: En Scrum, la reunión diaria (Daily Scrum) tiene las siguientes características, EXCEPTO:
- A) Su duración máxima es de 15 minutos.
- B) Su objetivo es inspeccionar el progreso hacia el Sprint Goal.
- C) La lleva y modera exclusivamente el Scrum Master.
- D) Cada miembro del equipo de desarrollo responde tres preguntas clave.
La Daily Scrum es un evento de 15 minutos donde el equipo de desarrollo se sincroniza. Aunque el Scrum Master puede facilitar la reunión, no la modera exclusivamente; es responsabilidad del equipo. El foco es responder: ¿Qué hice ayer? ¿Qué haré hoy? ¿Hay impedimentos?
Pregunta 29: ¿Qué herramienta de control de versiones está basada en un modelo distribuido, donde cada desarrollador tiene una copia completa del repositorio?
- A) Subversion (SVN)
- B) Git
- C) Team Foundation Version Control (TFVC)
- D) Concurrent Versions System (CVS)
Git es un sistema de control de versiones distribuido, a diferencia de los sistemas centralizados como SVN, CVS o TFVC. En Git, cada desarrollador clona un repositorio completo con todo el historial, permitiendo trabajo offline y múltiples copias.
Pregunta 30: En el contexto de las pruebas, ¿qué es un 'stub'?
- A) Un componente que simula el comportamiento de un módulo dependiente para aislar la unidad bajo prueba.
- B) Una suite completa de pruebas de extremo a extremo.
- C) Un tipo de prueba que verifica la interfaz de usuario.
- D) Un informe de errores encontrados durante las pruebas.
Un 'stub' es un objeto de prueba (test double) que simula el comportamiento de un componente real del que depende la unidad bajo prueba, proporcionando respuestas preprogramadas para permitir el aislamiento y la prueba de la unidad en cuestión.
Pregunta 31: La práctica de 'Integración Continua' requiere habitualmente que:
- A) Los desarrolladores integren su código en la rama principal al menos una vez al día.
- B) Se realicen despliegues manuales a producción varias veces al día.
- C) Cada desarrollador trabaje en una rama aislada durante semanas antes de integrar.
- D) Todo el código sea revisado manualmente por un líder técnico antes de ser integrado.
Un principio clave de la Integración Continua es que los desarrolladores fusionen sus cambios en una rama compartida (por ejemplo, main o trunk) con frecuencia, idealmente varias veces al día, para detectar y resolver conflictos e integraciones de forma rápida.
Pregunta 32: ¿Cuál de estos conceptos está más relacionado con la filosofía 'You build it, you run it' asociada a DevOps?
- A) Los desarrolladores solo escriben código y los operadores lo ejecutan en producción.
- B) El equipo de desarrollo es responsable del ciclo de vida completo del software que construye.
- C) Se externaliza la operación del software a un tercero especializado.
- D) El despliegue a producción solo lo realiza un equipo de operaciones dedicado.
La frase 'You build it, you run it', acuñada por Werner Vogels de Amazon, encapsula la idea de DevOps de que los equipos de desarrollo deben asumir responsabilidad sobre la operación y mantenimiento en producción del software que construyen, fomentando la propiedad end-to-end.