Otro gran video Ely. Dos correcciones: "Actual result" es resultado real (actual en castellano sería sería current en inglés) y "Workaround" no es atajo, es rodeo: evitar un inconveniente rodeándolo....
Oooh lo del Actual Result legalmente en castellano, en el mundo del Testing es "Resultado Actual" literalmente. y en mundo del testing en inglés, se le dice "Actual Result". Aquí no tiene nada que ver la traducción, sino la terminología del Testing. No existe nada como Resultado "Real" jaja eso no existe OJO con esto. Así que "Resultado Actual" es así en Español en el testing. y "Actual Result" es así en Inglés en el testing.
Hola!¡! Tengo una pregunta, cuando se encuentra un hallazgo, que no impacta el flujo, pero es algo como punto de mejora por así decirlo, ¿se debe de crear un issue de tipo defecto? ¿La nomenclatura para los hallazgos sería FINDING o todo lo manejo como DEFECT | US…?
Se llama Enhancement (sí la palabra es medio complicada, pero está en inglés, y es una palabra OFICIAL del lenguaje IT para los Testers). Se llama Enhancement a todo lo que son mejoras (bugs que no son bugs por así decirlo). Se suele levantar como un "Bug" pero con la etiqueta de "Enhancement" o "Mejora" si el proyecto está en español.
Gracias! Excelente video como siempre, dos preguntas, los bug generales son encontrados entonces mucho mas veces que los bug de defecto? 30% vs 70% ? Y mi otra duda, cuando dijiste que la prioridad la asigna el business analyst, quiere decir que nosotros creamos un bug sin asignarle una prioridad o con una prioridad por defecto y después esa persona cambia la prioridad o como sería?
Hola Feeerr!! Buenas preguntas! Mira: 1. El defecto es cuando hay una historia de usuario activa durante el Sprint y está fallando. Y el Bug es cuando falla una funcionalidad que no tiene una US activa sino cerrada, es decir una funcionalidad que se supone que debería funcionar. Pero en proyectos de bajo nivel suelen tratar todo como "Bug" así que bueeh. Jaja pero si te digo un aproximado desde mi punto de vista sobre qué se reporta más, diría que un defecto se reporta más. Es lo más probable. 2. Correcto! Exactamente lo que dices está OK ;) es lo que debería ser.
Puedes hablar de como debe ser esa comunicación con desarrollo, ya que me ellos ven el reporte en jira, entonces no se si se refiere como a enviarles un mensaje indicando que se reportó un bug nuevo para que lo revisen?
Literalmente es así! jaja 1. Descubre un Bug, 2. Analizas el Bug y te aseguras que es un Bug válido. 3. Reportas el Bug y se lo comentas al equipo de Dev
Hola una consulta. Entonces siempre primero vamos a ejecutar los TC. Si se tiene un defecto lo reportamos y de ahí yo hago un testing exploratorio para ir viendo si hay algún bug ? o eso normalmente en el entorno de trabajo me dirán si debo realizar la búsqueda independiende de un bug ?
No entendí mucho tu pregunta mi rey, pero para explicarte más sencillo el proceso es: Ellos implementan una funcionalidad "X", vos testeas esa funcionalidad "X", descrubres defectos, reportas el defecto, ellos lo analizan y lo arreglan, y vuelves a testear (re-testing) ese defecto para ver si está "arreglado", y tú cierras el bug.
Porque no puedes ni ejecutar ni DISEÑAR el caso de prueba, porque la funcionalidad falla. Por eso se coloca como bloqueante a ambos: TX y TS OJO, de todas formas este pequeño detalle no lo vas a ver en todos los proyectos! Es posible que donde trabajes se manejen de alguna forma, pero la base es la misma: Un Bug es un bloqueante siempre que afecte un avance.
Ely otra pregunta si estas haciendo esa US y te encontraste con el BUG de que en el Grand Total suma $100 de mas por cada item agregado, por que no lo reportaste ahi? Porque no tiene que ver directamente con la funcionalidad?
Excelente vista Maia! Creo que porque se trataba de un BUG y no de un DEFECT de mi Historia de Usuario. También porque iba a tomar mucho tiempo hacer el video jaja, así que fui directo a lo que necesitaban aprender del Defecto.
@@Saitest Genial!! Tenia esa duda con la US que estoy haciendo ahora, de borrar items del carrito. En si ese BUG no tiene que ver con la funcionalidad de borrar items, pero no sabia si lo debia reportar desde ese TX o reportarlo aparte, como un BUG. asique gracias!!!
Ojalá hubiera visto este video, antes de reportar el defecto que en contre como un Bug..ajaja, pero de los errores se aprende no?... Además le pifie horrible a la trazabilidad.XD😅😅
Banco esa song del Zelda!
Otro gran video Ely. Dos correcciones: "Actual result" es resultado real (actual en castellano sería sería current en inglés) y "Workaround" no es atajo, es rodeo: evitar un inconveniente rodeándolo....
Oooh lo del Actual Result legalmente en castellano, en el mundo del Testing es "Resultado Actual" literalmente.
y en mundo del testing en inglés, se le dice "Actual Result".
Aquí no tiene nada que ver la traducción, sino la terminología del Testing.
No existe nada como Resultado "Real" jaja eso no existe OJO con esto.
Así que "Resultado Actual" es así en Español en el testing. y "Actual Result" es así en Inglés en el testing.
Excelente videoo!! Gracias por compartir tus conocimientos, me ayudo un montón!!!
Un placer ayudar! :D
Hola!¡! Tengo una pregunta, cuando se encuentra un hallazgo, que no impacta el flujo, pero es algo como punto de mejora por así decirlo, ¿se debe de crear un issue de tipo defecto? ¿La nomenclatura para los hallazgos sería FINDING o todo lo manejo como DEFECT | US…?
Se llama Enhancement (sí la palabra es medio complicada, pero está en inglés, y es una palabra OFICIAL del lenguaje IT para los Testers).
Se llama Enhancement a todo lo que son mejoras (bugs que no son bugs por así decirlo). Se suele levantar como un "Bug" pero con la etiqueta de "Enhancement" o "Mejora" si el proyecto está en español.
@@Saitest gracias por la pronta respuesta, doc. La comenzaré a utilizar para los hallazgos 😊
Gracias! Excelente video como siempre, dos preguntas, los bug generales son encontrados entonces mucho mas veces que los bug de defecto? 30% vs 70% ? Y mi otra duda, cuando dijiste que la prioridad la asigna el business analyst, quiere decir que nosotros creamos un bug sin asignarle una prioridad o con una prioridad por defecto y después esa persona cambia la prioridad o como sería?
Hola Feeerr!! Buenas preguntas! Mira:
1. El defecto es cuando hay una historia de usuario activa durante el Sprint y está fallando. Y el Bug es cuando falla una funcionalidad que no tiene una US activa sino cerrada, es decir una funcionalidad que se supone que debería funcionar. Pero en proyectos de bajo nivel suelen tratar todo como "Bug" así que bueeh. Jaja pero si te digo un aproximado desde mi punto de vista sobre qué se reporta más, diría que un defecto se reporta más. Es lo más probable.
2. Correcto! Exactamente lo que dices está OK ;) es lo que debería ser.
@@Saitest Genial!!! Gracias, dudas despejadas, saludos!
Puedes hablar de como debe ser esa comunicación con desarrollo, ya que me ellos ven el reporte en jira, entonces no se si se refiere como a enviarles un mensaje indicando que se reportó un bug nuevo para que lo revisen?
Literalmente es así! jaja
1. Descubre un Bug,
2. Analizas el Bug y te aseguras que es un Bug válido.
3. Reportas el Bug y se lo comentas al equipo de Dev
Hola una consulta. Entonces siempre primero vamos a ejecutar los TC. Si se tiene un defecto lo reportamos y de ahí yo hago un testing exploratorio para ir viendo si hay algún bug ? o eso normalmente en el entorno de trabajo me dirán si debo realizar la búsqueda independiende de un bug ?
No entendí mucho tu pregunta mi rey, pero para explicarte más sencillo el proceso es:
Ellos implementan una funcionalidad "X", vos testeas esa funcionalidad "X", descrubres defectos, reportas el defecto, ellos lo analizan y lo arreglan, y vuelves a testear (re-testing) ese defecto para ver si está "arreglado", y tú cierras el bug.
En la estimación, el valor total no tenía que ser >= 9 (14:27) para ser Automatizado? o flashee , no recuerdo en que video mencionas jeje saludos
TAL CUAL jaja así suelo hacerlo como dices. Jajaj gracias rey! Espero los demás vean tu mensaje
Hola tengo una duda: al reportar un bug se crea una subtarea para re-testearlo ,por qué ahí no aparece la opción para crear el retest?
Hola mi rey! DEBERIA aparecer la opción de crear el subtask para el re-test execution... Estás trabajando en UPEX Sandbox?
Consulta, porque bloquea el set de pruebas?
Porque no puedes ni ejecutar ni DISEÑAR el caso de prueba, porque la funcionalidad falla. Por eso se coloca como bloqueante a ambos: TX y TS
OJO, de todas formas este pequeño detalle no lo vas a ver en todos los proyectos! Es posible que donde trabajes se manejen de alguna forma, pero la base es la misma: Un Bug es un bloqueante siempre que afecte un avance.
Ely otra pregunta si estas haciendo esa US y te encontraste con el BUG de que en el Grand Total suma $100 de mas por cada item agregado, por que no lo reportaste ahi? Porque no tiene que ver directamente con la funcionalidad?
Excelente vista Maia!
Creo que porque se trataba de un BUG y no de un DEFECT de mi Historia de Usuario.
También porque iba a tomar mucho tiempo hacer el video jaja, así que fui directo a lo que necesitaban aprender del Defecto.
@@Saitest Genial!! Tenia esa duda con la US que estoy haciendo ahora, de borrar items del carrito. En si ese BUG no tiene que ver con la funcionalidad de borrar items, pero no sabia si lo debia reportar desde ese TX o reportarlo aparte, como un BUG. asique gracias!!!
Ely por que no me aparece el sprint? me dice "ninguno"
Me avisas si te aparece el problema de nuevo!
@@Saitest si, me sigue apareciendo, no cambia al hacer click, sigue en "ninguno" lo pregunte en #consultas y me dijeron que lo deje asi
Ojalá hubiera visto este video, antes de reportar el defecto que en contre como un Bug..ajaja, pero de los errores se aprende no?... Además le pifie horrible a la trazabilidad.XD😅😅
Jajaja pasa mucho, pero para eso existe UPEX 🥰🥰 para que aprendas tranquilo de los tropiezos sin consecuencias