{"id":9548,"date":"2019-06-19T21:17:00","date_gmt":"2019-06-19T21:17:00","guid":{"rendered":"http:\/\/cl.abstracta.us\/blog\/?p=9548"},"modified":"2022-06-23T01:51:08","modified_gmt":"2022-06-23T01:51:08","slug":"ciclo-vida-bug-software","status":"publish","type":"post","link":"https:\/\/es.abstracta.us\/blog\/ciclo-vida-bug-software\/","title":{"rendered":"El error m\u00e1s com\u00fan en el ciclo de vida del bug"},"content":{"rendered":"\n

No pases por alto este paso clave al depurar el software.<\/h3>\n\n\n\n
\"\"
Foto de DenisDoukhan en Pixabay<\/em><\/figcaption><\/figure><\/div>\n\n\n\n

En nuestro planeta, el insecto Mayfly tiene uno de los ciclos de vida m\u00e1s cortos. Despu\u00e9s de la transici\u00f3n a la etapa adulta de su vida, generalmente se reproduce y luego muere en solo 30 minutos.\u00a0\u00bfQu\u00e9 pasar\u00eda si los bugs de software nacieran y se eliminaran de manera r\u00e1pida y f\u00e1cil?<\/p>\n\n\n\n

Cuando los testers y los desarrolladores trabajan juntos de manera efectiva, el per\u00edodo de tiempo desde la creaci\u00f3n de un incidente hasta su eliminaci\u00f3n en el software es m\u00ednimo. <\/p>\n\n\n\n

Aunque los bugs nunca pueden prevenirse al 100 % y el software nunca estar\u00e1 100% libre de errores<\/strong>, existen buenas pr\u00e1cticas que los equipos pueden adoptar para que los errores en el software vivan solo por un breve per\u00edodo de tiempo y nunca lleguen a multiplicarse.<\/p>\n\n\n\n

Un buen sistema de gesti\u00f3n de incidentes ayuda a garantizar que la mayor\u00eda de los bugs se encuentren y se solucionen mucho antes de pasar a producci\u00f3n.<\/strong><\/p>\n\n\n\n

Ciclo de vida del bug<\/strong><\/h2>\n\n\n\n
\"Ciclo<\/figure><\/div>\n\n\n\n

Este es un boceto b\u00e1sico que resume una de las formas posibles de representar el ciclo de vida de un bug, del que habl\u00e9 en nuestro e-book<\/a> de\u00a0automatizaci\u00f3n de pruebas funcionales.\u00a0En realidad, podr\u00eda haber miles de variaciones diferentes del ciclo de vida de un bug seg\u00fan el tama\u00f1o del equipo, la estructura organizativa, etc. pero, para nosotros, \u00a1este ciclo es b\u00e1sicamente una ley!<\/p>\n\n\n\n

\u00bfCu\u00e1les son los errores m\u00e1s comunes en la gesti\u00f3n de incidencias?<\/strong><\/h2>\n\n\n\n

Uno de los errores m\u00e1s t\u00edpicos en la gesti\u00f3n de errores que el equipo de Abstracta ha identificado al trabajar con diferentes empresas durante m\u00e1s de 14 a\u00f1os en entornos tradicionales y \u00e1giles, es cuando se corrige un bug y el desarrollador lo marca como cerrado.<\/p>\n\n\n\n

Sin embargo, no debemos olvidarnos de\u00a0verificar los\u00a0incidentes.\u00a0Primero, el tester lo informa y luego el desarrollador lo soluciona, pero la persona que finalmente debe determinar si se ha resuelto es el tester.<\/p>\n\n\n\n

\u00bfQu\u00e9 sucede si el desarrollador cree que se ha ido, pero despu\u00e9s de realizar m\u00e1s pruebas, todav\u00eda est\u00e1 all\u00ed? \u00bfQu\u00e9 sucede si se ha creado un nuevo error?<\/p>\n\n\n\n

Un tester de software siempre debe verificar que el fallo no exista para minimizar los riesgos<\/strong>.<\/p>\n\n\n\n

Variaciones del ciclo de vida de los bugs<\/strong><\/h2>\n\n\n\n

Hay otras variaciones que son v\u00e1lidas dentro de este entorno.\u00a0Por ejemplo, puede tener a alguien que tenga la responsabilidad de revisar los incidentes que surjan y decidir cu\u00e1les arreglar y cu\u00e1les no.<\/p>\n\n\n\n

Esta situaci\u00f3n podr\u00eda funcionar dentro del flujo anterior, ya sea el tester o el desarrollador que marque un error como “resuelto” o como “no se solucionar\u00e1”. O bien a trav\u00e9s de un acuerdo, el tester y el desarrollador podr\u00edan decidir cu\u00e1l es la opci\u00f3n adecuada con un mutuo acuerdo.<\/p>\n\n\n\n

En otro esquema, es posible que desee se\u00f1alar cu\u00e1ndo volver a abrir un incidente y qu\u00e9 sucede una vez que se vuelve a abrir. O bien, un error antiguo simplemente aparecer\u00eda como uno nuevo y comenzar\u00eda el ciclo de vida nuevamente.<\/p>\n\n\n\n

La gesti\u00f3n de incidentes es un indicador b\u00e1sico de la eficiencia de un equipo de desarrollo y, adem\u00e1s, es un \u00e1rea clave donde se puede ver si los testers y los desarrolladores se sienten parte del mismo equipo o no<\/strong>. Ambas partes deben hacer su parte para trabajar en equipo.<\/p>\n\n\n\n

No solo los desarrolladores deben trabajar para colaborar con los testers. Los testers por su parte, deben compartir una visi\u00f3n global centrada en los objetivos de todo el equipo y comprender que no todo se puede arreglar.<\/p>\n\n\n\n

Me encantar\u00eda escuchar tus comentarios respecto al ciclo de vida de los bugs y si sigues un esquema similar u otro que te resulte m\u00e1s \u00fatil o adecuado, as\u00ed como los problemas t\u00edpicos a los que te enfrentas, etc.<\/p>\n\n\n\n\n\n

\n\n\n\n

Otros contenidos relacionados<\/h3>\n\n\n\n

3 elementos esenciales para lanzar Software r\u00e1pidamente, sin afectar la Calidad<\/a><\/p>\n\n\n\n

Beneficios de Shift Left Testing en el Ciclo de Desarrollo de Software<\/a><\/p>\n\n\n\n

Software Testing Wheel<\/a><\/p>\n\n\n\n\n\n