Guía de oposiciones · Bloque III · Tema 23 · Actualizada a septiembre de 2026
Este es el tema donde el tribunal juega con las listas de herramientas. Te da cuatro nombres y te pide el intruso: entre los de control de versiones cuela uno de pruebas, entre los de pruebas cuela uno de privacidad. Y cuando no hace eso, cambia de sitio la definición de un tipo de prueba. Ha caído en 2023, 2024 y 2026, en test y en supuestos. Aquí tienes qué es cada herramienta, los comandos de Git que se confunden, las reuniones de Scrum, los tipos de prueba, tres preguntas reales resueltas y el esquema de memorización.
Control de versiones: centralizado frente a distribuido
Un sistema de control de versiones registra los cambios sobre un conjunto de ficheros para poder recuperar estados anteriores, saber quién cambió qué y trabajar varias personas sobre lo mismo sin pisarse.
La división que se pregunta es por dónde vive el historial. En los centralizados hay un único repositorio en un servidor y los clientes descargan una copia de trabajo: son Subversion (SVN) y CVS. En los distribuidos cada desarrollador tiene una copia completa del repositorio, con todo el historial: son Git y Mercurial.
El intruso que más se repite en las opciones falsas viene del mundo de las pruebas. JMeter, Selenium y Cucumber NO son control de versiones. Y ojo con la trampa inversa: GitHub y GitLab sí cuentan en esas preguntas, porque son plataformas construidas sobre Git.
Git por dentro: los objetos y los tres comandos que se cruzan
Git almacena el historial con cuatro tipos de objeto: el blob guarda el contenido de un fichero, el tree representa un directorio, el commit apunta a un árbol y a sus commits padre, y el tag etiqueta un punto concreto del historial.
Y luego están los tres comandos de red, que es donde se pierde la gente porque los enunciados los describen con las mismas palabras cambiadas de orden:
| Comando | Qué hace exactamente |
|---|---|
| git fetch | Descarga objetos y referencias del remoto y actualiza las ramas de seguimiento. No fusiona nada en tu rama |
| git pull | Es fetch + merge: descarga y lo integra en la rama actual |
| git push | Sube tus commits locales al repositorio remoto |
La frase que resuelve la pregunta de 2026 es «descarga pero no integra»: eso es fetch. Si el enunciado dice que además fusiona automáticamente, está describiendo pull.
Plataformas colaborativas: la pull request y los workflows
Sobre Git se montan plataformas de desarrollo colaborativo como GitHub, GitLab o Bitbucket, que añaden gestión de incidencias, revisión de código y automatización.
Su concepto más preguntado es la pull request (o merge request en GitLab): una propuesta para fusionar los cambios de una rama en otra, normalmente con revisión previa de otra persona. No es un comando de Git, y ahí está la trampa: la opción falsa suele describir git pull, o una etiqueta (tag), esperando que el parecido del nombre haga el resto.
De la automatización se pregunta GitHub Actions: sus workflows se definen en ficheros dentro del directorio .github/workflows/, con extensión .yml.
Metodologías: de Métrica v3 a Scrum
Las clásicas son la cascada (fases secuenciales, cada una empieza cuando termina la anterior), los modelos iterativo e incremental, el modelo en espiral (guiado por el análisis de riesgos) y Métrica v3, la metodología de planificación y desarrollo de sistemas de la Administración española, que además es la fuente de la que el tribunal saca las definiciones de los tipos de prueba.
Las ágiles que caen son Scrum, Kanban y XP (Extreme Programming). De Scrum lo que se pregunta son sus eventos, y casi siempre por descarte:
| Evento de Scrum | Para qué es |
|---|---|
| Sprint Planning | Planificar qué entra en el sprint |
| Daily Scrum | Sincronización diaria del equipo |
| Sprint Review | Mostrar el incremento de producto conseguido |
| Sprint Retrospective | Mejorar el propio proceso de trabajo |
La distinción que decide la pregunta: la Review mira el producto, la Retrospective mira cómo trabaja el equipo. Cualquier enunciado sobre malas prácticas, cuellos de botella o formas de mejorar el trabajo apunta a la Retrospective.
Pruebas de software: niveles, cajas y regresión
Por nivel, de lo pequeño a lo grande: las unitarias prueban un componente aislado, las de integración verifican el ensamblaje entre componentes a través de sus interfaces, las de sistema prueban el producto completo y las de aceptación las hace el usuario para dar el visto bueno final.
Por enfoque: la caja blanca mira la estructura interna del código; la caja negra considera solo las entradas y las salidas, sin entrar en cómo está hecho por dentro. Y las de regresión comprueban que los cambios no han roto lo que no se tocó.
Estas cuatro definiciones son las que el tribunal intercambia entre sí. En la pregunta de 2026 la opción falsa describía la caja negra llamándola blanca, otra describía la aceptación llamándola unitaria, y una cuarta se inventaba unas «pruebas circunstanciales» que no existen.
De herramientas conviene saber para qué es cada una, porque las preguntas van de intrusos: JUnit para pruebas unitarias en Java, Selenium (y su WebDriver) para automatizar pruebas controlando el navegador, Cucumber para pruebas en lenguaje natural, JMeter para rendimiento y carga, TestLink y Avocado también del mundo de las pruebas. El intruso reciente fue OneTrust, que es una plataforma de privacidad y cumplimiento.
Cuidado con la confusión al revés: como Selenium trabaja sobre el navegador, a veces aparece en listas junto a Angular o React, que son frameworks de front-end y no tienen nada que ver con probar. Lo que sí es de desarrollo web está en la guía de aplicaciones web, HTML, XML y CSS.
Integración continua y documentación del repositorio
La integración continua consiste en fusionar y verificar los cambios de forma frecuente y automática. La herramienta que más cae es Jenkins, que orquesta construcción y despliegue mediante pipelines; también aparecen GitHub Actions y GitLab CI. Cuidado con el señuelo: RabbitMQ y Apache Kafka son colas de mensajes, no herramientas de CI/CD.
Y de la documentación del repositorio se pregunta qué fichero hace qué: el README recoge el propósito del proyecto y cómo arrancarlo, el LICENSE es la licencia, el CONTRIBUTING explica cómo colaborar, el CODEOWNERS lista responsables de cada parte y el CITATION indica cómo citar el proyecto.
El diseño del software que se versiona y se prueba (orientación a objetos, patrones y UML) es el tema 18 y está en su propia guía; la seguridad y la accesibilidad durante el desarrollo son el tema 22, en la guía de accesibilidad y usabilidad.
Esquema de memorización
Los datos que se repiten convocatoria tras convocatoria, en una tabla para el repaso de última hora.
| Concepto | Clave |
|---|---|
| VCS centralizado / distribuido | SVN, CVS / Git, Mercurial |
| NO son control de versiones | JMeter, Selenium, Cucumber (son de pruebas) |
| Objetos de Git | blob · tree · commit · tag |
| git fetch / pull / push | Descarga sin fusionar / fetch+merge / sube al remoto |
| Pull request | Propuesta de fusión de una rama en otra, con revisión |
| GitHub Actions | Workflows en .github/workflows/ · extensión .yml |
| Metodologías clásicas | Cascada · iterativo e incremental · espiral · Métrica v3 |
| Ágiles | Scrum · Kanban · XP |
| Review / Retrospective | Muestra el incremento / mejora el proceso |
| Niveles de prueba | Unitaria · Integración · Sistema · Aceptación |
| Integración | Ensamblaje entre componentes por sus interfaces |
| Regresión | Los cambios no rompen lo no modificado |
| Caja blanca / negra | Estructura interna / solo entradas y salidas |
| Herramientas de prueba | JUnit · Selenium · Cucumber · JMeter · TestLink · Avocado (OneTrust NO) |
| CI/CD | Jenkins · pipelines · GitHub Actions (RabbitMQ y Kafka NO) |
| Documentación | README (propósito y arranque) · LICENSE · CONTRIBUTING · CODEOWNERS |
Tres preguntas reales de examen
De los exámenes oficiales, con la respuesta de la plantilla del INAP. En los apuntes completos hay once de este tema, resueltas y razonadas.
Después de clonar el repositorio, se ha ejecutado el comando git fetch. ¿Qué hace este comando?
- Descarga objetos y referencias del remoto y fusiona automáticamente esos cambios en la rama actual.
- Envía (sube) los commits locales al remoto y actualiza la rama remota correspondiente.
- Sustituye el historial local por el del remoto, reescribiendo commits locales para que coincidan.
- Descarga objetos y referencias del remoto y actualiza las ramas de seguimiento remoto, registrando los cambios sin integrarlos en la rama actual.
Ver solución
git fetch descarga y actualiza las ramas de seguimiento, pero no toca tu rama. Descargar y fusionar (opción a) es git pull, y subir (opción b) es git push.Suponiendo que se utilizara la metodología ágil SCRUM, si durante un sprint se da cuenta de que se está aplicando una mala práctica que puede enlentecer el proyecto, ¿en qué reunión comentará esa mala práctica?
- En la Daily Scrum.
- En la Sprint Retrospective.
- En la Sprint Planning.
- En la Sprint Review.
Ver solución
Señala la respuesta correcta acerca de las pruebas de software:
- Las pruebas de regresión comprueban que los cambios sobre un componente no introducen un comportamiento no deseado en lo que no se ha modificado.
- Las pruebas de tipo «caja blanca» consideran exclusivamente las entradas y salidas del sistema sin atender a su estructura interna.
- Las pruebas unitarias sirven para que el usuario del sistema determine su aceptación final.
- Las pruebas circunstanciales examinan las interfaces entre grupos de componentes o subsistemas.
Ver solución
Preguntas frecuentes
¿Qué diferencia hay entre git fetch, git pull y git push?
git fetch descarga del repositorio remoto los objetos y las referencias nuevas y actualiza las ramas de seguimiento, pero no toca tu rama de trabajo. git pull hace eso mismo y además fusiona: es un fetch seguido de un merge. Y git push va en sentido contrario: sube tus commits locales al remoto. Regla rápida: si el enunciado dice «descarga pero no integra», es fetch.
¿Qué diferencia hay entre pruebas de caja blanca y de caja negra?
La caja blanca prueba mirando la estructura interna del código: recorre caminos, condiciones y bucles, y por eso necesita conocer la implementación. La caja negra prueba solo desde fuera, con entradas y salidas, sin saber cómo está hecho por dentro. Es un cruce que el tribunal invierte a menudo, así que conviene tener la asociación fija: blanca = por dentro.
¿En qué reunión de Scrum se plantean las mejoras del proceso?
En la Sprint Retrospective. Es la reunión dedicada a revisar cómo trabaja el equipo y qué cambiar para el siguiente sprint. No hay que confundirla con la Sprint Review, que sirve para mostrar el incremento de producto a los interesados. Una mira el proceso, la otra el resultado.
¿Qué diferencia hay entre un control de versiones centralizado y uno distribuido?
En un sistema centralizado el historial vive en un único servidor y cada persona tiene una copia de trabajo: son Subversion (SVN) y CVS. En uno distribuido cada copia local es un repositorio completo con todo el historial, así que se puede trabajar y consultar sin conexión: son Git y Mercurial. GitHub y GitLab no son un tipo aparte: son plataformas construidas sobre Git.