Tema 6: Cliente/servidor, servicios web, control de versiones y pruebas

Metodologías de desarrollo de software

Una metodología de desarrollo es un marco de trabajo estructurado que ordena las actividades de análisis, diseño, construcción, pruebas y mantenimiento de un sistema de información, definiendo roles, productos y técnicas. En el contexto de la Administración pública española conviven metodologías clásicas (predictivas, como Métrica v3), marcos ágiles (como Scrum) y marcos de gestión de servicios (como ITIL). No conviene confundirlas: describen fases distintas del ciclo de vida y persiguen objetivos diferentes.

Enfoque predictivo frente a enfoque ágil

Las metodologías predictivas o "en cascada" planifican por adelantado la totalidad del alcance y avanzan por fases secuenciales. Las metodologías ágiles —basadas en el Manifiesto Ágil (2001)— trabajan de forma iterativa e incremental, entregando producto funcional de forma frecuente, adaptándose al cambio y favoreciendo la colaboración con el cliente. Scrum, Kanban o Extreme Programming (XP) son ejemplos de marcos ágiles.

Scrum

Scrum es una metodología (marco de trabajo) ágil para desarrollar, entregar y mantener productos complejos. Es un marco ligero ("lightweight") que ayuda a las personas y equipos a generar valor mediante soluciones adaptativas. Se apoya en el empirismo (las decisiones se basan en lo observado) y en el pensamiento lean, con tres pilares: transparencia, inspección y adaptación.

Scrum define un pequeño número de elementos:

• Roles / responsabilidades (Scrum Team): Product Owner (maximiza el valor del producto y gestiona el Product Backlog), Scrum Master (facilita el proceso y elimina impedimentos) y Developers (construyen el Incremento).

• Eventos: el Sprint (contenedor de los demás) y, dentro de él, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective.

• Artefactos: Product Backlog, Sprint Backlog e Incremento.

El Sprint

El Sprint es el corazón de Scrum: es un ciclo de trabajo de corta duración, de longitud fija de un mes o menos, en el que se produce un Incremento de producto utilizable y potencialmente entregable. En otras palabras, los sprints son los ciclos de trabajo de corta duración en los que se realiza el incremento de producto. Al tener una duración fija (time-box) crean consistencia y ritmo; cuando termina un Sprint, comienza inmediatamente el siguiente. El Incremento es un peldaño concreto hacia el objetivo del producto; cada Incremento se suma a los anteriores y debe cumplir la Definición de Terminado (Definition of Done) para considerarse completado. Todo el equipo Scrum es responsable de crear un Incremento valioso y útil en cada Sprint.

Puntos clave que se preguntan en examen:

• Scrum es un marco/metodología ágil (no es un lenguaje, ni una herramienta de control de versiones, ni una base de datos).

• Un sprint es un ciclo de trabajo de corta duración en el que se realiza un incremento de producto; su duración es fija y de un mes o menos.

ITIL

ITIL (Information Technology Infrastructure Library, Biblioteca de Infraestructura de Tecnologías de la Información) es una colección de mejores prácticas para la gestión de servicios de tecnologías de la información (ITSM, IT Service Management). No es una metodología de desarrollo de software ni un estándar de obligado cumplimiento, sino un conjunto de recomendaciones y buenas prácticas para planificar, entregar, operar y mejorar los servicios TI de forma alineada con las necesidades del negocio.

Características relevantes:

• Fue desarrollada originalmente en los años 80 por la británica CCTA (Central Computer and Telecommunications Agency); actualmente su propiedad y gobierno recaen en AXELOS/PeopleCert.

• ITIL v3 organizaba el ciclo de vida del servicio en cinco fases (Estrategia, Diseño, Transición, Operación y Mejora Continua del Servicio).

• ITIL 4 (2019) reorienta el marco hacia el Sistema de Valor del Servicio (SVS), la cadena de valor del servicio y sus principios guía.

• ITIL se relaciona con la norma ISO/IEC 20000 de gestión de servicios TI.

Idea clave para test: ITIL es una colección de mejores prácticas de gestión de servicios de TI, no un método de codificación ni una metodología ágil.

Métrica v3

Métrica versión 3 es la metodología de planificación, desarrollo y mantenimiento de sistemas de información promovida por el Consejo Superior de Administración Electrónica para las Administraciones públicas españolas. Estructura el trabajo en procesos principales —PSI (Planificación de Sistemas de Información), EVS (Estudio de Viabilidad del Sistema), ASI (Análisis del Sistema de Información), DSI (Diseño del Sistema de Información), CSI (Construcción del Sistema de Información), IAS (Implantación y Aceptación del Sistema) y MSI (Mantenimiento del Sistema de Información)— y define cuatro interfaces transversales que cubren todo el ciclo de vida:

El Plan de Gestión de Riesgos en Métrica v3

Dentro de la Interfaz de Gestión de Proyectos, Métrica v3 contempla la gestión de riesgos, cuyo primer objetivo es identificar los riesgos potenciales del proyecto para poder analizarlos, planificar respuestas y hacerles seguimiento. El Plan de Gestión de Riesgos es el producto que recoge esos riesgos identificados junto con su valoración y las estrategias de mitigación previstas.

En síntesis, el propósito del Plan de Gestión de Riesgos en Métrica v3 es identificar los riesgos potenciales del proyecto (y establecer cómo se van a analizar, tratar y controlar), no gestionar el presupuesto, el código fuente ni las versiones del software.

Fuentes

• The 2020 Scrum Guide — Ken Schwaber & Jeff Sutherland (versión en español europeo): https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-European.pdf

• The 2020 Scrum Guide (inglés): https://scrumguides.org/scrum-guide.html

• PAe — Metodología Métrica v3, Consejo Superior de Administración Electrónica (administracionelectronica.gob.es): https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_METRICA_v3.html

• Referencia estructurada de Métrica v3 (interfaces y procesos): https://manuel.cillero.es/doc/metodologia/metrica-3/

• AXELOS / ITIL 4 — IT Service Management best practice: https://www.axelos.com/certifications/itil-service-management

• ISO/IEC 20000 — IT Service Management: https://www.iso.org/standard/70636.html

CMMI: modelo de madurez de capacidades

CMMI (Capability Maturity Model Integration) es un modelo para evaluar y mejorar los procesos de una organización que desarrolla software y sistemas. Nació en el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon y hoy lo mantiene el CMMI Institute, integrado en ISACA. No es una metodología de desarrollo como Scrum o Métrica v3: no dice cómo construir un producto, sino en qué medida los procesos de la organización están definidos, medidos y mejorados.

Los niveles de madurez

El modelo actual describe los niveles de madurez del 0 al 5:

La diferencia que más se confunde es la del nivel 2 y el nivel 3: en el 2 la gestión se hace proyecto a proyecto; en el 3 hay estándares de toda la organización que se aplican a todos ellos. Y en el nivel 4 aparece el control cuantitativo (por datos), que es el paso previo a la mejora continua del nivel 5.

Fuentes de CMMI

• CMMI Institute (ISACA) — CMMI Levels of Capability and Performance: https://cmmiinstitute.com/learning/appraisals/levels

Control de versiones

Un sistema de control de versiones (VCS, Version Control System) es una herramienta que registra los cambios realizados sobre uno o varios ficheros a lo largo del tiempo, de modo que pueda recuperarse cualquier estado anterior, compararse revisiones y coordinarse el trabajo de varios desarrolladores sobre la misma base de código. Son herramientas específicas de control de versiones de software: Git, Mercurial y Apache Subversion (SVN), a las que se suman los sistemas históricos CVS (Concurrent Versions System) y Microsoft Visual SourceSafe (VSS).

Conviene no confundir el sistema de control de versiones con la plataforma de alojamiento colaborativo que lo aloja. GitHub, GitLab, Bitbucket o Azure DevOps Server son servicios/plataformas construidos sobre un VCS (normalmente Git), pero Bitbucket no es en sí mismo un sistema de control de versiones, sino una plataforma de Atlassian que aloja repositorios Git y que permite la integración con la herramienta JIRA. Tampoco es un VCS JMeter, que es una herramienta de pruebas de carga y rendimiento de Apache.

Modelos: centralizado frente a distribuido

• Centralizado (CVS, Subversion, VSS): existe un único repositorio central con el que cada desarrollador trabaja directamente; el historial reside en el servidor y suele necesitarse conexión para operar.

• Distribuido (Git, Mercurial): cada desarrollador dispone de una copia local completa del repositorio, con todo el historial. Por ello, es INCORRECTO afirmar que "en el modelo distribuido cada desarrollador trabaja directamente con el repositorio central": precisamente lo característico del modelo distribuido es que el trabajo se realiza contra el repositorio local, y solo se sincroniza con el remoto cuando se desea.

Git

Git es un sistema de control de versiones de código libre y arquitectura distribuida, creado por Linus Torvalds. Al ser distribuido, no es necesario tener conexión a internet para realizar confirmaciones (commits): los commits se registran en el repositorio local. En Git, hacer un commit es la acción de almacenar una nueva instantánea (snapshot) del estado del proyecto en el historial de Git.

Comandos esenciales de Git

El fichero .gitignore especifica qué archivos NO deben ser rastreados (ignorados) por el control de versiones. No es un comando, sino un fichero de configuración por directorio.

Apache Subversion (SVN)

Subversion es un sistema de control de versiones centralizado. Para indicar los ficheros que NO deben ser tenidos en cuenta por el control de versiones se emplea la propiedad svn:ignore, establecida con svn propset sobre un directorio versionado; para consultarla se usa svn propget svn:ignore. La propiedad contiene patrones de nombre de fichero separados por saltos de línea y aplica solo al directorio en el que se define, no a sus subdirectorios.

CVS (Concurrent Versions System)

CVS es un VCS centralizado clásico. Comandos relevantes:

• annotate: si se necesita verificar la revisión en que fue modificada cada línea de un archivo, se utiliza el comando annotate (muestra, línea a línea, la última revisión que la modificó y su autor).

• cvs add -kb miFichero: la opción de expansión de palabras clave -kb marca el fichero como binario; al ejecutarlo se está añadiendo un fichero como binario, evitando la conversión de fines de línea entre plataformas y la sustitución de palabras clave.

Mercurial

Mercurial es un sistema de control de versiones distribuido y multiplataforma, orientado a desarrolladores de software, cuyo cliente de línea de órdenes es hg. El comando outgoing (hg outgoing) permite comprobar qué conjuntos de cambios (changesets) se subirían al repositorio de destino si se ejecutara un push; muestra los cambios locales aún no presentes en el remoto, sin llegar a enviarlos.

Herramientas de Microsoft

• Microsoft Visual SourceSafe (VSS) es una herramienta de control de versiones de Microsoft (hoy descatalogada), de modelo centralizado.

• Azure DevOps Server (antes Team Foundation Server, TFS) es la plataforma de control de versiones de Microsoft actual, que soporta tanto repositorios Git como el control centralizado TFVC, además de gestión de proyectos y CI/CD.

Cuadro resumen de identificación

Fuentes

• Git — Documentación oficial (git-scm.com): https://git-scm.com/docs (git-init, git-clone, git-branch, git-tag, git-diff, git-commit, git-push, gitignore)

• Git Reference / gitignore: https://git-scm.com/docs/gitignore

• Apache Subversion — Version Control with Subversion, "Ignoring Unversioned Items" (svn:ignore, propget/propset): https://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html

• Mercurial SCM — Command reference hg outgoing: https://www.mercurial-scm.org/

• CVS — Concurrent Versions System, "Handling binary files" y "Keyword substitution" (-kb, annotate): https://www.gnu.org/software/trans-coord/manual/cvs/html_node/Binary-howto.html

• Atlassian Bitbucket / integración con Jira: https://www.atlassian.com/software/bitbucket

• Microsoft Learn — Azure DevOps Server: https://learn.microsoft.com/azure/devops/

Repositorios: estructura y actualización

Los programas para control de versiones (Git, Mercurial, Subversion, CVS…) guardan el historial en un repositorio. El desarrollador no trabaja directamente sobre él, sino sobre una copia de trabajo (working copy): un árbol de directorios corriente en su equipo, que es su espacio de trabajo privado.

Estructura de un repositorio Subversion: trunk, branches y tags

Subversion no impone ninguna organización de los datos, así que su documentación oficial recomienda una convención de estructura. Cada proyecto tiene una raíz de proyecto en el repositorio, y dentro de ella tres subdirectorios:

Si el repositorio aloja un solo proyecto, su raíz puede hacer de raíz de proyecto. Si aloja varios, cada uno tiene su propia raíz con su trunk, branches y tags.

Estructura de un proyecto Git: las tres secciones

Un proyecto Git tiene tres secciones principales:

• El directorio de Git (Git directory), donde se almacenan los metadatos y la base de datos de objetos del proyecto. Es lo que se copia al clonar un repositorio.

• El directorio de trabajo (working directory): una copia de una versión del proyecto, extraída de esa base de datos para usarla o modificarla.

• El área de preparación (staging area), también llamada índice (index). Es un archivo que guarda qué irá en la próxima confirmación.

De ahí salen los tres estados de un archivo en Git:

• Modificado (modified): ha cambiado desde que se obtuvo del repositorio y no se ha preparado.

• Preparado (staged): se ha añadido al área de preparación para la próxima confirmación.

• Confirmado (committed): está almacenado de forma segura en la base de datos local.

Actualización: el ciclo de trabajo típico

El libro oficial de Subversion describe así el ciclo de trabajo diario:

1. Actualizar la copia de trabajo con svn update.

2. Hacer los cambios: editar ficheros. Los cambios de estructura se hacen con svn add, svn delete, svn copy y svn move.

3. Revisar los cambios con svn status y svn diff.

4. Corregir los errores: svn revert devuelve un fichero o directorio a su estado sin modificar.

5. Resolver los conflictos, es decir, integrar los cambios que otros publicaron mientras tanto. Se hace de nuevo con svn update; si quedan conflictos locales, se resuelven con svn resolve.

6. Publicar (confirmar) los cambios con svn commit, que los envía al repositorio. Si se aceptan, crean las versiones más recientes.

Al ejecutar svn update, Subversion muestra junto a cada elemento un código de una letra que indica qué acción ha hecho para poner al día la copia de trabajo.

En Git, el equivalente es traer los cambios del remoto (git pull) y, en local, preparar los archivos (añadirlos al área de preparación) y confirmarlos (git commit). Confirmar toma los archivos tal como están en el área de preparación y guarda esa instantánea de forma permanente en el directorio de Git.

Fuentes de la estructura y actualización

• Version Control with Subversion (libro oficial de Apache Subversion, 1.7), «Recommended Repository Layout» y «Basic Work Cycle»: https://svnbook.red-bean.com/en/1.7/svn.tour.importing.html y https://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html

• Pro Git (git-scm.com, edición en español), «Fundamentos de Git — Los Tres Estados»: https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Fundamentos-de-Git

Pruebas de software

Las pruebas constituyen el conjunto de actividades encaminadas a verificar y validar que un sistema de información cumple los requisitos especificados y funciona correctamente. En el contexto de la Administración española, la metodología de referencia es MÉTRICA Versión 3, que estructura las pruebas a lo largo del ciclo de vida (procesos de Construcción del Sistema de Información —CSI— e Implantación y Aceptación del Sistema —IAS—). Junto a ella conviven numerosas herramientas de software libre para automatizar los distintos niveles y tipos de prueba.

Tipos de pruebas en MÉTRICA V3

MÉTRICA V3 distingue varios tipos de prueba, cada uno con un objetivo diferenciado:

• Pruebas unitarias: verifican el comportamiento de cada componente o módulo de forma aislada.

• Pruebas de integración: su finalidad es verificar que los distintos componentes o subsistemas interactúan correctamente a través de sus interfaces, tanto internas como externas, comprobando que cubren la funcionalidad establecida y se ajustan a los requisitos especificados. En términos de propósito, evalúan la capacidad del software para trabajar de manera efectiva con otros componentes y sistemas.

• Pruebas del sistema: comprueban el sistema completo integrado frente a los requisitos.

• Pruebas de implantación: validan el funcionamiento en el entorno de operación real.

• Pruebas de aceptación: permiten al usuario validar que el software cumple con los requisitos establecidos en la Especificación de Requisitos de Pruebas, desde el punto de vista de su funcionalidad y rendimiento.

• Pruebas de regresión: comprueban que los cambios sobre un componente de un sistema de información no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados (eliminación del "efecto onda"). Estas pruebas sí pueden automatizarse —afirmar que no es posible automatizarlas es incorrecto—; de hecho, la automatización es lo que las hace viables al repetirse tras cada cambio.

• Pruebas de rendimiento: consisten en determinar que los tiempos de respuesta están dentro de los intervalos establecidos en las especificaciones del sistema.

• Pruebas de carga: evalúan la capacidad del software para manejar grandes volúmenes de datos y usuarios concurrentes.

Documentos y planificación de las pruebas en MÉTRICA V3

MÉTRICA V3 formaliza la actividad de pruebas mediante varios productos:

• Plan de Pruebas: su propósito es establecer la estrategia y los objetivos de las pruebas. Recoge las actividades de prueba a realizar según una planificación y se inicia en fases tempranas del desarrollo.

• Especificación del Plan de Pruebas: detalla el plan e incluye, entre sus tareas, la Definición del Alcance de las Pruebas, la Definición de Requisitos del Entorno de Pruebas y la Definición de las Pruebas de Aceptación del Sistema.

• Especificación de Requisitos de Pruebas: sirve como guía para la realización de las pruebas y permite verificar que el sistema de información cumple las necesidades establecidas por el usuario, con las debidas garantías de calidad. Es la referencia contra la que se validan las pruebas de aceptación.

• Informe de Pruebas (o Evaluación del Resultado de las Pruebas): su propósito es documentar los resultados de las pruebas realizadas.

Verificación y validación del sistema

Las pruebas son el medio principal de dos actividades que conviene no confundir: la verificación y la validación. La norma ISO 9000:2015 (vocabulario de los sistemas de gestión de la calidad) las define así:

• Verificación (3.8.12): «confirmación, mediante la aportación de evidencia objetiva de que se han cumplido los requisitos especificados». La evidencia puede ser el resultado de una inspección o de otras formas de determinación, como realizar cálculos alternativos o revisar los documentos.

• Validación (3.8.13): «confirmación, mediante la aportación de evidencia objetiva, de que se han cumplido los requisitos para una utilización o aplicación específica prevista». Su evidencia es el resultado de un ensayo u otra forma de determinación, y las condiciones de utilización pueden ser reales o simuladas.

La diferencia está en contra qué se comprueba: la verificación confronta el producto con los requisitos especificados (¿se ha construido conforme a lo especificado?) y la validación con el uso previsto (¿sirve para aquello para lo que se pidió?). Por eso, en MÉTRICA V3, las pruebas unitarias, de integración y del sistema son sobre todo actividades de verificación, mientras que las pruebas de aceptación, en las que el usuario comprueba el sistema frente a sus necesidades, son la validación por excelencia.

Técnicas de prueba: caja blanca y caja negra

MÉTRICA V3 distingue dos enfoques para diseñar los casos de prueba:

• Enfoque estructural o de caja blanca: «se verifica la estructura interna del componente con independencia de la funcionalidad establecida para el mismo», por lo que no se comprueba la corrección de los resultados. Ejemplos: ejecutar todas las instrucciones del programa, localizar código no usado o comprobar los caminos lógicos del programa.

• Enfoque funcional o de caja negra: se comprueba el correcto funcionamiento analizando las entradas y salidas y verificando que el resultado es el esperado, sin preocuparse por la estructura interna.

En las pruebas unitarias el enfoque adoptado está orientado claramente a los casos de caja blanca, complementados con caja negra, porque el tamaño del componente permite examinar toda su lógica. Los casos de prueba deben contemplar tanto las condiciones válidas y esperadas como las inválidas e inesperadas.

Mantenimiento de sistemas de información

En MÉTRICA V3 el proceso de Mantenimiento de Sistemas de Información (MSI) tiene como objetivo «la obtención de una nueva versión de un sistema de información» a partir de las peticiones de mantenimiento de los usuarios, motivadas por un problema detectado o por la necesidad de una mejora. Se describen cuatro tipos de mantenimiento:

• Correctivo: los cambios precisos para corregir errores del producto software.

• Evolutivo: las incorporaciones, modificaciones y eliminaciones necesarias para cubrir la expansión o cambio en las necesidades del usuario.

• Adaptativo: las modificaciones que afectan a los entornos en los que el sistema opera (configuración del hardware, software de base, gestores de base de datos, comunicaciones…).

• Perfectivo: las acciones para mejorar la calidad interna del sistema: reestructuración del código, definición más clara del sistema y optimización del rendimiento y la eficiencia.

Solo el correctivo y el evolutivo entran en el ámbito de MÉTRICA V3: el adaptativo y el perfectivo quedan fuera porque requieren actividades y perfiles distintos de los del proceso de desarrollo. Cada modificación da lugar a una nueva versión del sistema, que se controla con la gestión de la configuración y las herramientas de control de versiones, y las pruebas de regresión comprueban que el cambio no ha introducido errores en lo que no se tocó.

Fuentes de este apartado

• ISO 9000:2015, Sistemas de gestión de la calidad — Fundamentos y vocabulario (traducción oficial), entradas 3.8.12 y 3.8.13: https://www.iso.org/obp/ui/es/#iso:std:iso:9000:ed-4:v1:es

• MÉTRICA v3, Técnicas — Pruebas unitarias (enfoques de caja blanca y caja negra): https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/pruebas/unitarias/

• MÉTRICA v3, Proceso de Mantenimiento de Sistemas de Información (MSI): https://manuel.cillero.es/doc/metodologia/metrica-3/procesos-principales/msi/

Herramientas de automatización y pruebas

Pruebas unitarias — JUnit

JUnit es el conjunto de bibliotecas para pruebas unitarias de aplicaciones Java. Forma parte de la familia xUnit y permite definir casos de prueba, aserciones y su ejecución automatizada, integrándose habitualmente en los entornos de compilación e integración continua.

Pruebas funcionales web y móviles — Selenium y Appium

Selenium es un entorno (framework) de pruebas de software para aplicaciones basadas en la web, específicamente diseñado para la automatización de pruebas funcionales sobre aplicaciones web. Sus pruebas pueden ejecutarse en Windows, Linux y OSX (macOS), y admite múltiples lenguajes (Java, C#, Python, Ruby, JavaScript, etc.) comunicándose con los navegadores mediante el protocolo WebDriver.

Appium es una herramienta de automatización de código abierto para ejecutar scripts y probar aplicaciones nativas, aplicaciones web y aplicaciones híbridas sobre Android o iOS utilizando un WebDriver. Extiende el modelo de Selenium al ámbito móvil.

Pruebas de carga, estrés y rendimiento

Apache JMeter es una aplicación Java de código abierto para pruebas de carga y estrés, que permite simular escenarios de concurrencia de usuarios sobre servidores, redes u objetos. Puede realizar pruebas de rendimiento y pruebas unitarias. Se define con claridad como una herramienta de pruebas unitarias para conexiones de bases de datos con JDBC, FTP, LDAP, servicios web, JMS, HTTP y conexiones TCP genéricas. Soporta, entre otros, los protocolos HTTP/HTTPS, SOAP/REST, FTP, JDBC, LDAP, JMS, SMTP/POP3/IMAP y TCP; es decir, se puede utilizar con todos ellos. En cambio, NO es una funcionalidad de JMeter capturar tramas de red (esa función corresponde a analizadores como Wireshark).

Gatling es una herramienta de prueba de carga de código libre que se integra con soluciones existentes y ofrece integración con herramientas de CI/CD. Está construida sobre Scala, Akka y Netty; su marco distribuido permite la computación totalmente asíncrona, modelando los usuarios virtuales como mensajes ligeros en lugar de hilos, lo que le permite simular grandes cargas con pocos recursos.

Tsung es una herramienta de software libre que se especializa en pruebas de carga y estrés para aplicaciones basadas en protocolos de base de datos (además de HTTP, WebDAV, LDAP, XMPP, MQTT, etc.), destacando por su capacidad de generar cargas distribuidas de alta concurrencia.

Producto que NO es de pruebas — OneTrust

Conviene distinguir las herramientas de prueba de otros productos. OneTrust NO es un producto orientado a las pruebas de software: es una plataforma de gestión de privacidad, cumplimiento normativo y gobierno de datos (GRC), ajena al ámbito del testing.

Resumen comparativo de herramientas

Fuentes

• MÉTRICA Versión 3 — Ministerio (portal de Administración Electrónica / preparatic): https://www.preparatic.org/material/20100918/Metrica_v3.pdf

• MÉTRICA v3, Técnicas de Pruebas (Integración y Regresión) — manuel.cillero.es: https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/pruebas/

• Apache JMeter — sitio oficial (protocolos soportados): https://jmeter.apache.org/

• Apache JMeter — Wikipedia (lista de protocolos): https://en.wikipedia.org/wiki/Apache_JMeter

• Gatling — documentación oficial (arquitectura asíncrona, CI/CD): https://docs.gatling.io/

• Gatling — repositorio oficial: https://github.com/gatling/gatling

• Appium — sitio oficial (automatización móvil vía WebDriver): https://appium.github.io/appium.io/index.html

• JUnit — sitio oficial: https://junit.org/

• Tsung — documentación oficial: http://tsung.erlang-projects.org/

TDD: desarrollo guiado por pruebas

El desarrollo guiado por pruebas (TDD, Test-Driven Development) es una técnica que guía el desarrollo escribiendo primero las pruebas. La desarrolló Kent Beck a finales de los años noventa como parte de Extreme Programming (XP).

El ciclo rojo-verde-refactorizar

TDD repite un ciclo corto de tres pasos, que se resume como rojo – verde – refactorizar (Red – Green – Refactor):

1. Rojo: se escribe una prueba para la siguiente funcionalidad que se quiere añadir. Como el código aún no existe, la prueba falla.

2. Verde: se escribe el código funcional imprescindible hasta que la prueba pasa.

3. Refactorizar: se reestructura el código, el nuevo y el anterior, para que quede bien organizado, manteniendo las pruebas en verde.

Saltarse la fase de refactorización es la forma más habitual de hacer mal TDD: el código pasa las pruebas, pero se va degradando.

TDD produce como efecto una batería de pruebas automatizadas que acompaña al código desde el principio y que se ejecuta en cada integración, por lo que encaja con la integración continua.

Fuentes de TDD

• Martin Fowler — Test-Driven Development (bliki): https://martinfowler.com/bliki/TestDrivenDevelopment.html