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 61

Preguntas 5

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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.

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.

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.

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.

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

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

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鈥揂BIERTO鈥揂SIGNADO鈥揂RREGLADO鈥揅ERRADO

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

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?

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鈥

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. 鈥漇teps to reproduce鈥, 鈥淓nvironment/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.

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

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.

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
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!

Remember, programmers make mistakes:

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

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

Supongo que una buena pr谩ctica para el arreglo de bugs ser铆a SCRUM

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!!!

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.

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 鈥極pen 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.

Una de las mejores y mas actuales herramientas que he usado es esta https://dev.azure.com te permite tener todo en un solo lugar en todo el ciclo de desarrollo incluyendo pruebas y manejo de bugs.

Es free y de mucha utilidad.

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

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.

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?

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.

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

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.

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.

Siempre se debe considerar cierto tiempo 鈥渟uponiendo鈥 se presente alg煤n error para evitar atrasos en el proyecto.

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.

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.

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.

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

Muy interesante, sigo aprendiendo!!

驴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) :

鈥淓l t茅rmino 鈥渢riaje鈥 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?鈥

Muy interesante

Cuales apps recomiendan para esta gesti贸n de Bugs?

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.

Me toc贸 reportar muchas fallas y lo que vi que pasaba en general es que a veces faltaba m谩s detalle en los reportes de bugs.
Lo que fue muy 煤til fue tomar video o capturas de las fallas y entender bien el checklist de lo que necesitaban los desarrolladores para solucionar el problema.
Les dejo un art铆culo si quieren saber m谩s sobre esto.

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.

klk

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.

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

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.

Estaba viendo 鈥渋f鈥 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

Super

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 鈥渆fecto 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

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

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

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铆

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.