Pruebas de seguridad de calidad desde cero hasta fin

1. Introducción: Poca introducción sobre mí, mi nombre es Emeka, y solía ser ingeniero de aseguramiento de la calidad durante muchos años He trabajado para muchas empresas privadas y empresas gubernamentales también. Principalmente me especializé en aseguramiento de calidad menor, pero también he hecho algunas pruebas de automatización. Pero en este curso, voy a estar entrenando a ustedes en aseguramiento menor de calidad. Si necesitas QA o simplemente juegas y ordenas este curso. Bienvenida. De hecho voy a hacer un poco de capacitación para ponerlos al día en términos de obtener manual de calidad experto, cuáles son los roles y responsabilidades de un ingeniero de control de calidad, qué hacen sus actividades diarias, y también preparación de entrevistas y consejos sobre cómo hacer un buen Así que definitivamente disfruta el proceso y el aprendizaje feliz. 2. Qué es SDLC: Entonces, ¿qué es SDLC, donde SDLC significa ciclo de vida de desarrollo de software Entonces esto es algo así como donde ocurre toda la magia. Entonces, en términos del ciclo de vida del desarrollo de software, lo voy a desglosar en términos de, ya sabes, cuando se intenta desarrollar una aplicación o un software, ¿verdad? ¿Cuál es el proceso o el método de desarrollo de una aplicación o un software desde cero hasta su finalización Entonces, enteramente ese proceso completo es lo que llamamos un ciclo de vida de desarrollo de software. Ahora, en el ciclo de vida del desarrollo de software, pasa por muchas fases, y hay mucha gente, expertos en la materia o funciones laborales que juegan un papel en el ciclo de vida del desarrollo de software. Entonces voy a explicar todo como en términos de lo que son los jugadores del equipo, ya sabes, cómo se llevan a cabo esos procesos, ya sabes, cuando se lleva a cabo. Y también para ti, QA, ¿cómo participas en el ciclo de vida del desarrollo de software? ¿Cuál es tu papel? Ya sabes, ¿qué haces en ese proceso? ¿Cuándo entra usted? Entonces todos estos te van a explicar más adelante en el curso. 3. Cómo funciona SDLC: Entonces, ¿cómo funciona SDLC? Bueno, como mencioné, es como el paraguas de cómo se desarrolla una aplicación de principio a fin o se desarrolla un software de principio a fin. Entonces ahora en el SDLC está todo roto en fases. Entonces una de las primeras fases es la fase de análisis de requerimientos. Ahora bien, si eres un poco nuevo en SDLC o nuevo en TI, ¿qué es la fase de análisis de requisitos Entonces, la fase de análisis de requisitos es donde el analista de negocios o el propietario del producto , ya sabes, se sienta con los stakeholders. Entonces somos un analista de negocios. Un analista de negocios es una persona que es contratada para escribir realmente historias de usuarios o escribir las funciones de cómo se va a desarrollar la aplicación o el software. Entonces el artefacto o el documento, el usuario, el analista de negocios se le ocurre, es una historia de usuario o un documento de requerimiento de negocio Así que permítanme desglosarlo más. Entonces esta persona, un analista de negocios, acude al stakeholder. Ahora bien, ¿quién es un stakeholder? Stakeholders podría ser el negocio, alguien que en realidad es para vamos, por ejemplo, hablamos de Walmart. Quién es un actor en Walmart. Entonces podrían ser los gerentes, ya sabes, las personas que en realidad son como trabajar en Walmart las que tienen esta necesidad de digamos que quieren desarrollar una aplicación para que sus clientes se pongan en línea a comprar producto, ¿verdad? Así que los directivos o la gente de Walmart pueden conseguir un analista de negocios y SG saben qué, tenemos este tema. Tenemos este problema. Estamos tratando de desarrollar un software o una aplicación que pueda permitir a los clientes ir en línea para comprar cosas. Ese es un ejemplo típico. Entonces, lo que hace el analista de negocios es que el analista de negocios se sienta con los stakeholders de Walmart y ellos tipo de, como, ya sabes, redactan escenarios de alto nivel de lo que debería ser esta aplicación. Entonces la aplicación podría ser ejemplo típico, podría ser una aplicación regular donde la gente pueda comprar cosas. Entonces tiene que tener un ID de registro, tiene que tener una contraseña. Tiene que tener una pantalla de checkout. Tiene que tener donde podrías ingresar en tu tarjeta los datos, todas esas cosas. Entonces el gerente tiene una idea de lo que quiere. Depende del analista de negocios o del propietario del producto poner esto una manera más estructurada que esté más pensada, esté más organizada donde los desarrolladores o donde puedan trabajar en él. Por lo que los interesados son como dar ideas de alto nivel, no organizadas. Por lo que el analista de negocios ahora se encarga obtener todas esas ideas y ponerlas en un formato más estructurado. Entonces, ¿qué es un formato más estructurado? Podría ser, por ejemplo, la aplicación debería tener un ID de usuario. La aplicación debe tener una contraseña. Ahora bien, ¿qué tipo de contraseña? La aplicación, la contraseña debe ser sensible a mayúsculas y minúsculas. Ya sabes, debería ser de ocho caracteres a diez caracteres de longitud. Entonces todos estos son como específicos, directo al grano Entonces, eso es lo que el analista de negocios se encarga de hacer. Asegurarse de que quien se vaya a desarrollar tenga una comprensión clara de lo que está tratando de hacer o lo que se supone que debe hacer la aplicación. Entonces ese es el papel de un analista de negocios. El analista de negocios toma todas estas ideas, las baja en un formato organizado más estructurado para quien vaya a desarrollar la aplicación debería trabajar. Y el producto final del documento o lo que desarrolla el analista de negocios, el producto final, es lo que llamamos BRD Ese es un documento de requerimiento de negocio en Waterfall. Me meteré en lo que es Waterfall más adelante, en Agile es lo que llamamos una historia de usuario. Entonces una historia de usuario como que habla de un escenario, cuáles son los criterios de aceptación o lo que la historia debería tener típica historia de usuario podría ser la aplicación debería poder tener una página de inicio de sesión. Ese es un almacenamiento típico de usuario. Entonces todos estos se descomponen en pedacitos. Entonces no va a ser como un documento donde todo se acaba de echar a conocer. Todo está desglosado en tamaños, donde trabajas en esto y trabajas en eso. Voy a decir explicar más en términos de cómo funcionan cómo funcionan el proceso en términos de cómo las personas o cómo trabaja el equipo en esta aplicación para meterla en la fase de finalización. Pero solo un recapitulación, hablamos de la etapa de análisis de requisitos y quiénes son los responsables en esa fase, es lo que llamamos propietario de producto o analista de negocios Nosotros somos los principales responsables de interactuar con los stakeholders, algo así como, poner sus ideas por escrito o en un formato donde puedan, ya sabes, obtener más abajo a los desarrolladores para que ellos las desarrollen. 4. Fase de diseño: Entonces la segunda fase es lo que llamamos la fase de diseño. Ahora bien, aquí es donde ocurre la mayor parte del trabajo. Entonces, ¿quién es el responsable en la fase de diseño? Entonces, como mencioné antes, se redacta el requisito. Entonces, lo que llamamos el documento de requerimiento de negocio o la historia de usuario, los analistas de negocios se han sentado con los grupos de interés. Ponen todo por escrito, y todo ha sido documentado. Ellos han hecho la firma por parte de la gerencia. Entonces la dirección en realidad se ha apuntado que o, este requisito es completo y bueno para ir. Entonces, en la fase de diseño, el desarrollador recoge esto, ¿verdad? Entonces, cuando el desarrollador recoge esto, empiezan a entrar en la fase de desarrollo donde el desarrollador comienza a desarrollar esta aplicación. Ahora bien, podría estar en fases o podría ser todo a la vez. Todavía voy a desglosar los diferentes tipos de metodología, y voy a explicarte qué es la metodología en cuanto a cómo ocurre este desglose. Pero solo en general, el desarrollador que en realidad se encarga de escribir el código, es el encargado de diseñar esta aplicación. Por lo que escriben los códigos basados en el almacenamiento del usuario. Entonces el usuario sc mencionar o el documento de requerimiento de negocio que el analista de negocios le da al desarrollador es muy específico al punto, ya sabes, que todo debe ser etiquetado directamente. Entonces adivina qué, los desarrolladores no son los que la creatividad haciendo la creatividad depende del negocio o el analista de negocios o el donante de producto son los que han descubierto todo. Entonces lo que hace el desarrollador es desarrollar. A pesar de que el desarrollador todavía tiene que hacer algo de creatividad en cuanto a cómo desarrollar la aplicación o qué tipo de códigos y cosas escribir, pero no es responsabilidad salir de alcance. La responsabilidad es desarrollar la aplicación como se establece el requisito. Entonces si el requisito dice, el nombre de usuario debe ser de este carácter, debe ser de ocho a diez caracteres. Eso es. No debería ser como diez o 12. Podrían volver atrás y sugerirle al analista de negocios y decir, bien, creo que podría ser esto, que muchas veces no sucede. Pero aunque sugieran, bien, el negocio se deja para el analista de negocios o el dueño del producto ir a la dirección y decir: Bien, ¿qué opinas de esto? Ya sabes, Pero muchas veces cuando el analista de negocios o el propietario del producto consigue redactar esos requisitos, el desarrollador se desarrolla de acuerdo con los detalles de los requisitos o la historia de usuario 5. Fase de prueba: Aplicación a fondo. Ahora no hay nada como una aplicación 100% libre de defectos o 100% libre de errores. La mayoría de las aplicaciones van a tener defectos, incluso cuando entran en producción. Como cuando me refiero a producción, quiero decir, cuando van a lanzar, cuando en realidad los clientes lo están usando, todavía va a haber errores, pero su papel como ingeniero de control de calidad para asegurarse que los errores mayores se corten temprano. Entonces los que podrían entrar en producción o los clientes que usan podrían estar encendidos, tal vez errores menores que no impidan que el cliente haga lo que necesita hacer. Entonces, por ejemplo, si un cliente no puede ir a agregar sus carritos, agregar artículos a sus carritos o tal vez pagar lo que sea que compró en línea, eso es un gran error, ya sabes, y vamos a hablar más en términos de, como, ya sabes, pozos altos, cómo priorizamos algo que es un defecto o un error, ya sabes, así que todos estos van a explicar como el día a día la responsabilidad del día a día de un QA, ya sabes, ¿ qué buscas? ¿Cómo haces tu trabajo? Ya sabes, ¿qué cuando inicias sesión en el sistema inicia sesión para el día, cuáles son tus roles y responsabilidades? Vamos a hablar más eso en el próximo curso. Pero en general, para un QA, ya sabes, tu rol es probar la aplicación para encontrar defectos. Y eso requiere mucha creatividad. Eso requiere mucho pensar fuera de la caja. Al igual que, por ejemplo, ejemplo típico es usar en la contraseña L cumbre. Y si utilizo todos los e diez e diez caracteres, ¿verdad? Ejemplo típico. Y si hago que todos ellos sean más sensibles a mayúsculas y minúsculas. ¿Eso es pura velocidad y error? Y si estás pensando en eso, eso también debería coincidir con lo que hay en el documento de requerimiento de negocio o historia de usuario. Entonces tu historia de usuario o tu documento de requerimiento de negocio es tu guía en cuanto a cómo probar. Entonces va a que va a indicar exactamente y a qué se pretende hacer la aplicación. Ahora tu papel es poner a prueba contra ella. Tu papel es hacer lo contrario de lo que él está haciendo, lo que se supone que debe hacer para crear un error. Entonces si dice, usa nombre y contraseña o ve a checar, ya sabes, haces lo contrario Para ver cómo vas a reaccionar cuando haces lo contrario? Si haces lo contrario, ¿qué debes hacer? Definitivamente debería darte un error. Porque si haces lo contrario, deberías darte un error. Si no es darte un error y llevarte a donde se supone que te lleve, eso es un defecto. Eso es un error. También haces lo positivo. La típica contraseña de userm cumbre de la manera correcta, y eso debería llevarte al lugar correcto Y lo que llamamos a eso son pruebas positivas. Entonces, cuando haces lo contrario, se llama prueba negativa. La prueba negativa es probar contra la aplicación, probar lo que se supone que no debe hacer la aplicación. Para ver cuál será la reacción. Y sea cual sea la reacción, debes compararla con el documento de requerimiento de negocio o la historia de usuario. Entonces si dice nombre de usuario contraseña, envíe, ingrese en nombre de usuario, contraseña incorrecta, envíe. Debería darte un error. Y ¿qué dice el requisito sobre cuando ingresas en nombre de usuario contraseña incorrecta y envías? ¿Qué error muestra? ¿Te está mostrando el error correcto o no? Entonces todas las cosas es poco complejo, ya sabes, y es interesante, muy interesante como si requiriera mucha creatividad, mucho como pensar fuera de la caja, adivinar, ¿cómo puedo romper esta aplicación ¿Qué puedo hacer? Y muchas veces tu proceso debería ser desde, ya sabes, en un escenario de la vida real, cuando un cliente está usando una aplicación. Varios clientes están usando la aplicación. Van a estar dibujando cosas diferentes , haciendo cosas diferentes. Algunos de ellos podrían talar, Una persona podría poner en las tarjetas. Algunas personas pueden poner artículos en su caja. Ya sabes, algunas personas podrían simplemente cosas diferentes que están pasando en diferentes momentos. Tu papel es pensar en diferentes formas de cómo estos clientes van a estar usando esta aplicación en la vida real, ya sabes, y pensar en cómo puedo encontrar errores. Entonces tu rol no es asegurarte de que la aplicación esté funcionando. No. Tu rol es romper la aplicación. Tu papel es encontrar defectos. Encuentra formas de cómo la aplicación te dará un error. Porque si miras si lo piensas de una manera así de bien, queremos asegurarnos de que la aplicación esté funcionando, bien, se el nombre contraseña enviar, ir al check in, iniciar sesión en la aplicación, agregar elementos a tu tarjeta, check out, otras cosas, probablemente va a pasar, ¿verdad? Pero ahora cuando empiezas a hacer cosas de pruebas negativas, negativas como te mencioné, así ingresas y usas un nombre incorrecto contraseña cumbre, ¿qué pasa? ¿Te da un error Utilice el nombre derecho contraseña cumbre. Ahora vas a entrar al check in, ya sabes, recoger artículos de recogida en tu auto, ya sabes, sacarlo, ¿lo saca? Se actualiza, ya sabes, cosas así solo trato de romper el sistema, ya sabes, hacer cosas que van a requerir que te gusten porque esas cosas codificando son más solo una especie de cosas complejas. Entonces la parte positiva probablemente va a ser más fácil de desarrollar para el desarrollador y probablemente va a pasar. Pero cuando empiezas a hacer cosas como, sabes, en la vida real, porque en la vida real, los clientes van a hacer mucho de tu sabes, cosas, cosas diferentes como pueden agregar una tarjeta. Pueden agregar artículos a la tarjeta, continuación, se la pueden quitar, o pueden comprarla, volver atrás, quieren cancelarla, ya sabes, cosas así. Todos los escenarios son las cosas en las que vas a estar pensando, como, cómo puedo romper la aplicación, o cómo puedo encontrar errores pensando así. Entonces así es como piensas como control de calidad o como ingeniero de control de calidad. Y vamos a hablar más en términos de ya sabes, los roles y responsabilidades, ya sabes, qué artefactos o documentos necesitas idear como ingeniero de control de calidad para prepararte para las pruebas. Vamos a hablar de tipos de pruebas. Por lo que hay varios tipos de pruebas. Entonces como mencioné, el que te expliqué ahora mismo es positivo y negativo. Cuando eso posee es negativo, todavía hay varios tipos diferentes de pruebas Entonces vamos a explicar con más detalle y en el futuro. 6. Fase de implementación: La siguiente fase es lo que llamamos la fase de despliegue. La fase de implementación es así que digamos que todo es como si hubieras hecho tu parte como ingeniero de aseguramiento de la calidad , probaste la aplicación , encontraste defectos o errores, tu parte como ingeniero de aseguramiento de la calidad, probaste la aplicación, encontraste defectos o errores, los desarrolladores la arreglaron y se comunicaron contigo, y voy a extender todo el proceso de cuando encuentres un error, ¿qué haces? ¿Cómo lo haces? Pero digamos que todo está hecho y están listos para, como, poner la aplicación para que los clientes la usen, ¿verdad? Entonces así es lo que llamamos la fase de despliegue. Entonces la fase de implementación habla de, ya sabes, va a haber un proceso de cómo, ya sabes, la aplicación se despliega en producción. Entonces, cuando decimos producción, nos referimos a en uso, como para que los clientes se conecten a Internet y la usen. Tantas veces, ese proceso o fase de despliegue es lo que llamamos liberación. Entonces cuando dicen que un lanzamiento también se habla de despliegue. Entonces, ¿cómo se coordina el equipo, verdad? Entonces, cuando ocurre un lanzamiento, es cuando han hecho las historias de usuario, ellos han desarrollado la aplicación, la han probado, y has dado el visto bueno que hasta ahora es bueno, como si todo estuviera funcionando como se esperaba, luego el PO También el equipo de la muerte colabora en términos de empujar esta aplicación a producción Una cosa que hay que tener en cuenta es la terminología Cuando digo terminología son los términos o jergas de TI o ya sabes, metodología, Ágil, Cascada, QA, PA, PO, documento de requerimiento de negocio, todos estos términos, hay que estar familiarizado con él y poder platicar con esos términos porque eso es algo así como el lenguaje en Así es como sabes que la gente entiende. Entonces, cuando dices producción, no van a decir cuándo la presionan para que los clientes la usen. Van a decir que lo van a empujar a producción, ya sabes, y también cómo lo empujan a producción, a una fase de lanzamiento o a una fase de despliegue. Entonces todos estos términos es algo con lo que necesitas estar familiarizado, ya sabes, necesitas hablar este idioma en TI, ya sabes, así porque cuando estás trabajando en un equipo, estas son las cosas que vas a estar escuchando, todos estos términos. Vas a estar encontrándote con la mayoría de cuáles son los términos, así que, ya sabes, quieres poder familiarizarte con todos estos términos en términos de, ya sabes, qué significa Entonces como dije, estoy Así que la fase de despliegue habla de liberación, ¿verdad? Y el PO y también los analistas de negocios de negocios y los desarrolladores, ya sabes, colaboran en términos de conseguir este esfuerzo. El QA no está muy participando participar en este proceso. Entonces las formas Q realmente no participan mucho en la fase de lanzamiento es principalmente porque el desarrollo es más activo en esta fase. Ellos son los que aseguran que el ambiente sea estable. Se aseguran de que el ambiente esté listo. Y um una cosa que voy a explicar también es el medio ambiente, correcto. Entonces, cuando se está realizando el trabajo de desarrollo o la Q estaba probando, no lo hacen en un entorno diferente al que se implementa una aplicación en producción. Entonces cuando una aplicación se despliega en producción, ese es un entorno diferente porque te voy a decir la razón porque cuando por ejemplo, voy a usar un ejemplo típico de Walmart. Entonces el sitio web de Walmart, ¿verdad? Esa aplicación, es posible que quieran actualizar algunas cosas ciertas en ella. No va a ser inteligente usar ese mismo servidor o ese mismo entorno para hacer trabajos de desarrollo porque podría ensuciar o interferir con su producción real como cuando una aplicación está en producción, ¿verdad? Entonces, digamos que un desarrollador escribe un código y lo pone en el entorno en el entorno de prueba o en el entorno Dev. Si comparten el mismo ambiente con el ambiente de producción, podría interferir con la aplicación o el sitio web en producción. Entonces digamos típico walmart.com, ¿verdad? Los clientes lo están utilizando de manera constante, están comprando, vendiendo. Quiero decir, están comprando cosas, ya sabes, cosas así. Ahora bien, si hay una nueva idea o una nueva iniciativa de desarrollar una aplicación o un futuro que van a agregar a walmart.com, Quieren agregar una característica a eso. Derecha. Entonces no lo hacen cuando el desarrollador trabaja en esa función, ahora está trabajando en el mismo entorno que se aloja el walmart.com , si eso tiene sentido Entonces ellos nos en lo que ellos llaman el entorno Dev. Vas a escuchar en ellos un entorno Dev, ambiente QA, pre Prod, entorno UAT Entonces tienen un ambiente separado, un espacio separado donde realizan trabajos de desarrollo. Cuando me refiero al trabajo de desarrollo, me refiero a dev, testing, UAT, preprod Podrías tener a veces tienes el Dev y el QA podría compartir el mismo entorno La UAT puede tener un ambiente diferente o lo que llamamos preparación antes de la producción Entonces, la producción es en realidad donde está alojada la aplicación, donde los clientes pueden usar la aplicación real como sus sitios web típicos se fueron y cosas así es el entorno de producción. La aplicación está en uso. Pero esa no es la misma aplicación donde ese no es el mismo entorno donde se lleva a cabo el SDLC El ciclo de vida del súper desarrollo. Se habla de todas las fases requerimiento, desarrollo Q manera. Esa no es la misma fase de cuando hacen el trabajo. Entonces, cuando usted cuando el desarrollo está escribiendo el código, el desarrollador está escribiendo el código, la Q cuando está probando la aplicación, no está probando el mismo entorno en el que se aloja el sitio web para que los clientes lo usen. Entonces una vez que haces tus pruebas, el desarrollo escribiendo el código, estás haciendo tus pruebas, le das el pulgar hacia arriba, luego lo empujan ellos empujan ese cambio Sea lo que sea que el desarrollador escribió, o los cambios, la nueva característica que creó o los nuevos complementos o cualquier cosa, y lo has probado, lo empujan ahora a producción hasta donde los clientes lo iban a usar. Entonces, cuando se trabaja, no es el mismo lugar donde los clientes están usando el mismo sitio web. Entonces, cuando hacen de todo. Entonces hasta los datos, todo es maqueta, es todo falso, ¿verdad? No es real. Una vez que todo está hecho, entonces lo empujan a producción donde los clientes ahora pueden ver el cambio. Entonces digamos que el futuro era agregar digamos un tipo diferente de pad a la caja. Entonces, cuando intentas hacer un pago, quieres agregar MX ahora a una de las opciones de cómo puede pagar un cliente. A lo mejor Amex no es una de las opciones en producción. Entonces el desarrollador escribe el código para permitir que AMEX, trabaje en el sitio web. Cuando está escribiendo el código, En producción, MX aún no está disponible. Pero ha escrito un código para permitir que los clientes de MX puedan comprar con la tarjeta MX, y ese entorno se llama entorno Dev. Te lo envía, Un test, prueba que los clientes de MX pueden usar su tarjeta para comprar productos en el sitio web. Eso lo prueba. Eso todavía está bajo el entorno Dev and Test. Una vez que hayas dado tus pulgares que yo lo probé, los clientes de MX pueden usar su tarjeta para comprar cosas Y recuerda, has hecho tus pruebas negativas, has hecho todo ese tipo de pruebas, has dado a tus pulgares que todo está bien Después hacen el despliegue o el lanzamiento. Entonces el despliegue del lanzamiento es que los que ahora tienen empujan esa característica, ese cambio a producción donde los clientes ahora pueden usar la tarjeta AMEX para comprar. Entonces cuando empujas se llama liberación. Cuando lo empujas a producción, bien, los clientes pueden ahora y ellos hacen el anuncio de que ok, clientes, quiero decir, a pesar en su sitio web ahora, ves el logo de Mex y cosas así que los clientes ahora pueden usar Amex en línea. Entonces una vez que está en su sitio web, entonces quiero decir, los clientes ahora pueden usar la tarjeta AMEX para comprar. Entonces así es como la llamada entonces ese cambio ha ocurrido y ese cambio está ahora en vivo ahora está en producción para que los clientes puedan usar. Entonces así es como ocurre la fase de despliegue, ya sabes, y también en términos del entorno. Por lo que ese ambiente también es muy clave. Vas a la debilidad que mucho. Entonces la muerte, el ambiente Q es diferente al ambiente de producción. Y también vamos a hablar de UAT, qué se trata la UAT en términos de, ya sabes, cómo sucede ese proceso antes de que entre en producción Entonces yo solo eso es eso es en realidad eso es que es una fase de despliegue para lanzar. 7. Fase de mantenimiento: Y la última fase es mantenimiento y el ciclo de vida del desarrollo de software. Entonces en mantenimiento, eso es bastante fácil, fácil, como, ya sabes, la producción de diseño de aplicaciones, esto ha sido lanzado a producción. Los clientes lo están usando. Ya sabes, ahora están dando sus comentarios, ¿verdad? Entonces, por ejemplo, el mantenimiento está ahí para que puedan ver cómo los clientes están usando la aplicación. Entonces digamos, ya sabes, a los clientes les resulta fácil, ya sabes, sin defectos, sin errores, ya sabes, luego envían los comentarios. Ya sabes, no tomamos, nosotros, pero el negocio toma la retroalimentación, el equipo, el equipo de desarrollo o precisar el análisis del negocio, para ser más precisos. Ellos son los que toman la retroalimentación y la envían a los stakeholders que bien, la aplicación está funcionando bien, no hay errores, no nada. Ahora bien, si, por ejemplo, hay un futuro que se desarrolló, pero no está funcionando, ¿verdad? Entonces ustedes se lo perdieron. Entonces el deve se lo perdió, el QA se lo perdió, ya sabes, está en producción, los clientes se quejan de que pueden, por ejemplo, pueden checar, ya sabes, hay un error en Ese es un tema, ¿verdad? Y eso es algo para lo que está la fase de mantenimiento. Entonces el mantenimiento es verificar correctamente los comentarios de los clientes. ¿Cómo se desempeña la aplicación en producción? ¿Hay algún problema? ¿Hay algún error? Ahora, cuando hay un error, ya sabes, en producción, ya sabes, entonces también hay un proceso diferente de cómo puedes remediar esos errores Ya sabes, que, como, ya sabes, no te va a gustar el corte no van a descontinuar toda la aplicación en producción. No. Entonces digamos que desarrollaste el software, ¿verdad? Y lo pones en producción. Incluso si hubo un error, no va a cerrar toda la aplicación. Solo vas a lo que sea ese error, te pones en contacto con el BA, nosotros obtenemos información, luego trabajan en luego se la envían al desarrollador, le avisan al desarrollador que, esto es lo que está rompiendo esto es lo que está pasando. Este es el error de que meterse en producción. Entonces lo que pasa es eso lo que llamamos el hot fix. Un hot fix es donde se produce un problema de producción. La mayoría de estas tarifas calientes son en su mayoría altas prioridades, ¿verdad? Entonces es como por ejemplo, en la aplicación, podrían decir, tal vez los clientes no puedan agregar artículos a su auto. Derecha. Y para que ellos salgan, necesitan agregar artículos a su auto, luego ir a la fase de pago. Entonces cuando agregan algo a su auto no se muestra. Eso es un hot f eso es un gran problema, ¿verdad? Detener a los clientes de comprar cosas. Entonces lo que hacen los desarrolladores es que escribe un código. No en producción, escribe un código en el entorno dev. Yo cuando hablamos del entorno Dave, él escribe el código para permitir que los clientes puedan agregar artículos. Por lo que le escribe esencial a U ahora, la manera Q. Lo pruebas, así que compras un montón de cosas en línea y ves si él es capaz de agregar un montón de cosas en línea para ver si se pueden agregar a la c. Recuerda, ese no es entorno de producción. Ese sigue siendo el entorno dev. Entonces haces todo esto, te aseguras de que esté funcionando. Una vez que veas eso, bien, vas como cliente, vas a agregar artículos a tu auto y está agregando, ¿verdad? Sacas cosas, sacaron, vuelves a agregar cosas, ¿ agregaron todo el tipo de escenarios? Te aseguras de que puedas, los clientes realmente pueden pedir que se vayan al auto. Una vez que vuelvas a subir los ums eso a la muerte que está funcionando que el no puedes agregar c. Entonces el dev ahora empujará ese código a producción para actualizar el error actual. Entonces sea cual sea ese error, va a hacerlo después de que haya reten el código y tú lo hayas probado, va a actualizar ese error Entonces ese error lo que escribió el código va a reemplazar ese error que actualmente está pasando en producción, justo para que lo arreglen. Y nuevamente, el mantenimiento sigue ocurriendo. Entonces ahora los clientes van a volver a usar esa aplicación. Continúa usando la aplicación para ver ¿ahora pueden agregar cosas a su auto? ¿Pueden ahora agregar cosas al auto antes de que salgan? Si son capaces de hacerlo, entonces ese es un éxito de esa manera ese error se ha solucionado. Entonces siguen usando la aplicación. Los clientes seguirán usando la aplicación continuamente. A ver si todo está funcionando. Es decir, siguen usando la aplicación, no para ver, pero van a seguir usando la aplicación. Entonces el BA está monitoreando, ¿verdad? Para ver si hay algún problema que se esté encontrando o qué dicen los clientes, ¿les está gustando o, ya sabes, siguen encontrando más problemas? Y en escenarios de la vida real, el mantenimiento es enorme porque los clientes sí encuentran problemas en la aplicación. Encuentran errores, ya sabes, y eso es algo por eso que tenemos mantenimiento porque no vamos a empujar la aplicación y producción y desempolvar nuestras manos y s estaban abajo. No. Una vez que lo empujamos a una producción, todavía tenemos que monitorearlo para asegurarnos que no se encuentran errores porque si se encuentra un error, entonces lo que hacen los clientes. Son como parar, ¿verdad? Entonces es como y eso puede detener negocio y eso puede detener el progreso. Entonces lo que hacen es que tenemos que monitorearlo. Entonces quien monitorea es el equipo de la muerte, el equipo de la muerte, el equipo del SDLC Entonces los desarrolladores analistas de negocios, ya sabes, todos estamos ahí, formas, ustedes siguen ahí parte del equipo para asegurarse de que aunque esta aplicación esté en producción, los BA siguen monitoreando, ¿verdad? Solo para asegurarse de que la aplicación siga siendo exitosa mientras los clientes la están usando. Y si hay algún error, que mencioné, hay todo un proceso como expliqué, de cómo solucionamos esto y lo empujamos de nuevo a producción. 8. Qué es una metodología: Ahora abajo a la metodología, ¿cuál es la metodología? Metodología. Recuerdas cuando hablé sobre el ciclo de vida del desarrollo de software y cómo el paraguas de cómo se desarrolla una aplicación de cero a fin, ¿verdad? Entonces así es lo que llamamos el ciclo de vida del desarrollo de software. Ahora, piense en las metodologías un paso por debajo de SDLC. Entonces ahora, recuerdo cuando mencioné sobre todas las diferentes fases, la fase de requerimiento, la fase de desarrollo, la fase de pruebas, ya sabes, la fase de despliegue, la fase de mantenimiento , esas fases es lo que llamamos SDLC, ¿verdad Pero un paso a continuación es la metodología. Ahora, ¿cómo hacen los requisitos la profundidad, la manera Q, el despliegue, el mantenimiento, cómo cayeron o cómo podemos ejecutar una aplicación usando todas esas fases, verdad? Entonces el desarrollo de software es justo como la aplicación va de cero a fin. Ahora bien, en los los de principio a fin, tenemos fases, ¿verdad? Ahora bien, los metodólogos que utilizan esas fases. Así que en en en en prueba en desarrollo, Esas fases pueden diferir en función del tipo de metodología. Con base en un tipo de metodología, los requisitos de mantenimiento de onda Q de profundidad podrían diferir de otro proceso. Entonces se diferencian, son diferentes en la forma en que usas esas diferentes fases. Pero en general, esas cinco fases es a través de todas las metodologías. Pero ahora alguna metodología puede ser diferente. De otros, ya sabes, usando esas cinco fases, ¿verdad? Entonces los dos comunes de los que voy a estar hablando son cascada y ágil, ¿verdad? Entonces Waterfall es algo así como al principio cuando la TI era nueva, ¿verdad? Cascada comenzó con cascada. Entonces Waterfall es como un enfoque más antiguo. Agile es el nuevo enfoque. Entonces voy a explicar más en términos de qué es la cascada, qué es ágil, cuáles son los pros y los contras, ya sabes, cuáles son los diferentes. Y quiero que ustedes estén familiarizados con ambos porque siento que cuando conocen cascada, saben ágil, están más equipados. Eres más versátil en términos de ser un ingeniero de control de calidad con más experiencia. Entonces creo que hoy en día todo es ágil, como muchas empresas están haciendo la transición de cascada a ágil Pero es muy importante, es muy bueno que ustedes todavía conozcan cascada y sepan ágil. que de esa manera puedas ser más educado en cuanto a conocer las diferencias, sabiendo también estar más equipado para ser un probador de aseguramiento de calidad más calificado en cuanto a calidad cuando conoces ambos. Así que de esa manera, ya sabes, estás más informado en términos de entender el ciclo SDLC y saber cómo funciona un QA tanto en cascada como ágil 9. Qué es la cascada: Entonces, ¿qué es la cascada, verdad? Entonces, la caída del agua es una metodología, y usamos esa metodología de término. Entonces Waterfall es una metodología bajo SDLC o Super ciclo de vida de desarrollo Entonces, ¿de qué comprende la cascada? Cascada comprende de todas esas fases. Entonces hay una fase de requerimiento. Hay una fase de desarrollo, hay una fase de pruebas, hay una fase de despliegue y hay una fase de mantenimiento, ¿verdad? Al igual que expliqué todas esas fases en cascada. Pero, ¿en qué se diferencia o qué es la cascada? Así que Waterfall es una metodología donde una aplicación se desarrolla completamente de cero a fin antes de que entre en QA y Diplomado. Entonces así como cuando como mencioné, como para los analistas de negocios, justo cuando se sientan con los stakeholders y el tipo de como los stakeholders explica lo que quieren, cómo debe ser la aplicación, qué necesitan. El analista de negocios toma esta idea, escribe en un proceso más detallado, en un documento donde los desarrolladores puedan desarrollar la aplicación porque no quieres tener confusión cuando los desarrolladores están escribiendo los códigos. Quieren ser lo más específicos posible, específicos al punto como sea posible. Entonces, en qué off, La persona que escribe que se sienta con el stakeholder es lo que llamamos un analista de negocios. ¿Correcto? Y voy a explicar quién se sienta con las partes interesadas en Aj, cómo se llaman. Pero en Waterfall, alguien que se sienta con el stakeholder es lo que llamamos el análisis de negocios, ¿verdad? Y los documentos que los desarrollan que crean después de hablar con el stakeholders y lo envían al equipo de la muerte, los desarrolladores en la forma clave de hacer su trabajo, es lo que llamamos un documento de requerimiento de negocio. Ahora, en algunos casos, hay situaciones en las que tienen documentos del sistema de negocios. Por lo tanto, un documento del sistema de negocios está un paso por debajo de los documentos de requisitos comerciales. Por lo que los documentos de requerimiento comercial es donde se escriben todos esos requisitos . Entonces lo que llamamos un requisito. El requisito podría ser escenarios de viñetas, ¿verdad? Entonces podría ser Una aplicación, una página de inicio de sesión debe tener un ID de usuario. Eso es un requisito. I I I cascada, lo llamamos requisitos. Por lo que una contraseña debe tener entre ocho y diez caracteres de longitud. Eso es un requisito. La página de inicio debe tener un botón de enviar. Eso es un requisito. Una vez que haga clic en el botón enviar, el usuario debería poder agregar elementos a su ct. Eso es un requisito. El usuario debe poder sumar hasta t artículos en su corte máximo, eso es un requisito. Entonces A esto son cosas que los analistas de negocios se discutieron con los grupos de interés. Y los stakeholders fue como que los stakeholders no tienen que venir con toda la solución. Es lo que llamamos el analista de negocios y y los stakeholders se sientan y tienen esta conversación como si hicieran una lluvia de ideas, cómo debería sentirse la aplicación Y lo que este proceso del análisis de negocios sentado con el stakeholder es lo que llamamos una sesión de elicitación de requisitos Entonces una sesión de elicitación de requerimientos, es donde los analistas de negocios y los stakeholders Entonces los directivos de la empresa se sientan y discutieron cómo debería ser la aplicación. Entonces eso es lo que llamas reunión de requisitos geniales o sesiones de provocación o sesiones de taller Entonces, una vez que esto está realmente documentado, bien, entonces los analistas de negocios se bajan a un proceso más detallado lo documenta recuerdo en lo que hasta el cero está comenzando a terminar. Por lo que desarrollaron toda la aplicación. Digamos que es una gran vajilla de software. Hay una página de registro, tienes cosas que podrías comprar, tienes cosas que podrías agregar a tu tarjeta, tienes cosas que podrías sea cual sea la aplicación, el analista de negocios va a documentarlo todo. Todo bien en un documento de requerimiento de negocio. Y te dije cuál es el requisito, entonces es como otros escenarios, ¿verdad? Entonces, todos los requisitos tendrán algunos requisitos para tener hasta 300 escenarios, ¿verdad? Una vez que tienen eso, vuelven al negocio, y c esto es lo que se nos ocurre, ¿verdad? Esto es lo que el requisito es para que revisen. Una vez que los requisitos una vez que el análisis de negocios una vez que el gerente lo revisa, bien, y todo está bien, entonces se cierran. Por lo que el negocio tiene que firmar los documentos de requerimiento del negocio. Porque si no se inscriben, significa que no han dado la aprobación, porque los analistas de negocios no pueden simplemente darse de baja y entregársela al desarrollador. Sé que todo está procesado, todo necesita aprobación y cosas así. La mayoría de estas cosas son como grandes ofertas, ¿verdad? Entonces el negocio va al analista de negocios va a los stakeholders y dice, muestran el documento de requerimiento de cada escenario que han escrito y para que ellos lo aprueben. Este proceso es lo que llamamos una sesión de jab, sesión de jab JAD Entonces en la sesión de jab es donde el negocio cierra la sesión. Entonces firman y dan su aprobación y esto es también podrían volver y decir, ¿adivina qué? Este escenario aquí en el documento de requerimiento, no quiero esto, o podrían decir, se puede hacer de esta manera. Entonces van y vienen. Entonces, una vez que todo esté completo y firmado, entonces el negocio el análisis de negocios ese requisito que firmó los documentos de requisitos y los envía al desarrollador Además, también te envían una copia, el ingeniero de aseguramiento de la calidad. Porque de esa manera, una vez el desarrollador está desarrollando todo el código, ahora tienes lo que tienes los documentos de requerimiento de negocio en tu tabla, tienes la copia. Entonces ahora tu rol es, si tiene quizá 1010 requisitos, ¿verdad? Tu papel es llegar a ideas de cómo poner a prueba esas diez historias. Y te voy a explicar cómo puedes saber cómo puedes probarlos en el futuro, pero. Tu rol es si tiene diez escenarios en los requisitos que se han firmado, tu rol es ¿cómo captas esas diez historias? ¿Cómo pruebas esas diez historias? ¿Correcto? Entonces en Cascada, como mencioné como Cascada lo es todo de cero a fin. Así que el desarrollo del negocio anal escribe todos los requisitos de historias de usuario. El desarrollador prueba todo, desarrolla algún desarrollador desarrolla todo, las diez historias de usuario completas. Prueba a quién escribes casos de prueba y pruebas las diez historias completas, y entra en implementación y entra en producción. Así que empujas toda la función o todo el software o toda la aplicación a la producción a la vez. Entonces todo se hace al instante. Entonces ahora lo que es como el inconveniente, ¿verdad? Entonces la desventaja es que no es flexible, ¿verdad? Entonces digamos que el desarrollador desarrolla toda la aplicación. Y el negocio, el negocio tiene que el analista de negocios tiene que aprobar lo que el desarrollador ha desarrollado porque incluso el desarrollador lo desarrolla, no sólo van a empujarlo en producción, tienen que aprobarlo. Por lo que el analista de negocios con la autoridad del negocio de los stakeholders que aprueben esa aplicación. Y digamos que hay un error. A lo mejor era de ocho a diez caracteres en contraseña. Ahora es ahora esto cambiar de opinión. El cambio de negocio esa mente dijo que quieren que sea 11 a 12. Ya sabes, o cosas así, es como que tienen que es muy complejo en términos de una vez que una aplicación de lo desarrollado de principio a fin, es difícil empezar a cambiar las cosas. No da espacio. Ya sabes, y a veces, voy a explicar, ya sabes, la diferencia entre la caída del agua y edad porque ya sabes, cuando estás aprendiendo algo o cuando te estás acostumbrando a algo, sigues mejorando, más sigues haciéndolo. Cuanto más sigues haciendo, sigues mejorando. que en la caída del agua no Para que en la caída del agua no permita ese margen de mejora porque ahí está como el pensamiento sobre todos los requisitos, el negocio y el stakeholder han pensado en todos los requisitos. ¿Correcto? Y los desarrolladores la desarrollaron, has probado, aprecias la producción. No hay lugar para que esa creatividad vuelva a sedar saber qué. Pensé en esto de esta manera. Yo quiero hacerlo de esta manera. ¿Sabes? Entonces en lo que después de todo se hace al instante. Entonces una vez que la muerte y una vez que B B y los interesados se sientan en la sesión de elicitación, escriben todos los requisitos. El cierre de sesión, el desarrollador lo desarrolla todo, lo pruebas todo y lo empujas a producción. Entonces no hay lugar para esa creatividad donde, y si, lo hace de esta manera, ya sabes, así que eso es una diferencia entre cascada y Agile, pero voy a explicar Agile más adelante, pero en términos de cascada, es como que todo se hace de cero a fin, de principio a fin se hace el desarrollo, pruebas se hacen y todo junto, y empujado a la producción Así que eso es como una idea de cascada. Voy a explicar Agile en el siguiente capítulo. 10. Qué es Agile: Para la segunda metodología, voy a estar explicando ágil. En Agile, esto es más popular y esto es más común, y esto es lo que muchos equipos muchas empresas están usando ahora o adoptando ahora porque sentían que en cuanto al software, ellos desarrollan aplicaciones de software más efectivas, mejores que, ya sabes, la cascada tradicional. Recuerden, pensé que esa cascada empezó antes, pero ahora es como ágil es lo que todo el mundo está buceando para ir muchas empresas están adoptando. Así que recuerden que también expliqué sobre el SDLC y las diferentes fases en SDLC, derecho, la fase de requerimiento, la profundidad, pruebas, despliegue, mantenimiento, todas esas fases, y también en caídas de agua, como cómo esas fases se unen a la caída de agua, como que todo se hace de cero a la vez para terminar. Ahora en Agile, todavía tiene esas fases, ¿no? Entonces la fase de requerimiento, la fase de desarrollo, la fase Q way, la fase de despliegue, la fase de mantenimiento. Waterfall y Agile tienen esas fases. Pero la única diferencia es que como se usan esas fases, ¿verdad? Entonces ahora voy a explicar Agile. Entonces en Agile, recuerden les explico que alguien que se sienta con los stakeholders o los gerentes de la empresa es lo que llamamos los analistas de negocios y cascada en Agile, se llaman propietarios de productos. Dueños de productos, ¿verdad? Entonces, ¿qué son para los analistas de negocios, dueño del producto IGL Ahora, también, recuerden que mencioné que el documento que se le ocurre a un analito empresarial justo después de sentarse con los interesados se llama documento de requerimiento de negocio. Pero en Agile, sí, esa reunión sigue sucediendo, ¿no? Entonces todavía se sientan, la enlatadora de productos se sienta con los stakeholders, justo en Agile Pero ese documento se llama historia de usuario, ¿verdad? Entonces sigue siendo el mismo proceso que mencioné, pero así es como lo hacen. Entonces ahora, esta historia de usuario. Entonces Agile se divide en fases, ¿verdad? Así que recuerden que les dije qué de, como, desarrollaron todos los requisitos, tal vez los diez escenarios en un solo documento. En Ag D se hace de manera diferente. Entonces digamos que quieren desarrollar y encajar una aplicación completa. Entonces lo que sucede en Ag es al principio, van a descomponer la aplicación. Van a decir, ¿cuál es la máxima prioridad? ¿Quién determina la máxima prioridad? ¿El negocio? Cuando me refiero al negocio, me refiero a los stakeholders, los gerentes y al comple manager en Walmart, por ejemplo, pueden ver que con el dueño del producto, segundo gues, quiero desarrollar esta aplicación Quiero desarrollar el software. Entonces el PO, el Patón que tiene el negocio. ¿Cuál es su máxima prioridad en el software? Primero, tienes que tener una página de registro. El cliente debe poder iniciar sesión primero. Esta es la mayor prioridad. El PO que se va a romper va a tomar primero la funcionalidad de inicio de sesión. Entonces van a ser lo que es el segundo. Deberían poder agregar cosas a su c. Luego el PO inicia la segunda fase. Entonces la tercera fase, deberías poder realizar el check out cuando te refieres al check out, poder ingresar la información de pago. Entonces el negocio le está diciendo al propietario del producto en base a la prioridad, cuál es cuál es cuál viene primero. Vendo una aplicación, pero la aplicación se desglosa en fases, ¿verdad? Entonces, cuál es una prioridad alta. Entonces, ¿el negocio le dice al dueño del producto cuál viene primero? ¿Qué es lo que es más importante para ellos primero para que se construya la aplicación? Y una vez que eso se determina, entonces el PO comienza a escribir historias de usuario para la funcionalidad de inicio de sesión primero. Entonces no vas a escribir recuerda para qué sirven ellos escriben todo a la vez. Sabiendo ágil, escriben primero solo las historias de usuario para la funcionalidad de inicio de sesión. Entonces la historia de usuario podría tener tal vez cuatro escenarios. A lo mejor nombre de usuario contraseña, deberías tener traje, los tipos de contraseña que toma otras cosas bien Una vez el PO anota los escenarios en una historia de usuario. Entonces digamos por ejemplo, la historia de usuario puede tener así como lo mencioné, la página de inicio de sesión, derecho, la par tienen cuatro historias de usuario, ¿verdad? Entonces la historia de usuario es solo escenarios, ¿verdad? Así que va a una historia de usuario puede comprender de ID de usuario. Descripción. Entonces, ¿cuál es el ID de usuario podría ser el nombre de usuario, verdad? Er nombre nombre de usuario de la función. La descripción podría ser que un usuario debería poder ingresar el ID de usuario para acceder a la aplicación. Entonces también podrían ser criterios de aceptación, ¿verdad? Además, te estoy dando cosas que conforman una historia de usuario. Por lo que la historia de usuario tiene el par de características que conforman una buena historia de usuario. Entonces, ¿quién es el responsable de escribir la historia de usuario, el propietario del producto? Entonces los propietarios del producto tienen la responsabilidad de decir, Bien, esta historia de usuario está calificada para ir al negocio para que ellos la aprueben y la vean o para que la revisen. Entonces tiene que tener algunas certezas descripción resumida del usuario, criterios de aceptación, ya sabes, lo que debería implicar la historia, ¿verdad Entonces, una vez que eso es como determinado que una vez que la historia de usuario, al propietario del producto se le ha ocurrido que al productor se le han ocurrido esas historias de usuario Entonces lo llevan al negocio. Así que recuerda, el producto um probablemente tenga como cuatro historias de usuario, ¿verdad? Entonces se rompe toda la función de inicio de sesión en cuatro escenarios. Entonces el ID de usuario, contraseña, cumbre, tipos de caracteres de contraseña, y todas esas cosas. Se lo llevan al negocio. El negocio dice: Bien, me encanta, ¿verdad? Esto es exactamente lo que quiero. Dan la aprobación, ¿verdad? Recuerdas en falla de agua dije como una sesión de jazz en ágil, no hay sesión de vendaval porque es solo pedacitos pequeños, ¿verdad? En Waterfall, hay una gran hay una sesión ga porque comprende todos los escenarios, ¿verdad? Pero en Waterfall está en Agile está en fases, así que no hay necesidad de sesion de vendaval Entonces el negocio lo aprueba. Cuando lo aprueben, vean la misma fase como mencioné con SDLC Se lo envían al desarrollador. El desarrollador recoge las historias de usuario, ya sabes, trabajan en ello. Te lo mandan. Ahora, no te preparas para toda la aplicación. Solo para lo que se está preparando es probar solo la función de registro. Eso es todo por ahora. Una vez que la función de registro, una vez que probó la función de registro en el desarrollador la ha desarrollado aquí, ahora prueba la función de registro. Después lo envían a para su despliegue, derecho y yendo a mantenimiento. Entonces el no pick up el segundo. La segunda fase y la segunda fase podrían ser para verificar el ct, a la derecha. Entonces eso significa que ¿pueden los clientes como iniciar sesión en la aplicación? Es decir, no el inicio de sesión a la aplicación. ¿Pueden agregarle artículos a su gato y todas esas cosas, verdad? Entonces esa es la segunda característica. Entonces por eso es como un aj va en fases, ¿verdad? Quiero decir en algunas de esas fases es todo un proceso porque ahora podemos dejar de hablar de scrum y de todas esas cosas como diferentes frameworks bajo agile Pero lo ágil en general va por fases, ¿no? Así que la cascada es como una enorme como cada toda la aplicación completa, y eso es cascada. Entonces ágil es como en fases. Todo se descompone en fases, pero siguen adoptando todas las etapas del SDLC, ¿verdad? Entonces, ¿todas las etapas como la etapa de requerimiento, la etapa de desarrollo, etapa Q way, la etapa de implementación y la etapa de mantenimiento? caída del agua y la agilidad son consistentes en esas, pero ¿cómo se diferencian, verdad? Entonces en las caídas de agua, todo se desarrolla desde scath hasta el final. Agile es como, ya sabes, en fases. Por lo que hacen la fase uno, la fase dos, la fase, hasta que se desarrolla toda la aplicación. Y a medida que están haciendo las fases, están desarrollando las pruebas, están empujando a la producción, desarrollan pruebas, empujan a la producción. Por lo que algunas características están saliendo poco a poco, poco a poco, gradualmente hasta que se ha desarrollado toda la aplicación. Ahora bien, ¿cuáles son las ventajas, verdad? Ch, ¿por qué la gente usa j porque permite espacio para el cambio Entonces digamos que en la fase uno, desarrollamos el inicio de sesión página dos, los clientes pueden agregar a la c. Pero ya sabes, el negocio y el PO escriben la historia del usuario. Desarrollador lo está desarrollando. Pero el negocio dice adivina qué, cambié de opinión, ¿verdad? No necesitan cambiar toda la aplicación. No necesitan cambiar la funcionalidad de registro. No necesitan cambiar esa fase. Entonces, sea cual sea esa fase en s agregando elementos a su c Simplemente pueden ir allí y ajustarlo que permita espacio para ser adaptado, la aplicación a la adaptada a. Yo permite la mejora. Entonces digamos la fase uno, estás escribiendo el registro, haces la página de registro, desarrollas la página de registro. Segunda fase, están haciendo los elementos de adición a la tapa. Cuanto más esté trabajando en ello, más conocedor estará sobre la aplicación Tanto la muerte, ambas como la manera Q. Porque y también el negocio puede realmente escribir mejores historias ahora, porque ahora cuanto más trabajas en una aplicación, desarrollándola en fases, ya sabes, todo el mundo está discutiendo, hablando de ello, las ideas fluyen. Porque ahora deja espacio para un software más efectivo. Porque ahora es como si todos estuvieran trabajando en ello, ya sabes, estamos haciendo cambios. Es decir, lo estamos haciendo. Entonces cuando lo sigues haciendo, ya sabes, sigues mejorando, ya sabes, más que en cascada, lo único que estás haciendo es desarrollar porque ya se redactó todo el requisito , así que no puedes cambiar nada. Todo parte de los requisitos. Entonces una vez que se escribe el requisito, no hay espacio para las ideas porque el desarrollador no requiere tener idea alguna, es solo hacer lo que indica la estadística de requisitos. Pero en Ágil, ya sabes, el requisito no está completamente escrito, solo está escrito en fases. Entonces ahora el negocio y el PO pueden autoadivinar qué en la fase dos, sabes, porque han trabajado en la fase uno, ya sabes, Fase dos, pueden empezar a llegar más ideas que pueden empezar a cambiar Ya sabes, los requisitos pueden empezar a cambiar. Ya sabes, las historias de usuario pueden empezar a cambiar, ya sabes, y eso permite un software más efectivo, amplio y lo que son por una vez que se sientan, los analistas de negocios y este negocio se sientan en una habitación y escriben el conjunto redactan todo el requisito, ¿verdad? Entonces no hay lugar para esa idea. Entonces es lo que sea que pensaran en ese momento. Eso es lo que van a hacer. Pero en AJ, tienen más tiempo para seguir pensando, seguir mejorando y cosas así. Entonces es por eso que muchas empresas están empezando a adoptar Aj. Y en cuanto a Aj es más caro porque interino allá atrás en mi carrera es como las formas claves más altas en cascada cuando se ha desarrollado la aplicación, ¿verdad? Entonces cuando se escribe la aplicación, se escribe el requisito del negocio, el desarrollador ha desarrollado la aplicación, luego el keyway más alto solo para que solo vengas por tres meses o cuatro meses No obstante, prueba la aplicación y ya está, ¿verdad? Entonces tienes tanto puesto en tu plato como si tuvieras todos estos requisitos que necesitas para gustarte sabes, entender y escribir, preparar tus documentos y cómo probarlos en forma justa una vez o lo que sea. Pero en Agile, ya sabes, a partir de la fase uno, el QA ya está involucrado, ya sabes, entonces porque vas a estar probando todas esas fases. Entonces de esa manera, el equipo de está involucrado, el equipo de QA está involucrado, el producto nueve está involucrado. Entonces es más caro, ¿verdad? Todo el mundo está involucrado desde el principio. Así que eso permite, ya sabes, pero tiene sus ventajas. Pero en términos de costo, Agile también es más caro. Pero quiero decir, las empresas están enfatizando el valor de adoptar Agile porque, ya sabes, permite una mejor aplicación de software, permite la creatividad, permite errores, ya sabes, así que eso es diferente entre la cascada y ágil 11. Qué es el control de calidad: Ahora me lleva al gran tema. ¿Qué es QA, verdad? Qué es Q ingeniero de aseguramiento de calidad o pruebas. Así que a veces se podía escuchar el término aseguramiento de la calidad o se podía escuchar el término testing. Ya sabes, todo es lo mismo, o podrías escuchar el término ingeniero de aseguramiento de la calidad. Entonces, ¿qué es el probador de ingeniero de garantía calidad o QA seguro?. Entonces un ingeniero de aseguramiento de la calidad o un tester, ya sabes, es un profesional que trabaja en el ciclo de vida de desarrollo de software que prueba la aplicación. Entonces ese es tu papel. Tu papel como he estado mencionando en el curso es probar la aplicación. Entonces, ya sabes, ahora voy a explicar también diferentes tipos de pruebas. Te voy a explicar cuales son los documentos o artefactos que se requieren para tengas o que hagas tus pruebas o que hagas tu trabajo o que hagas tu rol, ya sabes, entonces quiero decir, QA es grande, ¿verdad? Es realmente grande, como en términos de que tienen varios tipos de pruebas, tienen varios tipos de software. Te vendría bien y no estoy tratando de decir eso para asustarte, sino solo para que te interese, esto es un cuidador, ¿verdad Podrías tener una vida, un cuidador, ya sabes, ser ingeniero de aseguramiento de calidad No es algo que sea solo un pasivo, ya sabes, es igual que lo mismo, no. Muchas empresas que tienen ingenieros de QA, basados en la empresa, tu rol podría ser diferente, pero creo que lo fundamental es lo mismo, lo cual te voy a explicar. Te voy a dar lo fundamental del ingeniero de aseguramiento de la calidad, ¿verdad? Entonces ese es el básico de lo que va a ser similar en todos los ámbitos. Ahora lo que puede ser diferente de un QA podría ser la tecnología, ¿verdad? Entonces algunos QAs pueden decir que necesitan una prueba UAT y voy a explicar qué es eso Entonces podrían decir, necesito un probador de automatización. Necesito un tester para esto, o incluso aún necesito un tester que pueda probar XML. Necesito un tester que pueda probar esta aplicación. Entonces ahora para que no tengas que saberlo todo, ¿verdad? No sugiero que te aconsejo que lo sepas todo porque la tecnología es realmente grande, es realmente grande. Entonces solo necesitas enfocarte en tus propias cosas en las que necesitas en las que querías enfocarte y construir tu carrera con ellas. A lo mejor podrías hacer la transición a otras cosas para que pudieras aprender otras cosas. Ya sabes, pero creo que lo que te voy a explicar, te voy a dar los fundamentos del ingeniero de aseguramiento de la calidad A partir de ahí, puedes empezar a agregar cosas como, ya sabes, agregar software o agregar diferentes tipos de básculas a tu plato, pero quiero decir, en general, creo que el papel de quiero decir, el papel de ingeniero de aseguramiento de la calidad es probar. Ya sabes, así es que creo que ese es el comienzo y génesis de toda la historia, como para poder probar la aplicación, para romper la aplicación para encontrar defectos. Porque si estás trabajando y te mandan cosas a tu plato y pruebas y te pulgas hacia arriba, nada no hay error, te van a mirar como, realmente lo probaste correctamente, ¿verdad Entonces el que te aseguras de que las pruebas, nos encontramos con defectos o como dije errores defectos, bugs, y como vas por arreglar esos errores defectos o pantanos, ¿verdad? por arreglar esos errores defectos o pantanos, ¿verdad Entonces estas son todas las cosas que es su responsabilidad como ingeniero de aseguramiento de la calidad, slash tester Así que vamos a profundizar un poco más en, ya sabes, ¿cuáles son los artefactos? ¿Cuáles son los documentos, la forma Q que se te ocurre, cómo pruebas? Cuáles son los diferentes tipos de pruebas, ya sabes, todas las reglas y responsabilidad, la tarea del día a día del ingeniero de aseguramiento de la calidad. 12. Dónde encaja el control de calidad en Agile: Entonces, ¿dónde encaja realmente QA en Agile Waterfall SDLC, verdad Y creo que ustedes probablemente ya deberían saber esta respuesta. Pero, ya sabes, Para un QA, ya sabes, como mencioné tu papel es en realidad probar la aplicación, ¿verdad? Entonces en el ciclo de vida del desarrollo de software, y Water Fast lash Agile, ya sabes, ¿en dónde caen ustedes? Ustedes caen en la fase de pruebas, ¿verdad? Entonces en QA, en el proceso de ciclo de vida de desarrollo de software o cascada o Agile, ustedes están en la fase de pruebas. Entonces, cuando se escribe una aplicación, ya sabes, basada ya sea en un documento de reembolso comercial o en cosas de almacenamiento de usuarios, el desarrollador desarrolla la aplicación Estás en la fase de pruebas, la fase de pruebas se trata de ti, ¿verdad? Antes de que entre en implementación y mantenimiento, y en la fase de pruebas, podrían pasar muchas cosas. Como ustedes son los líderes, ustedes son el jefe. Ustedes son los que toman la autoridad. Hay tanta responsabilidad. Y no digo eso para asustarte, sino para prepararte o para que entiendas a lo que vas a entrar A esa fase, ese software. Imagina ese software completo que va a ser utilizado por X cantidad de clientes en la producción de la vida real en la vida real, en esa fase, sea lo que sea en cascada o ágil. Entonces en cascada durante tres, cuatro meses, toda esa aplicación entera está sobre ti. Y no solo te digo porque las muchas veces tienes múltiples Q formas, así como cuatro o cinco Q formas trabajando en un proyecto, ¿verdad? Entonces todos ustedes son responsables de eso por esos cuatro o cinco meses. Entonces está mucho en tu plato en términos de, la gente te está mirando, como, ya sabes, si se pierde un defecto, quiero decir, podría ser un tema como, ya sabes, ¿cómo es que esto se perdió, verdad? A veces, porque una vez que te lo pierdes, y el negocio lo echa de menos, voy a explicar qué es la UAT, que es la prueba de negocios, pero una vez que pierdes un tema y el negocio lo echa de menos y entra en producción y falla, entonces van a ser como, el primero voy a preguntar esto, hizo la prueba de QA. Derecha. Entonces no estoy diciendo que te asuste, pero estoy diciendo que esto es un gran problema. Es por ello que muchas formas Q hacen por encima de seis cifras por la responsabilidad de lo que tienen que hacer. Y es divertido, ¿verdad? Es que, ya sabes, voy a mostrarte, ya sabes, cómo prepararte, cómo estar más preparado. Como ingeniero de aseguramiento de la calidad, para que la mayoría de estos errores no ocurran. Ya sabes, te preparas, te instalas, como, ya sabes, y haces bien tu trabajo. Ya sabes, no es algo que deba asustarte ni nada, pero es que es una enorme responsabilidad, ya sabes, y es algo que quieres poder ejecutar porque hay mucho en tu plato, como, hay mucha obligación contigo que sabes, una vez una aplicación y una aplicación que tanta gente va a estar usando, ¿verdad Ya sabes, tener esa creencia de que probé esto, bien, lo verás en producción, probé esto y está funcionando. Ya sabes, te hace sentir bien. Hace que tu confianza salga como, Bien, trabajé en esto, ¿verdad? Y podría ir positivo o negativo. Entonces quiero prepararte para sentir dónde cuando llegas a ese lugar, haces un buen trabajo y, ya sabes, tu jefe está feliz, ya sabes, compañía es feliz, ya sabes, que tuviste un software exitoso en producción. 13. Tipos de pruebas: Entonces en este video, vamos a hablar de tipos de pruebas, ¿no? Entonces hay varios tipos de pruebas. Entonces a lo que me refiero, varios tipos de pruebas es como lo que realmente estás probando, ¿verdad? Entonces voy a hablar tantos tipos de pruebas en este curso, ya sabes, desglosar cada tipo de pruebas abajo. Entonces, en esto como QA, ya sabes, el y no estoy diciendo que tengas que ser responsable o deberías saber todo o poder realizar todos los diversos tipos de pruebas porque como dije, QA es grande, ya sabes, solo debes enfocarte en pocos tipos de pruebas. Pero voy a explicar todo la mayor parte. Y voy a explicar los que deberías poder conocer, ya sabes, para hacer tu trabajo y tener una carrera, ¿verdad? Porque hay muchos tipos de pruebas, pero las de igualdad como los tipos típicos de pruebas que una vez que contratan un QA deberían poder realizar. Derecha. Pero a veces otros tipos de pruebas pueden ser más complejas y cosas así y requerir cierto tipo de habilidad para ejecutar y esas y cosas así. Pero voy a ir a explicarlos también, pero también te diré en cuál debes enfocarte para tener un transportista, si vas a entrar en QA, si es algo que tienes un poco de experiencia y quieres, como, poder aprender nada para poder conseguir un trabajo y hacer tu trabajo antes de empezar a un trabajo y hacer tu trabajo mejorar incrementando tus conocimientos. Entonces voy a explicar todos los diversos tipos de pruebas y en la que siento que deberías enfocarte. 14. Pruebas funcionales: Entonces, el primer tipo de prueba y el tipo más importante de prueba son las pruebas funcionales. Entonces, ¿qué son las pruebas funcionales? Quiero decir, las pruebas funcionales es todo lo que me han mencionado probando las funciones de la aplicación o el software. Entonces voy a volver al ejemplo de Walmart. Entonces cuando dije, quieres desarrollar ellos quieren desarrollar una aplicación de cero a fin. Y por ejemplo, quieren comprobar probar la pantalla de registro, puedes agregar cosas a tu tarjeta, podrías check out y todas esas cosas. Todas esas son funciones de la aplicación, lo que se supone que debe hacer la aplicación o lo que se supone que debe realizar una aplicación, derecho. Entonces la función suele ser como, ok, ¿puedo ingresar nombre de usuario contraseña y enviar? Esa es una función, ¿verdad? ¿Puedo agregar cosas a mi auto? Esa es una función. ¿Puedo realizar el check out de una aplicación? Esa es una función, ¿verdad? Entonces todas estas son funciones de una aplicación. Entonces eso es en realidad El no voy a usar ningún porcentaje específico, pero esa es la mayoría del papel de ingeniero de aseguramiento de la igualdad. Prueba de la función de aplicación. Y te voy a explicar ¿cómo pruebas eso? O sea, para que pruebes que tienes que prepararte para probar esas funcionalidades, ¿verdad? Pero las pruebas funcionales son mayoritarias o obra de ingeniero de aseguramiento de la calidad. Probando la función de una aplicación. Ahora bien, la aplicación podría ser muy compleja, ¿verdad? Tenemos varios otros tipos de pruebas que voy a explicar. Pero la larga historia corta es que las pruebas funcionales son muy importantes para un ingeniero de aseguramiento de la calidad pueda realizar. Entonces te voy a mostrar como realizar o como hacer pruebas 15. Pruebas de caja negra: Por lo que nuestro segundo tipo de pruebas es Black Box. Entonces, ¿qué son las pruebas de Black Box? Las pruebas de Black Book son lo mismo que las pruebas funcionales. No voy a sumergirme demasiado en esto, pero Black Box es también otro término al que llaman para pruebas funcionales. Entonces exactamente lo mismo prueba las funciones de una aplicación, ya sabes, la funcionalidad y esas cosas. Así que en realidad podrías usar caja negra de Black Box o pruebas funcionales, lo mismo. 16. Pruebas de caja blanca: Entonces, el siguiente tipo de pruebas son las pruebas de caja blanca. Entonces, las pruebas de bus blanco en su mayoría pruebas realizadas por los desarrolladores, lo que las ondas Q no son responsables de hacer esas pruebas. Entonces, ¿qué son las pruebas de autobús blanco? La prueba de caja blanca es probar el código del código de la aplicación. Entonces digamos que el desarrollador desarrolla una aplicación escribe el código. Por lo general, podrían tener otro desarrollador que pruebe ese código, ¿verdad? Entonces quieres probar ese código por ciertas razones. Quieres ver que usas el tipo correcto de código, ¿verdad? Utiliza el código está a la altura de la norma. Entonces básicamente, como una manera Q, estás probando las funciones, derecho. No vas a depender o no vas a mirar los códigos y probar no. En realidad eres como probar el front-end. Entonces cuando estoy en front end es como la aplicación, correcto, estás haciendo pruebas manuales. Entonces como este curso es la prueba manual. Entonces en realidad estás ingresando el nombre de usuario, estás ingresando la contraseña, estás haciendo clic en alguna mezcla. Prueba de caja blanca es que estás probando el desarrollador en realidad está probando el código en sí, ¿verdad? Entonces todos esos scripts S sharp y java, y todas esas cosas, como el desarrollador en realidad está probando esos códigos. Entonces lo hacen antes de enviarlo a QA. Entonces yo pruebas de caja blanca también es lo que ustedes llaman pruebas unitarias. Entonces vas a usar eso quiero decir, realmente no usan pruebas de caja blanca, lo llamas pruebas unitarias. Entonces las pruebas unitarias son una necesidad, derecho, los desarrolladores siempre hacen pruebas unitarias. Entonces, una vez que el desarrollador desarrolla la aplicación, el equipo de la muerte hace su propia prueba unitaria. Entonces prueban la aplicación, la prueban el código, derecho, que utilizan al escribir la aplicación. Una vez que ese código está bien, luego lo envían al QA para realizar sus pruebas funcionales o sus pruebas de caja negra o cosas así, así que todo el tipo de pruebas. Pero inicialmente, como cuando el desarrollador ya conoces, escribe el código como si hicieran sus propias pruebas unitarias o pruebas de caja blanca para probar, específicas como asegurarse de que la aplicación esté a la altura del estándar y cosas así. Entonces ellos lo enviaré a la QA U que no realizará su otro tipo de pruebas. Y te voy a explicar sabes más a detalle, qué otro tipo de pruebas de las que particularmente serás responsable. ¿Por qué las pruebas unitarias mencionadas fueron porque, ya sabes, es un tipo de pruebas, verdad? Y es algo que surge todo el tiempo, vas a estar escuchando todo el tiempo, como si probablemente estuvieras como, bien, ¿qué son las pruebas unitarias? Qué son las pruebas de caja blanca. Entonces esto es lo que son las pruebas unitarias. No eres responsable de eso. El equipo sordo es el responsable de ello. Pero es un hecho una especie de prueba en SDLC, como ya sabes, muchas empresas, como muchos desarrolladores tienen que hacer pruebas unitarias para probar la aplicación Entonces no voy a hablar demasiado sobre esto porque es sobre todo para el equipo de la muerte que realiza eso, ellos saben cómo hacerlo. En su mayoría es probar los códigos. Ya sabes, es muy complejo en cuanto a probar las características. Así que en realidad no eres ningún responsable. Sólo queremos asegurarnos de que se ha hecho. Quiero decir, toma tu responsabilidad para asegurarte, pero ellos te lo dirán y ya hemos hecho las pruebas unitarias y todo es lo que sea y te lo mandan para que empieces a hacer tu propio tipo de pruebas. Entonces pruebas funcionales, pruebas de bus negro, eso es el único responsable de ti. 17. Pruebas adhoc: Las pruebas para adultos son algo aleatorias son aleatorias, ¿verdad? Entonces lo mencioné de manera Q, como, todo tiene que estar organizado, ya sabes, pero cuando estás haciendo pruebas para adultos, eso te permite simplemente, ya sabes, solo ser aleatorio, ya sabes, muchas veces, ese no es tu eso no es el grueso de tus pruebas. Ya sabes, ahí no es donde más estrategias en tus pruebas Donde más estrategias es tu prueba funcional, tu prueba a N, bus negro, UAT, ya sabes, aducto es justo, ya sabes, hacia Podrías simplemente pasar por todo y ver que todo está funcionando. Entonces eso es lo que se agrega. Eso es lo que es la prueba de aductos, ya sabes, y eso también es responsabilidad de un QA Por lo que el QA también se encarga de realizar las pruebas de aductos Entonces, cuando el aducto viene en su lugar, muchas veces es donde la mayor parte de todas las pruebas funcionales, las pruebas de bus negro se han hecho, las pruebas N a N se han hecho, pruebas de regresión se han hecho Entonces haces pruebas de aducto solo para asegurarte, antes de dar tus ums de eso todo está hecho, todo está funcionando correctamente 18. Pruebas de regresión: Otro tipo de prueba es la prueba de regresión. Entonces, las pruebas de regresión, este es otro tipo de prueba muy importante, ¿verdad? Entonces, ¿qué es la prueba de regresión? Por lo que las pruebas de regresión una vez que se ha probado una aplicación. Entonces, una vez que has hecho tus pruebas funcionales, has realizado pruebas funcionales o de busto negro, has hecho tus pruebas de N a N, encuentras defectos, ¿verdad? Cuando encuentres defectos, te voy a explicar ahora cómo funciona el proceso de defectos o el ciclo de vida del defecto. Entonces ya sabes, cuando pruebas una aplicación, encuentras un defecto en este momento. Yo entonces depende, ¿qué tipo de defecto es? Es una prioridad alta, baja prioridad, media, baja. Por lo que la alta prioridad es algo que está determinado por el análisis de negocios con la dirección del negocio. Entonces, si no puede iniciar sesión en una aplicación, si un usuario no puede iniciar sesión en una aplicación, El negocio ha dicho que la página de inicio de sesión es de alta prioridad. Recuerda cuando digo el Aj, como, ellos quieren trabajar primero en esta cara. Entonces, si quieren trabajar primero en esta cara, ya sabes que eso es de alta prioridad. Ahora si encuentras algún defecto en eso, sabes que si ingresas el nombre de usuario y contraseña y clic en la cumbre, no puedes iniciar sesión. Entonces sabes que eso es de alta prioridad porque eso está impidiendo que el cliente inicie sesión en el sistema. Entonces eso es de alta prioridad. Cualquier problema que encuentres, como si el botón enviar no funciona, o la sensibilidad entre mayúsculas y minúsculas de contraseña, o caracteres largos más largos, esos son defectos de alta prioridad, y esos tienen que solucionarse. Entonces una vez que encuentras eso, bien, hay un defecto hay una rueda de entrada en defecto, derecho. Entonces voy a mostrarte algunos de los artefactos o los documentos de un reporte de defectos. Entonces, de qué se supone que comprende un defecto o un error. Entonces es como el ID del defecto, la descripción. Entonces la descripción habla cuál es el error al que te enfrentas, ¿verdad? La descripción puede ser cuando hago clic en el botón de cumbre, no pasa nada, ¿verdad? Esa es una descripción, entonces también va a venir con los pasos inesperados reales. Entonces los pasos reales es, ya sabes, lo que realmente está sucediendo. Entonces, cuando haces clic en el botón de cumbre, no pasa nada. ¿Cuál es el resultado esperado? Los resultados esperados que cuando hago clic en el botón de cumbre, se supone que inicie sesión al cliente, ¿verdad? Además, puedes actuar en la captura de pantalla de envío. Así que la captura de pantalla es como imágenes de lo que estás diciendo. Y también pasos para reproducir porque si solo lo envías al desarrollador que ok, esto es un defecto, este es un error al que me enfrento. El pase esto hago clic en el botón de cumbre no va. El desarrollador está trabajando en tantas cosas, ¿verdad? Entonces para ahorrar tiempo, se quiere poner pasos para reproducir. Entonces pasos para reproducir o lo que quiero decir pasos para reproducir es, ¿qué hiciste? Para llegar a esa flecha, ¿verdad? Entonces primero ingresé el nombre de usuario. Yo primero segundo ingreso contraseña, T pensó que hice clic en cumbre, y yo y cuando hago clic en cumbre, no pasó nada Entonces esos son los pasos que diste. Entonces hay que incluir todo esto en el reporte de defectos. Y te voy a mostrar como, ya sabes, documento de reporte de defecto alto parece, ya sabes, pero esto es solo los pulmones solo vi como un defecto esto es lo que es un defecto y como lo documentas. Entonces una vez que haces eso, lo envías al desarrollador, al desarrollador, tomas recoge el defecto, cambia el estado para abrir, ¿verdad? Entonces, una vez que lo envías al desarrollador es nuevo, el estado es nuevo. Cada defecto tiene el estatus y el pus, por lo que es paridad alto estatus nuevo El desarrollador lo elige, cambia el estado para abrir, trabaja en él. Cuando funciona en él, te lo envía de vuelta. Así que una vez que creas un defecto, tienes que asignarlo a quien sea el desarrollador que vaya a estar trabajando en él. Entonces hay diferentes herramientas, de cómo ingresas defecto. Puedes usar Excel, puedes usar herramientas de software. Sabes, te voy a mostrar te voy a explicar algunas de las herramientas que hay ahí afuera quiero decir, en base a lo que está utilizando la empresa, la compañía te proporcionará la herramienta. Entonces una vez que tienes que tener siempre a alguien, lo vas a asignar al desarrollador, quien sea que vaya a estar trabajando en ese defecto, lo asignas ingresando los pasos, defecto, yo descripto resultados reales, resultados esperados, sprintsht, Cuando se lo envías en srtus de nuevo, él lo va a abrir cambia el estado para abrir, trabaja en ello cuando funciona en él, te lo devuelves a enviar Cuando el sensor de vuelta a ti va a ser reparado. Entonces lo que tienes que hacer es una vez que el sensor te devuelva, tienes que regresar y volver a probar esa funcionalidad Entonces, una vez que el sensor vuelve a ti como arreglado, vuelves a la aplicación. Lo que quiere decir es que en realidad ha ido a la propia aplicación en entorno dev. No estoy hablando de la vida en producción. La aplicación en entorno deve, y ha ido a arreglar ese botón de cumbre Así que recuerda que toda esta aplicación está siendo alojada en el entorno Dave, ¿verdad? Entonces ahora entra, arregla ese botón de enviar eso de una manera que, si ingresas el nombre de usuario contraseña y haces clic en enviar, ¿verdad? Debería llevarte él debe registrar la persona, al cliente en. Deberías iniciar sesión con el cliente, ¿ verdad? Entonces lo ha arreglado. Para que lo que el defecto está diciendo cuando te lo envía de vuelta como arreglo. Está diciendo que ok, vaya a la aplicación. Ingresa en la contraseña del nombre de usuario, haz clic en enviar y se debe iniciar sesión al cliente. Entonces eso es lo que ese defecto diciendo que está arreglado. Entonces ahora para ti, lo que supongas lo que voy a hacer es que vas a ir a la aplicación, ingresar el nombre de usuario contraseña, hacer clic en cumbre, una vez que te inicie sesión, entonces ese defecto ya ha sido pasado. Eso es lo que ellos llaman pase. Entonces cambias esas estrellas de fijas a pasadas. Ahora bien, si, por ejemplo, recuerda cuando estás probando, no solo vas a probar nombre de usuario contraseña cumbre la cumbre está funcionando y eso se pasa, no. También van a probar ahora porque a veces cuando el desarrollador arregla esa cumbre, algo más podría romperse. Me refiero a otra cosa mi gran nombre otra espada de error. Entonces hay que probar alrededor de esa característica. No solo vas a ir a probar el nombre del usuario y hacer clic en ese botón de cumbre está También vas a probar, si ingreso el nombre de usuario, si introduzco la contraseña incorrecta y hago clic en enviar. ¿Qué pasa si no ingreso contraseña de nombre de usuario, haga clic en enviar? ¿ Me va a dar el error correcto? Tal vez n, el botón de cumbre ya está funcionando, pero algo ha roto el error. Entonces, cuando haces clic en nombre de usuario, contraseña incorrecta cumbre, el mensaje de error que estoy recibiendo ahora está mal. Ese es otro tema, ¿verdad? Entonces hay que probar en torno a ese futuro. Ya sabes, así que una vez que todo está arreglado, cambias ese defecto de fijo a pasado. Entonces cuando se pasa el defecto, entonces ese defecto se cierra. Ya sabes, entonces cambias el estado de pase y el cambio y el estado, puedes ponerlo como pasado o puedes ponerlo como cerrado. Entonces, una vez que se pasa o se cierra, eso significa que ese defecto se hace ahí, como si fuera amado en. Ahí está la opinión de que la gente puede ir a verlo, pero cuando ves el estado como cerrado, eso significa que ese tema ha sido cerrado. Entonces eso es lo que es. Entonces lo que estoy diciendo esto es porque me lleva abajo a las pruebas de regresión. Entonces las pruebas de regresión ahora es Una vez que hiciste todas las pruebas completas y encontraste defectos, y el desarrollador te envía defectos y tú lo arreglaste y él lo ha arreglado y, ya sabes, digo que envías los defectos del desarrollador, él lo ha arreglado, te lo envía de vuelta a ti vuelve a probar otro todo de ida y vuelta, derecho Recuerdo tener en cuenta, como una manera Q, vas a estar teniendo esto de ida y vuelta con el desarrollador como. Tus cosas de prueba están fallando errores, estás registrando estás registrando defectos, él lo está arreglando él te lo está enviando de vuelta, estás probando todo eso de un lado a otro. Entonces una vez que hayas hecho todo eso y quiero decir, inicialmente, va a ir al defecto va a aumentar, va a ser enorme. Pero tu engranaje sigue funcionando, los defectos se están reduciendo. Entonces porque ahora es como que él está arreglando es arreglar, está arreglando, está arreglando, estás volviendo a probar, arreglando, estás cerrando, estás cerrando Entonces una vez que llega al final fue como, bien, ya no puedes encontrar más defectos. Ya sabes, la aplicación está funcionando, haces una prueba de regresión. Entonces, las pruebas de regresión es ahora lo que las pruebas de regresión son básicamente están probando el sistema heredado vs y la nueva funcionalidad. Entonces por ejemplo, ahora, una aplicación puede ver el sitio web menos el único montaje de com, ¿verdad? Quieren desarrollar una aplicación, pero ahora esta no es una aplicación de marca. A lo mejor la aplicación ya existe, pero quieren cambiar la fatura del registro Entonces la función de registro es que tal vez quieran cambiar algo ahí. A lo mejor quieren agregar autenticación de dos factores, ¿verdad? Pero aún existe toda la aplicación. Entonces, de lo que se trata las pruebas de regresión es que una vez que el desarrollador desarrolla la funcionalidad de registro, derecha y la empuja a tu fin. Van a probar el segundo factor de atericación de dos factores Van a probar la función de registro. También vas a probar toda la aplicación Eso es lo que ellos llaman pruebas de regresión. Entonces pruebas lo que ha desarrollado, y ahora pruebas toda la aplicación de lo que ellos llaman sistema heredado. Entonces pruebas si si cambia x y, y él lo empuja. Vas a probar de la A a la Z. No. Vas a probar S Y, X e Y. Yo también voy a probar de la A a la Z. así que vas a probar todo. Entonces ese tipo de pruebas se llama prueba de regresión, y eso ocurre después pruebas funcionales o pruebas de regresión, pero antes de esperar. Entonces pruebas funcionales, pruebas de bus negro, estás enviando mensajes de texto solo x y, ¿verdad? Sólo estás probando las cosas que él desarrolló. Esas dos características que desarrolló. Pero la regresión es que estás probando X Y, y también estás probando de la A a la Z. Estás probando todo, toda la aplicación, ya sean las que no tocó o cualquier cosa, la vas a probar Y también vas a probar el que él actualizó o cambió. Sabes, vas a probar eso también. Entonces a eso se le llama pruebas de regresión. Entonces esto sucede. Pruebas funcionales en este escenario, estás probando X Y, black bus sing. Entonces haces pruebas de regresión, por lo que prueban X Y y Z. Luego después de hacer eso, ahora haces tus pruebas adc para probar aleatoriamente Una vez que haces eso, quiero decir, ni siquiera antes de hacer pruebas aleatorias, haces de extremo a extremo. Entonces lo haces después de hacer funcional, haces caja negra, luego haces de extremo a extremo. Después de que haces de extremo a extremo, luego haces regresión, después haces regresión, luego ahora haces UAT Entonces la UAT es la que una vez que hayas hecho tu regresión, ahora puedes hacer lo siento adc Cuando haces ad hoc, puedes enviarlo al negocio para hacer la U esperando. Entonces U wait es el último tipo de prueba. Ahí es cuando has hecho toda tu prueba, luego la envías al negocio para que ellos hagan la U esperando. Así que recuerda, pruebas funcionales de caja negra, luego haces de extremo a extremo, luego haces regresión de regresión, luego haces ad hoc, entonces puedes enviarlo al negocio para que ellos hagan U esperando. Por lo que estos son los más para las pruebas que realiza como prueba de aseguramiento de calidad. Voy a hablar más sobre diferentes otros tipos de pruebas, y va a ser un tipo de prueba más complejo, que es principalmente para específico. Muchas veces, las personas que hacen este tipo de pruebas son en su mayoría personas que están trayendo para este tipo de propósito específico. No es algo que te digan, tú también necesitas hacer este tipo de pruebas, personas que están diseñadas o personas que son responsables de este tipo particular de pruebas y te voy a explicar eso en la próxima 19. Pruebas de extremo a extremo: N a intestino. Entonces, ¿qué es N al intestino? N al intestino es la mayoría de las veces esto se hace al final de las pruebas funcionales, ¿verdad? Entonces digamos que una prueba de función puede ser, ya sabes, probar la página de inicio de sesión, nombre de usuario, contraseña, enviar. Eso es una prueba funcional. Ya sabes, prueba una aplicación. Se puede poner un producto en el CAT, eso es pruebas funcionales. cliente de prueba puede realizar el check out, usted puede realizar el check out de su cT usando su método de pago, su método de pago preferido, eso es pruebas funcionales. Entonces N a las pruebas es probar, desde el principio, desde cuando un usuario o un cliente inicia sesión con su nombre de usuario y contraseña hasta cuando sale de la aplicación utilizando sus métodos de pago preferidos. Entonces vas a imitar, vas a ejecutar una manera de escenario, entra un usuario, ingresa el nombre de usuario contraseña cumbre va a la aplicación, ingresa como recoge un par de ítem lo pone en la tarjeta Va a pagar, paga y sale y reciben una confirmación por correo electrónico, eso es un final completo para n pruebas. Tantas veces es como si estuviera hecho hacia el final, si es un ágil, correcto, ágil como se hace en fases, ¿verdad? Entonces, una vez que se hayan completado todas las fases, desea realizar una prueba de extremo a extremo. Entonces de principio a fin, porque pensarlo, como en darse cuenta escenario. Los clientes van a hacer lo van a hacer. Como, van a iniciar sesión. Van a agregar elementos a la gorra. Ellos van a checar. Van a revisar su correo electrónico para obtener una confirmación por correo electrónico. Ellos van a hacer todo eso. Quizá no lo hagan de inmediato. A lo mejor podrían iniciar sesión por nosotros, ya sabes, hacer algunas compras, cosas publicitarias para el cp, el motu, todas esas cosas Entonces eventualmente tal vez lo pusieron en su lista de espera o algo así, antes de los días tiempo o cosas así, pueden venir a checar, pero sí realizaron todos esos escenarios para que realmente tuvieran un ciclo completo, correcto, para que para que una transacción suceda. Eventualmente tuvieron que iniciar sesión en algún momento. Tienen que agregar elementos a su acc. Tenían que hacer el check out, y en realidad acudieron a su correo electrónico para enviar confirmación por correo electrónico. Entonces en realidad hicieron todo esto. Entonces a las pruebas es verificar que eres capaz de hacer login, agregar artículos a tu cp, ya sabes, check out y check e mail confirmación de confirmación. Entonces así es lo que yo llamé un a intestino. Entonces en el agua para, es fácil porque como mencioné, todo se desarrolla inmediatamente probado de inmediato. Entonces es más fácil para ti hacerlo al intestino, ahí mismo. Entonces, una vez que hagas tus pruebas funcionales y pruebas de caja negra, podrías simplemente hacer una testina, ya sabes, para probar todo Entonces también te voy a explicar cómo prepararte para hacer una a intestino. Pero yo solo estoy como explicar lo que es un to intestino. Entonces más adelante abajo, el curso, te mostraré cómo prepararte o cómo realizar pruebas de n a n, cómo realizar pruebas funcionales, pruebas de bus negro y todo esto, derecho. Pero solo te estoy explicando lo que son, todos los tipos de pruebas. Recuerda que mencioné sobre las pruebas funcionales. Entonces, las pruebas funcionales son solo probar principalmente un escenario, ¿verdad? Entonces solo nombre de usuario contraseña cumbre, ya sabes, como una página de inicio de sesión , ya sabes, probando que los caracteres parciales están funcionando. Eso son pruebas funcionales. Entrar pruebas también es funciones a, así. Son funciones, pero es un propósito diferente, derecho a las pruebas funcionales, tú probando el escenario. Te pruebas ¿Puedes agregar artículo a tu ternero? Puedes checar, ya sabes, solo funciones, funciones. Ingresa estos, estás probando múltiples funciones a la vez. Múltiples funciones como un ciclo completo. Estás probando desde el principio hasta el final. Entonces prueba funcional es sólo una función, dos funciones. Unos es múltiples funciones a la vez. Ya sabes, solo asegúrate de que se transacción completa o pueda llevar a cabo una transacción completa o un ciclo completo. Entonces así es lo que llaman a Ns. 20. Pruebas de aceptación de usuarios: Sí, pruebas de aceptación de usuarios. Entonces esto es muy importante. Este es uno grande porque las pruebas de aceptación del usuario son algo que también se lleva a cabo. Al igual que en todo lo que mencioné para el aseguramiento de la calidad, como las pruebas funcionales son la máxima prioridad. Ese es el tipo número uno de pruebas que debe realizar el QA. Las pruebas de aceptación del usuario se detuvieron allí. Y muchas veces el QA puede realizar pruebas de aceptación del usuario o un negocio, el negocio puede realizar pruebas de aceptación del usuario. Recuerdas cuando pasé con los negocios, así que los negocios, en su mayoría como los stakeholders, ¿verdad? Los gerentes dicen que doy un ejemplo, gerente en Walmart, ¿verdad? Cuentan con el equipo. No es el gerente el que realmente vaya a probarlo, pero podría ser tal vez personas que atienden al cliente o personas con las que en realidad van a estar interactuando que no los propios clientes, pero, ya sabes, tal vez personas a las que les gusta, son empleados de Walmart, ya sabes, pueden ser ellos los que les gusten, salgan y miren la aplicación. Entonces, ¿cuándo sucede eso? ¿Cuándo hace esta prueba de aceptación de usuario o lo que llamamos UAT UAT, aceptación de usuario? ¿Cuándo sucede esto? Así que recuerda cuando la aplicación te ha llegado a la cara, como para que hagas las pruebas de QA o el ciclo de vida del SDLC Entonces una vez que hayas hecho, como tus pruebas funcionales, caja negra, ya sabes, todo este tipo de pruebas a N pruebas, quiero decir, le das tu ms de eso. Todavía voy a explicar más tipos de pruebas, pero has hecho todo el tipo de pruebas que necesitas para probar directamente en la aplicación. Se llega al BA, eso está en el agua en Ágil o el PO en agua en quiero decir, el BA en Cascada o el PO en Ágil. Yo digo Bien, esto ha sido probado, ¿verdad? Entonces ahora tomarán la solicitud y la entregarán o el BA o el PO tomarán sus propias pruebas, ¿verdad? Ellos simplemente lo harán rápido, como, solo comprueban la funcionalidad. Si todo se ve bien, lo enviarán al negocio para que el negocio realice sus propias pruebas. Por lo que el negocio tendrá su propio equipo que haría sus propias pruebas internas. Entonces no es como que el público haga las pruebas. Tienen su propio equipo, gente en trabajo como los stakeholders, ¿verdad? Ellos son los que obtendrían su propio equipo para probar la aplicación. Ahora bien, ¿cómo realizarían ese tipo de pruebas? Entonces tus pruebas, tus pruebas como QA, tus pruebas funcionales son más exhaustivas, ¿verdad? Probamos la aplicación, desde una perspectiva tecnológica, como estás probando para romper la aplicación y encontrar defectos. Las pruebas UD son principalmente como pruebas suaves suaves, solo pasan así me refiero características como solo para verificar como mayoría están haciendo la parte positiva, ¿verdad? Así que estás haciendo, ¿puedo iniciar sesión? ¿Puedo pedir a mi tarjeta? ¿Puedo revisar, ya sabes, esto así? Estás probando desde para romper la aplicación. Entonces si por ejemplo, un checkout puede decir, quiero usar este tipo de tarjetas para pagar. Van a usar autos inválidos que la aplicación ni siquiera acepta para ver si te va a dar un error, y si te da un error, qué tipo de error. Entonces ese es el tipo de cosas por las que debes estar revisando. Entonces eso es así en la UAT, sólo van a comprobar la parte positiva Entonces van a revisar la página de registro, ya sabes, el check in. ¿Puedo agregar sal a la tarjeta? Puedo, ya sabes, revisar, ya sabes, ya sabes, todo ese tipo de cosas como las que llamamos partes positivas Pero en QA, estás probando positivo y lo negativo, estás probando todo. Ya sabes, el tuyo es más minucioso, y lleva más tiempo. Ya sabes, pero UA es más rápido, y ellos tienen su propio equipo y ellos simplemente, ya sabes, solo revisan la mayoría de las cosas, ya sabes, tantas veces, puedes perder un defecto, y el co de negocios se pierde un defecto porque el tuyo debería ser más minucioso. Entonces, si te lo perdiste, lo más probable es que el BS lo pierda. Pero nuevamente, el BA no el BS, sino el negocio tienen más conocimiento, ¿verdad? Esto es algo que han estado haciendo, ¿verdad? Esto es algo que, ya sabes, son más conocedores del producto Así que en realidad podrían tener formas de cómo pueden probarlo mejor para entenderlo porque tienen una mejor comprensión. Entonces, por ejemplo, una persona de negocios como el stakeholder en Walmart, tiene mucho conocimiento sobre ellos saben cómo usan la aplicación, cómo interactúan los clientes con la aplicación. Saben cómo el cliente a qué lugares van los clientes, cómo usan sus. Entonces vas a hacer esos escenarios, ¿verdad? Entonces vas a probar en función del cliente qué tipo de cosas hace el cliente. Y siempre es una señal de alerta cuando el negocio encuentra el defecto que te perdiste, ¿verdad? Entonces si pruebas la aplicación, ya ves, encontraste el defecto, lo arreglaste todo. Das los términos y el envío al negocio, y el negocio encuentra el defecto. No es una buena mirada de tu parte porque demuestra que no hiciste tu trabajo correctamente. Tantas veces quieres desahogarte, Bien, encontraste todos los defectos, lo arreglaste. Ahora, eso es lo que llamamos temas conocidos. Los temas conocidos son como cuestiones minoritarias, menores, ¿verdad? Entonces ejemplo, podrías buscar puedes encontrar un defecto y error ware, haces clic ingresas la contraseña de nombre de usuario, haces clic en la cumbre y no lleva a ningún lado. El botón de cumbre no funciona. Eso es un gran Error. Por eso llamamos a un enorme defecto. Y priorizas esos defectos. Voy a hablar priorización y de todas esas cosas Pero eso es un gran problema, ¿verdad? Eso tiene que ser arreglado, como tiene que ser arreglado antes de que entre en el negocio. Entonces pero hay temas donde tal vez el aspecto y sensación de la aplicación tal vez la cumbre, quiero decir, como, ya sabes, los gráficos y cosas así. Hay cuestiones menores, derecho. Eso es lo que llamamos temas conocidos como sabes de esas cosas porque no concuerda con lo que estaba en el requisito o los s de historia. Estos son temas conocidos, pero está bien, ¿verdad? Debido a que una aplicación no se puede probar al 100%, no puede estar 100% libre de defectos o errores. Ya sabes, es imposible, ¿verdad? Todavía va a haber problemas. Pero esos problemas son cosas que bien, ¿ pueden los clientes seguir usando la aplicación con los pocos problemas Si eso es un sí, entonces esos son pequeños temas, ¿verdad? Y no hay temas que tengas que hacerle saber al negocio que, bien, esto es lo que encontré, ¿verdad? Los son los temas conocidos que ol pequeños errores aquí y allá. Conocidos, por lo que se conocen. Los analistas de negocios estarán al tanto de este tema. Entonces hablas con los analistas de negocios que esto es estos son los temas conocidos, ¿verdad? Entonces los analistas de negocios o el PO lo llevarán al negocio que bien, prueben la aplicación, pero mientras estás probando la aplicación para UAT, estos son los problemas conocidos, ¿verdad Estos son los temas que de baja prioridad. No es gran cosa, cosas así. Entonces, cuando el negocio está probando, el negocio tiene en mente que, bien, estos son los temas conocidos que el negocio, el BA o el PO me llamaron la atención, pero vamos a probar cosas importantes. Entonces las cosas mayores son grandes defectos que deberían ser que deberían ser no deben conocerse. Entonces si un tema, como por ejemplo, como mencioné, el nombre de usuario pase para la cumbre no está funcionando desde el cualquier negocio encuentra que es de mala suerte para ti porque como, como es que, como es que, no recogiste esto, y no estoy tratando de mandar para asustarte, pero solo estoy tratando de retro eso. Esta es esta carrera es un gran problema. No es por eso que muchas veces gente termina alrededor de seis cifras porque aquí es mucha responsabilidad y esto es algo que cuesta millones de dólares, estas aplicaciones cuestan millones de dólares y no quieres sacar una aplicación, están gastando esta cantidad de dinero y ya sabes, se está rompiendo o está fallando, ya sabes, entonces quieres hacer seguro que cuando estás entrando, como, en realidad te estás tomando tu tiempo para probar correctamente y hacer todo bien porque no puedes simplemente hacer cualquier trabajo de diapositivas y cosa que estás empujándolo a producción no. Ya sabes, tienes que hacer una prueba adecuada. Tienes que ser un verdadero profesional en la prueba de la aplicación. Entonces voy a hablar más sobre así que solo esto es UAT. Voy a hablar más sobre otro tipo de pruebas. Y esta UAT es el negocio que realmente prueba esta aplicación, por lo que son ellos los que, ya sabes, son los responsables, los únicos responsables, pero como también puedo mencionar, los QAs también pueden entrar también Por lo que los QAs también pueden haber visto QAs realizar pruebas td también. Y cuando sí realizaste pruebas de comido, ellos lo realizan junto con el negocio. Entonces una vez que están hechos se les da en sus términos y todo lo que han hecho la caja negra funcional, para terminar las pruebas, todo ese tipo de pruebas, se coordinarán con el analista de negocios o el propietario del producto a realizar y con el negocio para realizar la UAT Entonces a veces podrías apoyar al negocio en la realización de UAT junto con ellos. Pero muchas veces siempre es el negocio haciendo la UAT. 21. Pruebas de automatización: Entonces, lo que estaba diciendo antes era como todo el tipo de pruebas. Entonces este tipo de pruebas es lo que llamamos pruebas de automatización. Entonces las pruebas de automatización son enormes porque aquí es hacia donde se dirigen las pruebas en este momento. Así que muchos probadores, quiero decir, las pruebas manuales nunca desaparecerán Siempre va a haber oportunidades para un probador manual. Pero si quieres que te guste aumentar tus conocimientos, aumentar tu monto en dólares, como si ganas más dinero, automatización, es algo así como lo siguiente. Entonces, cuando Q comenzó, era una prueba manual. Pero a medida que pasaba el tiempo, o la automatización empezó a ir y muchas empresas han empezado a adoptar la automatización y empiezan a contratar probadores de automatización porque es más barato, ¿verdad Algo que harán cinco probadores manuales solo un probador de automatización puede hacer todo, lo que harían cinco probadores Entonces, ¿por qué contratarían cinco probadores cuando un tipo de automatización puede hacer todo? Y nuevamente, las pruebas señoriles seguirán siendo relevantes. Así que no lo pienses bien, si sabes pruebas señorial significa que tengo que ir a la automatización para ganar dinero. No. Incluso con las pruebas señoriles, aún podrías tener una carrera. Pero la automatización es en realidad el camino en el siguiente es el futuro. ¿Y qué son las pruebas de automatización? Las pruebas de automatización son secuencias de comandos. Entonces, el scripting es básicamente las herramientas, que están diseñadas para que puedas hacer scripting Entonces, las pruebas de automatización, en realidad puedes recordar cuando hablé de pruebas funcionales, pruebas de regresión. Todo esto se puede hacer usando automatización. La automatización es como cuando digo scripting, es como escribir códigos Por ejemplo, cuando dices prueba de mano normalmente es entrar, vas en la aplicación walmart.com, entrando en la página de inicio de sesión, ingresas nombre de usuario contraseña enviar, te llevará a la siguiente pantalla Con la automatización, no es necesario ingresar manualmente la URL de Walmart, ingresar nombre de usuario, ingresar contraseña, ingresar enviar. Escribes scripts, escribes funciones de código de función en la herramienta, la herramienta de automatización que interactuaremos con el sitio web de Walmart e iremos al sitio web de Walmart y realizaremos esas funciones. Entonces, por ejemplo, escribirás un guión en la herramienta. Te voy a contar algunas herramientas que puedes usar para hacer automatización. Escribes un guión en la herramienta. Y y esa herramienta interactuará con sitio web de Walmart e iremos ahí cuál es la URL de Walmart, ingresaremos el nombre de usuario, ingresaremos la contraseña, y los clics desde él todo por su cuenta. No vas a hacer nada. Entonces él lo va a hacer y enviarte el resultado. Si te lleva al registro si pasa por la página de registro, puedes decirte que esto ha pasado. Si falla, también te dará un error. Así que ni siquiera tienes que estar ahí. A veces podrías pudrir el script de automatización de la noche a la mañana. Y escribir tantas funciones. Usted para probar la página de inicio de sesión, para probar, verificar las tarjetas. Puedes obtener cosas y puedes agregar cosas a la tarjeta, puedes quitar cosas del cp Puedes verificar el checkout. Puedes verificar confirmar que estás recibiendo correos, correos confirmación a tu dirección de correo electrónico. Podrías probar todo eso. Entonces solo necesitas programarlo. Solo necesitas escribir todos los scripts completos, dejar que se ejecute. Entonces ahora ves lo que estoy diciendo que es robusto Triste de hagas todos estos escenarios de entrenamiento de pruebas. Podrías simplemente escribir algunos scripts de combustible y permitir que la automatización lo haga. Y muchas veces lo hacen porque por ejemplo, en lugar de ti muchas veces las aplicaciones siempre se construyen desde cero. Están construidos a partir de tal vez agregaron funcionalidades de combustible para calificar. Ahora bien, ¿por qué contrataría a alguien que va a probar manualmente 400 escenarios hacer pruebas de regresión, verdad? Yo me acuerdo dije que cambiaste x y, entonces los dos factores tication, y tienes que probar a z. Pero voy a contratar a alguien que va a tomar seis meses para probar X Y y A a Z para pruebas de regresión Cuando ya tengo scripts en automatización, donde ya tengo el código para probar de la A a la z. Así que lo único que ha cambiado es X Y. Entonces sí, puedo tener pruebas menores Mal test hago X Y, pero puedo ver escribir scripts, puedo hacer X Y, pero de una A a la Z, ya tengo un repositorio. Entonces donde almacenan todos estos códigos, es lo que llaman el repositorio a. Repositorio es como donde se escriben todos esos comandos. Así que vayamos al repositorio, escojamos todos esos comandos y ejecutémoslo. Así que no necesito comenzar a que alguien escriba todos esos scripts y comience a probar cada escritura todas esas funciones y comenzar a probarlas manualmente. Cuando puedo simplemente tirar todos esos scripts que están en el repositorio y ejecutar todo sin siquiera me gusta y es como correr a un buen. Puedo hacer que una persona solo haga toda la regresión. La automatización es muy buena para la regresión. Muy bien porque se fundan muchas empresas eso es más barato porque regresión como mencioné, es cuando estás probando el sistema heredado, estás probando la característica antigua más un nuevo futuro. Entonces con la automatización, la característica antigua ya tienes guiones para ello. Ya lo hicieron en el pasado. Entonces ya está sentado en la representación. Así que solo lo recoges. Y ejecutarlo. Así es como no necesitan contratar a demasiadas personas porque en las pruebas señoreras, si vas a hacer pruebas menores para regresión, tienes que contratar gente para probar toda la funcionalidad antigua y la nueva funcionalidad. Pero con la automatización, la vieja funcionalidad es que los scripts ya están ahí. Entonces solo necesitas sacarlo del repositorio y ejecutarlo y solo una persona puede hacerlo. Entonces es por eso que la automatización es mayormente buena para la regresión. También puedes hacer pruebas funcionales con automatización, pero, ya sabes, muchas empresas se han quedado entrando en la automatización. Quiero decir, si quiero decir, requiere mucho scripting, como si no fuera tan complejo como los desarrolladores, pero también es como escribir códigos, ¿verdad No va a ser como escribir códigos duros. Entonces es algo así como secuencias de comandos como um Alguna descripción puede involucrar como C sharp, Java, scripts java, y otras cosas Entonces si te sientes cómodo en esos, ya sabes, creo que si crees que puedes prestar Java y C sharp y cosas así, quiero decir, ir a por ello porque eso va a aumentar el dólar, eso te hará, ya sabes, hacerte más tipo de más demanda, ya sabes, conseguir trabajo más rápido, sabes, porque muchas empresas requieren o no requieren la X para los probadores de automatización Pero el hombre siempre va a estar ahí siempre vas a ver probadores de mano, como si pudieras tener un portador Si quieres tener un portador de seis figo, siendo un probador manual, también puedes Pero la automatización es que esos van rápido, como los más altos, son más buscados, ya sabes, porque son más pasados porque el probador de automatización también puede hacer manual y también puede hacer automatización. Pero un probador manual puede hacer automatización solo puede hacer manual. Entonces es por eso que las personas las empresas prefieren las pruebas de automatización. 22. Pruebas de rendimiento: El tipo final de prueba que voy a estar explicando son las pruebas de rendimiento o las pruebas bajas. Las pruebas de rendimiento o pruebas bajas tienen que hacerse con automatización. Entonces cuando me refiero a la automatización. Prueba de automatización, hacen pruebas funcionales, regresión, pero pruebas de carga o pruebas de rendimiento. Tiene que hacerse con la automatización usando herramientas de automatización porque cómo se carga o pruebas de rendimiento tiene que ver con el uso de una herramienta de automatización y eso es mayormente quiero decir, el QA lo hace, pero no va a ser tu responsabilidad, ¿verdad? Porque una vez que entras, en su mayoría estás haciendo responsable de como la manera de probar. Quiero decir, pruebas funcionales, bus negro, regresión, ya sabes, apoyando el negocio con UAT ad hoc Pero tienen personas específicas que contratan para realizar pruebas de carga. Entonces ves gente puedes ver persona de trabajo que diga, quiero hacer pruebas de desempeño. Ya sabes, son personas que contratan específicamente para realizar pruebas de desempeño. Entonces no es algo que sea una responsabilidad salarial Q realizar eso. Pero al mismo tiempo, cuando dicen, quiero un probador de rendimiento, quiero un probador de rendimiento, esos siguen siendo ingenieros de aseguramiento de la calidad, o analistas de aseguramiento de la calidad o probadores también Ya sabes, siguen siendo nosotros probadores, como, ya sabes, todo son pruebas, pero ese rol, pruebas de rendimiento están diseñadas específicamente para un tipo específico de propósito y hay personas que están especializadas en ese tipo específico de campo Entonces, ¿qué son las pruebas de rendimiento o las pruebas de carga? Por lo tanto, las pruebas de rendimiento o las pruebas de carga son probar el nivel de estrés de una aplicación. Entonces lo que quiero decir stress tp es, como, por ejemplo, volveré a usar el sitio Walmart. Cuando vas a walmart.com, ¿verdad? Ya sabes cuántas personas usan Walmart en un momento determinado. Entonces digamos por tal vez cierta hora. Puedes tener más de 5,000 personas usando Walmart. Y esos 5 mil usuarios están haciendo cosas diferentes. Algunos están ingresando, algunos están agregando cosas a su ct. Algunos están echando un check out. Entonces todos estos escenarios. Entonces esa es responsabilidad de un probador de rendimiento. Él va a ser o la persona va a ser responsable de probar todos estos escenarios para ver si 5 mil personas pueden venir a la aplicación a la vez. Cuatro personas, tal vez mil están en la página de inicio de sesión. 2000 es agregar cosas a la tarjeta de ida y vuelta, eliminar dejar de agregar, eliminar dejar de agregar. 2000 es check out, ingresando los datos de su tarjeta, checando, 1,000 está revisando sus correos electrónicos para confirmación de correo electrónico. Le va a gustar hay un dos a automatización porque no se pueden conseguir mil personas, 1,000 probadores menores agregando inicio de sesión o, ya sabes, aquí donde entra la automatización, la herramienta Entonces van a crear usuarios virtuales. Lo que llaman usuarios virtuales es usuarios falsos, es una forma esta es una startup cómo hacerlo , crear usuarios virtuales, tal vez 5,000 usuarios virtuales golpeando esa aplicación al mismo tiempo para ver si se va a romper porque si se rompe, eso significa que si la aplicación entra en producción, si hasta 5 mil personas están accediendo a la aplicación al mismo tiempo, la aplicación va a estar abajo. Y estoy seguro que probablemente escuchaste cuando dices a veces cuando mucha gente los usuarios están usando la aplicación, la aplicación es lenta o podría fallar. Entonces esto es lo que hacen pruebas de carga o pruebas de rendimiento para evitar algo como esto. De esa manera, cuando hay mucha gente usando la aplicación, la aplicación no se rompe, ya sabes, o no se ralentiza. Entonces esto es lo que hacen pruebas de rendimiento o pruebas de automatización o pruebas de carga para evitar que cosas como sucedan en producción porque una vez que se toman en producción, quiero decir, Walmart ya tiene una idea de cuántos usuarios usan la aplicación. Tienen el rango, ¿verdad? Entonces van al carga o el probador de ejecutantes va a imitar ese escenario Va a poner la misma cantidad no la misma cantidad, sino por encima del mismo rango de personas en la aplicación para ver si la aplicación se va a romper o cómo va a funcionar la aplicación. Entonces en base a eso, entonces determinarás si la aplicación es buena o no. Así que recuerda, has hecho tus pruebas funcionales, ya sabes, caja negra, pruebas de regresión de usuario, en testing. Todo este tipo de pruebas ocurren pruebas funcionales, ¿verdad? Lo que está haciendo se llama pruebas no funcionales. Recuerda cuando siempre usas el tallo. Pruebas no funcionales y funcionales. Entonces las pruebas funcionales son las que mencioné, aunque aún así, quiero decir, hablé de prueba habitual, prueba sal spance, pruebas de regresión , todas esas cosas Aunque para probar, aunque si veo funcional es diferente, pero siguen viendo clasificados en ese funcional porque las cosas que puedes ingresar en nosotros pasan así para probar, seguimos ingresando contraseña de userm, pero estás pasando por diferentes fases, ¿verdad Entonces Diferente estás golpeando diferentes escenarios. Es setance testing, pruebas de regresión, todo es todo funcional hasta cierto punto, correcto Porque estás probando funciones No funcional no es cuando es una no función, eso es lo que queremos decir performance porque no eres solo no es una función, ¿verdad? No es como una prueba de usuario de motor en contraseña. función es la no funcional, no puedo probar el rendimiento Entonces, si X cantidad de personas lo están usando en un determinado período de tiempo, ¿cómo funcionaría el sistema? Así es como lo calificas? Por eso lo llamas no funcional porque estás probando el nivel de estrés. Están probando un montón de cosas como, ya sabes, ya sabes, cuántas personas puedes usar, ya sabes, en la página de inicio de sesión, cuál es la capacidad para eso y cosas así. Entonces otros css lo que llaman no funcionales y las herramientas que utilizan para realizar las vacaciones. Entonces al final del curso, te voy a mostrar todas las herramientas son como hay para Q formas, ya sabes, tanto probando pruebas funcionales, en hacer una prueba funcional y pruebas no funcionales. Cuáles son las herramientas, incluso la automatización, si también te interesa la automatización, qué tipo de herramientas puedes usar, ya sabes, para realizar la automatización. 23. Tipos de artefactos: Entonces en este video, vamos a hablar de artefactos o documentos de pruebas. Cuando un QA U una realización de pruebas. Existen diferentes documentos basados en las etapas de prueba de las que serás responsable, ¿ verdad? Entonces documentos. Entonces, cuando realmente antes de comenzar a probar, hay algunos documentos que debe tener, pruebas de cable, hay algunos documentos se requieren para producir. Después de haber hecho las pruebas, hay algunos documentos que debe producir y cada documento tiene su propuesta o lo que servimos en ese proceso. Entonces voy a explicarte todos los diferentes tipos de documentos. Ahora, típico en el escenario realize, no hay que hacer todos esos documentos. Pero quiero prepararte de una manera que a veces entreviste preguntas podrías hacerte algunas de preguntas como esa. Y además, como cuando te metes cuando estás trabajando, ya sabes, quieres saber todo esto, ¿verdad? Entonces de esa manera, si se pueden mencionar dos de los documentos restantes, ya lo sabes. Entonces podría ser cualquier cosa, ¿verdad? Porque una vez que me realices una vez que haces una Q en la empresa, tienes que seguir los estándares de la compañía como este la forma en que hacen las cosas en el QA, ya sabes, algunos podrían requerir esto, podrían requerir eso. Entonces quiero equiparte mejor. Entonces, de cualquier manera por venir, podrás responder. Ya sabes, estarás bien informado en ese campo para poder agregar valor Entonces en el siguiente video, te voy a explicar los tipos de documentos para QA deben tener un QA produce y en qué etapa o en qué etapa se producen los productos antes 24. Documento del plan de prueba: Un QA produce es un documento de plan de prueba. Entonces, ¿cuál es el documento del plan de pruebas? Entonces esto no es muy común. QAs no necesariamente producen documentos de planes de prueba todo el tiempo Es decir, puedo contar el número de veces que produzco documentos de un plan de pruebas. Y la mayor parte del tiempo es en su mayoría es principalmente el líder de QA. Entonces cuando digo QA, un paso por encima de los ingenieros de QA. Entonces, el líder de QA es alguien que administra múltiples probadores de QA. Entonces las Q terminadas muchas veces son las que produjeron este documento. Pero solo lo estoy compartiendo para que también estés al tanto de lo que es un documento de plan de pruebas. Entonces a veces podría recaer en ti crear un documento de plan de prueba , ya sabes, y qué vas a hacer en ese escenario. Entonces, si ocurre este escenario, ya sabes, voy a adjuntar todos los artefactos en este video que puedas ver todos los tipos de documentos de los que el QA se encarga. Pero cómo es el documento del plan de pruebas habla la estrategia que vas a utilizar en las pruebas, ¿verdad? Entonces para recordar cuando dije como el análisis de negocios Bs o el PO escribe los requisitos, se lo da al desarrollador, correcto, ya sabes, para desarrollar la aplicación, por qué la aplicación por qué el desarrollador está desarrollando la aplicación. Se le está ocurriendo un documento de plan de pruebas. Y ten en cuenta, un documento de plan de prueba es mayormente popular en una metodología de cascada. Entonces en Agile, no necesariamente usamos documentos de plan de pruebas porque la mayoría de las veces todo se rompe en fases y las cosas cambian, ¿verdad? Entonces creas un documento de plan de prueba y de repente en la fase dos, no quieren esto. ¿Qué vas a hacer? Hay que volver al plan de pruebas para actualizarlo. Pero en una cascada, que era el viejo enfoque, tu plan de pruebas era muy común porque todo se desarrolló de cero a fin. Así que en realidad tenías una estrategia para cubrir toda la prueba porque todo se había pensado en términos de desarrollar la aplicación de cero a fin, como ya los desarrolladores ya desarrollaron toda la aplicación y todo Entonces todo fue como, ya sabes, no hubo mucho cambio. Entonces, en tu plan de pruebas, como que cubres todas las escenas. Lo que hace un documento de plan de pruebas es la estrategia de cómo vas a ejecutar tus pruebas. Y te voy a mostrar cómo ejecutar pruebas. Pero el documento del plan de pruebas es como un plan de cómo pretendes probar la aplicación. Entonces, ¿en qué consiste el plan de pruebas, primero habla del propósito, verdad? ¿Cuál es el propósito del documento? Bueno, el propósito del documento, cuando es el ejemplo de Walmart es probar la funcionalidad o el sitio web de Walmart. Entonces ese es el propósito. Quieres probar. Y a continuación, se habla del alcance, ¿no? Lo que está en su alcance. Entonces, lo que está en su alcance es un recuerdo cuando hablar sobre la página de registro, desea probar la página de registro. Quieres probar, puedes agregar esto a tu carrito. Quieres probar, puedes checar. Quieres probar, puedes recibir correos a tu correo electrónico puedes correo electrónico de confirmación a tu casilla de correo electrónico. Quieres probar todo eso. Entonces así es lo que llama en alcance. ¿Qué está fuera de alcance podría ser? Ya sabes, las pruebas de carga, ¿verdad? Pruebas de rendimiento, O como si no fueran tan relevantes para ti. Esas cosas podrían estar fuera de alcance, dependiendo de lo que sepa, qué dirección obtenga de su prueba de QA Living o lo que esté fuera de alcance. Entonces, el alcance automático podría ser algo que no pertenezca a las pruebas de control de calidad, lo que todos ustedes son responsables Entonces, lo que está en alcance es lo que eres responsable de probar. Como mencioné, vas a probar la página de inicio de sesión, vas a probar, puedes atten a tu carrito, vas a probar, ya sabes, puedes salir de tu carrito, vas a probar, puedes enviar por correo electrónico la confirmación, todos esos, es lo que está en alcance, ¿verdad También sección en plan de pruebas es la estrategia, ¿verdad? Déjame estrategias como ¿cómo vas a probar todas estas características? La página de registro, cosas tu auto, checkout, correo electrónico, confirmación. ¿Cómo vas a probar esto? Entonces la página de registro, quiero decir, la estrategia podría ser, ¿qué tipo de pruebas vas a emplear? ¿Qué tipo de pruebas vas a desarrollar? Entonces vas a hacer pruebas funcionales, pruebas de regresión, pruebas de usuario, pruebas de bus negro, y todo ese tipo de cosas y quién lo va a hacer. Entonces a veces como mencioné, la UAT la realiza principalmente el negocio. Entonces podría ser el negocio el que va a hacer UAT. Entonces lo mencionaste, ya sabes, en la estrategia. Podría ser prueba funcional la vas a hacer tú o donde esté la prueba de QA que esté. lo mencionaste. Ya sabes, las pruebas de regresión van a ser hechas por ti o los QAs o ¿cuántos QAs? Mencionaste que, ya sabes, todas esas cosas son tipo de cosas como vas a mencionar los tipos de pruebas. También en el apartado va a haber criterios de entrada y salida. Entonces carteras de entrada y salida cuando el desarrollador te lo envía a prueba, ¿verdad? Lo que tiene que estar listo o cuáles son las casillas de verificación que hay que hacer para que lo recojas del desarrollador dice que el bono están probando Entonces algunas de las ideas podrían ser que haya hecho sus pruebas unitarias, bien. Recuerda, hablo de pruebas unitarias. También una de las características que desea verificar que tiene pruebas unitarias se han realizado. También el medio ambiente, ¿verdad? ¿Tenemos un ambiente estable? Rmember, cuando decir a veces lo que el entorno que pruebas o la aplicación se desarrolla es diferente de la aplicación y producción Entonces quieres asegurarte de tener un ambiente estable. A veces los sordos y el QA comparten el mismo ambiente. A veces los sordos pueden tener su propio entorno, la Q puede tener su propio entorno. Entonces todos estos criterios de entrada van a ser antes de que empiece a probar, el ambiente tiene que estar listo, pruebas unitarias tienen que estar listas Y también me perdí otro tipo de pruebas y lo que llamamos pruebas de humo. La prueba de humo es Muchas veces, es muy popular en las preguntas de la entrevista, la palabra como prueba de humo. prueba de humo es ante el desarrollador cuando el desarrollador te la envía y tú la recoges para comenzar a probar. Lo que es la prueba de humo es lo mismo que al azar como ad hoc, pero no lo llamó ad hoc. La prueba de humo es que solo busca y llena la solicitud antes de comenzar a probar. Entonces quieres verificar, bien, si dice que tiene una página de inicio de sesión. ¿Veo la página de registro? Si dice que tiene un agregar cosas al cheque verifíquelo agregue suf al ct. ¿Puedo ver eso? Si dice que va a tener checkout. ¿Puedo verlo confirmación de correo electrónico me fumo prueba es como, visibilidad como, todavía se pueden ejecutar algunas funciones, pero esto es lo que es de muy alto nivel. No es detalle, no estás corriendo positivo ni negativo, no es complejo. Está bien, lo que el sordo dijo que iba a desarrollar, lo desarrolló. Entonces solo lo miras solo corriendo por las cosas, entonces sabes que eso es prueba de humo. Estos son como criterios de entrada para el humo como criterios de entrada. Estas son cosas que debes tener en su lugar antes de poder comenzar a hacer las pruebas. Todo esto va a ser empujado, va a ser beld en los documentos del plan de pruebas Otra cosa son los criterios de salida, son los criterios. Antes de dar el pulgar hacia arriba, ¿cuáles son las cosas que hay que hacer Obviamente, debes haber realizado toda la prueba. Obviamente, los defectos que encontré deberían haber sido corregidos, ¿verdad? Entonces los criterios podrían estar bien, sin problemas, bien. Recuerda cuando hablamos de no temas. Entonces tengo tal vez tres temas que son de baja prioridad. Recuerda que te dije que una aplicación nunca puede estar libre de defectos, nunca puede estar libre de errores. Pero el negocio y el propietario del producto o los analistas de negocios necesitan estar al tanto de estos problemas conocidos. Muchas veces, los criterios de salida podrían estar bien, hubo cuatro problemas conocidos y son de baja prioridad. Recuerda, no puedes renunciar a términos cuando hay un defecto que es un defecto de alta prioridad o un error de alta prioridad. Es imposible. No se puede decir que lo ha hecho todo. Has probado todo cuando ven defectos de alta prioridad. Entonces Salir anterior es principalmente cuando alta prioridad, prioridad media de arreglo, y tal vez ahora prioridad es lo que queda debido a que todavía no se puede gastar X cantidad de dinero contratando gente, solo para arreglar problemas bajos, porque tienen otras cosas en las que trabajar. No van a pasar tanto de su tiempo arreglando problemas bajos o trabajando en temas bajos. Alta prioridad, prioridad media, sí, tiene que ser encontrada, fija, cercana. Pero prioridades bajas, esos no son temas. Los criterios de salida pueden estar bien, la aplicación debidamente probada, corrección de defectos, las prioridades bajas son lo que queda, los defectos de baja prioridad son lo que queda. Eso es un criterio X. Y también hitos. Otra sección en el plan de pruebas son los hitos. Los hitos van a ser, ok, pretendo probar esta aplicación en X cantidad de tiempo porque como dije, tiempo es dinero, si lo vendes a tu página, no voy a pasar 88 meses probando esa aplicación Si el negocio probablemente se pronostican justo cuando estaban haciendo todo el proyecto y y desarrollando toda la aplicación y, ya sabes, no desarrollando sino mirando la planeación para desarrollar la aplicación. Ellos rojos diciendo que el gerente de proyecto ya tiene como determinado cuánto tiempo va a tomar para los desarrolladores desarrollen la prueba de la aplicación. Entonces los hitos van a ser, bien, va a tomar esto va a tomar cuatro meses para que una aplicación vaya a ser probada En el primer mes, ¿qué haces? ¿Cuál es el hito? ¿Estás creando un artefacto ¿Estás creando un documento? ¿Estás creando un plan de pruebas? Segundo al tercer mes? ¿Estás sertin arriba ¿Te estás asegurando de que, ya sabes, yo creo qué estás haciendo? Entonces estos son los hitos. Entonces, desde el primer mes hasta el cuarto mes, lo que está pasando, Cuando estás probando cuando pruebas el número de aplicación, pruebas también pueden requerir múltiples ciclos. Para que pudieras festejar podrías hacer el primer ciclo de pruebas, encontrar defectos, arreglarlo. Haces otro ciclo de pruebas, otro ciclo de pruebas antes de entrar en regresión. La regresión es probar, recuerda dije X Y y Z. pruebas todo, sistema heredado todo antes de dar tus toneladas Por lo que todos estos tienen se desarrollarán como contabilizados por ese hito. Entonces, en el primero de los cuatro meses, ¿qué vas a hacer cuál es el plan, verdad? Entonces esto no va a caer sólo sobre ti. A la tapa de QA también se le dará la dirección en términos de bien, esto es lo que es el plan. Entonces no quiero asustarte nada como no es nada desafiante, como una vez que estés en el proceso, ya sabes, verás como cosas, es mucha comunicación, como nada no todo está cayendo de nada no todo está tu mano en tus manos, ya sabes, como para que vayas a averiguar por tu cuenta, no, tu tapa de Qa, gerente de QA test QA, ya sabes, el trabajo contigo en este proceso, ya sabes, quiero decir si crearas un documento de plan de pruebas, ya sabes, entonces a veces no creas un documento de plan de pruebas, pero eso es como, ya sabes, alto nivel de lo que implica o lo que consiste en un documento de plan de pruebas. Y también adjunté artefactos. También adjunté un documento, una muestra de plan de pruebas de cómo suele verse un plan de pruebas. Ya sabes, a veces podría ser más complejo, a veces podría ser menos complejo, pero adjunté, ya sabes, te di una muestra en el video de cómo debería ser un plan de pruebas. A continuación, vamos a hablar de documentos de casos de prueba. 25. Documento de casos de prueba: El siguiente tipo de documento es lo que ellos llaman un documento de caso de prueba. Este es en realidad el documento más importante para un Qa. Como siempre hay que crear un documento de caso de prueba. No hay Qa no hay pruebas que se hagan sin un documento de prueba s. Ahora bien, ¿cómo se crea un documento de caso de prueba depende? Hay herramientas que puedes usar para crear documentos de un caso de prueba o podrías crear una hoja de Excel. Se adjunta una hoja Excel de cómo se crea un documento de caso de prueba. Ahora bien, si realmente te pasa a tener una herramienta que crea donde puedes ingresar tus casos de prueba, bien, todavía vas a seguir el mismo formato de lo que adjunté en la hoja de Excel, ¿verdad? Esto es en la creación de un documento de caso de prueba, hay una especie de patrón o un método. Entonces, en realidad, voy a descomponerlo. Entonces cuando digo documento de caso de prueba, ¿verdad? Un documento de caso de prueba se compone de muchos casos de prueba. Entonces, ¿qué es un caso de prueba? Un caso de prueba es una situación que muestra cómo vas a probar un escenario en particular o un requisito particular o una historia de usuario en particular. Recuerda cuando dije, una historia de usuario puede decir un requisito de historia de usuario desde el BO P puede decir verificar que el usuario un usuario debe tener una página de inicio de sesión, tienes un ID de usuario. Una página de inicio de sesión, tienes una contraseña. Una página de inicio de sesión debe tener un botón de enviar, debe poder ingresar el nombre de usuario contraseña y enviar para ir a la página siguiente. Entonces estos son todos los requisitos. Ahora bien, cuál es el caso de prueba es cómo satisfaces o cómo pruebas o cubres ese caso de prueba o ese almacenamiento de usuario. Entonces digamos una funcionalidad de inicio de sesión, ¿verdad? Ingresas un nombre de usuario contraseña click, así que voy a la página siguiente. Eso es lo que requieres. Tu caso de prueba dices, cómo vas a verificar que ingresas el nombre de usuario, contraseña, envíes, y vas a la página siguiente. Entonces eso es lo que el caso de prueba es un caso de prueba que está satisfaciendo una historia de usuario o un requisito. Entonces los requisitos, como dije, están escritos por el BAS, el desarrollador lo está desarrollando. Ahora tu caso de prueba, estás probando, no estás probando, no estás escribiendo, no estás probando en base a la aplicación. Estás escribiendo tu caso de prueba contra la historia del usuario. Entonces ni siquiera te importa lo que esté haciendo el desarrollador. Si el QA, si el desarrollo, si el BA o el PO te da diez requisitos, diez historias de usuarios. Recuerda, hablamos de historias de usuarios, diez escenarios. El caso de prueba debe tener diez o más casos de prueba. Usted documento de caso de prueba debe tener diez o más casos de prueba. Porque recuerden, un escenario puede tener una parte positiva y una parte negativa. Entonces, por ejemplo, el registro prueba una funcionalidad de registro, sing password. La contraseña puede ser positiva positiva de ocho a diez caracteres. También puede ser de 11 a 12 caracteres. También puede ser de siete a ocho así que cuando dice la contraseña en el requisito dice que la contraseña tiene ser de ocho a diez caracteres, se sensible. Tu parte positiva es, la va a probar ocho a diez caracteres se sensibles. Ahora tu parte negativa puede ser, van a probar de 11 a 12 caracteres sensibles a mayúsculas y minúsculas para ver si te das un error. Porque recuerda cuando pruebes el requisito, dice ocho a diez positivos y sensibles a mayúsculas y minúsculas. Entonces cuando escribes cuando pruebes en aplicación con la contraseña entro en ocho a diez caracteres sensibles a mayúsculas y minúsculas. Estás haciendo una prueba positiva. Miembros la Q dije, hay que romper la aplicación, hay que encontrar defectos. No se puede encontrar ningún defecto. Es una bandera roja. Entonces vas a probar diez a 12 para ver qué va a pasar. Recuerda, el criterio es de ocho a diez, ¿verdad? Vas a probar diez a 12 para ver si se va a romper darte un mensaje de error. Van a probar siete a ocho para ver si él también te va a dar un mensaje de error. También vas a probar si distingue entre mayúsculas y minúsculas, van a usar minúsculas, mayúsculas para ver si te va a dar un error. Si te da un error, voy a verificar que error es coincidente con lo se supone que hay en el requisito. Entonces, cuando escribes tu caso de prueba es, correcto, tienes que tener en cuenta cada escenario en la historia de usuario. Entonces eso es lo que es un caso de prueba. Un caso de prueba es, cómo se cubren todos los requisitos. Si un requisito que digo es que tengas un usuario y el requisito te va a decir qué tipo de nombre de visa, podría tomar cualquier nombre de visa, ¿verdad? Entonces tu caso de prueba va a ser cuando inicie sesión en la aplicación, vaya a la página de inicio de sesión, ingrese este nombre de usuario. Ese es el caso de prueba. Y comentas puedes decir que así tienes una contraseña. Como mencioné, el requisito va a decirte qué tipo de contraseña, ocho a diez caracteres. Entonces tu en tu testc dices, Cuando me conecto a esta aplicación, ingresando nombre de usuario, ingresé esta contraseña, ocho a diez caracteres Yo también otra prueba se puede ver, también ingresé diez a 11, diez a 12 caracteres. Otro caso de prueba puede ver entro de siete a ocho caracteres. Entonces así es como es eso lo que es un caso de prueba. Un caso de prueba está satisfaciendo los requisitos. Estás probando contra el requisito. Por lo que cada requisito debe tener un caso de prueba para cubrir ese requisito. Otro requisito puede decir ingresar el nombre de usuario contraseña, él envía, llevarlo a la página de inicio de sesión. Tu testc puede estar bien, ingresa nombre de usuario contraseña, él envía Cuando voy a la página de registro, ¿qué veo? Ya sabes, ci a la página de registro. Y tsk esa es una parte positiva. Puedes escribir una parte negativa e ingresar el nombre de usuario perdido, ingresar contraseña, enviar calor y deberías recibir un mensaje de error. Ingrese el nombre de usuario, pierda la contraseña, ingrese enviar, debería recibir un mensaje de error. Y el requisito te va a decir si recibes un mensaje de error, digamos por ejemplo, ingresas no ingresas en el nombre de usuario, ingresas en la contraseña, el heat submit. El mensaje de error debe decir nombre de usuario, falta el ID de usuario. Ese es un mensaje de error. Ese va a ser el requisito de que requisitos sea ese detallado. Va a no hay nada como averiguar nada, como que el desarrollador no está averiguando Todo lo que ha sido previsto había sido documentado por el analista de negocios o el PO Cuando dices si no ingresas y nombre de usuario ingresa contraseña que heat summit, deberías darle este mensaje de error eso es lo que van a ver los requisitos En tu caso de prueba, sho deberías escribir el caso de prueba que diga, Bien, voy a dejar el nombre de usuario en blanco, ingresa contraseña, heat summit, debería recibir un mensaje de error ¿El mensaje de error coincide con lo que dicen los requisitos o la historia de usuario? Entonces, si la historia de usuario dice, ID de usuario está en blanco, por favor ingrese el ID de usuario. Cuando haces ese escenario, cuando ejecutas ese escenario, cuando estás escribiendo el caso de prueba, debes anotar la prueba. Eso es lo que se supone que debes ver. Se supone que debes ver este error mache que dice que el ID de usuario está en blanco, por favor ingresa el ID de usuario Recuerda, cuando escribes cuando estás haciendo caso de prueba, cuando estás escribiendo caso de prueba, en realidad no estás probando la aplicación. No. Se está preparando para probar la aplicación. Entonces estás escribiendo todos estos escenarios abajo para cubrir. Recuerda, no tienes la aplicación. No se ha desarrollado la aplicación, ¿verdad? Entonces estás viendo el requisito solamente. Entonces, sea cual sea lo que diga el requisito, estamos escribiendo casos de prueba y va a ser difícil porque a veces algunas empresas ahora tienen st viniendo con ellas llaman mako Entonces Mockups es como Por ejemplo, la página de inicio de sesión, cómo se supone que debe verse la página de registro se supone que debe verse la página No es como la aplicación en sí, no. Un MCO puede ser como un PDF, como un documento PDF que te muestre una imagen de lo que usas en pars Puedes usar eso para escribir un caso de prueba. Ya sabes cómo va a quedar la aplicación. Recuerda, no estás probando, así que no lo estás haciendo porque no tiene sentido que salga la aplicación. Yo estás escribiendo tu caso de prueba contra la aplicación. Nunca atraparás ningún defecto ni ningún error. Entonces estás escribiendo tu caso de prueba no basado en la aplicación. Lo estás escribiendo en base a los requisitos. R. Entonces, sean cuales sean los requisitos que se indiquen, usted escribe su documento de caso de prueba. Con la ayuda de un marcado a veces, la empresa te da marcador como un PDF Miras las fotos, ya sabes, y podrás escribir más para ayudarte a escribir tus casos de prueba. Entonces, cuando la aplicación haya sido empujada a su a sus cesionarios Recuerda cuando hayas hecho tus pruebas de humo, acabas de hacer el aspecto y la sensación, ya que el medio ambiente está listo. Ya sabes, el desarrollador ha hecho las pruebas unitarias, te lo manda abajo. Entonces ya puedes usar esos casos de prueba. Para probar la aplicación. Recuerda que cuando estés leyendo, estás listo para volver a escribir casos de prueba como deberías tener un ID de usuario Vas en la aplicación, ingresando ID de usuario, sí. Deberías tener una contraseña. Vas a la aplicación, ingresa contraseña. Los requisitos, recuerda tus casos de prueba, debes tener de ocho a diez caracteres sensibles a mayúsculas y minúsculas. Vas en la aplicación ingresa ocho a diez caracteres sensibles a mayúsculas y minúsculas, o si también puedes probar casos de prueba negativos, ¿verdad? Por lo que se puede ingresar siete a ocho. Puedes ingresar diez a 12, ya sabes, para ver si te va a dar un error. Si da un error, son esos errores coincidentes, lo que hay en tu documento de caso de prueba, en tu documento de caso de prueba, has escrito eso bien, nombre de usuario contraseña enviar. Yo no ingreso el nombre de usuario. Ingreso la contraseña que me envíe. Me da nombre de usuario no es válido. Ingresa el ID de usuario. El ID de usuario no es válido, ingrese el ID de usuario. Lo has escrito en tu documento de caso de prueba. Ahora, cuando estás probando la aplicación, lo que deberías comparar es lo que hay en tu caso de prueba versus lo que estás viendo en la aplicación. Entonces, sea lo que sea que esté viendo en la aplicación, lo está comparando con los documentos de su caso de prueba. Recuerda, obtuviste tu caso de prueba de los requisitos. Pero cuando estás probando la aplicación, no estás comparando con el requisito, estás comparando cuál es lo que bajas, el documento de caso de prueba. Por lo que cualquier aplicación prueba cualquier escenario que se ejecute en la aplicación es la guía usa su caso de prueba para guiarlo. Y el caso de prueba puede ser complejo puedes ser mucho dependiendo de qué tipo de prueba. Recuerden, digo pruebas funcionales. Pruebas de caja negra. Eso es todo el nombre de usuario contraseña que envía. N a n pruebas a. Ese también es otro proceso como este pero sigue siendo el mismo derecho de captura estás escribiendo un documento de caso de prueba. Un documento de caso de prueba puede comprender un funcional, regresión, aceptación del usuario, extremo a extremo, add ho Addo realmente no usa documentos de casos de prueba Él es solo al azar, pero funcional, caja negra, regresión, pruebas de aceptación del usuario, ya sabes, todo esto requiere para ser un caso de prueba un caso de prueba casos de prueba. Entonces simplemente no empiezas a ir a la aplicación y a probar las cosas bien? No. Vas a escribir el documento de caso de prueba casos de prueba. Una vez que escribas los casos de prueba, con la ayuda de los casos de prueba, ahora vas a usar eso para probar la aplicación. Y podrá adjuntar su caso de prueba que comprende tanto de escenario positivo como negativo. Entonces no sólo lo positivo, sino positivo y negativo. Y también adjunto una pantalla un documento y adjunto a este video de cómo suele ser un caso de prueba. ¿Correcto? Entonces el caso de prueba surge en Entonces de lo que comprende es el ID de prueba, que es muy único. Ya sabes, entonces podría ser 001 o 002. Entonces, cada caso de prueba debe tener una identificación de prueba, que es única. Debería tener el nombre de un caso de prueba. Por lo que el nombre del caso de prueba podría ser verificar el inicio de sesión una vez que ingresas la contraseña de usam, él envía vas a la página de inicio de sesión Así que la funcionalidad de inicio de sesión. También deberías tener pasos, ¿verdad? Entonces cuando voy a worm.com, voy a la página de inicio de sesión, entro a usa ingresando contraseña, haga clic en enviar . Deberías llevarlo al siguiente. Esta es una prueba positiva. También debes tener resultado real e inesperado. Entonces, ¿qué es realmente lo que estás viendo? Similar como un reporte diferente a, ¿qué estás viendo? Cuál es la expectativa los resultados reales es lo que estás viendo Los resultados esperados es lo que deberían ser los resultados esperados. Mm recuerda, cuando estés creando el documento de caso de prueba, aún no hemos usado la aplicación. Por lo que aún no tiene un resultado esperado. Una vez que ahora lo pruebes en la aplicación, entonces ingresas en el resultado esperado y solo ves si un pase o falla. Pero cuando estás creando el documento de caso de prueba antes de usarlo antes de que la aplicación llegue a ti cuando solo estás usando el simulacro de requisito. Podrías dejar en blanco el resultado esperado. Podrías dejar pase o fallar, no necesitas poner pase o llenar, sino el resultado real, ya sabes cuál es el resultado real porque no dejas en blanco el resultado real, pero dejas el esperado llenas el resultado esperado porque sabes lo que esperas, ¿verdad? Cuando ingrese usando pars submit, debe llevarlo a la página de inicio de sesión Entonces ese es el resultado esperado. Aún no tienes el resultado real porque no has ejecutado la aplicación en vivo. Quiero decir que aún no has corrido la aplicación. Para que puedas dejar en blanco el resultado real. Puedes dejar el campo passel en blanco, ya sabes, pero de lo que debes comprender es el ID de defecto Quiero decir, la identificación del caso de prueba, descripción de la prueba, los pasos reales, los resultados reales. Espera lo siento, resultado esperado. Los resultados reales deben estar en blanco. El campo Parsle debe estar en blanco. Y actúo también adjunto como un documento Excel de cómo debería ser el documento del caso de prueba. Ahora hay herramientas. Muchos adjuntan, van a tener estar escribiendo caso de prueba desde Excel. Al igual que hay herramientas que te permiten gustar ya es como el ID del caso de prueba, que ya se genera por sí solo para ti. Solo lo que no necesitas hacer es ingresar el nombre del caso de prueba, descripción, los resultados reales y cosas así. Otras cosas ya ahí. Pero muchas a veces como ya tienen herramientas, hay herramientas que están ahí afuera que permiten ingresar casos de prueba. Pero quiero decir, también están los escenarios donde no se tienen esas herramientas. En realidad hay que rastrearlo en Excel. Entonces lo que me centavos Excel, lo que se adjuntan en los videos Excel. Pero puedes la misma lógica. Una vez que sepas cómo escribir esos casos de prueba en Excel, aunque tengan una herramienta, puedes hacer lo mismo. Se puede reproducir todo es lo mismo. Entonces se trata de escribir casos de prueba de casos de prueba documental. 26. Datos de prueba: El siguiente artefacto del que vamos a estar hablando son los datos de prueba. ¿Qué son los datos de prueba? Los datos de prueba son datos o información que utiliza para respaldar su caso de prueba. Un ejemplo típico, como mencioné con los casos de prueba es enter in username, password, head Submit button. Los datos de prueba significan ¿qué información está ingresando para respaldar su caso de prueba? Qué ID, qué datos estás usando para respaldar tu caso de prueba. Por ejemplo, un caso de prueba típico podría ser ingresar en nombre de usuario, contraseña cabeza el botón Enviar. Ahora, los datos de prueba son ¿qué nombre de usuario estás ingresando? Qué contraseña estás ingresando. Vamos a volver al ejemplo, otra vez, el ejemplo de Walmart donde la contraseña podría ser de ocho a diez caracteres, y cuando realmente pruebes el camino positivo, vas a crear un dato de prueba para el parsle donde va a tener ocho a diez caracteres Ese es un camino positivo. También vas a crear un dato, que va a tener siete a ocho o seis a siete caracteres de largo para ver si va a fallar. También vas a crear un dato que va a tener 11 a 12 caracteres de largo para ver si va a fallar. Con base en cuáles son los criterios para la contraseña, podrías crear datos de prueba. No es nada complejo, podría ser cualquier cosa genérica, podría ser cualquier cosa que te venga a la mente o en base a lo que el requisito esté indicando. No tiene que ser un tipo de dato loco ni nada. Es sólo algo aleatorio. La mayoría de estos datos son datos falsos o ficticios. Tantas veces los desarrolladores te apoyan con estos datos, y si no te apoyan, tienes que crear tus propios datos. Ahora no hay repositorio ni ninguna herramienta que puedas usar para almacenar datos. Muchas veces, almacenas estos datos en hojas de Excel, así tienes tu propia hoja de Excel, creas donde todos tus casos de prueba, donde todos tus escenarios, esto está en la herramienta o Excel o cualquier aplicación instala tus casos de prueba. De hecho, podría completar su caso de prueba, sus datos de prueba en el caso de prueba. Entonces, por ejemplo, cuando estás escribiendo tu caso de prueba, podrías cc el requisito podría ser verificado, puedes iniciar sesión. Cuando escribes tu caso de prueba, podrías ingresar el nombre de usuario contraseña que envía Sus datos de prueba pueden ser llenados en el caso de prueba. Entonces podrías decir ingresar nombre de usuario, cualquiera que sea el nombre , John Smith, ingresa contraseña, sea cual sea la contraseña , presiona el botón de cumbre. Esa es en realidad otra forma en la que podrías crear tu caso de prueba. Entonces podrías crear un caso de prueba con datos de prueba en él. A veces podría ser genérico donde es solo ingresar nombre de usuario ter contraseña it summit. Ese es un típico caso de prueba estándar. Pero también puedes ingresar los datos junto con el caso de prueba. Entonces se podría decir ingresar nombre de usuario, Charlie, ingresar contraseña, la información, presionar el botón de cumbre. Así que podrías llenar tus datos de prueba en tu caso de prueba, ya sabes, y también herramientas, como mencioné, donde realmente puedes almacenar tu caso de prueba. Entonces voy a explicar qué tipo de herramientas podrías usar para crear un caso de prueba para crear un caso prueba aparte de los documentos Excel Excel. Entonces esas herramientas, en realidad puedes ingresar tu caso de prueba e ingresar tus datos de prueba junto con tu caso de prueba, que con tus casos de prueba. Por lo que los datos de prueba son muy obligatorios, ya sabes. Cuando realmente golpeas probar el sistema, probar la aplicación, requiere usar datos. ¿Cómo vas a consultar la base de datos? ¿Cómo vas a consultar la aplicación? Entonces, cuando realmente estás iniciando sesión en un sistema, cuando inicias sesión en una aplicación, ¿qué nombre de usuario y contraseña estás ingresando? Tienes que entrar en algo, ¿verdad? Entonces definitivamente, entonces necesitas datos de prueba para apoyar tu caso de prueba. Los datos de prueba son muy importantes ahora. No tienes que crearlo todo el tiempo. El biólogo y para los datos que te estarán dando para pruebas en función del tipo de prueba que estés realizando En realidad hay diferentes tipos de Tal vez algunas pruebas puedan requerir tal vez este privilegio. A lo mejor este usuario tiene acceso a esto. Este otro usuario tiene acceso a esta funcionalidad. Quiero decir, ese tipo de pruebas también surgen. Ese tipo de pruebas requerirán qué tipo de datos también vas a obtener soporte del desarrollador en términos de crear estos datos de prueba. A veces si es complejo, si es un dato que requiere un tipo específico de creación o lo que tal vez necesites para crear un tipo específico de datos. Siempre se cuenta con el apoyo de los desarrolladores en la creación de estos datos. A veces no tienes que hacerlo por tu cuenta. Pero si es algo así como, muy simple en cuanto al solo crear un nombre de usuario y contraseña estándar y eso quiero decir, eso es algo que puedes simplemente crear aleatoriamente lo que quieras. Entonces, lo que estoy explicando esto es que los datos de prueba son muy cruciales para apoyar tu caso de prueba, y los datos de prueba también pueden determinar En términos de crear datos de prueba, eso puede determinar qué tipo de funcionalidad o qué tipo de aplicación estás probando. Así que puede haber algún tipo sensible de aplicaciones o cosas que tengas que crear un tipo específico de datos de prueba. Entonces no puedes simplemente crear una theta de prueba aleatoria. Tiene que ser un dato de prueba que pueda ajustarse al propósito, y todo esto va a venir de los requisitos. Va a provenir de las historias de usuario. Todas estas instrucciones van a venir dependiendo de cómo se quiera crear prueba el aa. 27. Informe de defectos: Y el artefacto o documento final es un reporte de defectos. Ya sabes, has mencionado sobre defectos y, ya sabes, qué es un defecto. Ya sabes, solo reiterar un defecto es un error, un error, ya sabes, un bicho. Entonces así es lo que llamamos defecto. ¿Qué es un reporte de defectos, verdad? Por lo que un reporte de defectos es un documento que muestra el estado o las situaciones actuales de tu defecto o tus errores o tus errores. Recuerda cuando te dije que cuando el desarrollador prueba la aplicación, quiero decir, desarrolla la aplicación y la envía a tu plato para que comiences a probar. Te vas a encontrar con múltiples defectos. Vas a estar encontrándote con múltiples errores. Vas a estar encontrando problemas con la aplicación. Es natural. Recuerda que te dije que si no encuentras problemas o defectos, no estás haciendo tu trabajo. Entonces tu trabajo es en realidad encontrar defectos y romper la aplicación. Así que vamos a encontrarnos con múltiples errores, bugs, ya sabes, problemas que no coinciden con los requisitos y no coinciden con la historia del usuario. Cuando te encuentras con este tema, ¿qué haces? Eso es lo que llamamos una defecciada. En realidad hay un proceso que expliqué anteriormente en términos de cómo abordas los problemas, errores o errores con los que te encuentras. Ejemplo tan típico, encuentras un error en la página de inicio de sesión, presionas el botón enviar, no va, nada está funcionando. Eso es un bicho. Qué tipo de error es como alta prioridad porque los clientes no podrán iniciar sesión en la aplicación para que actualicen su tarjeta y verifiquen cosas así. Esa es una prioridad alta. Entonces también puedo explicar cómo es un defecto un defecto general como en qué consiste, ¿verdad? Entonces el ID de defecto, la descripción, pasos para reproducir, pasos reales, resultados esperados. Entonces todo esto, bien. Entonces un reporte de defectos. Muchas veces, podrías usar Excel, pero a mí realmente no me gusta Excel porque este es un reporte de defectos tiene que ser un documento en vivo porque se actualiza constantemente constantemente yendo y viniendo. Pero solo por el bien de la simplicidad, sí adjunté un informe de defectos Excel para que ustedes los echen un vistazo. Pero en realidad las herramientas que utilizas en la gestión de defectos. Muchas herramientas que usas ingresando casos de prueba, administrando tu documento de caso de prueba y cosas así. También tienen un lugar donde realmente se puede ingresar defecto y manejar defecto. Voy a explicar de nuevo, el defecto o el ciclo de vida del defecto. Cuando se encuentra un error o cuando se encuentra un defecto, ¿verdad? Lo ingresas, el ID de defecto, los pasos de descripción a reproducir, resultado esperado, resultados reales. Capturación de pantalla. Capturas de pantalla también es muy importante. Capturas de pantalla es lo que estás viendo. De esa manera, cuando se lo envías al desarrollador porque el desarrollador está muy ocupado quiere ver tus cosas y poder señalar donde las cosas reales están fallando. No quieres empezar a torcerte la cabeza. Una vez que lo envías al desarrollador, el estado es nuevo. El desarrollador lo escoge, cambia el estado abierto, trabaja en ello. Te lo devuelve tan fijo como estrellas como fijas. Una vez que lo recoges, lo vuelves a probar. Recuerda que dije cuando estabas probando un defecto, también pruebas en otras áreas. Simplemente no pruebas ese tema. Se prueban múltiples cosas. Por ejemplo, si esto dice que el botón de cumbre está arreglado, también pruebas qué pasa si falta el ID de usuario, la contraseña está ahí y escuchas la cumbre. Prueba otras partes a través de eso. No solo pruebas solo el botón de cumbre. Una vez que haces la prueba o se arregla, cambias las estancias del defecto para cerrar y ya está hecho. Si aún tienes un problema, lo vuelves a abrir y enviar de vuelta al desarrollador. Muchas veces defectos para tener comentarios. Si en realidad estás usando una herramienta, que te voy a explicar los tipos de herramienta. Si en realidad estás usando una herramienta, ¿verdad? Hay quiz donde puedes tener entrar en comentarios. Y así tú y el desarrollador y también el BA o el PO pueden estar intercambiando comunicación. Por ejemplo, si tienes algún problema, tal vez lo registras, registras el defecto en el lo asignas al desarrollador y quieres hacer un comentario sobre el defecto. Se podría decir, podría comunicarse con la def si quiere decir algo Necesariamente, en realidad hay un formato de defecto, y hay una herramienta que usas en la entrada de defectos. La misma herramienta es la misma herramienta que usas para ingresar tu caso de prueba tus casos de prueba. Entonces es todo 12. Pero en la sección de defectos, se crea un reporte. En realidad hay una plantilla donde haces clic en defecto. Yo todo va a poblar y solo necesitas ingresar en el defecto ya se genera auto generado Simplemente ingresa en la def el nombre, la descripción, los pasos para reproducir las artes Todo es todo lo que la plantilla está lista para ti. Entonces solo necesitas ingresar la información, adjuntar tu captura de pantalla y eso es todo. En esa captura de pantalla esa plantilla, cuando la envías al desarrollador como nueva También hay donde puedes ingresar en los comentarios. Digo que es porque esa es una forma de comunicarse con el desarrollador. A veces desarrollador puede decir, Oh, no soy capaz de ver cuál es el error, cosas así. Esa es la forma en que puedes ser el desarrollador y también el BA también y PO también pueden intercambiar comunicación por trazabilidad para ver qué está pasando Una vez que lo ingresas, así es como sigues yendo y viniendo. Las estrellas siguen cambiando. Entonces, por qué adjunté un documento en Excel, es solo para que veas cómo es un reporte de defectos. Muchas veces, muy pocos casos en los que se utiliza una hoja de Excel, donde administrar. Pero en caso de que no tengan una herramienta, adjunté una hoja de Excel para que veas como suele ser un reporte de defectos en Excel. Pero generalmente, hay herramientas donde la misma herramienta que usa la creación de un caso de prueba también es la misma herramienta usando una entrada o defecto. El defecto también es muy clave en términos del ciclo de vida del defecto. Te vas a preguntar. Entonces esa es una entrevista cuestionar la acción. Explícame un defecto del ciclo de vida. Un ciclo de vida de defecto es básicamente cuando pruebas una aplicación, encuentras un error, encuentras un error o un defecto, y cómo trabajas en el error para asegurarte de que desde cuando abres un defecto hasta cuando el desarrollador lo elige te lo envíes de vuelta, vuelves a probar, cierras, ese es un ciclo de vida diferente F el ciclo de vida significa desde que se encuentra el defecto hasta cuando el defecto está cerrado, lo que sucede en eso. Va de membrana y el que el interger era uno aquí el staus, Sus es muy clave El de aquí cuando abro el defecto, ya sabes, pongo el starus como nuevo Se lo asignó al desarrollador. abrió, la puso como abierta, trabajó y me la devolvió como staus fijos Lo volví a probar una vez que todo estaba hecho, lo cerré. Entonces el de aquí los staus. Un ciclo de vida diferente, enfatiza en las estrellas. Entonces, cómo se mueve de ti al desarrollador de ida y vuelta, ya sabes, de ida y vuelta hasta que se cierre el defecto. Cuando se cierra un defecto, ese es el final de ese ciclo de vida, eso ha sido atendido. Muchos cajeros automáticos como mencioné, a veces podrías enviártelo de vuelta , ves que tiene problemas, reabres, se lo mandas de vuelta a él, así sigues yendo y viniendo y los staus siguen cambiando El estado es muy importante y lo asignamos a Porque cuando el desarrollador está trabajando en ello en una aplicación en defecto, Lo único que está mirando es el staus Es esto nuevo, entonces va a trabajar en ello. Si está cerca, no le importa porque eso terminó. Sus es muy clave. Cuando estás explicando a tus entrevistadores, Sus en cuanto a defectos, quieren escuchar el staus, ¿cómo se movía? ¿Cuál era el esterus Cuando la abriste, encuentras un bicho, ¿qué esterus es? Nuevo. Cuando se lo envías a ellos está abierto, el desarrollador lo abre, te lo devuelven como fijo, luego trabajas en él, lo cierras. Eso es lo que ellos llaman un ciclo de vida de defectos. Eso también es muy clave. Eso es muy clave en su papel como ingeniero de aseguramiento de la calidad, cómo maneja los defectos. También con las prioridades como cada defecto, tienes una prioridad, Alta media baja. Mencioné que hay que fijar prioridad alta, media prioridad. Se les tiene que trabajar. Recuerda, también vas a explicar a tus criterios de salida en el plan de pruebas donde no puedes tener defectos medios o altos, y das los términos de que has hecho tu trabajo. No. Cada defecto alto y medio tiene que ser cerrado. Prioridades bajas está bien, pero son temas conocidos. Recuerden, hablé de temas conocidos. Podrías resaltarlo a tu pista Q way o al BA o al PO, que estos son los temas conocidos. Por el bien del tiempo, tal vez no tengan que arreglar todos los defectos, porque el tiempo es dinero. Pero la prioridad media de alta prioridad tiene que ser fija y tiene que ser cerrada. La prioridad baja está bien, podrías mantener que podrías dejar que eso sea porque no afecta al cliente de hacer lo que hace. Alta prioridad media alta y media son tapones show. Te son bloqueadores. Esas son cosas que afectarán al cliente de hacer lo que quiere hacer. Sí, así que en general, ya sabes, los reportes de defectos son muy cruciales en tu día a día de trabajo. Ya sabes, es muy importante en cuanto a cómo trabajas como asegurador de calidad, cómo manejas tus defectos, ya sabes, asegurándote de que antes dar el pulgar hacia arriba, ya sabes, quieres asegurarte de que todos son realmente atender la prioridad media superior y también a la prioridad media superior y quién le asignas tus defectos Entonces cada defecto, recuerda cuando dije cuando creas, encuentras el error o encuentras un error, y vas a los dos y en realidad es una sección donde dices que haces clic en defectos, la plantilla o información de la edad mayor generada automáticamente. A quien le asignes también es muy importante. Porque porque cada vez que le asignes ese defecto a eso determinará quién va a trabajar en él. Si lo asignas al desarrollador, a veces puede haber un tipo específico de desarrollador que va a trabajar en ese defecto. Cuando lo asignas, simplemente no lo asignas a nadie o no lo asignas en absoluto. Hay personas particulares con las que estamos trabajando a las que necesitas asignarle ese defecto. Todos esos es algo así como lo que conforma y en realidad tienen una captura de pantalla, quiero decir , tengo un reporte, un reporte de defectos que puedes mirar para ver cuál es el estándar en cuanto a crear un defecto. Toda esta información allí se va a rellenar automáticamente para que puedas ingresar tu información y registrar el defecto. 28. Introducción a las herramientas: Ahora hemos concluido nuestra sección en Q. Así que he hablado de, ya sabes, SDLC, el proceso de ciclo de vida de desarrollo de software , las metodologías, Ágil, cascada, ¿qué hace el aseguramiento de la calidad qué tipos de pruebas realizan ? Ya sabes, ¿cuáles son los artefactos? ¿O cuáles son los documentos? Ya sabes, aseguramiento de calidad que se supone que debes tener o hacer y ¿qué proceso hacen todo esto? Y también, ya sabes, qué tipos de pruebas de nuevo, así como dar una elaboración en cuanto lo que hace la manera Q y dónde encaja la manera Q en el SDLC, dónde encajamos en las fases, tanto en Ágil como en Waterfall Entonces Siguiente video, voy a estar hablando de las herramientas, ya sabes, qué herramientas hacen el aseguramiento de la calidad para hacer sus actividades diarias del día a día, y también para qué sirven las herramientas, ya sabes, y también cómo puedes ponerte al día a la velocidad, aprendiendo esas herramientas. No es nada complejo, muy fácil de navegar. También voy a estar hablando varios tipos de herramientas, solo solo para manual, pero también manual y automatización también. Entonces voy a estar discutiendo todo eso en el siguiente video. 29. Tipos de herramientas: Para herramientas, para pruebas manuales, hay una herramienta muy popular. Y cuando empecé mi carrera, solía usar mucho la herramienta. Se llamaba Centro de Calidad ALM. Entonces no soy capaz de mostrarte la herramienta, pero puedes encontrar que podrías encontrar Google Quality Center AM. Va a ser que verás el PDF dentro de donde realmente puedes encontrar un Google que peaje. Entonces la herramienta es en realidad específicamente para el aseguramiento de la calidad. Ya sabes, esta herramienta está diseñada únicamente para pruebas de aseguramiento de calidad. Entonces, ya sabes, habla de cómo ingresar en tus casos de prueba. Entonces en Quality Center ALM, en realidad puedes entrar y crear un caso de prueba, crear un caso de prueba ¿está ahí Se podrían introducir errores de defectos. Puede utilizar la herramienta para administrar el proceso de ciclo de vida de defectos. Podrías ingresar defectos y asignarlo al desarrollador. El desarrollador también tiene acceso al centro de calidad ALM, donde realmente pueden trabajar en esos defectos y enviarlo de vuelta para enviar la memoria sobre el proceso del ciclo de vida del defecto centro de calidad ALM es bueno para manejar defectos, ya sabes, y también ingresar casos de prueba, casos prueba manual de entrada Por lo que el centro de calidad ALM es para pruebas manuales. Ya sabes, en realidad estoy agregando características donde también podrías hacer algo de automatización, pero se basa únicamente en pruebas manuales. Otra herramienta es Jira. Entonces Jira es algo así como lo nuevo. Así que eso es como la nueva aplicación o la nueva herramienta para un montón de cosas. Jira se usa principalmente para Agile donde el PO, los maestros scrum y los desarrolladores de luces, ya sabes, es una herramienta muy robusta Pero el centro de calidad y los probadores también pueden usar Jira también, pero para que realmente accedan a ira teined para obtener un agregado llamado rayos X. Rayos X es una característica que agrega a Jira que le permite escribir casos de prueba e ingresar defecto Creo que esa es en realidad la nueva herramienta que hay. El centro de calidad ha sido B, quiero decir, lleva años ahí. Cuando empecé mi carrera, eso es todo lo que estamos usando. Pero ahora Jira es como hacerse cargo como por lo ágil, Jira es muy popular y Entonces creo que muchas empresas están navegando hacia Jira Ya sabes, y para que puedas acceder a Jira, necesitas un plugin llamado X ray Y quiero decir en cuanto a ingresar casos de prueba, manejar defectos, el proceso es todo igual. El centro de calidad, Jira, es lo mismo. Cada caso de prueba, tienes ya sabes, identificación de prueba, descripción, nombre de prueba, resultados reales esperados, lo mismo con Polity Center AM y gia Entonces el documento que adjunto te mostrará cómo Como se supone que se debe ingresar el caso, cómo se supone que se debe ingresar un defecto. Entonces, incluso si estás usando algún centro de calidad de herramientas ALM o Jira, solo necesitas enchufar esa Entonces es muy autoexplicativo cuando accedes a la herramienta, verás toda la información para que acabes de comerte. Entonces solo necesitas saber lo que eres rey, lo que eres rey. Así que asigne, prioridad, ya sabes, alta pérdida media, todas esas cosas. Así que es más o menos estándar en todos los ámbitos. Ahora para las pruebas de automatización, bien, recuerda cuando hablé de eso, eso es algo nuevo. Ahí es hacia donde están navegando muchas empresas, hacia dónde va la industria cada industria va a la automatización porque hasta el punto es automatización porque hasta el punto más barato para ellas, ¿verdad? Entonces un rol o una tarea que harán diez probadores de Q. Solo dos o uno de los comprobadores de automatización podían hacer todo. Entonces a pesar de que las pruebas manuales nunca desaparecerán. Así que no tengas miedo como las pruebas manuales nunca irán lo cual siempre va a estar ahí, ya sabes, Pero la automatización es algo así como si quieres más dinero, si quieres avanzar tu actual, si eres bueno con la codificación porque la automatización es una especie de scripting, hay diferentes lenguajes para que puedas escribir en Java, C sharp, y todas esas cosas Entonces, si quieres avanzar tu carrera y conseguir un trabajo más rápido, obtener más dinero, la automatización es algo así como el futuro. Pero lo que debería hoy era manual, siempre habrá un manual ahí. En realidad hay empresas que siempre tienen probadores manuales, y en realidad podrías tener un sustento siendo un probador manual No tengas miedo, manual, sé que estoy sin negocio o me quedo sin trabajo. No, siempre consigues un trabajo y un buen trabajo. Para la automatización, los dos muy populares al selenio. El selenio es un IDE que permite crear scripts. El selenio interactúa con la aplicación con el front-end Por ejemplo, como el típico ejemplo worm.com. Escribes tus guiones sobre selenio y vinculas selenio al sitio web de Walmart Cualquier código que estés escribiendo, estás escribiendo tu código sobre selenio Estás escribiendo tus guiones sobre selenio. Un Selenio está interactuando con la página de Walmart para hacer lo que quieras hacer Por ejemplo, ejemplo típico, solo quiero probar la funcionalidad de registro, el nombre de usuario, contraseña, botón de enviar. Escribiré programaré esto en selenio. Selenium hablará con Walmart y dirá: Bien, Walmart, vaya a la página de inicio de sesión, ingrese el nombre de usuario, ingrese esta contraseña, ingrese el botón enviar ¿Qué ves? Entonces, pase lo que pase cuando se haga clic en la contraseña del nombre de usuario y enviar en el Walmart, Selenium leerá esa información y la mostrará y se la enviará de vuelta Entonces vas a Seleu y ya ves, este pase. Me llevaste al cuello al al sesión informarme me llevé más allá del acceso a la información de inicio de sesión, tengo acceso a la cuenta del cliente ahora, o podrías decir que falló. La contraseña no era válida. Ya verás. Entonces es una herramienta muy genial, ya sabes, y la automatización es interesante, en realidad, es bastante interesante, ya sabes, así que es muy divertida. Sabes, creo que Mana también es muy interactiva, muy analítica. Ya sabes, siempre hay que estar pensando fuera de la caja y pensando en formas. Pero la automatización también es un futuro muy genial para aprender. Ya sabes de esa manera, nunca buscarás trabajo porque en términos de SDLC, en términos de TI, en términos de proceso de ciclo de vida de desarrollo de software, y construcción de una aplicación de cero a fin. El centro de calidad es tan importante y relevante como los desarrolladores porque tenemos que probar. Ya sabes, todo lo prueban todo. Entonces no solo se están probando los derechos de aplicación, incluso hardwares, ya sabes , aviones, autos Entonces cuando desarrollamos lo probado. Pero lo que hoy estoy enseñando es en software, aplicaciones, herramientas blandas. Entonces esas son las cosas de las que me gusta hablar, así que eso son pruebas de aseguramiento de calidad. Pero en general, todo tiene que ser probado. Todo lo que pongas ahí afuera tiene que ser probado porque si no lo pruebas y hay un problema, ellos regresan y te demandan por mucho dinero y daños y, ya sabes, alto riesgo en tus vidas. Así que las pruebas de co son muy importantes en la vida. Lo que en realidad estoy enseñando ahora son las aplicaciones de software, y cada aplicación tiene que ser probada. Imagine cada garantía de calidad, en realidad hay una posición o una regla para los ingenieros de aseguramiento de la calidad porque la aplicación necesita ser probada. Los desarrolladores no pueden probar su trabajo. En realidad, en realidad es decir que no es apropiado en el mundo de las TI que los desarrolladores prueben su trabajo. Sé imagina cuando escribes tu código y lo pruebes , claro, vas a estar sesgado. Entonces es por eso que siempre tienen un pueblo independiente. Siempre tienen personas de aseguramiento de la calidad para poner a prueba realmente su trabajo. Entonces QA es muy importante. QA es muy relevante. Siempre van a necesitar Q formas. Yo barco manual, automatización automatización mejor porque una automatización puede hacer manual también. Pero Manual también es muy relevante para, no desaparecen. Piénsalo como esta es una buena carrera para hacer realmente porque no es algo que sientas que tal vez en los próximos diez años o 15 años va a desaparecer. No. Q siempre estará en demanda. Siempre ha estado en demanda de. Desde cuando inicié mi carrera hace más de diez, 15 años, Q sigue en alta demanda y estar siempre en alta demanda. 30. Hacia dónde se dirige la industria: Entonces en cuanto a hacia dónde se dirige la industria, sé que hablé de SDLC y de todas las fases de requerimientos, desarrollo, pruebas, despliegue, mantenimiento Entonces así es como el estándar, y cómo se movió de cascada y se fue a Agile. Ahora muchas empresas van a la Nube, y mucha ingeniería devo DevoX y canalizaciones CICD y cómo los datos se almacenan realmente en la nube y cómo las personas o la aplicación interactúan con los datos En cuanto a aseguramiento de la calidad, cierto, siento que siempre debes adoptar esta mentalidad de aprendizaje continuo Así que simplemente no redis curso y consigue un trabajo y se como, ya terminé, quiero decir, ingeniero Q de calidad No. No termina ahí. Siempre hay que seguir aprendiendo. Las industrias mantienen la industria siempre está cambiando. Siguen surgiéndose cosas nuevas. Tienes que seguir avanzando, aprendiendo cosas o menos vas a estar desactualizado. Es como cuando en realidad intentas avanzar, si no estás aprendiendo cosas, te van a parar en un hoyo. Y estoy seguro que probablemente te vas a aburrir de la cabeza. Siempre sigue aprendiendo. Siempre sigue aprendiendo, siempre sigue avanzando. Sabes, creo que aunque todavía quieres permanecer en digamos que podrías tener una iglesia, quieres permanecer en las pruebas manuales, no quieres entrar en la automatización, pero aún puedes avanzar en las pruebas manuales, y el camino. Por ejemplo, expliqué sobre, ya sabes, probar el sitio web de Walmart, esa podría ser una página web estándar. Ahora en TI, hay diferentes tipos de cosas que vas a estar probando. No solo vas a estar probando sitios web. Tienen CRM, ya sabes, tienen CMS, sistema de gestión de contenidos, ya sabes, gerentes de relaciones con clientes Diferentes formas de lo que podrías probar. Ya sabes, podrías probar MLS, ya sabes, los diferentes no solo páginas web Entonces en la pregunta de la entrevista, puedes venir de como, qué probaste. Es la una página web, yo hardware, ya sabes, ese es el tipo de cosas que entrevista a mi real, como en cuanto a qué tipo de aplicaciones pruebas. Somos diferentes tipos de aplicaciones. Ya sabes, son, ya sabes, estándar típico como sitios web. Ya sabes, eso suele ser walmart.com, ya sabes, prueba la portada, ya sabes, la página de inicio de sesión Puedes cambiar puedes agregar cosas a tu tarjeta, puedes checar eso es típico, ya sabes, una página web. Pero en realidad son diferentes tipos de aplicaciones y cosas que Q formas hacen probar. Así que no pienses que ya sabes, solo vas a estar probando solo un sitio web. No. Ya sabes, tienen MLS, tienen UI de jabón. Ya sabes, tienen tantas cosas que quieren que pruebes. Y no estoy diciendo esto para abrumarte, sino solo para prepararte QA es dinámico, ¿verdad Es una posición dinámica donde no tienes que aprender todo, ¿verdad? Podrías simplemente concentrarte en lo que te sientes cómodo y en lo que puedes desafiarte a ti mismo a hacer. Sabes, creo que también una cosa es también respaldar la base de datos. Yo hablé de datos, pero muchos datos almacenados en el back-end, y hay herramientas que usas almacenando esos datos, así que podría ser Oracle SQL y cosas así. Ahora la mayoría de esos datos en realidad se están moviendo a la nube. A veces te podrían decir que hagas pruebas de backend. Ben testing es en realidad cuando está aquí pruebas de backend, Ben testing es probar la base Recuerda cuando digo Walmart, walmart.com, página de inicio de sesión y todas esas cosas, eso es lo que llaman front end Front end es lo que puedes ver, como lo que verá el cliente. B end es lo que está sucediendo en la parte posterior de la aplicación. Los datos que se están moviendo. Al ingresar en el nombre de usuario, ingrese en el pase llegará a la cima. Esa es la parte delantera. Lo que pasa en el back-end es que ese nombre de usuario, donde ingresas los datos, ingresas en la pestaña de nombre de usuario, va a golpear el back-end, donde realmente se almacenan los datos, y va a verificar, ¿existe este nombre de usuario? Si ingresas a Charlie como ID de usuario, va a ingresar la contraseña. Digamos que ingresas la información de la contraseña y presionas el botón de cumbre. Lo que sucede en el front-end es que ingreses el nombre de usuario C char contraseña información, es el botón de enviar. Ahora en el back-end, esa cumbre de contraseñas de información de Charlie va a activar el back-end y verificar. ¿Hay algún Charlie, y si hay un char, cuál es la contraseña? Es la información de la contraseña, y si la contraseña esta información, otorgar acceso. ¿Verdad? Entonces ese es el back-end. Ahora los clientes van a ver eso en el back-end, que todo el nombre de usuario contraseña y todas esas cosas. O sea, en el respaldo estaba pasando en el backend. Entonces eso lo que llaman las pruebas de back-end. Y eso es muy crucial porque muchos entrevistadores que preguntaron, ya sabes, buscan backend tester Entonces, el probador de backend es adecuado para que pruebes realmente el back-end, ¿verdad No solo escribes consultas SQL. Consultas SQL como consulta la base de datos a. Ese es otro tipo de prueba también. B end también es muy importante porque eso también es a veces como Q, te pueden contratar para hacer front end y back end. Cuando escuchas el front-end, el front-end solo está probando la parte frontal de la aplicación. Así que usa en contraseña, envía, ve a la tarjeta, agrega tarjeta, quita tarjeta, echa un vistazo a ese front end. back-end ahora está cortejando la base de datos, por lo que puede haber tantos problemas en el back-end Entonces ya sabes, y para que consultes el back-end, necesitas poder estar cómodo escribiendo consultas SQL. La consulta SQL también es muy importante como rol o como habilidad para el ingeniero de aseguramiento de la calidad, pudiendo consultar la base de datos. Para que consultes la base de datos, tienes que escribir s, lenguaje de consulta estructural. Es que no es tan complejo, pero es una forma de cómo interactúas con la base de datos porque la base de datos no sabe qué es, cómo verifico el nombre de usuario. Ese no es un lenguaje que la base de datos va a entender. Entonces tienes que poder interactuar con los datos en el back-end, tienes que poder escribir el lenguaje que entenderán los datos en la parte posterior. Si estás intentando verificar qué hay en si Charlie existe, o quieres verificar cuántos ID de usuario hay en quizás Nueva Orleans en Walmart. Por ejemplo ahora. Quieres verificar cuántos usuarios usan la aplicación Walmart en Nueva Orleans. Vas al back-end y escribes una consulta. No vas a ingresar cuántos nombres de usuario o ID de usuario usan walmart.com La base de datos no va a entender eso. Hay una manera de interactuar con la base de datos o hay una forma de lenguaje que ingrese para que los datos en el backend puedan entender lo que está diciendo y producir cuántos ID de usuario hay en Nueva Orleans que están usando walmart.com diciendo y producir cuántos ID de usuario hay en Nueva Orleans que están usando walmart.com Entonces Data, lo que estoy mencionando esto es que pruebas de back-end de datos también son muy clave en su papel como ingeniero de aseguramiento de la calidad. Entonces lo que expliqué hasta ahora fueron tipos de pruebas, pruebas funcionales y esos gustos. Pero las pruebas de back-end también son muy cruciales. Realmente no toqué, no expliqué mucho sobre las pruebas de back-end porque ese también es otro tema por su cuenta. Eso también porque para que puedas realizar pruebas de back-end, necesitas saber cómo escribir consultas. Necesitas poder ser bueno en S QR. Si quieres aprender más sobre las pruebas back-end, te sugiero que podrías buscar cursos que hablen sobre cómo escribir consultas, cómo consultar la base de datos y cosas así. Una vez que lo prestas y sabes fronting, front-end suele ser como solo pruebas señorosas como toda la funcionalidad, todas esas cosas Cuando conoces fronting y backend, estarás mejor equipado para ser un probador Q ten Qa de ronda completa Entonces creo que el back-end también es muy importante. 31. Cómo hacer un currículum de control de calidad: Entonces, ¿cómo se hace un currículum Qa, verdad? Por lo que también adjunté un currículum típico Qa estándar. Entonces eso es como un currículum de QA estándar. Quiero decir, claro, currículums es todo diferente, pero para que hagas un currículum destacado Y te lo puedo decir porque tengo una buena cantidad de experiencia haciendo currículums, ¿verdad Una cosa que siempre quieres destacar es que siempre quieres mirar la descripción del trabajo, ¿verdad? Entonces cada descripción de trabajo es diferente. A pesar de que voy a ser específico con QA, los fundamentos que os han explicado o tocado chicos son similares en todos los ámbitos 80% de los roles y responsabilidad requieren de todo lo que expliqué. Pero ahora algunas posiciones podrían diferir en función del rol. Por lo que la descripción del trabajo puede requerir cierto tipo de acero. Digamos que podría ser, solo quiero un probador de back end, como lo que pensé de probar, la base de datos. Otra posición puede decir, quiero un front-end o quiero automatización. Sabes, quiero manual, ya sabes, basado en si dicen que quieren probar, quieren automatización y estás hablando de habilidades manuales. Existe una alta probabilidad de que no te seleccionen para una entrevista. Entonces quieres mirar la descripción del trabajo para ver qué están buscando realmente. Una vez que miras la descripción del trabajo, ve lo que realmente estás buscando, realidad no tienes que hacer cada currículum para cada descripción de trabajo. Eso es demasiado. Quieres incluir en tu currículum muchas cosas que cubran mucho. Para empezar, no quieres hablar de crear un currículum para automatización, donde no seas un probador de automatización o donde no tengas idea de que no quieres hacer automatización, eso es derrotar el propósito Cualquier cosa que estés creando en un currículum es algo que puedas justificar y algo que puedas ser capaz de defender y querer hacer. Simplemente no pones automatización en tu currículum y no quieres hacer automatización. Cualquier cosa en tu currículum es algo que puedes definir y quieres hacer. Ahora, ¿cómo haces ese currículum? Miras la descripción del trabajo. Siempre tienes un currículum estándar que cubre mucho. Pero ahora cada puesto quieras aplicar o cualquier persona que te interese mucho, podrías agregar algunas características en tu currículum que muestren lo que busca la responsabilidad laboral. Cualquier viñeta en tu currículum que cubra la responsabilidad laboral que estás buscando, la descripción del trabajo que estás buscando. En tu currículum, ahora no tienes que decir, en términos de crear ese currículum, cuáles son las cosas que has hecho en el pasado que pueden traducirse en ese rol. Entonces ya sabes, en términos de, ya sabes, hacer ese currículum, podrías hablar de, por ejemplo, voy a dar un ejemplo como creo que mencioné sobre help desk, y si estás tratando de hacer la transición a la manera Q. Como mesa de ayuda, eres muy analítico, justo porque estás resolviendo problemas. Tienes un boleto, ya sabes, un problema. Ya sabes, ¿cómo arreglas ese problema? ¿Cómo se llega a una resolución? Estamos siendo ingeniosos, estamos resolviendo problemas. Eso puede hacer la transición a QA donde se consulta el sistema o la aplicación para encontrar defectos. Estás pensando en hacer preguntas a la aplicación o al sistema. ¿Y si hago esto? ¿Y si hago esto? ¿Y si hago esto? Porque cuando obtienes una ayuda, cuando obtienes un boleto, automáticamente, no sabes cómo resolverla. Intentas esto, intentas esto, intentas esto, intentas esto hasta que arregles hasta que arregles el boleto. Eso es lo mismo con QA. De manera Q, no miras una aplicación y aquí es donde está el error, no. No lo sabes, tienes que intentar y probar y probar. Momento en el que sigues intentando, sigue tratando de encontrar el bicho. Eso es ayuda esto te mantienes sabes tratando de arreglar cosas, ¿y si hago esto? ¿Y si lo hago? Así es como solucionas problemas, eres ingenioso Entonces ahora cuando cierras el boleto, sabes que lo has resuelto. En Q, también resuelves defectos. Una vez que pasas por todo el ciclo de vida del defecto. Recuerda que hablo de las estrellas, y tú abres y todas las estadísticas con el equipo de la muerte. Y lo cierras, resuelves ese defecto. Por lo que también resuelves problemas también. Eres bueno resolviendo problemas. Este es el tipo de cosas que puedes poner en tu currículum porque no quieres poner que tienes 20 años de experiencia en QA porque cuando te hagan esas preguntas, no vas a poder defenderte. Entonces quieres jugar seguro mientras que como pones todas esas habilidades, en tu currículum que pueden mostrar las habilidades de un ingeniero de QA para ese puesto o simplemente en general. Entonces quieres hablar de destacar, pensar en cosas de tu pasado. ¿Piensa en cosas de tu pasado que son buenas en la comunicación? Eres analista de comunicación porque Q way requiere comunicarse con el dev, ¿ saber gestionar la relación? Porque muchas veces el problema típico podría ser, me parece un defecto un enviarlo al dev. El def dice que este no es un tema que no esté rompiendo en mi sistema No veo el tema. Vas de un lado a otro. ¿Pierdes la calma? ¿Cómo manejas tu relación con el desarrollador? ¿Cómo manejas tu relación con el analista de negocios? Cómo manejas tu relación con otros miembros de QA, tus habilidades de comunicación, tu problema tus habilidades de resolución de conflictos. Cuando surge un conflicto entre tú y el desarrollador, ¿cómo lo arreglas? Entonces eso es en el pasado para que también puedas dibujar ejemplos de cómo manejas los conflictos o cómo manejas problemas con tus compañeros de trabajo o lo que sea, y puedes adaptarlo a la responsabilidad de un ingeniero de control de calidad. Sólo hay que sacar cosas del pasado. No quieres poner cosas irrelevantes en tu currículum que no te ahorren ninguna necesidad. Por favor, sácalo. Cualquier cosa que estés poniendo en tu currículum, no tienes que hacerlo no tienes que hacerlo solo porque quieres ecliminar, poner cosas irrelevantes No te van a elegir para una entrevista. Quieres poner cosas que sean significativas para esa descripción del trabajo. Cualquier cosa que diga, aunque tuvieras un premio, hacer algo que incluso un premio es genial, pero si tienes algo que sientes que no es relevante para esa propuesta para la descripción del puesto Q, no necesita estar ahí. Todo lo que hay que poner cuando están mirando tu currículum, hay tantos currículums. Estás viendo a alguien que pueda ser capaz que tenga esa habilidad para hacer este puesto de trabajo. Cuando ven cosas que destacas que coincidan con la habilidad para resolver la necesidad que buscan en la descripción del trabajo, entonces tienes una alta probabilidad. Hay que ser estratégico. Tienes que ser muy estratégico en cuanto a lo que pones en tu currículum. Siento que muchas habilidades son muy transferibles. Muchas habilidades que vemos tenemos en nuestro día a día, incluso nuestras vidas personales son muy transferibles. Porque el trabajo de Q IT requiere mucha interacción. Requiere mucha comunicación. Podría ser estresante. Voy a ser honesto contigo. Podrías ser muy estresante porque estás trabajando en los plazos, cómo puedes poner en tu currículum. ¿Cómo puedes resolver o arreglar x y z en un marco de tiempo muy específico? Ya sabes, ¿cómo eres capaz de realizar múltiples tareas? Porque a veces podrías estar trabajando en múltiples aplicaciones, ya sabes, ¿tienes habilidades multitarea y todas esas cosas ¿Estás orientado al tiempo de resolución de tiempo?, cuando te dan algo, lo haces rápidamente. Todas las cosas son buenas habilidades. Ya sabes, puedes destacar en tu currículum. En el siguiente video, te voy a mostrar cómo responder a las preguntas de la entrevista. ¿Qué tipo de preguntas se les ocurren? Ahora es el siguiente paso es conseguir una vez que entres por la puerta. Una vez que consigas esa entrevista, ¿ qué haces con ella? Hablamos de tu currículum, haciendo ese buen currículum increíble. Ahora de lo que vamos a hablar es cuando recibas esa entrevista, ¿cómo haces esa entrevista? 32. Introducción a cómo conseguir un trabajo: Ahora, en el siguiente video, voy a estar explicando, ya sabes cómo conseguir un trabajo, cómo aprender ese trabajo soñado, ¿verdad? Entonces no se trata sólo de que te conozco viendo este curso. No solo está bien, leí toda esta información, ¿qué voy a hacer con ella, verdad? ¿Bien? Tengo una idea de Q. Ya sabes, ahora estoy muy familiarizado con el QA. ¿Qué hago? Sé que todos los que están viendo este curso quieren aprender ese trabajo soñado. Quiero tener una carrera en ingeniero de aseguramiento de la calidad. Entonces en el siguiente video, voy a estar mostrándote cómo sabes, hacer un currículum y también cómo responder preguntas de entrevista. 33. Cómo pasar por alto una entrevista: Bienvenido al video de cómo pasas una entrevista. Supongo que ahora te han seleccionado para una entrevista y ahora va a la pregunta, ahora estás sentado con el entrevistador y piensas, cómo paso esta entrevista para conseguir un trabajo Creo que lo primero es que hay que practicar. Tienes que practicar antes de entrar a la entrevista. Te puedo decir eso por experiencia porque cada vez que practicas antes de tu entrevista, Tu entrevista siempre es mejor, siempre mejor porque has hecho tu investigación, te has entrenado, practicas, tu confianza está arriba. Una cosa en las entrevistas es que siempre hay que tener confianza. Siempre hay que tener confianza porque confianza es clave en cualquier cosa que hagas. Aunque digas algo equivocado, tienes que decir lo incorrecto como y lo dices muy bien. Si dices lo correcto y no hay confianza, tal vez ni siquiera obtengas esa posición. La confianza es como casi todo porque incluso podrías decir algo equivocado, pero con tanta confianza, déjame darle una oportunidad. Además, hay que tener la mentalidad de que estás dispuesto a aprender No solo dispuestos a aprender porque en QA o IT, su mayoría buscan personas con experiencia. Pero ellos quieren ver eso que quieres lanzar una manera que seas ingenioso No necesitas entrenamiento, no necesitas tutoría Podrías recoger cosas, podrías hacer rodar la pelota, esa mentalidad. Porque en QA, en TI, nadie no eres autogestionado. No te van a contratar. Aunque te van a decir un papel, pero no les va a gustar, tienes que hacer esto para hacer esto mañana. Porque te están pagando mucho dinero. No te están pagando mucho dinero para sentarte y esperar a que la gente te diga qué hacer. Tienes que ser el que esté montando reuniones, tienes que ser el que inicie. Esto es como si llamaras mucho tiro en tu espacio, en tu espacio Q way. Estás sentado con el desarrollador, estás probando, estás tratando de asegurarte de que el entorno esté listo. Entonces estás haciendo muchas cosas, estás siendo proactivo. Eso es lo que quieren ver. Quieres hablar de lo proactivo que eres. En términos de, no te sientas, que te digan qué hacer, te mueves. Configura reuniones, pruebas, haces esto, Tse las cosas que confian y siendo proactivo Esas cosas, de todas formas, quieres destacar eso a tu entrevistador Podrías dibujar experiencia en el pasado. Muchas preguntas del entrevistador van a ser qué haces en este escenario También las terminologías, las jergas de TI, como mencioné, otras, back-end testing front end, las fases SDLC, todas estas terminologías de TI, todas estas terminologías de TI, es algo con lo que quieres Se quiere entender lo que son. Ya sabes. También en cuanto a qué preguntas hacen. Sé que la pregunta típica siempre es decirme por ti mismo. Dime por ti mismo es una forma de exhibir para ti. No tienes que empezar a decir cosas irrelevantes, pero puedes mencionar que sabes lo proactivo, ya sabes, cómo haces las cosas relacionadas con ese puesto de trabajo Simplemente no dices nada. Ves todo lo que dices, tu proactividad, tu ingenio, tu comunicación está relacionada con A nadie le importa si hiciste algo en el pasado que no se relacione con lo que están buscando. Entonces cualquier cosa que puedas decir que te pueda acercar más a esa descripción del puesto, a lo que buscan. En realidad cuando quieren ver tu confianza, tu proactividad, tus habilidades de comunicación, otras cosas, todas esas cosas buenas relacionadas con tu puesto de trabajo También otra cosa nuestro consejo va en YouTube. Puedes ir en YouTube y puedes google en Q way preguntas de entrevista y cómo las respondieron. Creo que eso es básicamente el 70%. Quiero decir 70%, pero eso es mucho aparte de tu confianza y esas proactividad y comunicación. Ser capaz de saber responder a las preguntas. Verás mucho. Entonces voy a ser honesto contigo. Las preguntas de la entrevista de garantía de calidad son prácticamente estándar en todos los ámbitos. Entonces hay un par de preguntas que vas a escuchar todo el tiempo. Vas a escuchar un tipo específico de pregunta. TI. Las preguntas son siempre las mismas. Entonces, si solo vas a YouTube y solo gastas X cantidad de minutos u horas, escuchando las preguntas de la entrevista y cómo responden, y ahora estás pensando en cómo puedes responder también para conseguir un trabajo no va a ser difícil peal cuando tienes esa confianza porque las preguntas son iguales, iguales, iguales, iguales Entonces Google en YouTube, entrevista preguntas y respuestas, mira cómo responden esas preguntas, y mira cómo puedes dibujar de tu pase para responder esas preguntas. Te puedo garantizar que si miras no solo un YouTube, varios, ves las similitudes, la mayoría de las preguntas que están saliendo. Si te preparaste para ese tipo de preguntas, cómo puedes responder esas preguntas, tienes más posibilidades de que tu confianza consiga ese trabajo porque las preguntas de la entrevista son todas iguales. No es algo que en realidad va a ser algo que está totalmente fuera de la pelota, algo que es imaginario no. Las preguntas son preguntas estándar muy arenosas, y la mayor parte de la respuesta es siempre la misma. Pero siendo que no tienes tanta experiencia o esa experiencia, podrías sacar de tu pasado que se relacionará con esas respuestas a esas preguntas. Y cuando hablas con confianza, ya sabes, vas a poder ejecutar u obtener esa posición, ya sabes, porque la mayoría de las preguntas, como dije, son todas las mismas preguntas. Entonces solo hay que prepararse prepararse, prepararse para la entrevista, algunos confiados, ya conocen sus iones, conocen sus cosas, y ser capaces de ejecutar. Conoces esa sonrisa, muy importante, sonríe amable. No tienes que venir muy hostil, no. No tienes que poner esa sonrisa en tu cara que se acerque a ella porque una cosa buscan las entrevistas Aparte del conocimiento, aparte del conocimiento, Así que la intervención. Ella sabe o él sabe lo que está haciendo, posible que no den conferencias porque quieren gente que pueda encajar en su cultura. Entonces quieres ver que eres accesible, ya sabes, que eres, ya sabes, como eres una persona orientada al equipo, puedes trabajar en equipos Para que esa sonrisa sea agradable, ya sabes, también es muy importante en TI, porque vas a estar trabajando con mucha gente, y yo voy a estar trabajando con mucha gente bajo condiciones apretadas y estrés No estoy diciendo que sea tan estresante. Pero no te van a pagar por encima seis cifras para no estresarte o no hacer nada. Cuanto mayor sea la paga, más responsabilidades. Estas son como si estuvieras haciendo muchas responsabilidades. Interactuar con mucha gente. Estás probando, estás leyendo documentos. Todo esto es como que vas a estar trabajando con mucha gente. ¿Cómo es tu enfoque? ¿Quieren contratarte cuando vean que pueden trabajar contigo, no pueden sentirse cómodos trabajando contigo? Hay que demostrar que son muy agradables. Tienes que demostrar que están muy orientados al equipo, confianza, y proactivos, y también junto con capaces de responder esas preguntas de la entrevista. A veces incluso la entrevista cuestiona, aunque no tengas esa experiencia, pero tú ansite de una manera que a la entrevista le guste lo que oye Te gusta sacamos cosas de tu pasado que se relacionan con esa respuesta y tienes otras cosas funcionando para ti. Hay tantas cosas. Hay tantas cosas más que te hacen destacar. Aparte de la confianza, tu proactividad, tus habilidades agradables, tus habilidades orientadas al equipo y lo que estás diciendo Entonces hay tantas cosas. Y cuanto más no me desanimes que no quieras entrevistar, no pasas, siempre es como si hubiera múltiples posiciones de onda Q por ahí Entonces hay mucho. Debo decir que hay mucho, pero siguen llegando, y la industria también es competitiva. Pero no tengas miedo porque también hay gente que viene como tú. Hay gente que tiene muy poca o ninguna experiencia como tú mismo. Entonces, cuanto más sigas practicando y aprendiendo tus cosas, ya sabes, y también ese equipo o habilidades de alquiler habilidades interpersonales , esa buena sonrisa Ya sabes, esa sonrisa en tu cara, ya sabes, no duele, ser accesible porque la gente va a estar trabajando contigo Vas a estar trabajando con la gente. Entonces todo esto debería configurarte para poder prestar el trabajo de tus sueños. Entonces los veré chicos en el próximo capítulo. Voy a hablar de certificaciones. 34. Certificaciones: En este video, voy a estar hablando de certificaciones. Como ingeniero de aseguramiento de calidad, siempre es bueno tener certificaciones. Ahora cuando obtienes esas certificaciones, gente dice que las obtienes cuando ingresas porque va a ser más fácil para ti aprobar el examen porque tienes más conocimiento y las certificaciones pueden ser bastante No es barato. No solo querrás comenzar a gastar dinero cuando ni siquiera estés en, sino que también ayudan a tu estándar en tu currículum. Porque cuando ven que estás certificado, aunque no sea la N de BO, sino que es una ventaja añadida y también a tu crédito, porque quieres que te catifiquen Quieres sentir que quiero decir, tengo esto, soy un ingeniero certificado en aseguramiento de la calidad. Se siente bien. Por lo que obtener la certificación es muy importante en su área en aseguramiento de la calidad y en la TI porque a pesar de que sabe que a veces tenemos licenciatura, nuestra maestría es un doctorado en certificaciones de TI Ya sabes, mucha gente que cuando ingresas, cuando empiezas a trabajar en TI, entiendes que las certificaciones son muy importantes. Como, ya sabes, te hace sentir bien, te hace gustar, ya sabes, algo que logras, lograste, ¿verdad? Entonces aunque cuando lo pones en tu currículum, sí, ellos lo miran, por qué está bien, esta persona, ya sabes, tiene la certificación, pero también para que te guste, bien, soy un ingeniero certificado de aseguramiento de calidad. Hay m múltiples cuerpos que sí ofrecen certificaciones para ingenieros de Qway. Pongo la lista en línea para que vayas y mires, puedes investigar cuál quieres hacer. Cualquiera de ellos es bueno. Todos ellos son buenos para ti la mayor parte del tiempo, lo que deberías estar esperando porque como probador manual es la certificación de aseguramiento de calidad manual. No es necesario entrar en automatización. Pero si también estás muy familiarizado con la automatización, también hay certificaciones para ingenieros de automatización. Las pruebas manuales tienen las certificaciones para esos. Cuando te tomas eso Cualquier momento para ser honesto es increíble. Si puedes pagarlo, entonces si lees y lo entiendes, y eres capaz de aprobar la certificación. Hay una probabilidad muy alta puedas conseguir ese trabajo soñado porque todo lo que te van a pedir en el trabajo va a estar en esas certificaciones. Vas a la certificación cubrirá todas las preguntas de la entrevista. Si realmente puedes aprobar esa entrevista y esas certificaciones, tienes una mayor probabilidad de aprobar una entrevista. Al mismo tiempo, aún puedes conseguir ese trabajo soñado sin una certificación, y una vez que ingreses, eventualmente podrás obtener esa certificación. Pero de cualquier manera, en algún momento hay que recoger u obtener esa certificación. 35. Gracias: Gracias a todos por acompañarme en este viaje y en este proceso por poder totalizarlos en aseguramiento de la calidad. Fue un placer, ustedes viendo mi video, y estoy feliz y me alegro espero que ustedes hayan podido aprender una o dos cosas y prepararlos para el aseguramiento de la calidad. Ya sabes, solo tienes que creer en ti mismo, saber que lo tienes, ya sabes, ver los videos, si tienes alguna duda, ya sabes, puedes comentar a continuación, y definitivamente te responderé. Al igual que, estoy aquí para guiarte hacia conseguir ese trabajo soñado. Sabes, sí te expliqué mucho en detalle. Entonces ya sabes, muchos de los videos, mucho del mensaje que envié te expliqué es muy útil para conseguir ese trabajo soñado. Ya sabes, entonces estoy aquí, como si miras los videos y estás confundido en cualquier cosa, ya sabes, en cualquier material, ya sabes, solo envíame un mensaje. Sabes, estoy aquí para, ya sabes, guiarte en el proceso en el aterrizaje de esa posición. Ya sabes. Entonces cualquier duda que tengas, ya sabes, házmelo saber, creo en ustedes chicos, sé que ustedes lo entendieron. Ya sabes, tienes que poner en ese trabajo. Entonces, cuanto más pongas, más vas a salir en ese estándar. Entonces no solo haces las cosas pasivamente y solo, ya sabes, para que realmente estés viendo este video, en realidad tenías una intención, ¿verdad Tenías la intención de seguir esta carrera. Entonces simplemente no ves el video y no haces nada. Ves el video, vas a YouTube, preguntas de entrevista. Ya sabes, estudias el material. Así que muchos de los artefactos que te envié entienden todos esos artefactos, ya sabes, relacionados con lo que estoy diciendo en términos de lo que hace el aseguramiento de la calidad. Solo tienes relacionado con tu currículum, tus experiencias pasadas, tienes que rellenar el punto, tienes que crear tu historia, y tienes que estar bien informado También con todas las habilidades blandas que mencioné sobre tu confianza y personalidad y ser accesible Es un proceso y no estoy diciendo que sea fácil. No es fácil. Pero es un proceso y es un proceso que va a ser regado porque esto podría cambiar tu vida para siempre. Una vez que te metes como si estuvieras dentro, el mayor desafío es entrar y todavía tengo que apoyarte para entrar. Una vez que ingresas y pasas uno, dos años en QA, eres bueno. Podrías hacer la transición a otra cosa. Podrías hacer cualquier otra cosa que quieras hacer porque es todo el mismo SDL, todo es el mismo proceso El mayor reto es dar ese primer paso, comenzar, y creo que podemos empezar. Una vez tú estoy feliz de que seas capaz de ver este video. Ya sabes, una vez que miras, no termina aquí. No termina aquí. Hay que continuar con este proceso. Hay que continuar este viaje. Tienes alguna duda. Estoy aquí para responder Estoy aquí para apoyarte, y tienes que continuar. Ya sabes, tienes que seguir mejorando, aprendiendo más cosas, ya sabes, más conocedor, más práctica, práctica, práctica, te vuelves mejor, ya sabes, entonces ya sabes, tienes que ser intencional Y, ya sabes, estoy aquí para responder cualquier duda. Entonces si tienes alguna duda, ponte en contacto, y si nada más, gracias por unirte. Gracias por cuidar mi caso, y definitivamente estaré en contacto. Gracias por ver Buena suerte. Yo creo en ti y sé que lo tienes.