Metodologías de desarrollo. Pruebas. Programas para control de versiones. Plataformas de desarrollo colaborativo de software (PDF)

1. Metodologías de desarrollo 1.1. Introducción Metodología de desarrollo: es un conjunto de principios, prácticas, y procesos que guían cómo se debe planificar, gestionar, y ejecutar el ciclo de vida del desarrollo de software. Tipos de Metodología Metodologías Tradicionales (Predictiv...

1. Metodologías de desarrollo 1.1. Introducción Metodología de desarrollo: es un conjunto de principios, prácticas, y procesos que guían cómo se debe planificar, gestionar, y ejecutar el ciclo de vida del desarrollo de software. Tipos de Metodología Metodologías Tradicionales (Predictivas): se basan en una fuerte planificación durante todo el desarrollo. Se focalizan en la documentación, planificación y procesos ○ Cascada (Waterfall): metodología secuencial en la que cada fase del desarrollo debe completarse antes de pasar a la siguiente. Las fases típicas incluyen requisitos, diseño, implementación, pruebas, y mantenimiento. ○ Modelo en V (V-Model): extensión del modelo en cascada que enfatiza las fases de verificación y validación. Por cada fase de desarrollo hay una fase de prueba correspondiente. ○ Modelo en Espiral: Se centra en el análisis de riesgos y combina aspectos de desarrollo iterativo con la metodología en cascada. Es adecuado para grandes proyectos con mucha incertidumbre. Ágiles: el desarrollo de software es incremental, cooperativo, sencillo y adaptado. Ponen de relevancia que la capacidad de respuesta a un cambio es más importante que el seguimiento estricto de un plan ○ XP ○ Scrum ○ FDD ○ BDD - Behavior-driven development ○ Kanban: pizarra con tareas (To do - Doing - Done)  1.2. RAD: Rapid Application Development RAD es una metodología de desarrollo enfocada en reducir el tiempo entre el diseño inicial y el producto final mediante prototipos rápidos, ajustes constantes y la participación continua del usuario. La metodología se centra en dividir el desarrollo en módulos que se pueden trabajar de manera independiente, con ciclos rápidos de revisión y mejora. Fases del Proceso RAD Requisitos y Planificación: Se hace una recolección rápida de requisitos clave, generalmente en una serie de reuniones breves e intensivas con el usuario o cliente. ○ Se identifican las características críticas del sistema sin entrar en detalles exhaustivos, priorizando funcionalidades esenciales. Diseño del Usuario: En esta fase, se crea un diseño interactivo basado en prototipos que representan la funcionalidad del sistema. ○ El equipo colabora estrechamente con el cliente, permitiendo ajustes continuos de los prototipos. ○ Aquí, se establecen las bases de la interfaz de usuario, el diseño de interacción y las funcionalidades. Construcción Rápida: La fase de desarrollo donde se construyen los módulos del sistema en paralelo. Se hacen pruebas continuas y se integra cada módulo tan pronto como esté funcional. ○ La retroalimentación constante permite hacer modificaciones rápidas sin esperar a una revisión completa del sistema. Transición: Se realiza la implementación del sistema y la transición al entorno de producción. ○ En esta fase, se capacita a los usuarios, se documenta el sistema y se realizan los ajustes finales. ○ A menudo incluye pruebas finales, mejoras de rendimiento y optimización para garantizar que el sistema esté listo para uso diario.  1.3. RUP: Rational Unified Process RUP es una metodología de desarrollo de software orientada a objetos que se basa en un enfoque iterativo e incremental. Está fundamentada en la arquitectura de software y se organiza en fases claramente definidas, asegurando un desarrollo controlado y documentado en cada etapa. RUP se caracteriza por su flexibilidad, ya que puede adaptarse a diferentes tipos de proyectos y permite el ajuste de las prácticas y artefactos según las necesidades específicas. Fases de RUP RUP se divide en cuatro fases principales que representan los hitos en el ciclo de vida del proyecto: 1. Inicio (Inception): ○ Se define la visión y el alcance del proyecto, así como los principales requisitos y riesgos. ○ Se crea una propuesta del proyecto y se realizan las primeras estimaciones de tiempo y coste. ○ Resultados: Documento de visión, casos de uso iniciales y modelo de negocio preliminar. 2. Elaboración (Elaboration): ○ Se detalla la arquitectura del sistema y se aclaran los requisitos clave. ○ Es una fase de mayor exploración, en la que se desarrollan prototipos y se valida la viabilidad técnica. ○ Resultados: Arquitectura base del sistema, plan detallado para la fase de construcción y lista de riesgos ajustada. 3. Construcción (Construction): ○ Se construyen los componentes del sistema, se implementan los casos de uso y se realizan pruebas continuas. ○ Esta fase tiene un enfoque en la producción del sistema, manteniendo el modelo arquitectónico y los requisitos previamente establecidos. ○ Resultados: Software funcional y probado, manuales de usuario y plan de despliegue. 4. Transición (Transition): ○ Se despliega el sistema en el entorno de producción, y se realizan ajustes finales. ○ Esta fase incluye la capacitación de los usuarios, la documentación final y la corrección de errores. ○ Resultados: Producto final entregado, aceptación del cliente y documentación completa. Cada fase incluye iteraciones que permiten realizar ajustes, garantizar la calidad y minimizar el riesgo a medida que avanza el proyecto.  1.4. SCRUM Scrum es un marco de trabajo ágil diseñado para ayudar a los equipos a trabajar de manera eficiente en proyectos complejos, logrando una entrega continua de valor. Fue desarrollado por Ken Schwaber y Jeff Sutherland y forma parte de la familia de metodologías ágiles. La principal característica de Scrum es su enfoque en la colaboración, la autoorganización y la mejora continua. Roles en Scrum 1. Product Owner (Dueño del Producto): ○ Responsable de maximizar el valor del producto y de gestionar el Product Backlog. ○ Define y prioriza los requisitos (historias de usuario) y asegura que el equipo tenga claro qué es lo que debe construir. ○ Actúa como enlace entre el equipo de desarrollo y los stakeholders. 2. Scrum Master: ○ Facilita el proceso Scrum y asegura que el equipo siga las prácticas ágiles. ○ Elimina los obstáculos que puedan interferir con el progreso del equipo. ○ Es un líder-servicial, ayuda al equipo a auto-organizarse y facilita los eventos de Scrum. 3. Equipo de Desarrollo: ○ Equipo multidisciplinar que incluye desarrolladores, testers y diseñadores. ○ Es auto-organizado y tiene la responsabilidad de completar los elementos del Sprint Backlog. ○ Suele ser un equipo pequeño (3 a 9 personas) que colabora para cumplir con los objetivos del sprint. Artefactos en Scrum 1. Product Backlog: ○ Es la lista priorizada de todas las funcionalidades, mejoras, errores y tareas necesarias para el proyecto. ○ Las historias de usuario son el formato más común para los elementos del Product Backlog. ○ El Product Owner es responsable de gestionar y priorizar el backlog. 2. Sprint Backlog: ○ Conjunto de elementos seleccionados del Product Backlog que el equipo se compromete a completar en el sprint actual. ○ Incluye una meta del sprint (objetivo específico para esa iteración) y las tareas necesarias para completarlo.  3. Incremento: ○ Representa el avance del producto, el cual debe estar en un estado utilizable y listo para producción. ○ Al final de cada sprint, el equipo presenta el incremento, que incluye todos los elementos completados y probados. Eventos en Scrum 1. Sprint: ○ Iteración corta (generalmente de 1 a 4 semanas) en la que el equipo trabaja para completar un conjunto de elementos del Sprint Backlog. ○ Cada sprint tiene una meta clara y al final se produce un incremento. 2. Sprint Planning (Planificación del Sprint): ○ Reunión inicial del sprint donde el equipo define qué elementos del Product Backlog se incluirán en el Sprint Backlog. ○ El Product Owner ayuda a priorizar los elementos, y el equipo de desarrollo estima las tareas necesarias para cumplir con la meta del sprint. 3. Daily Scrum (Reunión Diaria): ○ Reunión de 15 minutos donde cada miembro del equipo responde a tres preguntas clave: ¿Qué hice ayer? ¿Qué haré hoy? ¿Hay algún obstáculo? ○ Ayuda a mantener el equipo alineado y a identificar problemas tempranamente. 4. Sprint Review (Revisión del Sprint): ○ Reunión al final del sprint donde el equipo presenta el incremento al Product Owner y a otros stakeholders. ○ Se recopila retroalimentación y se evalúan los logros del sprint, lo que puede llevar a ajustes en el Product Backlog. 5. Sprint Retrospective (Retrospectiva del Sprint): ○ Reunión donde el equipo reflexiona sobre el sprint recién finalizado. ○ Identifica aspectos que funcionaron bien y áreas de mejora, estableciendo acciones para mejorar en futuros sprints.  1.5. Extreme Programming Extreme Programming es una metodología ágil que se centra en desarrollar software de alta calidad mediante la implementación de prácticas de programación avanzadas y la retroalimentación constante del cliente. XP promueve la adaptabilidad, permitiendo que el equipo responda rápidamente a los cambios en los requisitos del cliente, especialmente en entornos donde los requisitos no están claros desde el principio. Elementos de la metodología Las historias de usuario: son la técnica utilizada para especificar los requisitos del software. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarlas en unas semanas. Las historias de usuario se descomponen en tareas de programación y se asignan a los programadores para ser implementadas durante una iteración. Roles XP: ○ Programador: el programador escribe las pruebas unitarias y produce el código del sistema ○ Cliente: escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en apoyar mayor valor al negocio. ○ Encargado de pruebas (tester): ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para las pruebas. ○ Encargado de seguimiento (tracker): proporciona realimentación al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteración. ○ Entrenador (coach): es el responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente. ○ Consultor: es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas. ○ Gestor (big boss): es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación. Proceso XP: el ciclo de desarrollo consiste en los siguientes pasos: ○ El cliente define el valor de negocio a implementar. ○ El programador estima el esfuerzo necesario para su implementación. ○ El programador construye ese valor. ○ Vuelve al paso 1. El ciclo de vida ideal de XP consiste en 6 fases: exploración, planificación de la entrega, iteraciones, producción, mantenimiento y muerte del proyecto  1.6. Métrica 3 Se concibe como una Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información. Puede ser utilizada libremente con la única restricción de citar la fuente de su propiedad intelectual: el Ministerio de Administraciones Pública Métrica v3 se centra en proporcionar un marco estandarizado para el ciclo de vida de desarrollo de sistemas, mejorando la productividad y la calidad en los proyectos de desarrollo. Sus principales objetivos son: Definir procedimientos y roles claros en el ciclo de vida de desarrollo de software. Asegurar la adaptabilidad y reutilización del software. Proveer herramientas de gestión y control de calidad. Orientar el desarrollo de sistemas hacia las necesidades del usuario y la seguridad de la información. Características principales: Tiene un enfoque orientado al proceso. Organizada en Procesos, Actividades y Tareas que cubren todas las fases del ciclo de vida de un proyecto. Además, define roles y entrega productos específicos en cada fase. Cubre el proceso de Desarrollo y el proceso de Mantenimiento de Sistemas de Información. Ha sido concebida para abarcar el desarrollo completo de sistemas de información sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto. La metodología descompone cada uno de los procesos en actividades, y éstas a su vez en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales acciones, productos, técnicas, prácticas y participantes. El orden asignado a las actividades no debe interpretarse como secuencia en su realización, ya que éstas pueden realizare en orden diferente a su numeración o bien en paralelo, como se muestra en los gráficos de cada proceso. Sin embargo, no se dará por acabado un proceso hasta no haber finalizado todas las actividades del mismo determinadas al inicio del proyecto. Métrica v3 define tres procesos principales: 1. Proceso de Planificación de Sistemas de Información (PSI): tiene como objetivo la obtención de un marco de referencia para el desarrollo de sistemas de información que responda a los objetivos estratégicos de la organización. ○ Se enfoca en alinear los sistemas de información con los objetivos estratégicos de la organización. ○ Incluye el análisis del estado actual de los sistemas de información y la definición de un plan estratégico para mejorar la infraestructura tecnológica. ○ Define actividades como el análisis de necesidades, identificación de sistemas críticos y propuesta de un plan de acción. 2. Proceso de Desarrollo de Sistemas de Información (PDS): ○ Es el núcleo del ciclo de vida de desarrollo de software en Métrica v3. ○ Comprende fases como análisis, diseño, construcción e implantación. ○ Se subdivide en cuatro subprocesos: Estudio de Viabilidad del Sistema (EVS): Evaluación inicial de la viabilidad técnica, económica y organizativa del proyecto. Análisis del Sistema de Información (ASI): Análisis detallado de los requisitos del sistema, en función de las necesidades del usuario. Diseño del Sistema de Información (DSI): Creación de un modelo detallado del sistema, que incluye la arquitectura, diseño de la base de datos, diseño de la interfaz de usuario y procedimientos. Construcción del Sistema de Información (CSI): Implementación y pruebas del software, así como la integración de todos los componentes en un sistema funcional. Implantación y Aceptación del Sistema de Información (IAS): Preparación para la puesta en producción, despliegue y transferencia a producción. Incluye pruebas finales y aceptación por parte del usuario. 3. Proceso de Mantenimiento de Sistemas de Información (MSI): ○ Establece un proceso estructurado para mantener y mejorar los sistemas ya implementados. ○ Define actividades para corregir errores, mejorar el rendimiento y adaptar el sistema a cambios en la normativa o en los requisitos del usuario. Las interfaces descritas en la metodología son: Gestión de Proyectos (GP): tiene como finalidad principal la planificación, el seguimiento y control de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un Sistema de Información. Como consecuencia de este control es posible conocer en todo momento qué problemas se producen y resolverlos o paliarlos lo más pronto posible, lo cual evitará desviaciones temporales y económicas. Seguridad (SEG): el análisis de los riesgos constituye una pieza fundamental en el diseño y desarrollo de sistemas de información seguros. Si bien los riesgos que afectan a un sistema de información son de distinta índole: naturales (inundaciones, incendios, etc.) o lógicos (fallos propios, ataques externos, virus, etc.) siendo estos últimos los contemplados en la interfaz de Seguridad de Métrica v3. Gestión de la Configuración (GC): consiste en la aplicación de procedimientos administrativos y técnicos durante el desarrollo del sistema de información y su posterior mantenimiento. Su finalidad es identificar, definir, proporcionar información y controlar los cambios en la configuración del sistema, así como las modificaciones y versiones de los mismos. Este proceso permitirá conocer el estado de cada uno de los productos que se hayan definido como elementos de configuración, garantizando que no se realizan cambios incontrolados y que todos los participantes en el desarrollo del sistema disponen de la versión adecuada de los productos que manejan. Aseguramiento de la Calidad (CAL): el objetivo esta interfaz es proporcionar un marco común de referencia para la definición y puesta en marcha de planes específicos de aseguramiento de calidad aplicables a proyectos concretos. 2. Clasificación pruebas Métrica 3 2.1. Unitarias Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado. Caja Blanca(logic driven). Se verifica la estructura interna del componente con independencia de la funcionalidad establecida para el mismo. ○ Técnicas De interfaz: analiza el flujo de datos hacia y desde el componente, para asegurar que la información fluye adecuadamente. De estructuras de datos locales: asegura la integridad de los datos durante la ejecución del código. Las pruebas que se realizan en los datos: referencias (accesos a los datos), declaraciones (definiciones), cálculos (errores de uso de datos) y comparaciones (errores en sentencias condicionales o repetitivas). Del camino básico: permite la obtención de una medida de la complejidad lógica del diseño procedimental De bucles o de condiciones límite: se comprueba la validez de un bucle Caja Negra(data driven). Se comprueba el correcto funcionamiento de los componentes del sistema de información, analizando las entradas y salidas y verificando que el resultado es el esperado ○ Técnicas Particiones de equivalencia: Técnica sustentada en el concepto de clase de equivalencia, agrupación de un conjunto de valores de una determinada entrada donde el comportamiento del componente es igual, considerándose su estado como válido o inválido. Análisis de los valores límite o frontera: parte de la base que proporciona la experiencia de que los errores suelen aparecer con mayor probabilidad en los extremos de los campos de entrada Valores típicos de error y valores imposibles: consiste en probar ciertos valores según la entrada concreta que, a priori, deben causar un error. La elección de los valores depende de la experiencia de los desarrolladores. Tabla de decisión: se identifican las condiciones (a menudo entradas) y las acciones resultantes (a menudo salidas) del sistema.  2.2. Integración Verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes. Integración incremental ○ De arriba abajo (top-down). El primer componente que se desarrolla y prueba es el primero de la jerarquía (A). Los componentes de nivel más bajo se sustituyen por componentes auxiliares para simular a los componentes invocados. En este caso no son necesarios componentes conductores. Una de las ventajas de aplicar esta estrategia es que las interfaces entre los distintos componentes se prueban en una fase temprana y con frecuencia. ○ De abajo arriba (bottom-up). En este caso se crean primero los componentes de más bajo nivel (E, F) y se crean componentes conductores para simular a los componentes que los llaman. A continuación se desarrollan los componentes de más alto nivel (B, C, D) y se prueban. Por último dichos componentes se combinan con el que los llama (A). Los componentes auxiliares son necesarios en raras ocasiones. Este tipo de enfoque permite un desarrollo más en paralelo que el enfoque de arriba abajo, pero presenta mayores dificultades a la hora de planificar y de gestionar. ○ Estrategias combinadas. A menudo es útil aplicar las estrategias anteriores conjuntamente. De este modo, se desarrollan partes del sistema con un enfoque «top-down«, mientras que los componentes más críticos en el nivel más bajo se desarrollan siguiendo un enfoque «bottom-up«. En este caso es necesaria una planificación cuidadosa y coordinada de modo que los componentes individuales se «encuentren» en el centro. Integración no incremental: Se prueba cada componente por separado y posteriormente se integran todos de una vez realizando las pruebas pertinentes. Este tipo de integración se denomina también Big-Bang (gran explosión).  2.3. Sistema objetivo ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica. Pruebas funcionales. Dirigidas a asegurar que el sistema de información realiza correctamente todas las funciones que se han detallado en las especificaciones dadas por el usuario del sistema. Pruebas de comunicación. Determinan que las interfaces entre los componentes del sistema funcionan adecuadamente, tanto a través de dispositivos remotos, como locales. Asimismo, se han de probar las interfaces hombre/máquina. 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 volumen. Consisten en examinar el funcionamiento del sistema cuando está trabajando con grandes volúmenes de datos, simulando las cargas de trabajo esperadas. Pruebas de sobrecarga. Consisten en comprobar el funcionamiento del sistema en el umbral límite de los recursos, sometiéndole a cargas masivas. ○ El objetivo es establecer los puntos extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos. Pruebas de disponibilidad de datos. Consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de equipo físico como lógico, sin comprometer la integridad de los datos. Pruebas de facilidad de uso. Consisten en comprobar la adaptabilidad del sistema a las necesidades de los usuarios, tanto para asegurar que se acomoda a su modo habitual de trabajo, como para determinar las facilidades que aporta al introducir datos en el sistema y obtener los resultados. Pruebas de operación. Consisten en comprobar la correcta implementación de los procedimientos de operación, incluyendo la planificación y control de trabajos, arranque y rearranque del sistema, etc. Pruebas de entorno. Consisten en verificar las interacciones del sistema con otros sistemas dentro del mismo entorno. Pruebas de seguridad. Consisten en verificar los mecanismos de control de acceso al sistema para evitar alteraciones indebidas en los datos. 2.4. Implantación Comprobar el funcionamiento correcto del sistema integrado de hardware y software en el entorno de operación, y permitir al usuario que, desde el punto de vista de operación, realice la aceptación del sistema una vez instalado en su entorno real y en base al cumplimiento de los requisitos no funcionales especificados seguridad van dirigidas a verificar que los mecanismos de protección incorporados al sistema cumplen su objetivo  rendimiento a asegurar que el sistema responde satisfactoriamente en los márgenes establecidos en cuanto tiempos de respuesta, de ejecución y de utilización de recursos, así como los volúmenes de espacio en disco y capacidad operación se comprueba que la planificación y control de trabajos del sistema se realiza de acuerdo a los procedimientos establecidos, considerando la gestión y control de las comunicaciones y asegurando la disponibilidad de los distintos recursos gestión de copias de seguridad y recuperación, con el objetivo de verificar que el sistema no ve comprometido su funcionamiento al existir un control y seguimiento de los procedimientos de salvaguarda y de recuperación de la información, en caso de caídas en los servicios o en algunos de sus componentes 2.5. Aceptación Validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento 2.6. Regresión Comprobar 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 2.7. Otro tipo de pruebas Pruebas de humo (smoke testing): son una revisión rápida de un producto de software para comprobar que funciona y no tiene defectos evidentes que interrumpan la operación básica del mismo. Las pruebas fuzzing testing son un conjunto de pruebas de caja negra que permiten descubrir errores de implementación mediante la introducción de datos al azar, inválidos o malformados. Las pruebas de usabilidad permiten determinar hasta qué punto el software es comprendido, aprendido, usado y atractivo para los usuarios en condiciones específicas de uso.  2.8. Herramientas para la prueba de Software Nombre Observaciones Pruebas unitarias para aplicaciones Java. Es ampliamente utilizado para JUnit validar métodos individuales. Pruebas unitarias para Java, permite simular dependencias y realizar pruebas Mockito basadas en mocks. PHP Unit Pruebas unitarias para PHP CPPUnit Pruebas unitarias para C++ Pruebas unitarias para.NET y otras plataformas. Parte de la familia de xUnit herramientas xUnit (como JUnit). TestNG Pruebas unitarias para Java, basado en JUnit y NUnit Pruebas unitarias para aplicaciones JavaScript; ideal para probar funciones y QUnit módulos en aplicaciones web. Pruebas funcionales y de automatización para interfaces de usuario web; Selenium soporta múltiples navegadores. Pruebas de API; permite realizar pruebas funcionales y de integración en APIs Postman RESTful. Pruebas de aceptación y funcionales. Facilita pruebas en inglés sencillo para Cucumber aplicaciones BDD (Behavior-Driven Development). Pruebas de rendimiento, carga y estrés; principalmente para aplicaciones web JMeter y servicios. Pruebas de automatización para aplicaciones móviles, tanto en iOS como Appium Android. Pruebas de servicios web SOAP y REST, útil para pruebas de funcionalidad, SoapUI carga y seguridad en APIs. Pruebas de rendimiento y carga para aplicaciones web, aplicaciones móviles y LoadRunner entornos de red. Pruebas de automatización y funcionalidad para aplicaciones web, API y Katalon Studio móviles; soporte de BDD. Pruebas de aceptación y funcionales con un enfoque en palabras clave; Robot Framework extensible a través de Python. Protractor Pruebas end-to-end para aplicaciones Angular y otros frameworks JavaScript. Pruebas end-to-end y de integración para aplicaciones web; incluye Cypress herramientas para pruebas rápidas y visualización en tiempo real. Pruebas unitarias y de integración para Java y Groovy, útil para pruebas de Spock comportamiento BDD. Pruebas unitarias para aplicaciones.NET, similar a JUnit pero orientado al NUnit ecosistema.NET. Pruebas de automatización para aplicaciones de escritorio, móviles y web; Ranorex incluye grabación y reproducción.  Pruebas funcionales de aplicaciones empresariales de escritorio y web; incluye HP UFT soporte para pruebas de regresión. Unit.sj Framework de pruebas para JS Framework de pruebas JS usado en TypeScript, Node.js, React, Angular, Jest Vue… Framework de pruebas JS usado en TypeScript, Node.js, React, Angular, Jasmine Vue… Mocha Framework de pruebas JS para Node.js. Ofrece pruebas asincrónicas