{"id":2073,"date":"2023-10-19T14:40:46","date_gmt":"2023-10-19T12:40:46","guid":{"rendered":"https:\/\/ittester.sk\/sin-categorizar\/ciclo-de-vida-defecto\/"},"modified":"2024-06-25T16:03:53","modified_gmt":"2024-06-25T14:03:53","slug":"ciclo-de-vida-defecto","status":"publish","type":"post","link":"https:\/\/ittester.sk\/es\/pruebas-manuales\/ciclo-de-vida-defecto\/","title":{"rendered":"Ciclo de vida del defecto"},"content":{"rendered":"\n<p>Esta gu\u00eda enumera las distintas fases del ciclo de vida del defecto por las que pasa.<\/p>\n\n<p>Un defecto es un error o equivocaci\u00f3n en una aplicaci\u00f3n que hace que el sistema se comporte de forma diferente a lo que exigen los requisitos. Encontrar fallos o errores de la aplicaci\u00f3n programada por los desarrolladores es el trabajo del equipo de pruebas.<\/p>\n\n<p>El equipo de pruebas se asegura de que se encuentran todos los errores antes de que la aplicaci\u00f3n salga al mercado o est\u00e9 disponible para los usuarios finales.<\/p>\n\n<h2 class=\"wp-block-heading\">\u00bfCu\u00e1l es el ciclo de vida de un fallo o defecto?<\/h2>\n\n<p>El ciclo de vida de un fallo o defecto es el movimiento de un fallo o defecto a trav\u00e9s de las distintas fases de su vida, desde el principio, cuando se identifica por primera vez, hasta el momento en que se marca como verificado y se cierra.<\/p>\n\n<p>Dependiendo de la herramienta de gesti\u00f3n de fallos utilizada (como Bugzilla, Jira, etc.) y de los procesos seguidos por la organizaci\u00f3n, podemos tener distintos estados, as\u00ed como distinta nomenclatura para los estados en el ciclo de vida de los fallos.<\/p>\n\n<p>El ciclo de vida del defecto incluye los siguientes recursos:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>Comprobador <\/strong>&#8211; para encontrar el error y volver a comprobar el error resuelto.<\/li>\n\n\n\n<li><strong>Jefe de Proyecto \/ Director de Proyecto \/ Jefe de Pruebas<\/strong> &#8211; Para verificar el fallo y asignarlo al desarrollador adecuado.<\/li>\n\n\n\n<li><strong>Desarrollador <\/strong>&#8211; Para resolver un error o defecto notificado por un probador.<\/li>\n<\/ul>\n\n<h2 class=\"wp-block-heading\">Ciclo de vida del defecto<\/h2>\n\n<p>A continuaci\u00f3n se indican las distintas fases del ciclo de vida del defecto:<\/p>\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"853\" src=\"https:\/\/ittester.sk\/wp-content\/uploads\/2023\/10\/zivotny-cyklus-chyby-1200-1000-2-1024x853.webp\" alt=\"Ciclo de vida de un defecto o fallo\" class=\"wp-image-553\" srcset=\"https:\/\/ittester.sk\/wp-content\/uploads\/2023\/10\/zivotny-cyklus-chyby-1200-1000-2-1024x853.webp 1024w, https:\/\/ittester.sk\/wp-content\/uploads\/2023\/10\/zivotny-cyklus-chyby-1200-1000-2-300x250.webp 300w, https:\/\/ittester.sk\/wp-content\/uploads\/2023\/10\/zivotny-cyklus-chyby-1200-1000-2-768x640.webp 768w, https:\/\/ittester.sk\/wp-content\/uploads\/2023\/10\/zivotny-cyklus-chyby-1200-1000-2.webp 1200w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption class=\"wp-element-caption\">Ciclo de vida de un defecto o fallo<\/figcaption><\/figure>\n\n<p><strong>Nuevo<\/strong><\/p>\n\n<p>Cuando el probador encuentre un nuevo fallo\/defecto, se publicar\u00e1 en el seguimiento de fallos con el estado \u00abNUEVO\u00bb. Se indicar\u00e1n los pasos para reproducir el error y la gravedad del mismo, junto con una explicaci\u00f3n del error.<\/p>\n\n<p><strong>Asignado<\/strong><\/p>\n\n<p>Cuando se informa de un nuevo fallo, el responsable o gestor correspondiente (jefe de proyecto\/director de proyecto\/director de pruebas) lo aprueba y asigna el fallo al desarrollador adecuado. Una vez asignado el fallo al desarrollador, su estado cambia a \u00abASIGNADO\u00bb. Cuando se asigna un error, tambi\u00e9n se asigna su prioridad.<\/p>\n\n<p><strong>Abre<\/strong><\/p>\n\n<p>A veces, en cuanto se asigna un error a alguien, \u00e9ste tiene un estado com\u00fan, es decir j. \u00abABIERTO\/ASIGNADO\u00bb. A veces los dos estados son diferentes, por ejemplo, un fallo est\u00e1 abierto pero sin asignar, o un fallo est\u00e1 asignado pero no abierto. Cuando se asigna un fallo a un desarrollador y \u00e9ste empieza a trabajar en \u00e9l, su estado cambia a \u00abABIERTO\u00bb.<\/p>\n\n<p><strong>Rechazado\/No es un error\/Desechado<\/strong><\/p>\n\n<p>Si el desarrollador o quien asigne el fallo\/defecto (jefe de proyecto\/l\u00edder de proyecto\/l\u00edder de pruebas) determina que el fallo no es v\u00e1lido, se le da el estado \u00abRECHAZADO\u00bb.<\/p>\n\n<p><strong>Diferido (Aplazado)<\/strong><\/p>\n\n<p>A veces, a un fallo\/defecto nuevo o asignado se le asigna el estado \u00abAplazado\u00bb en funci\u00f3n de la urgencia y criticidad del fallo. La correcci\u00f3n de un error diferido se retrasar\u00e1 durante un periodo de tiempo (para futuras versiones de la aplicaci\u00f3n).<\/p>\n\n<p><strong>Fijo\/En pruebas\/Completado<\/strong><\/p>\n\n<p>Cuando el desarrollador resuelve o arregla el fallo, su estado cambia a \u00abARREGLADO\u00bb y se asigna de nuevo al equipo de pruebas. Tras comprobarlo, si se resuelve, su estado cambia a \u00abVERIFICADO\u00bb, y si no se resuelve y el error persiste, su estado cambia a \u00abREABIERTO\u00bb.<\/p>\n\n<p><strong>Reabierto<\/strong><\/p>\n\n<p>Si el comprobador no est\u00e1 satisfecho de que se haya resuelto el problema, se asigna al error el estado \u00abREABIERTO\u00bb. De nuevo, el mismo ciclo de arreglar el fallo y asignarlo de nuevo al probador contin\u00faa hasta que el fallo est\u00e1 en estado \u00abCERRADO\u00bb.<\/p>\n\n<p><strong>Verificado (Verificado)<\/strong><\/p>\n\n<p>Si el comprobador considera que el error se ha resuelto tras la prueba, lo marcar\u00e1 como \u00abVERIFICADO\u00bb.<\/p>\n\n<p><strong>Cerrado<\/strong><\/p>\n\n<p>Una vez verificado el error, \u00e9ste pasa al estado \u00abCERRADO\u00bb.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>El ciclo de vida de un fallo o defecto es su movimiento a trav\u00e9s de las distintas etapas de su vida, desde la identificaci\u00f3n, hasta el marcado verificado y cerrado.<\/p>\n","protected":false},"author":8,"featured_media":2076,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[40],"tags":[],"class_list":["post-2073","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pruebas-manuales"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2073","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/comments?post=2073"}],"version-history":[{"count":1,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2073\/revisions"}],"predecessor-version":[{"id":2077,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2073\/revisions\/2077"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media\/2076"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media?parent=2073"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/categories?post=2073"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/tags?post=2073"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}