{"id":547,"date":"2023-10-19T14:40:46","date_gmt":"2023-10-19T12:40:46","guid":{"rendered":"https:\/\/ittester.sk\/automatisiertes-testen\/lebenszyklus-eines-defekts\/"},"modified":"2024-06-05T10:58:16","modified_gmt":"2024-06-05T08:58:16","slug":"lebenszyklus-fehler","status":"publish","type":"post","link":"https:\/\/ittester.sk\/de\/manuelles-testen\/lebenszyklus-fehler\/","title":{"rendered":"Lebenszyklus eines Defekts"},"content":{"rendered":"\n<p>In diesem Leitfaden sind die verschiedenen Phasen des Fehlerlebenszyklus aufgef\u00fchrt, die er durchl\u00e4uft.<\/p>\n\n<p>Ein Defekt ist ein Fehler oder Irrtum in einer Anwendung, der dazu f\u00fchrt, dass sich das System anders verh\u00e4lt, als es die Anforderungen vorsehen. Das Auffinden von Bugs oder Fehlern in der von den Entwicklern programmierten Anwendung ist die Aufgabe des Testteams.<\/p>\n\n<p>Das Testteam stellt sicher, dass alle Fehler gefunden werden, bevor die Anwendung in Betrieb geht oder den Endbenutzern zur Verf\u00fcgung steht.<\/p>\n\n<h2 class=\"wp-block-heading\">Wie sieht der Lebenszyklus eines Fehlers oder Defekts aus?<\/h2>\n\n<p>Der Lebenszyklus eines Fehlers oder Defekts ist die Bewegung eines Fehlers oder Defekts durch die verschiedenen Phasen seines Lebens, vom Beginn, wenn er zum ersten Mal identifiziert wird, bis zu dem Zeitpunkt, wenn er als verifiziert und geschlossen markiert wird.<\/p>\n\n<p>Je nach verwendetem Fehlerverwaltungsprogramm (z. B. Bugzilla, Jira usw.) und den von der Organisation befolgten Prozessen k\u00f6nnen wir verschiedene Zust\u00e4nde sowie eine unterschiedliche Nomenklatur f\u00fcr die Zust\u00e4nde im Fehlerlebenszyklus haben.<\/p>\n\n<p>Der Fehlerlebenszyklus umfasst die folgenden Ressourcen:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>Tester <\/strong>&#8211; um den Fehler zu finden und den behobenen Fehler erneut zu testen.<\/li>\n\n\n\n<li><strong>Projektleiter\/Projektmanager\/Testleiter<\/strong> &#8211; Um den Fehler zu \u00fcberpr\u00fcfen und ihn dem entsprechenden Entwickler zuzuweisen.<\/li>\n\n\n\n<li><strong>Entwickler <\/strong>&#8211; Um einen von einem Tester gemeldeten Fehler oder Defekt zu beheben.<\/li>\n<\/ul>\n\n<h2 class=\"wp-block-heading\">Lebenszyklus eines Defekts<\/h2>\n\n<p>Im Folgenden werden die verschiedenen Phasen des Fehlerlebenszyklus beschrieben:<\/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=\"Lebenszyklus eines Fehlers oder einer St&#xF6;rung\" 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\">Lebenszyklus eines Fehlers oder einer St\u00f6rung<\/figcaption><\/figure>\n\n<p><strong>Neu<\/strong><\/p>\n\n<p>Wenn der Tester einen neuen Fehler\/Mangel findet, wird er im Bugtracker mit dem Status &#8222;NEW&#8220; ver\u00f6ffentlicht. Die Schritte zur Reproduktion des Fehlers und der Schweregrad des Fehlers sind zusammen mit einer Erkl\u00e4rung des Fehlers anzugeben.<\/p>\n\n<p><strong>Zugewiesen<\/strong><\/p>\n\n<p>Wenn ein neuer Fehler gemeldet wird, genehmigt ihn der zust\u00e4ndige Leiter oder Manager (Projektleiter\/Projektmanager\/Testleiter) und weist den Fehler dem entsprechenden Entwickler zu. Nachdem der Fehler dem Entwickler zugewiesen wurde, \u00e4ndert sich sein Status auf &#8222;ASSIGNED&#8220;. Wenn ein Fehler zugewiesen wird, wird auch seine Priorit\u00e4t zugewiesen.<\/p>\n\n<p><strong>\u00d6ffnen Sie<\/strong><\/p>\n\n<p>Manchmal hat ein Fehler, sobald er jemandem zugewiesen wird, einen gemeinsamen Status, d.h. j. &#8222;OFFEN\/ZUGEORDNET&#8220;. Manchmal sind die beiden Zust\u00e4nde unterschiedlich, z. B. ist der Fehler offen, aber nicht zugewiesen, oder der Fehler ist zugewiesen, aber nicht offen. Wenn ein Fehler einem Entwickler zugewiesen wird und dieser mit der Arbeit daran beginnt, \u00e4ndert sich sein Status auf &#8222;OPEN&#8220;.<\/p>\n\n<p><strong>Abgelehnt\/Kein Fehler\/Abgelehnt<\/strong><\/p>\n\n<p>Wenn der Entwickler oder derjenige, der den Fehler\/Mangel zuweist (Projektmanager\/Projektleiter\/Testleiter), feststellt, dass der Fehler ung\u00fcltig ist, erh\u00e4lt der Fehler den Status &#8222;ZUR\u00dcCKGEWIESEN&#8220;.<\/p>\n\n<p><strong>Aufgeschoben (Aufgeschoben)<\/strong><\/p>\n\n<p>Manchmal wird einem neuen oder zugewiesenen Fehler\/Mangel der Status &#8222;DEFERRED&#8220; zugewiesen, je nach Dringlichkeit und Wichtigkeit des Fehlers. Die Behebung eines aufgeschobenen Fehlers wird f\u00fcr eine gewisse Zeit verz\u00f6gert (f\u00fcr zuk\u00fcnftige Versionen der Anwendung).<\/p>\n\n<p><strong>Behoben\/getestet\/abgeschlossen<\/strong><\/p>\n\n<p>Wenn der Fehler vom Entwickler gel\u00f6st oder behoben wurde, wird sein Status auf &#8222;FIXED&#8220; ge\u00e4ndert und er wird wieder dem Testteam zugewiesen. Nach der Pr\u00fcfung \u00e4ndert sich der Status auf &#8222;VERIFIED&#8220;, wenn der Fehler behoben ist, und auf &#8222;REOPENED&#8220;, wenn er nicht behoben ist und der Fehler weiterhin besteht.<\/p>\n\n<p><strong>Wiederer\u00f6ffnet<\/strong><\/p>\n\n<p>Ist der Pr\u00fcfer nicht davon \u00fcberzeugt, dass das Problem behoben ist, erh\u00e4lt der Fehler den Status &#8222;REOPENED&#8220;. Auch hier wird der gleiche Zyklus der Fehlerbehebung und der R\u00fcckgabe an den Tester fortgesetzt, bis der Fehler den Status &#8222;GESCHLOSSEN&#8220; hat.<\/p>\n\n<p><strong>Gepr\u00fcft (Gepr\u00fcft)<\/strong><\/p>\n\n<p>Wenn der Pr\u00fcfer der Meinung ist, dass der Fehler nach der Pr\u00fcfung behoben ist, markiert er ihn als &#8222;VERIFIED&#8220;.<\/p>\n\n<p><strong>Geschlossen<\/strong><\/p>\n\n<p>Nach der \u00dcberpr\u00fcfung des Fehlers wird der Fehler in den Zustand &#8222;GESCHLOSSEN&#8220; versetzt.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Der Lebenszyklus eines Fehlers oder Defekts ist seine Bewegung durch die verschiedenen Stadien seines Lebens, von der Identifizierung bis zur Markierung, die \u00fcberpr\u00fcft und geschlossen wird.<\/p>\n","protected":false},"author":8,"featured_media":1450,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[18],"tags":[],"class_list":["post-547","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-manuelles-testen"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/posts\/547","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/comments?post=547"}],"version-history":[{"count":7,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/posts\/547\/revisions"}],"predecessor-version":[{"id":997,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/posts\/547\/revisions\/997"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/media\/1450"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/media?parent=547"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/categories?post=547"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/de\/wp-json\/wp\/v2\/tags?post=547"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}