🤑¿Quieres un DESCUENTO para presentar el examen de certificación📜? Si eres un seguidor de este canal, estos son los pasos: - Envíame un email a info@fulladvanced.com ✉ - Coloca como parte del título del email "Cupón de descuento" 🎟 - Indica la Región donde tomarás el examen, las opciones son: America, Venezuela, Argentina y Europa. 🌎 Obtendrás un descuento que va desde 10US$ hasta 25 US$ al momento de adquirir el examen💰 En este canal no solo me enfoco en darte el contenido que necesitas para prepararte sino en facilitar el acceso a la certificación 🏆 Aprovecha este beneficio que te ofrecemos desde #FullAdvanced
40:34 no entendí porque los probadores también son responsables en la prueba de aceptación. Porque la documentación se dice que el principal responsable es el cliente de efectuar las pruebas de aceptación. Por supuesto que los probadores deben estar de preferencia pendientes en todas las etapas, pero en la de aceptación tengo entendido que el cliente es el principal ente encargado de realizar las pruebas debido a que el objetivo es establecer la confianza en el software. En la integración si estoy de acuerdo que es un equipo de probadores especializados el que hace el mayor rol de las pruebas
Hola Chris, la verdad es que tu interpretación es bastante acertada, sin embargo en este punto hay varias cosas a considerar: - Al momento de presentar este tipo de exámenes existe algo llamado "la mejor opción", aunque varias parezcan correctas o incorrectas, una de ellas es la mejor opción. - Las "Pruebas de Aceptación" es un Nivel de pruebas donde nos enfocamos en conocer si se aceptará el sistema, los probadores serán responsables de la administración/gestión de las pruebas. tú haces referencias a las "Pruebas de Aceptación de Usuario", que son un tipo de las antes mencionadas. - La documentación dice que "en ocasiones" los clientes son responsables, pero aunque ellos tomen la última decisión en esa instancia, el probador no deja de ser responsable (aunque fuese en menor proporción). - Estas preguntas suelen ser un poco "Tricky" con la intención de generar estas confusiones, pero en los detalles se ocultan las respuestas. Cabe destacar que esta es una pregunta diseñada por ISTQB, no por mi En verdad espero haberte ayudado a aclarar un poco el punto, saludos y gracias por escribir
Hasta ahorita en todos los trabajos en los que he estado he trabajado bajo la metodología Scrum ya que es un modelo que reduce el tiempo de entregas, si bien no en todas las empresas o clientes implementan Scrum en su totalidad, en mi último trabajo si era totalmente Scrum.
Hola Fransheska, tienes toda la razón. están invertidas esas definiciones, a NIVEL DE INTEGRACIÓN sería como sigue: BASES DE PRUEBA: - Diseño de software y sistemas. - Diagrama de secuencias - Especificaciones de interfaz y protocolos de comunicación - Casos de uso - Arquitectura a nivel de componentes o sistemas según corresponda - Flujos de trabajo y, - Definiciones de interfaces externas. OBJETOS DE PRUEBA: - Subsistemas - Bases de Datos - Infraestructura - Interfaces - Interfaces de comunicación de aplicaciones o API’s por sus siglas en ingles y, - Microservicios Muchas gracias por la observación Fransheska, dejaré tu comentario fijado para que nos sirva como "fe de errata". Saludos.
Ante todo agradezco el esfuerzo que se hace en cada video que publican, tengo una duda en caso de que ya se tengan las pruebas de interfaz de usuario en estado OK y aún estén pendientes las pruebas unitarias esto se traduciría en un potencial error en las validaciones que ya se hicieron (en las pruebas de interfaz de usuario) correcto?
Hola Andrés, te comento que ese escenario sería una mala práctica en si mismo. No tiene mayor sentido recibir un producto de trabajo (código) sin pruebas completadas en la fase anterior (pruebas a nivel de componente que debió realizar el desarrollador). Al comenzar con las pruebas a nivel de sistemas sin haber completados las anteriores estaríamos fomentando la mala práctica, y como consecuencia podría ocurrir lo que comentas (hago algunos ajustes a tu comentario: un potencial "defecto" en las "verificaciones" que ya se hicieron "de manera incompleta"). Espero haber aclarado el punto
Buenas gracias por el video, una duda se indica que las pruebas de aceptación de una nueva funcionalidad se pueden realizar antes de las pruebas de sistema, esto es se pueden realizar en las pruebas de integración ??
Buenas muy buen video, tengo una duda en el caso de pruebas de sistemas indicas que entre los defectos mas comunes está "Funcionamiento incorrecto en el entorno de producción", pero entiendo de que el sistema se está probando en un entorno lo mas aproximado de producción, no realmente producción, por lo que no entiendo este punto. muchas gracias
Buenas 👋, muy interesante la interpretación que le diste a esa sentencia, me dejaste pensando un rato 😅, voy a tratar de interpretar la intención del autor del syllabus: + Ambiente de Producción: - Probar en producción es válido aunque no recomendado. - En ocasiones probar en producción es la única manera de verificar un comportamiento en particular porque emular ese ambiente podría ser imposible. + Ambiente de Pruebas: - Aún cuando la prueba se haga en un ambiente especial para tal fin (ambiente distinto a producción), se supondría que cualquier falla manifestada ahí, debería ocurrir igualmente en producción. Entonces, siguiendo cualquiera de los 2 análisis propuestos, me parece que la sentencia estaría acertada. Espero haber aclarado el punto.
Hola buenas noches, de acuerdo a tu explicaciòn el nivel de prueba con el que se encuentran los primeros defectos, serìa la prueba de componente? gracias de antemano por la aclaracion
Hola 👋, está muy interesante tu pregunta 🤔 - Muy probablemente los primeros defectos los encuentres durante la implementación de pruebas estáticas, quizá en alguna de las distintas reuniones de Revisión en cualquiera de sus distintos niveles de formalidad (formal, informal, guiada o inspección). - Lo antes mencionado ocurre durante las actividades de Análisis y Diseño. - Estos niveles de pruebas (Componentes, Integración, Sistemas y Aceptación) existen posterior a alguna actividad de desarrollo, por lo tanto acá encontraremos Defectos y Fallas. Espero haber aclarado tu duda. Feliz día.
Hola buena noche, tengo unas dudas referentes a las pruebas de integración podrías apoyarme con algún ejemplo de como se realizan dichas pruebas? No me queda claro si se hacen sobre los sistemas (por ejemplo digamos que tenemos una aplicación donde se obtiene info de otro lado al realizar una consulta, mi prueba de integración sería validar que la aplicación me trajera la información al yo realizar la consulta) o las pruebas se hacen sobre la interfaz por ejemplo validando la API. Así como también si estás pruebas son aplicables a testers manuales o automatizados. Saludos
Hola John, esta pregunta tiene varias partes, así que vamos a cubrir cada una. Hay 2 niveles de prueba de Integración: de Componentes y de Sistemas. Las de componentes suelen ocurrir dentro del mismo sistema, por ejemplo tienes el sistema Calculadora, que tiene las funciones (servicios, APIs) Suma, Resta, Multiplicación, etc... Entonces se puede probar que los APIs Suma e Igualdad se Integran adecuadamente entre ellos. Ahora, a Nivel de Integración de Sistemas, tendríamos por ejemplo la comunicación entre el SO (Windows) y el sistema Calculadora. Acá podremos verificar si la calculadora es capaz de mostrar su interfaz adecuadamente (a traves de los manejadores de interfaz gráfica ofrecidas por el SO), o que el sonido de las teclas es identificado por los drivers de sonido del SO, entre otras cosas. Por último, respecto a alguna consideración sobre si las pruebas a Nivel de Integración deben ser cubiertas por técnicas de ejecución Manual o Automática, la verdad sería irrelevante. Ambas deberian realizarse porque logran coberturas y tienen objetivos distintos, no son intercambiables. Espero haberte ayudado con la explicación y gracias por comentar, saludos.
hola, en la pregunta de las normativas, quería saber xq era pruebas aceptación? si yo pienso q las normativas son los documentos q se empiezan a leer y las UAT es la etapa final.
Hola Alfredo, tu pregunta es interesante y ese es un mal ententido común. En efecto las pruebas tempranas (early testing) suelen cubrir las pruebas estáticas (verificación de documentos), pero las "normativas" son bastante más que una serie de documentos. Por ejemplo, para la banca, una normativa podria implicar mantener respaldo de ciertos datos de los clientes por un tiempo determinado o algún criterio de seguridad (encriptación) de esos datos. Entonces realizar verificaciones y/o validaciones de esas normativas formarian parte de pruebas Dinámicas. Otra curiosidad es que estas pruebas pueden realizarse por equipos distintos a los usuarios que utilizan las funcionalidades comúnes de las aplicaciones. Generalmente son usuarios con habilidades técnicas especificas. Espero haber aclarado el puntos. Saludos y gracias por escribir.
Hola me podrías ayudar con esta duda del syllabus? "Base de prueba" Los ejemplos de productos de trabajo que se pueden usar como base de prueba para pruebas de componente incluyen:
Diseño detallado , Código, Modelo de datos, Especificaciones de los componentes En un mismo párrafo habla de base prueba y producto de trabajo?. Estos conceptos son iguales?. Tenia entendido que eran conceptos diferentes. Saludos.
Hola Arlin, en efecto son cosas diferentes: - Una Base de Prueba es un Producto de Trabajo. - No todos los Producto de Trabajo son Bases de Prueba. - La Base de Prueba es el origen del conocimiento que utilizarás durante la fase de Análisis y Diseño. + Una Base de Prueba podría ser: - Un Requerimiento Funcional, - Una Historia de Usuario, - Un Diagrama de Flujo o de Procesos, entre muchos otros, y todos los mencionados se catalogarían al mismo tiempo como Productos de Trabajo como lo indiqué anteriormente. Espero haber aclarado el punto
Hola si yo entiendo que un base de prueba es un producto de trabajo .. pero cuales producto de trabajo no serian una base de prueba? m podrías dar algunos ejemplos? . Muchas gracias.
Hola de nuevo Arlin, Los siguientes no serían Bases de Prueba: - Las Condiciones de Prueba que se generan a partir de la Base de Prueba. - Un Framework de automatización. - Un Caso de Prueba. - Un Plan de Pruebas - Un Reporte Resumen de Pruebas Y cualquier otro producto de trabajo que se genera a lo largo y ancho del proceso de pruebas, todos como consecuencia del Análisis inicial que realizamos sobre la Base de Pruebas. Espero que te sirva
Mi buen amigo, quizas sea bueno corroborar la parte de prueba de componente, pareciera que esta invertida la info de base de pruebas con objetos de prueba (comparando mi lectura con lo que dice el syllabus). saludos
Hola Arlin, en efecto así es, está invertido. Si te fijas hay otro comentario "fijado/pinned" de una persona que también lo notó, se nos escapó esa 😅 Cada vez que alguien detecta algo así, esa es la acción que tomamos porque no puedo simplemente actualizar el video, no lo permite 🤦 Entonces los comentarios fijados quedan a manera de "fe de erratas". Espero que para la 2da edición removamos esos detalles. Muchas gracias por colaborar depurando el material
Cordial saludo para todos, En el video usted dice lo siguiente cuando habla de que las pruebas se deben ajustar al contexto: En un sistema de mensajería que se integra a un sistema de comunicación se pueden realizar pruebas de integración a nivel de sistemas y pruebas de aceptación. En este caso las pruebas de componentes no serían necesarias. Cuando afirma que no son necesarias la pruebas de componentes es porque éstas ya se realizaron al momento de desarrollar el sistema de comunicación y el sistema de mensajería y se puede deducir que funcionan correctamente, y que por eso se van a integrar. ¿Estoy errado o puede ser una deducción correcta? Saludos,
Hola Betania, los aspectos relacionados a la seguridad se consideran "no funcionales" o "atributos de calidad". Estos no miden el cumplimiento de las funciones sino, por ejemplo, que tan bien ó que tan rápido lo hacen. En este caso, que tan segura es la aplicación. Esto no quiere decir que sea más ó menos importante, simplemente está en otra categoría. Saludos y feliz inicio de año 👋🏻
“Quedarse en casa” fue lo que derrumbó el mundo. Y no, no ayudo con el problema del virus. Entiendo lo que trays de decir, pero no le mintamos a la gente. Sin mencionar que eso nada de eso fue voluntario. Creo que existen mejores ejemplos
Hola Luis, este proyecto nació durante la pandemia, los videos se construyeron en esa época mientras estaba en casa, así pensaba entonces y sigo pensando igual. Basé el curso en fuentes verificables, confio en que te sirva
🤑¿Quieres un DESCUENTO para presentar el examen de certificación📜? Si eres un seguidor de este canal, estos son los pasos:
- Envíame un email a info@fulladvanced.com ✉
- Coloca como parte del título del email "Cupón de descuento" 🎟
- Indica la Región donde tomarás el examen, las opciones son: America, Venezuela, Argentina y Europa. 🌎
Obtendrás un descuento que va desde 10US$ hasta 25 US$ al momento de adquirir el examen💰
En este canal no solo me enfoco en darte el contenido que necesitas para prepararte sino en facilitar el acceso a la certificación 🏆
Aprovecha este beneficio que te ofrecemos desde #FullAdvanced
Descarga gratis el RESUMEN del capitulo en www.fulladvanced.com/e-book-fundamentos-de-pruebas-de-software
De todos los videos enserio el que más aterriza y ayuda a entender los diferentes niveles felicitaciones fue de mucha ayuda
Genial Heyder, que bueno que te haya servido para aclarar el punto 🤓, espero que el resto de los videos sean igualmente valiosos
este capitulo hasta ahora es el que mas me ha gustado ... muy bueno
🥳
Excelente video de lo mejor que he encontrado
Muchas gracias por el comentario Luca 💪, espero que te sea de utilidad el resto de la serie 🤓
Gracias me sirvio mucho el contenido de este video.
Bueno saberlo Daniel 👏🤓
Gracias por los videos, me han servido muchisimo.
Un gusto Jose, gracias por escribir 😁
40:34 no entendí porque los probadores también son responsables en la prueba de aceptación. Porque la documentación se dice que el principal responsable es el cliente de efectuar las pruebas de aceptación. Por supuesto que los probadores deben estar de preferencia pendientes en todas las etapas, pero en la de aceptación tengo entendido que el cliente es el principal ente encargado de realizar las pruebas debido a que el objetivo es establecer la confianza en el software. En la integración si estoy de acuerdo que es un equipo de probadores especializados el que hace el mayor rol de las pruebas
Hola Chris, la verdad es que tu interpretación es bastante acertada, sin embargo en este punto hay varias cosas a considerar:
- Al momento de presentar este tipo de exámenes existe algo llamado "la mejor opción", aunque varias parezcan correctas o incorrectas, una de ellas es la mejor opción.
- Las "Pruebas de Aceptación" es un Nivel de pruebas donde nos enfocamos en conocer si se aceptará el sistema, los probadores serán responsables de la administración/gestión de las pruebas. tú haces referencias a las "Pruebas de Aceptación de Usuario", que son un tipo de las antes mencionadas.
- La documentación dice que "en ocasiones" los clientes son responsables, pero aunque ellos tomen la última decisión en esa instancia, el probador no deja de ser responsable (aunque fuese en menor proporción).
- Estas preguntas suelen ser un poco "Tricky" con la intención de generar estas confusiones, pero en los detalles se ocultan las respuestas.
Cabe destacar que esta es una pregunta diseñada por ISTQB, no por mi
En verdad espero haberte ayudado a aclarar un poco el punto, saludos y gracias por escribir
Hasta ahorita en todos los trabajos en los que he estado he trabajado bajo la metodología Scrum ya que es un modelo que reduce el tiempo de entregas, si bien no en todas las empresas o clientes implementan Scrum en su totalidad, en mi último trabajo si era totalmente Scrum.
Genial! Gracias por comentar!
creo que ha intercambiado las bases de pruebas por los objetos de pruebas del nivel de Integración
Hola Fransheska, tienes toda la razón. están invertidas esas definiciones, a NIVEL DE INTEGRACIÓN sería como sigue:
BASES DE PRUEBA:
- Diseño de software y sistemas.
- Diagrama de secuencias
- Especificaciones de interfaz y protocolos de comunicación
- Casos de uso
- Arquitectura a nivel de componentes o sistemas según corresponda
- Flujos de trabajo y,
- Definiciones de interfaces externas.
OBJETOS DE PRUEBA:
- Subsistemas
- Bases de Datos
- Infraestructura
- Interfaces
- Interfaces de comunicación de aplicaciones o API’s por sus siglas en ingles y,
- Microservicios
Muchas gracias por la observación Fransheska, dejaré tu comentario fijado para que nos sirva como "fe de errata".
Saludos.
Ante todo agradezco el esfuerzo que se hace en cada video que publican, tengo una duda en caso de que ya se tengan las pruebas de interfaz de usuario en estado OK y aún estén pendientes las pruebas unitarias esto se traduciría en un potencial error en las validaciones que ya se hicieron (en las pruebas de interfaz de usuario) correcto?
Hola Andrés, te comento que ese escenario sería una mala práctica en si mismo.
No tiene mayor sentido recibir un producto de trabajo (código) sin pruebas completadas en la fase anterior (pruebas a nivel de componente que debió realizar el desarrollador).
Al comenzar con las pruebas a nivel de sistemas sin haber completados las anteriores estaríamos fomentando la mala práctica, y como consecuencia podría ocurrir lo que comentas (hago algunos ajustes a tu comentario: un potencial "defecto" en las "verificaciones" que ya se hicieron "de manera incompleta").
Espero haber aclarado el punto
Buenas gracias por el video, una duda se indica que las pruebas de aceptación de una nueva funcionalidad se pueden realizar antes de las pruebas de sistema, esto es se pueden realizar en las pruebas de integración ??
¡Así es! Se podrían realizar durante las pruebas a nivel de Componentes o Integración de Componentes.
Buenas muy buen video, tengo una duda en el caso de pruebas de sistemas indicas que entre los defectos mas comunes está "Funcionamiento incorrecto en el entorno de producción", pero entiendo de que el sistema se está probando en un entorno lo mas aproximado de producción, no realmente producción, por lo que no entiendo este punto. muchas gracias
Buenas 👋, muy interesante la interpretación que le diste a esa sentencia, me dejaste pensando un rato 😅, voy a tratar de interpretar la intención del autor del syllabus:
+ Ambiente de Producción:
- Probar en producción es válido aunque no recomendado.
- En ocasiones probar en producción es la única manera de verificar un comportamiento en particular porque emular ese ambiente podría ser imposible.
+ Ambiente de Pruebas:
- Aún cuando la prueba se haga en un ambiente especial para tal fin (ambiente distinto a producción), se supondría que cualquier falla manifestada ahí, debería ocurrir igualmente en producción.
Entonces, siguiendo cualquiera de los 2 análisis propuestos, me parece que la sentencia estaría acertada.
Espero haber aclarado el punto.
Hola buenas noches, de acuerdo a tu explicaciòn el nivel de prueba con el que se encuentran los primeros defectos, serìa la prueba de componente? gracias de antemano por la aclaracion
Hola 👋, está muy interesante tu pregunta 🤔
- Muy probablemente los primeros defectos los encuentres durante la implementación de pruebas estáticas, quizá en alguna de las distintas reuniones de Revisión en cualquiera de sus distintos niveles de formalidad (formal, informal, guiada o inspección).
- Lo antes mencionado ocurre durante las actividades de Análisis y Diseño.
- Estos niveles de pruebas (Componentes, Integración, Sistemas y Aceptación) existen posterior a alguna actividad de desarrollo, por lo tanto acá encontraremos Defectos y Fallas.
Espero haber aclarado tu duda.
Feliz día.
@@FullAdvanced muy amable muchas gracias!
Un gusto@@cingabrr4879, por acá estamos para ayudar 👏
Hola buena noche, tengo unas dudas referentes a las pruebas de integración podrías apoyarme con algún ejemplo de como se realizan dichas pruebas? No me queda claro si se hacen sobre los sistemas (por ejemplo digamos que tenemos una aplicación donde se obtiene info de otro lado al realizar una consulta, mi prueba de integración sería validar que la aplicación me trajera la información al yo realizar la consulta) o las pruebas se hacen sobre la interfaz por ejemplo validando la API. Así como también si estás pruebas son aplicables a testers manuales o automatizados. Saludos
Hola John, esta pregunta tiene varias partes, así que vamos a cubrir cada una.
Hay 2 niveles de prueba de Integración: de Componentes y de Sistemas.
Las de componentes suelen ocurrir dentro del mismo sistema, por ejemplo tienes el sistema Calculadora, que tiene las funciones (servicios, APIs) Suma, Resta, Multiplicación, etc... Entonces se puede probar que los APIs Suma e Igualdad se Integran adecuadamente entre ellos.
Ahora, a Nivel de Integración de Sistemas, tendríamos por ejemplo la comunicación entre el SO (Windows) y el sistema Calculadora. Acá podremos verificar si la calculadora es capaz de mostrar su interfaz adecuadamente (a traves de los manejadores de interfaz gráfica ofrecidas por el SO), o que el sonido de las teclas es identificado por los drivers de sonido del SO, entre otras cosas.
Por último, respecto a alguna consideración sobre si las pruebas a Nivel de Integración deben ser cubiertas por técnicas de ejecución Manual o Automática, la verdad sería irrelevante. Ambas deberian realizarse porque logran coberturas y tienen objetivos distintos, no son intercambiables.
Espero haberte ayudado con la explicación y gracias por comentar, saludos.
hola, en la pregunta de las normativas, quería saber xq era pruebas aceptación? si yo pienso q las normativas son los documentos q se empiezan a leer y las UAT es la etapa final.
Hola Alfredo, tu pregunta es interesante y ese es un mal ententido común. En efecto las pruebas tempranas (early testing) suelen cubrir las pruebas estáticas (verificación de documentos), pero las "normativas" son bastante más que una serie de documentos.
Por ejemplo, para la banca, una normativa podria implicar mantener respaldo de ciertos datos de los clientes por un tiempo determinado o algún criterio de seguridad (encriptación) de esos datos.
Entonces realizar verificaciones y/o validaciones de esas normativas formarian parte de pruebas Dinámicas.
Otra curiosidad es que estas pruebas pueden realizarse por equipos distintos a los usuarios que utilizan las funcionalidades comúnes de las aplicaciones. Generalmente son usuarios con habilidades técnicas especificas.
Espero haber aclarado el puntos.
Saludos y gracias por escribir.
Hola me podrías ayudar con esta duda del syllabus?
"Base de prueba"
Los ejemplos de productos de trabajo que se pueden usar como base de prueba para pruebas de componente incluyen:
Diseño detallado
, Código, Modelo de datos, Especificaciones de los componentes
En un mismo párrafo habla de base prueba y producto de trabajo?. Estos conceptos son iguales?. Tenia entendido que eran conceptos diferentes.
Saludos.
Hola Arlin, en efecto son cosas diferentes:
- Una Base de Prueba es un Producto de Trabajo.
- No todos los Producto de Trabajo son Bases de Prueba.
- La Base de Prueba es el origen del conocimiento que utilizarás durante la fase de Análisis y Diseño.
+ Una Base de Prueba podría ser:
- Un Requerimiento Funcional,
- Una Historia de Usuario,
- Un Diagrama de Flujo o de Procesos, entre muchos otros, y todos los mencionados se catalogarían al mismo tiempo como Productos de Trabajo como lo indiqué anteriormente.
Espero haber aclarado el punto
Hola si yo entiendo que un base de prueba es un producto de trabajo .. pero cuales producto de trabajo no serian una base de prueba? m podrías dar algunos ejemplos? . Muchas gracias.
Hola de nuevo Arlin,
Los siguientes no serían Bases de Prueba:
- Las Condiciones de Prueba que se generan a partir de la Base de Prueba.
- Un Framework de automatización.
- Un Caso de Prueba.
- Un Plan de Pruebas
- Un Reporte Resumen de Pruebas
Y cualquier otro producto de trabajo que se genera a lo largo y ancho del proceso de pruebas, todos como consecuencia del Análisis inicial que realizamos sobre la Base de Pruebas.
Espero que te sirva
Mi buen amigo, quizas sea bueno corroborar la parte de prueba de componente, pareciera que esta invertida la info de base de pruebas con objetos de prueba (comparando mi lectura con lo que dice el syllabus). saludos
Hola Arlin, en efecto así es, está invertido. Si te fijas hay otro comentario "fijado/pinned" de una persona que también lo notó, se nos escapó esa 😅
Cada vez que alguien detecta algo así, esa es la acción que tomamos porque no puedo simplemente actualizar el video,
no lo permite 🤦
Entonces los comentarios fijados quedan a manera de "fe de erratas".
Espero que para la 2da edición removamos esos detalles.
Muchas gracias por colaborar depurando el material
Acortar el camino no suele ser una buena idea, por eso todos los niveles de pruebas son importantes. Muchas gracias. Saludos
Agree! 🤝
✅
Cordial saludo para todos,
En el video usted dice lo siguiente cuando habla de que las pruebas se deben ajustar al contexto:
En un sistema de mensajería que se integra a un sistema de comunicación se pueden realizar pruebas de integración a nivel de sistemas y pruebas de aceptación. En este caso las pruebas de componentes no serían necesarias.
Cuando afirma que no son necesarias la pruebas de componentes es porque éstas ya se realizaron al momento de desarrollar el sistema de comunicación y el sistema de mensajería y se puede deducir que funcionan correctamente, y que por eso se van a integrar.
¿Estoy errado o puede ser una deducción correcta?
Saludos,
Hola Erasmo, tu afirmación es correcta. Las pruebas de componente ya fueron realizadas en este punto.
Saludos
@@FullAdvanced Muchas gracias maestro 🎩
@@ErasmoMartinez-w1v
Siempre me he preguntado por que una falla de seguridad no es una falla funcional?
Hola Betania, los aspectos relacionados a la seguridad se consideran "no funcionales" o "atributos de calidad".
Estos no miden el cumplimiento de las funciones sino, por ejemplo, que tan bien ó que tan rápido lo hacen.
En este caso, que tan segura es la aplicación. Esto no quiere decir que sea más ó menos importante, simplemente está en otra categoría.
Saludos y feliz inicio de año 👋🏻
“Quedarse en casa” fue lo que derrumbó el mundo. Y no, no ayudo con el problema del virus. Entiendo lo que trays de decir, pero no le mintamos a la gente. Sin mencionar que eso nada de eso fue voluntario. Creo que existen mejores ejemplos
Hola Luis, este proyecto nació durante la pandemia, los videos se construyeron en esa época mientras estaba en casa, así pensaba entonces y sigo pensando igual.
Basé el curso en fuentes verificables, confio en que te sirva
@@FullAdvanced y al igual que ayer, sigues equivocado