<?xml version="1.0"?>
<rss version="2.0">
   <channel>
      <title>Mi padlet by FABIAN RODRIGUEZ ABREO</title>
      <link>https://padlet.com/fabianrodriguez221/s1e4s0ivajdgkho7</link>
      <description>En este padlet se encuentra la informacion correspondiente a la actividad de la clase de Ciencia de datos, dia 21/10/2025.</description>
      <language>en-us</language>
      <pubDate>2025-10-22 02:24:49 UTC</pubDate>
      <lastBuildDate>2025-10-22 03:15:18 UTC</lastBuildDate>
      <webMaster>hello@padlet.com</webMaster>
      <image>
         <url></url>
      </image>
      <item>
         <title>Fase de pruebas del softaware</title>
         <author>fabianrodriguez221</author>
         <link>https://padlet.com/fabianrodriguez221/s1e4s0ivajdgkho7/wish/3644361137</link>
         <description><![CDATA[<p>1. Definición y propósito de las pruebas</p><p>El texto explica claramente la importancia de las pruebas dentro del ciclo de vida del software, destacando su papel en el aseguramiento de la calidad, detección temprana de errores y reducción de costos.</p><p>“Las pruebas de software son importantes porque aseguran el correcto cumplimiento de la funcionalidad del producto, ayudan a ganar confianza, confirman la fiabilidad del uso y previenen defectos en producción” [5, p. 4].</p><p>2. Proceso de pruebas (basado en IEEE 829)</p><p>El documento describe un flujo completo del proceso de pruebas: planeación, análisis y diseño, ejecución, evaluación y cierre, siguiendo estándares reconocidos.</p><p>“El conjunto de actividades de pruebas dentro del proceso de desarrollo de software [...] incluye planeación, análisis y diseño, ejecución, evaluación de resultados y cierre de pruebas” [5, p. 4].</p><p>3. Tipos y niveles de prueba</p><p>Contiene descripciones de las pruebas unitarias, de integración, de sistema y de aceptación, así como de los tipos funcionales, no funcionales y estructurales.</p><p>“Las pruebas de sistema se desarrollan utilizando casos de prueba funcionales y no funcionales. [...] Las pruebas de aceptación son realizadas por el usuario para obtener el visto bueno del cliente” [5, p. 13].</p><p>4. Diseño de casos de prueba</p><p>Basado en el estándar <strong>IEEE 829</strong>, el documento detalla qué debe incluir un caso de prueba (precondiciones, valores de entrada, resultados esperados, postcondiciones, etc.).</p><p>“Lo que debe contener un caso de prueba según el estándar IEEE 829, es: precondiciones, valores de entrada, resultados esperados, postcondiciones, identificador único [...] y prioridad” [5, p. 9].</p><p>Sirve para <strong>estructurar la plantilla de casos de prueba</strong> en la documentación.</p><p> 5. Técnicas de prueba (Caja blanca y Caja negra)</p><p>Se explican las técnicas dinámicas de caja blanca (cobertura de sentencias, caminos, decisiones) y caja negra (partición de equivalencia, valores límite, tablas de decisión).</p><p>“La técnica de caja negra se enfoca en probar el sistema sin tomar en cuenta la estructura interna del mismo, su objetivo es validar que las salidas sean las esperadas” [5, p. 23].</p><p>Estas secciones sirven para <strong>justificar las técnicas empleadas</strong> en las pruebas y la metodología de diseño de casos.</p><p>6. Metodología de pruebas</p><p>El capítulo 7 presenta una <strong>guía formal para planificar, diseñar, ejecutar y cerrar pruebas</strong>, incluyendo criterios de salida y métricas.</p><p>“Un proceso de pruebas formal está compuesto, cuando menos, por las siguientes cinco etapas: planeación de pruebas, diseño, implementación, evaluación de criterios de salida y cierre del proceso” [5, p. 25].</p><p>7. Caso práctico (Agenda Web)</p><p>El capítulo 9 incluye un <strong>caso de estudio completo</strong>, con plan de pruebas, estrategia, alcance, criterios de suspensión/reanudación, diseño de casos de prueba, ejecución, defectos y liberación.</p><p>“Se ejecutaron 29 casos de prueba en un ciclo completo. [...] Se detectaron tres defectos no funcionales. Tras la corrección, se ejecutó el re-test y se aplicaron pruebas de regresión del flujo principal” [5, p. 43].</p><p>8. Rol del ingeniero de pruebas</p><p>También es útil para justificar la participación del equipo en la fase de QA:</p><p>“El ingeniero de pruebas asegura que el equipo de desarrollo ofrece la calidad necesaria [...] centrándose en la entrega de un producto que proporcione más valor al negocio” [5, p. 10].</p><p><br></p><p>Chiu, C. C. (2015). Las pruebas en el desarrollo de software. <em>Universidad Nacional Autónoma de México</em>.</p>]]></description>
         <enclosure url="" />
         <pubDate>2025-10-22 02:39:04 UTC</pubDate>
         <guid>https://padlet.com/fabianrodriguez221/s1e4s0ivajdgkho7/wish/3644361137</guid>
      </item>
      <item>
         <title>Ejemplo de un caso en su fase de pruebas</title>
         <author>fabianrodriguez221</author>
         <link>https://padlet.com/fabianrodriguez221/s1e4s0ivajdgkho7/wish/3644380360</link>
         <description><![CDATA[<p>En este espacio se encuentra un ejemplo de aplicación de fase de pruebas.</p>]]></description>
         <enclosure url="https://padlet-uploads-usc1.storage.googleapis.com/4602475714/19a620ac35fe8bccbcae0519879f0be0/Fase_de_Pruebas_AgendaWeb.docx" />
         <pubDate>2025-10-22 02:48:06 UTC</pubDate>
         <guid>https://padlet.com/fabianrodriguez221/s1e4s0ivajdgkho7/wish/3644380360</guid>
      </item>
      <item>
         <title>Diagramas UML para la fase dse prueba de un software</title>
         <author>fabianrodriguez221</author>
         <link>https://padlet.com/fabianrodriguez221/s1e4s0ivajdgkho7/wish/3644415723</link>
         <description><![CDATA[<ol><li><p>Segun el siguientre articulo de <em>Sahoo et al. (2021)</em> publicado en <em>Computers, Materials &amp; Continua</em> de TechScience Durante la fase de pruebas del ciclo de vida del software, los diagramas UML (Unified Modeling Language) constituyen una herramienta esencial para representar, comprender y validar el comportamiento esperado del sistema. Su correcta aplicación permite mantener la trazabilidad entre los requisitos funcionales y los casos de prueba, además de facilitar la identificación de escenarios críticos y la verificación de las interacciones entre componentes.</p></li><li><p>Los diagramas UML más utilizados en la etapa de pruebas son los diagramas de casos de uso, de actividades, de secuencia, de estados y de clases, cada uno con un propósito específico dentro del proceso de aseguramiento de la calidad. El diagrama de casos de uso se emplea para derivar escenarios funcionales que servirán de base para el diseño de casos de prueba, garantizando que cada funcionalidad especificada en los requerimientos sea verificada al menos una vez. El diagrama de actividades describe el flujo lógico de las operaciones del sistema, permitiendo identificar caminos alternos y condiciones de decisión que deben ser evaluadas durante la ejecución de pruebas funcionales e integrales. Por su parte, el diagrama de secuencia resulta útil para modelar la interacción temporal entre objetos o componentes, siendo indispensable para las pruebas de integración. El diagrama de clases, en cambio, respalda las pruebas unitarias al evidenciar las dependencias entre métodos y atributos, facilitando la detección de inconsistencias estructurales. Finalmente, el diagrama de estados se utiliza para validar el comportamiento del sistema ante transiciones específicas, asegurando que cada cambio de estado cumpla con las condiciones definidas en los requerimientos.</p></li><li><p>Diversos estudios han demostrado que la utilización de modelos UML no solo mejora la comprensión del sistema, sino que también posibilita la generación automática de casos de prueba a partir de dichos diagramas. Sahoo et al. [1] plantean un enfoque de generación automatizada de casos de prueba mediante la transformación de diagramas de actividad y de estados en un grafo unificado denominado <em>Activity State Chart Diagram Graph</em> (ASCDG). Este modelo se somete posteriormente a un proceso de optimización utilizando un algoritmo genético básico (BGA), con el propósito de reducir redundancias y aumentar la cobertura de pruebas. Según los autores, la combinación de diagramas UML con técnicas de inteligencia computacional permite obtener conjuntos de casos de prueba más eficientes y representativos del comportamiento real del sistema, lo cual contribuye significativamente a la mejora de la calidad del software.</p></li><li><p>En este sentido, la integración de los diagramas UML en la planificación y diseño de pruebas ofrece múltiples beneficios. En primer lugar, asegura la trazabilidad bidireccional entre los requerimientos, los casos de uso y las pruebas ejecutadas, lo que facilita el seguimiento del cumplimiento de cada funcionalidad. En segundo lugar, posibilita la identificación temprana de errores en los flujos lógicos o en las dependencias de los componentes. Finalmente, los modelos UML proporcionan una base sólida para la automatización de pruebas, ya que pueden ser transformados en grafos, scripts o plantillas reutilizables que optimizan el esfuerzo de validación manual.</p></li><li><p>En conclusión, los diagramas UML desempeñan un papel determinante en la fase de pruebas, no solo como instrumentos de documentación, sino también como herramientas de diseño y optimización del proceso de verificación. La literatura reciente respalda su utilización como una práctica que incrementa la eficiencia, la trazabilidad y la cobertura del proceso de aseguramiento de calidad, reforzando así la confiabilidad del producto final.</p><p><br></p></li><li><p>Bibliografía.</p><p>[1] P. K. Sahoo, S. K. Panigrahi, S. K. Behera y P. K. Mallick, “Test Case Generation from UML-Diagrams Using Genetic Algorithm,” <em>Computers, Materials &amp; Continua</em>, vol. 67, no. 2, pp. 2045–2061, 2021. Disponible en: <a rel="noopener noreferrer nofollow" href="https://www.techscience.com/cmc/v67n2/41305/html">https://www.techscience.com/cmc/v67n2/41305/html</a> </p></li></ol><p><br></p>]]></description>
         <enclosure url="" />
         <pubDate>2025-10-22 03:04:17 UTC</pubDate>
         <guid>https://padlet.com/fabianrodriguez221/s1e4s0ivajdgkho7/wish/3644415723</guid>
      </item>
      <item>
         <title>Software para fases de pruebas</title>
         <author>fabianrodriguez221</author>
         <link>https://padlet.com/fabianrodriguez221/s1e4s0ivajdgkho7/wish/3644435574</link>
         <description><![CDATA[<p>Herramientas utilizadas en la fase de pruebas</p><p>Durante la fase de pruebas de software se emplean diversas herramientas que permiten garantizar la calidad y el correcto funcionamiento del producto desarrollado. Entre las más utilizadas se encuentran <strong>Selenium</strong>, <strong>TestLink</strong>, <strong>JMeter</strong>, <strong>Cypress</strong> y <strong>JUnit</strong>, cada una orientada a un tipo específico de verificación.</p><p><br/></p><p>En este caso es con el software JUnit en la fase de pruebas de software, una de las herramientas más ampliamente utilizadas es <strong>JUnit</strong>, un marco de trabajo (<em>framework</em>) de código abierto diseñado para la ejecución de <strong>pruebas unitarias en el lenguaje Java</strong>. Su principal objetivo es verificar el funcionamiento individual de los componentes del sistema, garantizando que cada método o clase cumpla con el comportamiento esperado antes de proceder a su integración con otros módulos.</p><p>Según Bolaños [1], JUnit constituye una herramienta esencial dentro de las metodologías de desarrollo basadas en pruebas, al permitir que los desarrolladores creen y ejecuten casos de prueba de manera estructurada y repetible. El autor señala que este framework “proporciona un entorno que facilita la ejecución automatizada de pruebas unitarias y la comparación de los resultados obtenidos con los esperados, asegurando así la validez del código fuente” [1, p. 4].</p><p>Entre las características más relevantes de JUnit se destacan su <strong>facilidad de uso</strong>, <strong>integración con entornos de desarrollo integrados (IDE)</strong> como Eclipse y NetBeans, y su compatibilidad con herramientas de <strong>integración continua</strong>, tales como Jenkins o Maven. Estas cualidades hacen posible la ejecución continua de pruebas durante el ciclo de desarrollo, promoviendo la detección temprana de defectos y mejorando la calidad final del software.</p><p>Bolaños enfatiza además que el uso de JUnit contribuye al enfoque de <strong>Desarrollo Guiado por Pruebas (TDD, <em>Test Driven Development</em>)</strong>, el cual propone escribir las pruebas antes de la implementación del código. Este paradigma impulsa la escritura de código más limpio, modular y verificable, ya que cada funcionalidad del sistema se construye en función de una prueba previamente definida [1, p. 6].</p><p>En conclusión, JUnit representa una herramienta fundamental en la fase de pruebas de software, particularmente en el nivel de <strong>pruebas unitarias</strong>. Su capacidad de automatizar la ejecución, generar reportes y mantener la trazabilidad de los resultados lo posiciona como un componente indispensable en los entornos de desarrollo modernos y en la garantía de calidad del producto final.</p><p><br/></p><p>Bibliografía</p><p>[1] B. Bolaños, <em>Pruebas de Software y JUnit</em>, Universidad Nacional de Colombia, 2007.</p>]]></description>
         <enclosure url="" />
         <pubDate>2025-10-22 03:13:35 UTC</pubDate>
         <guid>https://padlet.com/fabianrodriguez221/s1e4s0ivajdgkho7/wish/3644435574</guid>
      </item>
   </channel>
</rss>
