No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Sistema de seguimiento de bugs

22/29
Recursos

La mala administración, malas prácticas o falta de seguimiento entorpece las tareas de todo el equipo sino que además sumamos el retrabajo en la mala documentación puede que nuestro proyecto se salga de presupuesto o tiempo.

Razones por las que aparecen defectos:

  • Hay presión de tiempo en la entrega del software
  • Descuidos en el diseño
  • Inexperiencia o falta de conocimiento
  • Falta de comunicación en los requerimientos
  • Diseño complejo de código
  • Desconocimiento de las tecnologías usadas

Preguntas a realizar para construir un proceso de gestión de bugs:

  • ¿Qué debe de hacer la persona que encuentre el defecto?
  • ¿En qué herramienta debe documentar el defecto?
  • ¿Cómo vamos a almacenar la información?
  • ¿Qué información requiere el equipo de desarrollo para poder resolver un defecto?
  • ¿Cuáles son los estatus que se manejan para que fluya la resolución del defecto?
  • ¿Cuáles son los criterios de aceptación de cierre del defecto?

Aportes 69

Preguntas 7

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Como no me gustó el diagrama de flujo de la profe hice otro! Espero que les guste.

Lo que ha pasado a veces en mi trabajo es que en un requerimiento con 10 puntos para probar, llega uno a fallar y se devuelve al desarrollador, el programador lo arregla y lo devuelve al equipo de testing pero este punto que ajusto hace que otros puntos de la prueba falle y esto hace un retrabajo inmenso por que se debe volver a probar todo de nuevo y esperando que ninguno llegue a fallar.

Apuntes:

Sistema de seguimiento de bugs

Las malas administración o prácticas, las faltas de seguimiento no sólo entorpece las tareas del equipo, sino que, además, si sumamos el retrabajo, puede que el proyecto se salga de presupuesto y de tiempo.

Razones por las que aparecen defectos

• Hay presión de tiempo en la entrega del software
• Descuidos en el diseño
• Inexperiencia o falta de conocimiento
• Falta de comunicación en los requerimientos
• Diseño complejo de código
• Desconocimiento de las tecnologías usadas

¿Cómo crear un proceso de gestión de bugs?

¿Qué debe hacer la persona que encuentre un defecto?
¿En qué herramienta se debe documentar el defecto?
¿Cómo vamos a almacenar la información?
¿Qué información requiere el equipo de desarrollo para poder resolver un defecto?
¿Cuáles son los estatus que se manejan para que fluya la resolución del defecto?
¿Cuáles son los criterios de aceptación de cierre del defecto?

Repositorio y Monitoreo de Defectos

Una vez instaurado el proceso de gestión de bugs, también se debe precisar quién tiene acceso a los bugs y cuáles son los permisos que tiene, por cuánto tiempo se almacenan, etc.

Un proyecto interesante sería desarrollar una App, para instrumentar el Ciclo de Gestión expuesto por Blanca, desde luego apoyándose en GIT y GITHUB.

Bueno generalmente el proceso que aplico es el siguiente:

  1. Montar el proyecto que se va a probar, con todas las funcionalidades objetivo o ítems de pruebas, de tal forma que al momento de reportar algun bug sea mas facil y al final de cuentas me ayude a ver claramente que funcionalidades generaron mas bugs y demás.

  2. Defino/doy a conocer al equipo los estados por el que pasará un bug: Abierto, Asignado, en resolución, Resuelto, Cerrado. Luego de resuelto puede ser reabierto.

  3. Se priorizan los bugs dependiendo su impacto.

  4. Cuando se ha reportado un bug, se le hace seguimiento para su resolución.


Me ha sucedido lo que comentabas que los desarrolladores a veces no han solucionado un bug realmente y le dan solucionado y cuando se va a revisar, se presenta el problema nuevamente.

Creo que estaría excelente este curso si se llevara todo de la mano de uno o dos casos reales, con herramientas reales y bugs reales, dashboard real, etc… para tener más contexto de lo que se está enseñando y no sea mayormente abstracto.

Esto es desde el punto de vista de un estudiante que no tiene experiencia en la industria, más que las pequeñas pruebas que se hacen en los primeros cursos de Python por ejemplo 😂. Pero por eso mismo creo que nos sería más valioso para darnos un panorama de una empresa en particular, con un producto en particular, con un equipo, con un proceso de pruebas, con un bug…

Siempre me pasa que el Dev dice que en su ambiente si funciona, cuando lo llamo y hacemos el testing falla.

Gestión de bugs
Razones por las que aparecen defectos:

  • Hay presión de tiempo en la entrega del software
  • Descuidos en el diseño
  • Inexperiencia o falta de conocimiento
  • Falta de comunicación en los requerimientos
  • Diseño complejo de código
  • Desconocimiento de las tecnologías usadas

Cómo crear un proceso de gestión de bugs?

  • Qué debe de hacer la persona que encuentre un defecto?
  • En qué herramienta debe documentar el defecto?
  • Cómo vamos a almacenar la información?
  • Qué información requiere el equipo de desarrollo para poder resolver un defecto?
  • Cuales son los estatus que se manejan para que fluya la resolución del defecto?
    Cuales son los criterios de aceptación de cierre del defecto?

Repositorio y monitoreo de defectos
Una vez instaurado el proceso de gestión de bugs, también se debe precisar quién tiene acceso a los bugs y cuales son los permisos que tiene, por cuánto tiempo se almacenan, etc.

Un buen ciclo de gestion de bugs, debería contar con 5 pasos desde que se encuentra hasta que se soluciona. Estos pasos son:
Reportado -> Abierto -> Asignado -> Arreglado -> Cerrado

La mala administración, malas prácticas o falta de seguimiento entorpece las tareas de todo el equipo sino que además sumamos el retrabajo en la mala documentación puede que nuestro proyecto se salga de presupuesto o tiempo.

Razones por las que aparecen defectos:

Hay presión de tiempo en la entrega del software
Descuidos en el diseño
Inexperiencia o falta de conocimiento
Falta de comunicación en los requerimientos
Diseño complejo de código
Desconocimiento de las tecnologías usadas

Preguntas a realizar para construir un proceso de gestión de bugs:

¿Qué debe de hacer la persona que encuentre el defecto?
¿En qué herramienta debe documentar el defecto?
¿Cómo vamos a almacenar la información?
¿Qué información requiere el equipo de desarrollo para poder resolver un defecto?
¿Cuáles son los estatus que se manejan para que fluya la resolución del defecto?
¿Cuáles son los criterios de aceptación de cierre del defecto?

Este diagrama me ayudo a entender un poco mas, espero les ayude

Desde que estoy en ésta hermosa especialización de mi carrera, como QE, he aprendido mucho en el camino, pero algo que siempre rescato son éstas best practices del manejo de Bugs que se los quiero compartir.

RIGMEN
Reproducir/Replicate
Determinar lo necesario para reproducir el bug en cualquier momento que quieras demostrarlo o determinar si no es reproducible y describir los factores que podrían incrementar la probabilidad de que se reproduzca.
Atencion al detalle, estara dentro los camposdel bug report. ”Steps to reproduce”, “Environment/Requirements”
Isolar/isolate
Encuentre la menor serie de acciones necesarias para replicar el issue y comuníquelo de forma sencilla.
Generalizar/Generalize
Determine el rango de circunstancias en las que este bug causará un failure.
Maximizar/Maximize
Encontrar los síntomas más graves de este issue, esto define la severidad
Externalizar/Externalize
Considera las consecuencias del bug, como afectara al usuario, a la reputación de la compañía, empatía con el customer, client, Stakeholder, ver desde su perspectiva cuán importante es este bug.
Neutral Tone
Mantenga el informe basado en hechos o especulaciones de forma constructiva.
Evite criticar/irritar o insultar a las personas.

Si el programador corrige algo y en la etapa de pruebas se verifica que efectivamente se arreglo el bug pero empezaron a fallar otros procesos, los cuales ya estaban solucionados, ¿Como se podría tratar de evitar esos casos?

Para una buena gestión de bugs en 5 pasos
REPORTADO–ABIERTO–ASIGNADO–ARREGLADO–CERRADO

Me ha pasado que en algunas ocaciones, yo debo de explicarle a mis compañeros como buscar la ruta del error por ser el mas antiguo, pero esto me lleva mucho tiempo con cada uno. Aun no logro aplicar o explicar una ruta de análisis para que ellos mismos hagan la investigación sin mi ayuda, o que ya tengan la mitad del análisis antes de yo intervenir. Ayuda!!!

Lo que sucede al reportar un bug casi siempre se informa a nuestro lider de qa para saber a quien dirigir al equipo de trabajo de desarrollo y el nos de el tiempo de respuesta o la solución, se realiza el re-test del bug y se valida si se cierra o se deja en estado diferido a lo cual esta sujeto a la prioridad del proyecto con base a las entregas

Como herramientas de seguimiento he utilizado Mantis Bug Tracker que es una herramienta de libre uso, y en los últimos tiempos ya nos pasamos a JIRA.

Visual Studio es una buena herramienta para gestion de bugs. Así lo manejamos en nuestra empresa y nos funciona bastante bien 😃

Preguntas a realizar para construir un proceso de gestión de bugs:

¿Qué debe de hacer la persona que encuentre el defecto?
R/Reportarlo para que asi los demas tengan conocimiento del error y asi mismo sugerencias de como arreglarlo

¿En qué herramienta debe documentar el defecto?
R/se puede usar una herramienta opensourt o de paga las herramientas las de paga cuentas con mas habilidades para poder documentar tu error asi mismo saber quien lo esta ejecutando y cuando lo puede entregar tambien implementa la app completa y la monitoea asi mismo mostrando tods los errores del sistema y su respectivo progreso

¿Cómo vamos a almacenar la información?
R/se puede usar una herramienta llamada easiRedmi es de paga pero se puede probar por 14 dias

¿Qué información requiere el equipo de desarrollo para poder resolver un defecto?
R/El equipo requiere saber con que se estab trabjando que modulos estan conectados el tiempo estimado para resolverlo entre otros

¿Cuáles son los estatus que se manejan para que fluya la resolución del defecto?
R/Los estactus son 4 : Estan
*Reportado
*Abierto
*asignado
*Entregado
Eston son los cuatro estactus a seguir para resolver un bug

¿Cuáles son los criterios de aceptación de cierre del defecto?
R/Los criterios de aceptacion son aquellos q ya cuando se le realizan las pruebas se acepta o se indica que esta bien se le hacen el ultimo chaking para reverificar que este bien y se implementa a producion

Razones por las que aparecen defectos:

  • Hay presión de tiempo en la entrega del software
  • Descuidos en el diseño
  • Inexperiencia o falta de conocimiento
  • Falta de comunicación en los requerimientos
  • Diseño complejo de código
  • Desconocimiento de las tecnologías usadas

¿Cómo crear un proceso de gestión de bugs?:

  • ¿Qué debe de hacer la persona que encuentre un defecto?
  • ¿En qué herramienta debe documentar el defecto?
  • ¿Cómo vamos a almacenar la información?
  • ¿Qué información requiere el equipo de desarrollo para poder resolver un defecto?
  • Cuáles son los estatus que se manejan para que fluya la resolución del defecto?
  • ¿Cuáles son los criterios de aceptación de cierre del defecto?

Repositorio y monitoreo de bugs: Una vez instaurado el proceso de gestión de bugs, también se debe precisar quién tiene acceso a los bugs y cuales son los permisos que tiene, por cuánto tiempo se almacenan, etc.

Pueden darse casos en los bugs de integraciones en los que el problema pertenece a los equipos de desarrollo de ambos sistemas pero los equipos no se ponen de acuerdo y se pasan el defecto sin llegar a ningun acuerdo ni avance. En nuestro trabajo se coloca en status ‘Open Triage’ Y el bug es seguido por el Defect Manager que se asegura de que ambos equipos de los diferentes sistemas trabajen en conjunto para solucionarlo. Es algo que me ha pasado como tester par de veces en mi trabajo.

Supongo que una buena práctica para el arreglo de bugs sería SCRUM

Remember, programmers make mistakes:

  • Time pressure
  • Complex existing code
  • Complex infrastructure
  • Complex systems interactions
  • Misunderstanding of requirements
  • Incorrect requirements
  • Unexpected physical/environmental conditions

Razones por las que aparecen defectos:

Hay presión de tiempo en la entrega del software
Descuidos en el diseño
Inexperiencia o falta de conocimiento
Falta de comunicación en los requerimientos
Diseño complejo de código
Desconocimiento de las tecnologías usadas
Preguntas a realizar para construir un proceso de gestión de bugs:

¿Qué debe de hacer la persona que encuentre el defecto?
¿En qué herramienta debe documentar el defecto?
¿Cómo vamos a almacenar la información?
¿Qué información requiere el equipo de desarrollo para poder resolver un defecto?
¿Cuáles son los estatus que se manejan para que fluya la resolución del defecto?
¿Cuáles son los criterios de aceptación de cierre del defecto?

si que la gestión puede ser más sencilla y directa

Súper interesante esta clase!

Hola, en el utimo proyecto de pruebas con el cliente que trabaje se utilizaba Azure Test Plans, me paso una anecdota de que al probar un bug que habia sido resuelto, probandolo en ese mismo caso de prueba aparecio otro defecto en el flujo al que reporte pero la LT me dijo que porfavor no creara un nuevo ticket sino que lo volviera abrir. A mi parecer esto era un bug diferente e independiente pero insistia de que lo abriera de nuevo, la verdad el trabajo en equipo con lideres tecnicos como clientes fue un poco tedioso ya que algunos quieren imponer por encima del tester. Un aporte que quiero dejar es que el trabajar con herramientas como Azure Devops en test plans es super agil y eficienciente para reportar y hacer monitoreo, es una herramienta que toda empresa deberia de invertir.
Implementar un modelo de gestión como tester implica estructurar y sistematizar el proceso de pruebas de software para garantizar la calidad del producto final. Aquí te dejo una guía general sobre cómo hacerlo: ### 1. **Definir el Modelo de Gestión** * **Metodología de Pruebas:** Decide qué tipo de pruebas utilizarás (manuales, automatizadas, pruebas unitarias, de integración, de aceptación, etc.). * **Enfoque de Pruebas:** Define si seguirás metodologías ágiles (como Scrum) o más tradicionales (como el modelo en cascada). * **Herramientas:** Selecciona herramientas de gestión de pruebas y automatización, como JIRA, Selenium, TestRail, etc. ### 2. **Planificación y Documentación** * **Plan de Pruebas:** Crea un plan de pruebas detallado que incluya objetivos, alcance, criterios de entrada y salida, roles y responsabilidades, y cronograma. * **Casos de Prueba:** Documenta los casos de prueba basados en los requisitos del proyecto. Estos deben ser claros, concisos y cubrir todas las funcionalidades. ### 3. **Gestión de Requisitos** * **Trazabilidad:** Asegúrate de que cada caso de prueba esté vinculado a un requisito específico. Esto ayuda a garantizar que todos los requisitos se prueben adecuadamente. * **Revisión de Requisitos:** Participa en la revisión de requisitos para identificar posibles problemas desde el principio. ### 4. **Ejecución de Pruebas** * **Pruebas Manuales:** Ejecuta pruebas manuales según lo planificado, registrando todos los resultados. * **Pruebas Automatizadas:** Implementa pruebas automatizadas para las funcionalidades críticas y repetitivas. Asegúrate de mantener y actualizar estos scripts regularmente. * **Gestión de Defectos:** Registra, clasifica y prioriza los defectos encontrados. Utiliza herramientas de seguimiento para gestionar la resolución de estos. ### 5. **Monitoreo y Control** * **KPIs y Métricas:** Establece indicadores clave de rendimiento (KPIs) para medir la eficiencia del proceso de pruebas, como la tasa de defectos, la cobertura de pruebas y la efectividad de la automatización. * **Informes:** Genera informes regulares para el equipo y la gerencia, mostrando el estado de las pruebas, los defectos encontrados y el progreso hacia los objetivos del proyecto. ### 6. **Retroalimentación y Mejora Continua** * **Revisión Post-Mortem:** Después de cada ciclo de pruebas, realiza una revisión para identificar qué funcionó bien y qué podría mejorarse. * **Capacitación y Actualización:** Mantén al equipo de pruebas actualizado con las últimas prácticas, herramientas y tecnologías. ### 7. **Comunicación y Colaboración** * **Integración con el Equipo:** Trabaja de cerca con desarrolladores, analistas de negocios y otros stakeholders para asegurar que las pruebas estén alineadas con los objetivos del proyecto. * **Reuniones Diarias o Semanales:** Participa en reuniones de seguimiento (como stand-ups en entornos ágiles) para mantener a todos informados sobre el progreso y los obstáculos.

Cuales apps recomiendan para esta gestión de Bugs?

Super

La mala administración, malas prácticas o falta de seguimiento entorpece las tareas de todo el equipo sino que además sumamos el retrabajo en la mala documentación puede que nuestro proyecto se salga de presupuesto o tiempo.
Razones por as que aparecen defectos:
Hay presión de tiempo en la entrega del software
Descuidos en el diseño
Inexperiencia o falta de conocimiento
Falta de comunicación en los requerimientos
Diseño complejo de código
Desconocimiento de las tecnologías usadas
¿como crear un proceso de gestion de bugs?
¿Qué debe de hacer la persona que encuentre el defecto?
¿En qué herramienta debe documentar el defecto?
¿Cómo vamos a almacenar la información?
¿Qué información requiere el equipo de desarrollo para poder resolver un defecto?
¿Cuáles son los estatus que se manejan para que fluya la resolución del defecto?
¿Cuáles son los criterios de aceptación de cierre del defecto?
Repositorio y monitoreo de defectos
Una vez instaurado el proceso de gestion de bugs, tambien se debe precisar quien tiene acceso a los bugs y cuales son los permisos que tiene, por cuanto tiempo se almacenan, ect.

Para gestionar los errores se ha trabajado con Asana (Trello) en la cual se tiene listas o columnas de estados, por los cuales va a pasar el error hasta que se verifica que está entregada la corrección al usuario final, y ahí se le da por terminada.
En el caso de errores mal reportados porque son temas operativos, se regresan y no ingresan al flujo de corrección de desarrollo.

La gestion de bugs es un proceso muy importante que debe ser planeado y estructurado por cada una de las areas que intervinene o participan en el proyecto, esto con el fin de generar un proceso claro y preciso, donde todos aportes y se defina un protocolo y una cultura de cummplimiento.
Lo que sucede es que muchas veces se concoe la importante de la gestion de bugs pero se cae en la premura, el afan, la prioridad y hasta la irresponsabilidad, no se mantiene un orden en cada una de las fases e incluso de omiten actividades escenciales como por ejemplo las revisones o las pruebas unitarias.
A veces los lideres no son consientes de que mas que entregar un producto de forma rapida aun cliente es entregar un producto que si cumpla con los requerimientos a gran escala , no a la minima, pues se esta sujeto a que se presenten muchos bugs y el usuario final es quien lo persisve.
Muchas empresas comunican a voces que tiene muchas herramientas, personas caapcitadas y que cumplen con varios estandares de caldiad, pero tristemente dentro de los proyecto se evdiencia que poco provecho le sacan a las aplicaciones de gestion, las personas no reportan sus tareas, no cumplen con las actividades en los tiempos establecidos, todos documentan a su estilo y gusto, no existen evdiencia de los procesos e incluso no se generan procesod e retrospectiva con los equipos.
La gestion de bugs debe ser una cultura, algo que todas las personas deben procurar realziar sin importar el cargo, todo se debe basar en la respondabilidad yla organziacion de las tareas y actividades.

¿Cómo gestionar los bugs o errores del software?
Puede estar seguro de que todo desarrollador quiere ser el primero en conocer cualquier bug o error que resulte inconveniente para los usuarios, pero una pregunta esencial es ¿cómo distinguir entre los errores que los usuarios siempre encontrarán y los que probablemente nunca verán?

El primer paso es tomar la lista de errores de los testers o probadores y tener una reunión de triaje (triage en inglés) :

“El término “triaje” se tomó prestado del triaje médico donde un médico o enfermera tiene que priorizar la atención para un gran grupo de personas heridas. El trabajo principal de un equipo de triaje de bugs o errores de software es decidir qué errores deben corregirse (o, a la inversa, qué errores estamos dispuestos a liberar).

[Hay] cuatro preguntas que deben responderse durante el triage para decidir si un error se debe corregir o no:

Gravedad : cuando ocurre este error, ¿qué tan negativo es el impacto?
Frecuencia : ¿con qué frecuencia ocurre este error o bug?
Costo : ¿cuánto esfuerzo se requeriría para solucionar este bug?
Riesgo : ¿Cuál es el riesgo de corregir este error?”

para mi ese ciclo consistiría en nuevo, asignado, activo o rechazado, verificado y cerrado.

Me pasa mucho que reporto errores, y al solucionar este dañan muchas cosas que ya funcionaban lo cual genera mucho reproceso.

Cuando se trabaja en un issue es muy tentador querer arreglar un bug que esta en el camino pero fuera del issue. La teoría y la experiencia dicen que es mejor siempre reportarlo y hacer el proceso completo.

En mi experiencia he utilizado Jira para el seguimiento, haciendo una integración con HPE ALM como repositorio y monitoreo de defectos

Estaba viendo “if” por todos lados jaja.

Buenas tardes

Primero que todo tendría que estandarizar un determinado Bug Tracker como Mantis cuando se trata de pruebas manuales. Después para un equipo de trabajo estandarizar los diferentes estados que aplican por cada bug y por qué se pueden presentar esos estados y cómo se pueden gestionar hasta el cierre. Luego darles seguimiento a los bugs por medio de reuniones o revisiones pares para saber cómo gestionarlos.

Algo que me ha pasado muy frecuentemente es que se vuelve complejo documentar bugs que no se sabe si deben asignarse a los desarrolladores o al personal de operaciones o funcional del negocio.

Gracias

Una de las situaciones que en mi experiencia han surgido defectos, es por la forma en que se vende el proyecto, donde el cliente pide y exige más de los requisitos acordados, haciendo que hayan repercusiones en las fechas de las actividades, entregas o revisiones con el cliente.

En nuestro caso lo que hacen es esperar a que se termine todo el sistema y recién hacen la prueba uno es su propio tester en el camino lastimosamente, ya hasta el momento se implementó un estándar cosa de que al ingresar nuevas personas al equipo puedan entender como se trabaja

no tengo experiencia aún pero creo que la comunicación en equipo , y el trabajo responsable de cada miembro de éste es clave para evitar los errores y adversidades.

Siempre se debe considerar cierto tiempo “suponiendo” se presente algún error para evitar atrasos en el proyecto.

algo q me gustaría aportar, es que en alguna experiencia laboral al hacerle seguimiento de un bug, me tope con equipos que tenían fallas en sus flujos de integración y los cambios nuevos o los cambios de la resolución del bug, dañaban flujos o componentes que estaban bien o borraban resoluciones recientes. El problema era obvio, una mala practica de integración, pero el retrabajo fuerte que se hacia al momento de probar era inmenso.

Notion tiene plantillas para darle seguimiento a proyectos y bugs . Es una alternativa para cuando se va empezando y no se tiene presupuesto para un sistema de paga.

Con esta clase y su diagrama entendí mucho mejor el retrabajo .

Sistema de seguimiento de Bugs

Algunas razones por las que aparecen los defectos:

  • Hay presión de tiempo en la entrega del software
  • Descuidos en el diseño
  • Inexperiencia o falta de conocimiento
  • Falta de comunicación en los requerimientos
  • Diseño complejo de código
  • Desconocimiento de las tecnologías usadas
  • Rotación de personal sin personal capacitado.

Cómo crear un proceso de gestión de bugs?

  • Que debe de hacer la persona que encuentre un defecto?
  • En qué herramienta debe documentar el defecto?
  • Cómo vamos a almacenar la información?
  • Qué información requiere el equipo de desarrollo para poder resolver un defecto?
    Cuales son los estatus que se manejan para que fluya la resolución del defecto?
  • Cuales son los criterios de aceptación de cierre del defecto?

1.Llega la solicitud de revisión
2. se evidencia el error reportado en un ambiente de pruebas
3. Si no ocurre se rechaza
4. Si ocurre se asigna al ingeniero de producto
5. La ajusta y le devuelve
6. El analista de pruebas revisa el cambio
7. Si falla se devuelve al ingeniero de producto
8. Si no falla se pasa al cliente.

Pueda que lo más considerable a ralizar es que al momento de encontrar un bug documentarlo de la mejor forma posible, ser explicito donde esta la falla, creo que el pilar importante es la buena comunicación.
A mi me gustaría entender y practicar algún modelo de gestión, donde se pueda organizar y luego documentar bajo alguno norma de calidad. Siendo honesto, para mí es necesario desarrollar y poder pre desarrollar esto de manera eficiente y rápida. Donde se pueda comunicar de manera efectiva.
Yo ingrese a un proyecto que ya había avanzado a más de la mitad de su desarrollo, afortunadamente tenemos un buen PO y me basto con leer las descripciones de las historias de usuario y asistir a una reunión de refinamiento para acoplarme al proyecto y comenzar a diseñar y ejecutar pruebas.
REPORTADO.- Comentarlo con el lider de proyecto e identificar si es un bug que afecte completamente ose pueda minimiar \--ABIERTO-- que nos den el visto bueno que si es posible el bug por que como en la clase se comenta a veces no los toman como tal \--ASIGNADO-- Su nombr elo dice saber quien realizara la corrección del bug y tener ocmunicación constante \--ARREGLADO-- Solución del bug \--CERRADO-- nuevamente a pruebas con el bug resuelto

Se reporta un defecto:
• Pasa al equipo técnica, en donde se documento y se analiza a que área se va a enviar para solución
• El área encargada debe dar solución a dicho bugs, y pasar reporte de solución al equipo de prueba
• El equipo de prueba realiza pruebas de conformación y regresión, con el fin de verificar que estos cambios no afectan las funcionalidades del sistema
• Bugs arreglados
• Si el equipo de desarrollo insiste con el defecto, se convoca una reunión con le PM, y demás encargados, donde se expongan los argumentos y se realice en conceso la toma de decisión

En mi trabajo utilizamos planner para reportar bugs, lo bueno que planner te permite asignar la tarea a los desarrolladores, te permite tener en 3 estados la tarea, los clasifico con etiquetas. Tambien tienes un dasboards ver el avance de los bugs.

Un defecto es muy costoso en el ciclo de software, especialmente aquellos que se evidencian en ambientes productivos, ya que requieren de un flujo de estimación, replicación con pruebas, identificación del origen del problema, desarrollo y pruebas exploratorias en ambientes de pruebas. Debido a la premura, estos deben ser estimados en cortos tiempos de entrega. Para esto, se recomienda realizar un flujo aparte del plan normal de los features o historias.

Es el ciclo de gestión del bug es sencillo si el equipo sabe lo que debe de hacer pero cuando no hay un equipo que sigue las metodologías, se transforma en una pesadilla.

NOTA: Si un defecto es encontrado durante la ejecución del software, este puede producir un fallo.

Resulta que en mi anterior trabajo yo era el desarrollador y el tester de un proyecto heredado, me puse unos tiempos mortales para cualquiera haciendo esto solo y morí en el intento.

fin.

Muy interesante, sigo aprendiendo!!

Muy interesante

klk

Creo que la profa dice bien al momento de que entra una nueva persona al equipo, ya que siempre es importante que sepamos como funciona el software, de otra forma podemos cometer mas errores que arreglarlos

Leí una analogía muy graciosa en donde dice que hay bugs (errores en el software) que vuelven a aparecer o que se hacen mas fuertes incluso después de que se les haya puesto un parche o que se hayan arreglado. Se llama el “efecto pesticidas” o algo así y lo que quiere decir es que los bugs que sobreviven a los parches se harán mas fuertes, como pasa en la vida real con los insectos

Quizá falta un camino desde el diferido al rechazado debido a que puede ocurrir esa situación, ¿como se puede hacer mejor análisis de cada bug?
Lo digo por que si son 100 bugs la tarea del averiguar cuanto pesó cada uno en realidad es tediosa, ¿alguien sabe de una herramienta donde este seguimiento se pueda hacer?
Si decimos que cada flecha equivale a 1 punto estaríamos en teoría asumiendo que cada proceso toma el mismo tiempo y no necesariamente es así

Me pareció muy interesante que debemos enfocarnos en la tarea que se nos pidió porque a veces por intentar ayudar y arreglar algo que no se nos pidió se puede afectar la ruta de desarrollo y ser contraproducente

About testing:

  • it documents system behavior. The expected output of a function given an input can easily be seen through testing.
  • It can, sometimes, find errors that are not actively looked for, when (for example) a program crashes during execution of a test case. Many errors are found by running a test that are not in fact the goal of the test.