Como no me gustó el diagrama de flujo de la profe hice otro! Espero que les guste.
Introducción
Lo que aprenderás sobre los fundamentos de testing
Principios de las pruebas
¿Qué son las pruebas y por qué deberíamos hacerlas?
Proceso de pruebas del software y los estándares internacionales
Ciclo de vida del software
Proceso de pruebas del software: Calidad y Defectos
Principios del testing moderno
Especialidades del testing
Testing
Presupuesto, Recursos, Tiempo y Actividades Clave
Estrategia de pruebas
Testing en desarrollo de software
Testing ágil
Niveles de pruebas
Tipos de pruebas
Pruebas estáticas y dinámicas
Definición y diseño de pruebas
Gestión, monitoreo y control
Caja Blanca, Gris y Negra
Gestión, monitoreo y control: Monitoreo y Seguimiento
Roles y Responsabilidades
Roles y Responsabilidades en acción
Gestión de bugs
Ejercicios
Retrabajo
Sistema de seguimiento de bugs
Defectos y sugerencias
Depuración
¿Qué es la depuración?
Pruebas de verificación
Técnicas de depuración
Bases de la automatización de pruebas
Automatización de pruebas
Gherkin
Cierre del curso
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Blanca Moreno
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:
Preguntas a realizar para construir un proceso de gestión de bugs:
Aportes 69
Preguntas 7
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:
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.
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.
Se priorizan los bugs dependiendo su impacto.
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:
Cómo crear un proceso de gestión de bugs?
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:
¿Cómo crear un proceso de gestión de bugs?:
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:
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!
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
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.
Con esta clase y su diagrama entendí mucho mejor el retrabajo .
Sistema de seguimiento de Bugs
Algunas razones por las que aparecen los defectos:
Cómo crear un proceso de gestión de bugs?
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.
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:
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?